-
Notifications
You must be signed in to change notification settings - Fork 232
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Policy API] Add multi-modal support to Policy #614
Comments
I like the idea of a new |
Could be related to some of the ideas here: #574 |
We will be discussing this topic at tomorrow's Working Group meeting. |
Notes from the public working group meeting:
|
The City and Provider Working Group Steering Committees met last week for the Midway Checkpoint for the 1.2.0 proposed release. The Checkpoint let them review feature proposals, align current work to goals, and ensure the release features and work is on track. For this work, we have created a new rubric to help guide the evaluation, looking at feature utility, stakeholder adoption, implementation simplicity, direction consensus, and work completed as part of the evaluation criteria. The outcomes and actions from these discussions are summarized here:
|
This is part of a larger discussion on how to specify new modes in MDS: #652 |
In addition to Policy: In Agency we would propose that the optional For Provider, you'd need For the root of the spec, we would need to enumerate the Also does anyone prefer a different word, like |
I'm not loving the word because it doesn't match up with the concept "mode of transport", which is closer to "vehicle type". It seems like here we are wanting to differentiate types of businesses, or lines of business. Maybe something along those lines? |
There is no PR for this yet, correct? I'm unsure how to add this in a way that won't conflict with the larger idea of Modes we are planning on working on for 2.0.0. But I'm willing to be convinced otherwise. Will there be an enumerated list of modes, or up to the agency to create? 'modality' might work a bit better here as the word to use, instead of 'mode'. But I agree with @jiffyclub it's not clear to me what to call this, since it's more like an agency's set of rules that apply to an operating program, permit program, policy, service type, etc. |
Can you get a PR made for this before Thursday's WG meeting, @marie-x? We are at the end of the 1.2 release now. |
I think that this should be paused while we go through @jfh01's multi-modal review. |
We do now have an 'mode' field in Policy to specify which mode the rule applies to. Also been added to multiple endpoints as part of the modes work. I don't think there is more to do on this for 2.0 but let me know if I am wrong about that. |
Is your feature request related to a problem? Please describe.
Policy objects are matched with vehicles by their
vehicle_type
,propulsion_type
,vehicle_state
, and optionally theevent_type
that put them into that state. This is sufficient with today's single MDS mode (micromobility). Other modes are on the horizon, including bus, taxi, delivery vehicles, carshare, and so on, and they will have new mode-specific states. Disambiguating based onvehicle_type
will not be sufficient, because (for example) a vehicle of typecar
could be a taxi or it could be a carshare vehicle.We should be able to start reasoning about how we can expand Policy to encode other transportation modes, even as those other modes are being defined.
Describe the solution you'd like
Adding a
mode
field at the Policy level would be required, plus some language requiring that thestates
used in eachRule
would have to match the particular mode type.Is this a breaking change
Impacted Spec
For which spec is this feature being requested?
policy
for sureagency
maybeprovider
maybeMode information might be fully inferred from the Provider, and in that case modification to Agency and Provider might not be necessary.
Describe alternatives you've considered
I am not yet making a specific proposal, just flagging the issue for consideration.
Additional context
None at present
The text was updated successfully, but these errors were encountered: