Closed jyeo17 closed 1 year ago
Yes this is problematic from the operator side. The point of having a standard is that consumers can build a standard implementation that works everywhere. In this case operators need to build logic into their ingest that is specific to the endpoint they are ingesting from, and manage that logic alongside the rest of their integration, keeping it updated as aggregators make changes.
In general the more degrees of freedom allowed for "agencies" the more complex the operator implementations will become.
The plan is for the MDS WG to write some consensus-driven guidance mapping use-cases to how that use case should canonically be implemented.
For point 2 Populus doesn't have strong feelings for having one type of rules versus another. It would not be difficult for us to adapt to whatever the group consensus turns out to be.
@quicklywilliam, @S-eb your thoughts on this?
I wonder if it would be best to add some sort of "prohibited" rule type, rather than implying something is prohibited via a count or time? This might be a lot more intuitive/explicit and evidently covers several major use cases.
The plan is for the MDS WG to write some consensus-driven guidance mapping use-cases to how that use case should canonically be implemented.
Yes @marie-x this is why the issue is posted here, to support this consensus
For point 2 Populus doesn't have strong feelings for having one type of rules versus another. It would not be difficult for us to adapt to whatever the group consensus turns out to be.
@quicklywilliam, @S-eb your thoughts on this?
@jean-populus similar state of mind. We are open to adapt if required. Now there’s difference between rules types so might be interesting to discuss which rule type fit best a given use case
Great you bring this up, @jyeo17 !
Imho, (and as we implement in DB Curbside Management), I see different aspects which the regulation focuses on, resulting in the different rule types:
time
, with the extreme of "not allowed" (duration = 0)speed
, with the extreme of "no riding" (speed = 0)count
, with the extreme of "no offering allowed" (count = 0). Of course, usually availability of a vehicle is defined by "a vehicle is parked", but the difference to parking is that a potential violation addresses not a particular vehicle, but the whole fleet. When violating a count
rule, this is only evaluated once per rule (aggregating all vehicles inside the geographies referred to in the rule) and thus creates only max. one compliance violation. Think about a count > 0, say max. 500 vehicles in an operating area. If it's 501, which would be the one to violate the rule? Even more weird: If you had min. 200 vehicles agreed between city and provider but only 199 are parked or rented, which is the one missing 😬 ?Thus, for DB Curbside Management (which is not on your list (yet) ;) )
Rule | DB Curbside | |
---|---|---|
1 | Operating Area | Count |
2 | No Riding | Speed |
3 | No Parking | Time |
4a | Allowed Parking | Time |
4b | Required min. parking vehicles of a provider in Region | Count |
Thank you all for your comments and input. From the previous working group, it seems like there is a general concensus that:
So, by specifying the definitions of the use cases, we have the recommendations below:
While I unserstand that speed
is a difficult thing since it's telemetry and not event based, I don't quite understand how something related to time (something you can measure looking at your watch) can relate to the process of riding.
Outside in the real world:tm: , "riding" is defined by "something is moving" and movement is something you measure by determining its speed.
@jyeo17 Can you shed some light which time
(value and unit) would be used to define "no riding"? How is this different from "no parking" ?
@mrsimpson Thanks a lot for your comment!
Here our understanding of “time’ is amount of time spent by a device in a given state. A No Parking rule would result in allowing no more than 0 minutes in the ‘available’ status in a given geography. A No riding zone would result in allowing no more than 0 minutes in the ‘on_trip’ status in a given geography. Does this make sense?
The above table is really helpful and I think the interpretations given are very reasonable. That said, I agree with @mrsimpson that using time
to cover a No Ride Zone is very unintuitive. And I think it's an orange flag that we are leaving so much up to our differing interpretations. I don't think you should have to read detailed documentation to understand such a basic, common Policy use case.
My suggestion is that we take this opportunity to make the Policy API more explicit and use-case driven, such as adding a prohibited
rule type. The current implementation is derived from the original design goal of having everything be 100% interpretable via an abstracted state machine interpreter. That goal hasn't matched up with how Policy is used IRL, where implementations can differ greatly and interpretation is often done by humans.
We will be discussing this at tomorrow's working group meeting.
@S-eb sorry for taking so long to respond – it took me a while to clear my ~throat~ fingers in order to respond kindly to your question without sounding rude (which we Germans are said to tend to do ;) )
Does this make sense?
After two days of picking my words carefully, I'd kindly reply "that depends how you look at it".
If you mean "Is this a change for the better and does it make policies easier to interpret" I'd say "hell no!" ;) Currently, the rule rules have feature a rule_type
which classifies them. This classification relates to the aspect which shall be governed. I do think it's strange that the same rule type may refer to different vehicle states
– and equally may make only sende in combination with a particular state (speed
would only apply to the vehicle state on_trip
).
If you mean "Can we utilize the unit time
and the vehicle states to express how long a particular vehicle moves within a city" I'd agree: That makes some sense. Are there other ways to express the same: I do think that describing which aspect of a vehicle utilization shall be regulated is much better since the vehicle state would be generally independent from the rule type, but may be used to further specify particular rules.
I do think we really have to decide about the target audience of an mds policy document.
rule type
). Then, we'd ... well also need the written specification to include real world use cases and their mappings to the technical representation so that developers of compliance-checking services can code it equally.I hope I could make sense with writing that – it's a bit tricky for me as a non-native writer to find the right words, but I tried my best.
@schnuerle I'll take your statement as an invitation and will try to attend tomorrow's meeting
I'd like to take a step back and see if we have consensus on the Use Case Definitions in https://github.com/openmobilityfoundation/mobility-data-specification/issues/764#issuecomment-1129963329 because this will inform our thinking on speed vs time and using prohibitive rules.
Are the Use Case Definitions how most municipalities and providers are interpreting these rules? In particular No Parking means Vehicles should not be in the area regardless of status.
We will be talking about this at this week's MDS meeting.
We discussed in our development team what is really the problem that different applications map use cases differently into rules. Our finding was that the engine that interprets the rules has no problem at all with the different mappings: A compliance processor can quite easily evaluate whether a vehicle has violated maximum speeds, stop times, or if a fleet has violated counts based on the transmitted telemetry. Rather, the problem lies in the comprehensibility by a human. Therefore, we questioned whether it might not make more sense to leave the API as it is currently designed (optimized for machine-to-machine) and introduce a second interface that focuses on human authoring. Ideally, a library could then also be provided as a referential implementation that realizes this mapping between use case and policy.
So it seems like we have consensus on everything except for the No Ride rule.
For the No Ride the description should be broadened to be -
Vehicles should not be in the area.
Which covers the two use cases discussed during the call
If we want to have just a single rule_type
, that means for the options -
speed
cannot be applied to both use casestime
was considered not intuitiveSo that leave count
as the best option for a No Ride rule. Any thoughts on the recommendation to use count
as the rule_type
for a No Ride area?
Lacuna is (for now) using count
, although we used to use speed
. We had to change our compliance measurement mechanisms to include telemetry, but that seems to be working well. It also means that we can't adjudicate violations in real-time in LA, because telemetry is delayed by up to 24h for privacy reasons.
I still can't understand how one can count the process of riding: Riding something is a process (movement over time), it can be measured as speed. What would be counted? What would a "count" rule for a no riding look like? And how would it be differentiated from a no-operating-area for a particular provider (which is obviously a very different thing to regulate)? Can you please elaborate on that?
In the call, a representative of an operator (William?) also brought up the fact that preventing a ride is technically sanctioned on the vehicle => Speed rules would be deployed to the vehicle so it can safely reduce the speed (at most to 0) when entering a no ride area. To me, this is a very strong pro for implementing "no ride" as speed.
That leaves the issue that speed does not address that the vehicle should also not be parked (bullet point 2. on @jean-populus 's list). I strongly recommend that this is expressed as a second rule (of rule type time, max 0s
): This rule would then be naturally be deployed to the operator's app making it impossible to terminate the rent within this rule.
Any objections on this approach?
You can count vehicles that are on_trip
to count the process of riding. This works in most cases as trip telemetry and speed isn't usually measured in real-time.
Parking in a No Ride zone isn't how the majority of cities are implementing this policy so I recommend we use count
for No Ride policies as the primary implementation and include an alternative option for speed
when parking isn't part of the policy.
After all these discussions, it seems like the agreement that we have come to is:
Resolved with #786
After investigation of the 11 use cases on https://github.com/openmobilityfoundation/mobility-data-specification/issues/752, we have found that amongst the different companies (Ride Report, Populus, Vianova, Blue Systems), different rule types are used for the Operating Area/ No Riding and No Parking/ Required Parking policies.
This poses the question to operators if