Add Stops across all of MDS #554
Comments
|
Tony Cruz from Long Beach CA mentioned on the Provider call today a use case related to this. The city defines preferred parking areas for events (temporary mobility hubs) and emails them to each provider a few days before the events. Thinks defining them with GeoJSON would work for the city. Another use case is in Louisville where they've setup stops in Policy to communicate spray painted scooter parking areas along a corridor. It's a hack right now with Stae and using some combination of when speed is 0 and the trip_end event. If Stops are added in Policy these can be defined here. Since Policy is currently not meant to be real time, he could then mass email the providers to say that the Policy feed has been updated, and they can ingest the parking locations digitally instead. |
|
The most straight-forward way I can think about implementing this would be just allowing an array of |
|
We will be discussing this tomorrow at our Joint Working Group meeting, so attend if you are interested. |
|
From the WG call yesterday. Vianova, Louisville, and LADOT have existing use cases for this. Note the city defines these stops and publishes the API. Stops can be physically or virtually created by the city and communicated via this API. Some cities already doing this with GIS files to providers. Also providers can define them and tell the city to be included in this API officially - cities need to approve these anyway. Can the 'user' rule type be used for this? Maybe but it's not clear enough and is meant to be for end user/rider consumption. Vianova has use cases in South America and Europe now. Maybe this can be added to Geography, as a type of geography, eg 'stop'. Per suggestion, Michael renamed this issue to have the solution be assumed to be in Policy. Discussion about making stops non-authenticated/public, just like Geography. |
|
Using cutouts is not the canonical way to identify drop zones. The way LA does them around Venice Beach is to have a Policy with two rules:
(1) a rule with the drop zones and a cap greater than zero
(2) a rule with the city limits (without cutouts) cap of zero
max
…On Sep 18, 2020, 12:39 PM -0700, Michael Schnuerle ***@***.***>, wrote:
From the WG call yesterday.
Vianova, Louisville, and LADOT have existing use cases for this.
Note the city defines these stops and publishes the API. Stops can be physically or virtually created by the city and communicated via this API. Some cities already doing this with GIS files to providers. Also providers can define them and tell the city to be included in this API officially - cities need to approve these anyway.
Can the 'user' rule type be used for this? Maybe but it's not clear enough and is meant to be for end user/rider consumption.
Vianova has use cases in South America and Europe now.
The idea is Enforceable Mobility Hubs.
2,700 hubs in Paris,
Has it 'working' with current MDS, but it's not elegant or understandable by providers,
Eg - mark an entire city as a no parking zone except for cutouts where mobility hubs are,
Want to instead define the hubs, not the areas that are not the hubs.
Maybe this can be added to Geography, as a type of geography, eg 'stop'.
Geography is intended to be generic, but this and other use cases may be a reason to add an enumerated 'type' field and an 'id' field to it to reference things from Geography.
Per suggestion, Michael renamed this issue to have the solution be assumed to be in Policy.
Was previously 'Add Stops to Policy.'
Discussion about making stops non-authenticated/public, just like Geography.
Maybe, but consider privacy, eg device IDs.
Device IDs could only be returned if the feed is authenticated, but left out when public.
Check GBFS - add fields like theirs, what is the overlap?
Here is their 'station_information' endpoint, similar to Stops.
And their 'geofencing_zones' endpoint, similar to Policy.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
Would anyone who thinks this proposal is of high value to them like to make a PR for this to get ball rolling on the implementation details? Alternatively, we can flesh out the details here and then make a PR. We'd need to move it along soon to have time to review and include in the 1.1.0 release. |
|
@tybaltspark per your comment in #557, would you like to try a PR here to for getting Stops into Policy and all of MDS? I'm also thinking of a |
|
Hi @schnuerle , this is Jack with Vianova Our proposal is adding an This allows us to directly address the "mobility hubs" use-case that Brussels wants to implement. The rule is to only allow parking in mobility hubs while within the city border would be stated as: By permitting both "stops" and "geographies" in "exclusions", one may attach meaning to an exclusion, or fall-back to a plain geography otherwise. Additionally, by making an explicit distinction between the top-level geographies and the exclusion geographies, one can naturally create more intricate policies like "forbid parking in NeighborhoodA excluding these 5 mobility hubs, but allow parking everywhere outside NeighborhoodA" This is an improvement over "geographies with cutouts" since the explicit presentation is more natural, and is semantically richer (e.g., stop information). This is also an improvement over layering multiple, contradictory rules like
, since rule 1 would contain spurious infractions while vehicles are complying with rule 2. Exclusions are also useful across any geographically-constrained rule, and the logic for checking for infraction is simple:
This logic for CONTAINED can be compacted into a single geographical check:
What are your thoughts? We can certainly get started on a proposal PR if this is suitable. |
|
@jackdreillyvia I don't think this is the ticket for discussing this sort of change to Policy. But also, your "contradictory" example is not a good one. The way you would structure this is
These are not "contradictory". This is how Policy is fundamentally meant to work. I still have yet to see an example where exclusions are necessary. |
|
Does anyone want to take on a PR for this idea for inclusion in 1.1.0? We've got about 2 weeks of development time left before features that are not complete and have consensus may be moved to the next release. |
|
Hi, 5 cent.. We have to implement a scenario where a city want to define a big "no parking" zone and many (50+) small "parking" zones within that big zone. We will probably implement this using the "Order of operations" as mentioned here, ex:
Probably there will be a last rule as well defining the outer municipality boundary
My first thought about the proposed solution by @jackdreillyvia regarding "exclusions" is that this seems to specific, unnecessary and not generic enough. That being said, it could be my understanding of their scenario is not good enough. Internally we have used a property called priority on all zones, which solves all our problems when it comes to overlapping zones. This can be directly translated to the policy api via the "Order of operations". |
|
@fractalf Yes, using Rule order-of-operations as you describe is exactly how parking zones are intended to be implemented. The municipal boundary is what the Jurisdiction API is intended for. :) Also you can just have an "INFO" policy for that if you don't need to measure against it. |
You mention two terms I've not yet encountered reading the docs.
I'm asking 'cause I want to get my implementation right the first time :) |
|
@Karcass @Retzoh Thanks for the clarification regarding Rule Order of Operations. While your advice is clear, would you mind explaining the interpretation that Henri gives on the mds-city-services mailing list?
The above exchange seems to conclude that holes are necessary, since rules do not have the capacity to permit behavior, only disallow behavior. In other words, your interpretation permits rule-searching to terminate at the first matching rule (whether the rule allows OR disallows behavior), while Henri's interpretation only permits rule-searching to terminate on a disallowing rule. Am I misunderstanding something, or is there a disagreement in the two interpretations discussed? |
|
Addressing specifically the title of this issue (separate from the holes vs. not holes discussion above), I'd like feedback on the following proposal for linking Stops with Policies: The core use case seems to be creating counting rules that reference the properties of a One solution to this duplication-problem is to add a
This connection allows cities the convenience of having tightly-bound relationships between In general, our clients would find this rule useful: the ability to tie policies directly to the properties of specific stops. Besides this proposal (linking capacity directly to a stop), it appears that |
|
@jackdreillyvia: the @Retzoh interpretation is not correct. A Rule can absolutely "permit" something (e.g. a count rule with a minimum of 0 and no maximum), followed by another rule that forbids something (e.g a count rule with a maximum of 0). But this ticket is still not the best place to discuss it. :) |
Sorry, I've read the Policy API spec doc up and down many times now, even searching for the string info, but just can't see any concept of "Info Policy". What am I missing? This is the document you are refeering to right? https://github.com/openmobilityfoundation/mobility-data-specification/tree/main/policy @jackdreillyvia |
|
Wow, I'm sorry @fractalf. I was mis-remembering, I was thinking of the |
Apologies for that, I just noticed your request now. I've edited out identifiable information from the email. |
|
Based on this discussion, what are some proposals people have for modifying Policy or other parts of MDS so that stops can be communicated via Policy from the city? Question, can stops be defined with a rule using trip_end states (and speed=0) with point or polygon geographies? Throwing in a $1 rate subsidy example with it. This is how Louisville is handling this now. If this is good it should be added to the examples. If this not accurate, then what needs to be changed to communicate a stop? What would your edits be to this example? It's almost as if rule_type is irrelevant (optional?) for this 'Stops' purpose. You just want a rule to refer to a geometry for a trip end status. This is where I think a change is needed to more clearly support stops. Eg, a rule_type called "stop"? I think @jackdreillyvia is getting at this a bit here but in a different way, and I'm not sure a It also seems a bit counter intuitive to make it relevant on the 'available' state, though I realize that's where trip_end is. You want to encourage people who are on_trip to take this action, not after their trip is over. And that affects the |
|
@schnuerle The main use-case we have with cities is in defining geographical regions where vehicles must be parked. For this purpose, it's not strictly necessary to use stops, just geographies. From the prior discussions above w/ @Karcass it appears sufficient to implement our use-case with 2 rules:
As a counter-argument to your example of rule-types being irrelevant for stops-related policies, it's evident that our policy would actually leverage Admittedly, my proposal above was meant to serve as a straw-man to understand what are the specific requirements that others need from stops in policies. Since a stop is just a geography w/ additional properties, it's hard to ascertain use-cases where stops are strictly necessary to specify a rule, thus the proposal to make a link between stop-capacity and policy-max-count. But this link may be too implicit and more confusing than helpful. So we're keen to hear others' ideas on what is the best way to evolve the specification. |
|
Following up on our conversation in the meeting last night, I give an example policy which dictates, within the downtown region, parking of scooters and bicycles must take place within specific geographies. {
"name": "Test City Mobility Hubs",
"description": "Enforced parking in specific mobility hubs for downtown area",
"policy_id": "99f7a469-6e3a-4981-9313-c2f6c0bbd5ce",
"start_date": 1558389669540,
"end_date": null,
"published_date": 1558389669540,
"prev_policies": null,
"rules": [
{
"name": "Allow parking in specific locations",
"rule_id": "8a61de66-d9fa-4cba-a38d-5d948e2373fe",
"minimum": 0,
"rule_type": "count",
"rule_units": "devices",
"geographies": [
"e3ed0a0e-61d3-4887-8b6a-4af4f3769c14",
"1512a3f4-313c-45fc-9fae-0dca6d7ab355"
],
"states": {
"available": ["trip_end"]
},
"vehicle_types": ["bicycle", "scooter"]
},
{
"name": "Disallow parking elsewhere in downtown area",
"rule_id": "0240899e-a8ad-4263-953a-6e278ff859ab",
"rule_type": "count",
"maximum": 0,
"rule_units": "devices",
"geographies": ["075a5303-2571-4ca5-b429-841bcc4025d1"],
"states": {
"available": ["trip_end"]
},
"vehicle_types": ["bicycle", "scooter"]
}
]
} |
|
That's how I'd do it. ;). Although you could also omit the |
Thanks, I've included your suggestion above |
|
FYI @jackdreillyvia I added your example to this branch. |
|
This feature was pulled for this release, but we can discuss for next release in a larger context. |
|
We will be talking about this on today's working group call. Please join if you can. |
|
See meeting minutes here. There are three main use cases for stops
The discussion for this issue is aligned to use case number 2. It may be that the way Policy works now, we don't need to modify it to more explicitly support a 'Stop' concept. |
|
Implemented with PR #603 in MDS 1.1.0. |
Is your feature request related to a problem? Please describe.
Stops has been added to Agency and Provider as a new beta feature in 1.0.0, but is not a part of Policy yet.
Describe the solution you'd like
Add a way to specify Stops so they can be used by Policy, so that cities can geographically define and communicate details around docking stations, charing stations, parking locations, corrals, etc.
Is this a breaking change
Impacted Spec
For which spec is this feature being requested?
policyDescribe alternatives you've considered
N/A
Additional context
This is a requested addition that was not ready for the 1.0.0 release.
The text was updated successfully, but these errors were encountered: