profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/jiffyclub/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
Matt Davis jiffyclub @populus-ai Bay Area, California http://penandpants.com

jiffyclub/cext23 36

Examples of Python C extensions that work on Python 2 and 3

jiffyclub/2015-07-06-scipy 14

Software Carpentry Workshop at SciPy 2015

jiffyclub/dc-python-meetup-nov-2012 14

Material for the Number Crunching in Python workshop.

ivanov/ipython-trainingwheels 4

A beginner student friendly profile for IPython notebook

abostroem/2014-09-10-LBL 3

LBL Lab Day 2014

jiffyclub/advent-of-code 1

Advent of Code

startedjiffyclub/palettable

started time in 6 hours

startedjiffyclub/snakeviz

started time in 8 hours

startedjiffyclub/palettable

started time in 15 hours

issue commentopenmobilityfoundation/mobility-data-specification

[Policy API] support parking fees by duration

@karcass suggested a possible solution in #632 but after speaking with my engineers they don't think it's very clear that this is a duration based policy. I would prefer to include rate_duration instead of trying to bend the current fields. Using the current fields in a way that they weren't intended requires a lot of familiarity with the Policy API to understand.

jean-populus

comment created time in 17 hours

issue commentopenmobilityfoundation/mobility-data-specification

[Policy API] support one-time fee after a buffer/duration

The solution you outlined above could then also be applied to my other issue #631 pretty easily.

jean-populus

comment created time in a day

issue commentopenmobilityfoundation/mobility-data-specification

[Policy API] support one-time fee after a buffer/duration

Yeah, I think having a rule_type = rate is tripping me up. Why can't we just apply a rate_amount and rate_recurrence to all the rules instead of having a separate "rate" rule?

jean-populus

comment created time in a day

issue commentopenmobilityfoundation/mobility-data-specification

[Policy API] support one-time fee after a buffer/duration

So the semantics of having a fee on Rule types other than rate is currently ambiguous but easily fixed. I believe we can simply document the way you can apply a rate_amount to a time rule.

jean-populus

comment created time in a day

issue commentopenmobilityfoundation/mobility-data-specification

[Policy API] support one-time fee after a buffer/duration

I'm not sure I follow. Based on the examples, I thought for a one-time fee the variables would be

  • rule_type = rate
  • rule_units = amount
  • rate_amount = user entered
  • rate_recurrence = once
  • states = available, non-operational

Where does time come in? Should the rule_units = days with min = user entered buffer/duration?

jean-populus

comment created time in a day

issue commentopenmobilityfoundation/mobility-data-specification

[Policy API] support one-time fee after a buffer/duration

That's easy with the current Policy. Two Rules. One for less-than-duration and one for more-than-duration.

jean-populus

comment created time in a day

issue openedopenmobilityfoundation/mobility-data-specification

[Policy API] support one-time fee after a buffer/duration

Is your feature request related to a problem? Please describe.

Cities would like to implement a fee if a parked vehicle isn't moved after for example 2 days. This is a one time fee but there's a buffer/duration before it applies.

Describe the solution you'd like

I'm not sure. We could add a new field for this buffer/duration before the rate is applicable?

Is this a breaking change

No, I don't think so as this concept doesn't currently exist.

Impacted Spec

For which spec is this feature being requested?

  • policy

Describe alternatives you've considered

Additional context

created time in a day

issue commentopenmobilityfoundation/mobility-data-specification

[Policy API] support parking fees by duration

I think this can be implemented with Policy as-is via multiple Rules. I will read the details and confirm.

jean-populus

comment created time in a day

issue openedopenmobilityfoundation/mobility-data-specification

[Policy] support parking fees by duration

Is your feature request related to a problem? Please describe.

Some cities have implemented fees where the rate varies by how long the vehicle is parked. This is to encourage operators to move vehicles.

Describe the solution you'd like

Proposals for extending MDS Policy API -

  • add new field for rate_duration, similar to what's in CurbLR for payments
  • allow for arrays in rate_amount and rate_duration so we don't have to create new rules to accommodate the different rates by duration

Is this a breaking change

No? Because this concept doesn't currently exist in Policy so this would be additive.

Impacted Spec

For which spec is this feature being requested?

  • policy

