@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.

thank you @karcass

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

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?

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.

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?

That's easy with the current Policy. Two Rules. One for less-than-duration and one for more-than-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

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

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

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.)

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.

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

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])

      "type": "array",

<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/>_{You have signed the CLA already but the status is still pending? Let us recheck it.}

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.