Examples of Python C extensions that work on Python 2 and 3
Software Carpentry Workshop at SciPy 2015
jiffyclub/dc-python-meetup-nov-2012 14
Material for the Number Crunching in Python workshop.
jiffyclub/2015-03-18-sfpython-project-night 5
LBL Lab Day 2014
ivanov/ipython-trainingwheels 4
A beginner student friendly profile for IPython notebook
LBL Lab Day 2014
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.
comment created time in 17 hours
issue commentopenmobilityfoundation/mobility-data-specification
[Policy API] support one-time fee after a buffer/duration
thank you @karcass
comment created time in a day
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.
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?
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.
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?
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.
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.
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
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.)
comment created time in a day
PR opened ActivitySim/activitysim
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.
pr created time in a day
issue commentActivitySim/activitysim
Skim Dictionary Lookup Fails in Estimation Mode
This issue occurred on the develop2 branch running PSRC's MAZ-based model.
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",
comment created time in 2 days
pull request commentopenmobilityfoundation/mobility-data-specification
Align propulsion_types in provider/status_changes spec and .ReadMe
<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>
comment created time in 2 days
PR opened openmobilityfoundation/mobility-data-specification
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.
pr created time in 2 days