Describe alternatives you've considered

No other viable alternatives.

Additional context

See Omaha's permit, Exhibit B

created time in a day

pull request commentopenmobilityfoundation/mobility-data-specification

Align propulsion_types in provider/status_changes spec and .ReadMe

Thank you for the feedback @ezmckinn. A few issues with the proposal:

First and foremost, any changes to the JSON Schemas need to originate in the templates and/or generator code, which are found under the schema/ directory. The schema files sitting in top-level agency/, provider/ etc. directories are generated files and should not be edited directly.

These proposed changes were made against the common definitions; the actual status_changes schema is a few more lines down and (correctly) references the propulsion_types definition, matching the README: here in the list of required properties and here in the properties.

We split "item" and "array" definitions in a few other places, including UUID/UUID array, vehicle_type/vehicle_types, vehicle_event/vehicle_events ... again these are all in the definitions, to be composed by the schema generator code into the actual schemas in various ways.

Can you give a little more context about the trouble you were having validating your Provider feeds? We may need to update these definitions! Some clarity around the issues would help us target the right place to make the updates (templates, generators, etc.)

ezmckinn

comment created time in a day

PR opened ActivitySim/activitysim

Document input files for MTC TM1 example

This adds documentation for all the fields and codes in the MTC TM1 input files, based on reading constants.yml and the Bay Area Metro data dictionaries. If any of these codes have changed for the ActivitySim implementation of TM1, these could be incorrect - but they seem to match up.

I based this on the develop2 branch since that seems to be where development is occurring, but I can change the base if that's not correct.

+181 -20

0 comment

1 changed file

pr created time in a day

GollumEvent

issue commentActivitySim/activitysim

Skim Dictionary Lookup Fails in Estimation Mode

This issue occurred on the develop2 branch running PSRC's MAZ-based model.

bricegnichols

comment created time in 2 days

issue openedActivitySim/activitysim

Skim Dictionary Lookup Fails in Estimation Mode

When checking for bad indices, the following assertion fails when reading survey data that contains -1 values:

https://github.com/ActivitySim/activitysim/blob/master/activitysim/core/skim_dictionary.py#L244

I don't really understand the implications, but I bypassed the issue by allowing -1 as a valid value:

in_skim = (mapped_orig >= -1) & (mapped_orig < self.omx_shape[0]) & \
                  (mapped_dest >= -1) & (mapped_dest < self.omx_shape[1])

created time in 2 days

Pull request review commentopenmobilityfoundation/mobility-data-specification

Align propulsion_types in provider/status_changes spec and .ReadMe

         }       }     },-    "propulsion_type": {-      "$id": "#/definitions/propulsion_type",+    "propulsion_types": {+      "$id": "#/definitions/propulsion_types",       "type": "string",
      "type": "array",
ezmckinn

comment created time in 2 days

pull request commentopenmobilityfoundation/mobility-data-specification

Align propulsion_types in provider/status_changes spec and .ReadMe

CLA assistant check <br/>Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.<br/><sub>You have signed the CLA already but the status is still pending? Let us recheck it.</sub>

ezmckinn

comment created time in 2 days

PR opened openmobilityfoundation/mobility-data-specification

Align propulsion_types in provider/status_changes spec and .ReadMe

name: Emmett McKinney about: Suggest changes to MDS title: Aligning "propulsion_types" in provider/status_changes spec with ReadMe.


Explain pull request

The ReadMe for provider/status_changes.json 1.0.0 and the spec appear to conflict on the deprecated 'propulsion_type' field. We suggest renaming the propulsion_type object to propulsion_types (i.e., adding an 's'), replacing the $id reference with an enum[], and removing the existing propulsion_types object.

Is this a breaking change

Yes, breaking

  • Yes, breaking
  • No, not breaking
  • I'm not sure

Impacted Spec

  • agency
  • provider

Additional context

The competing fields begin at Line 127 of provider/status_changes.json and Line 138, respectively. This caused some confusion for us while validating our Provider feeds.

+5 -14

0 comment

1 changed file

pr created time in 2 days

GollumEvent
GollumEvent
GollumEvent
GollumEvent
GollumEvent
GollumEvent
GollumEvent
GollumEvent
GollumEvent