Web conference notes, 2022.05.26 (MDS Working Group)
MDS Working Group
- Every other Thursday at 9am PT, 12pm ET, 5/6pm CET
Zoom Registration Link: https://us02web.zoom.us/meeting/register/tZAscOmhpjIuHNakPx6CNbACpjUjw1Gsucr4
One tap mobile: +19294362866,,84170989462#,,,,*612987# US (New York) - though we encourage Zoom
Note: Attendees register upon entry into the Zoom meeting. An attendee count will be posted here after the meeting:
22 attendees
Main Topics
- Kickoff - Steve Brining, Blue Systems (5 mins)
- Rethinking the use of ‘Unknown’ state
- Unification
- Policy: defining standard rule types
WGSC Meeting Organizers
- Host: Steve Brining, Blue Systems
- Facilitator: Michael Schnuerle, OMF
- Outreach: Michael Schnuerle, OMF
- Note taker: Alex Demisch, SFMTA
Unknown
- Jay Williams - create an issue around standardizing usage of "unknown" state
- Jean Kao - create an issue around whether "unknown" should be counted in the PROW
- continue discussion around lookback period
- how "unknown" or a vehicle heartbeat could provide clarification and guidance on this
- what standardization/recommendation does MDS want to provide
Unification
- OMF - Reach out to cities (including Oslo) that use both Provider and Agency to understand their use cases and leave comments
- leave comments on what you think the solution should be
- create pull requests about an idea you think is good for review and discussion
Policy Rules
- get agreement on use case definition
- continue discussion on time/speed/count recommendations
- flesh out recommendations on GitHub regarding Policy rule type implementation and request feedback.
- create examples using recommendations
Rethinking the use of 'Unknown' state
- Most aggregators/cities use a 'lookback' period to determine whether or not a vehicle should be counted -- if we haven't received any status changes for a given vehicle in X days, then we stop counting it. This is less than ideal because the lookback period isn't standardized, involves assumptions that aren’t always true, and the last event state must also be considered to determine whether or not it is in PROW. Additionally, the 'unknown' state along with the 'missing' event type was introduced to explicitly address uncertainty about state, but implementation hasn’t been standardized across operators.
JK: Not sure what’s going on if they don’t hear from a vehicle in a while.
-
Trying to standardize lookback
-
First idea was a heartbeat
-
Second idea proposed by Bird around how we use the unknown vehicle state
-
-
There are two concerns: (1) policy concern about how long are operators allowed to leave them in the unknown state and must be investigated/removed from PROW, and (2) the technical concern about how long ambiguity is allowed.
Jay Williams with Bird > original proposal of Unknown for MDS 1.0
-
Didn’t do a good enough job explaining it
-
Can agree after a certain time, ok to take out of PROW
-
Saying issue isn’t standard across cities
-
Suggesting a transition called “missing”
- So PROW states count in PROW all the time
-
It is difficult for cities to enforce how operators implement MDS and the 'unknown' state.
-
One option is to define a recommended lookback period (which could be communicated via MDS Policy or Requirements), and cities can choose to modify it if needed.
-
One option is to specify that as soon as operators have not heard from a vehicle, it must go into the 'unknown' state. This likely involves a recommendation for a lookback period. Cities can then define how long they are allowed to be in that state, which is more of a policy decision that should be left to cities anyhow.
-
The vehicles endpoint can also be used to count vehicles. This is simpler because it does not involve going through the history of events. This still requires consensus over how the 'unknown' state is implemented.
-
'Unknown' is not always explicitly in or out of PROW. If a vehicle goes into the 'unknown' state due to lost comms only to come back with comms restored, then it was always in the PROW. The event type that explains the 'unknown' state must be considered.
MD: How long to wait before reporting a vehicle as lost comms?
- Just because you haven’t heard from it doesn’t mean it’s off the street
AD: I like the idea of using the vehicles endpoint to count devices, but don't we still need to have consensus over how 'unknown' is implemented?
- WH: @alex yep! just making the case that we need an unknown state (and an explicit incentive for operators to put it in that state in a timely way)
JW: wants clarification > they use lost comms for shorter interruptions. Why can’t you use the state and the transition.
- WH: complicated, but should be up to city, not a technical implementation question
JK: hearing 3 issues
-
Standardizing the use of unknown
-
Is unknown in the PROW
-
Idea of lookback periods > once unknown better defined, possibly can be used.
Agency/Provider Unification
-
Not a lot of feedback on the four options Marie proposed. If there isn’t broad consensus that this is important, then we do not have to push it forward. However, some people just need time to digest this topic.
-
One comment on GitHub proposes a fifth option that adds telemetries to Provider and trips to Agency. This makes both APIs symmetrical. Data can be provided in real time via Agency, while still allowing historical data to be pulled later via Provider. However, this requires both APIs to be implemented.
-
It is difficult to work with data from both Provider and Agency because the data model is different for some items. E.g., telemetry vs status changes, and trips present in Provider but not Agency. If the data models were the same across both, then it would be easier to use them because the downstream processing could be the same and yield the same results.
-
We need to consider how to made MDS easier to implement. Agency and Provider serve different use cases.
-
Some cities like Oslo use both Provider and Agency. We need to learn more about how/why.
WH: Option 1 feels like a half-step. I'm a bit torn on whether that's a good thing or a bad thing
- WG could propose an option 6
Policy: defining standard rule types
-
There are multiple ways to express the same rule. Goal of this issue is to have the top use cases for Policy and creating a standard/recommended way to implement them in Policy.
-
The Policy Task Force has a list of top use cases – we should flesh out recommendations for implementation on GitHub for review/comment.
-
We can also bring this issue to the Technology Council for guidance.
OJ: Have you discussed having a rule type of no-go zone within MDS
-
MS: I think we talked about this before
-
WH: @Oliver i suggested that as well
-
MM: original intention was to not directly map the use cases
-
On no-fly zones, could use several ways to express
-
Seems to be bad news that operators might not know.
-
-
MS: Oliver I see now that you are @mrsimpson in the comments. Thanks for attending!
-
WH: IMO it's a tension between the original design goals and the actual use of MDS in practice today
-
Oliver Jägle to Everyone (12:02 PM)
-
I’m a software engineer and it’s my first time joining this meeting. Therefore, quick intro: I’m working for Deutsche Bahn (public railway company in Germany) and I’ll probably keep quiet for today until we cross the topic of rule-types ;)
-
Steve Brining to Everyone (12:03 PM)
-
Peter Panov (Lacuna) to Everyone (12:03 PM)
-
Hello Oliver!
-
Sharada strasmore (DDOT) to Everyone (12:04 PM)
-
Wooot! Indy sounds fun!
-
Oliver Jägle to Everyone (12:04 PM)
-
…with the scooter...
-
Sharada strasmore (DDOT) to Everyone (12:06 PM)
-
DB is a great train system! I loved the great app and booking system when I was in Germany.
-
Welcome Oliver!
-
Me to Everyone (12:06 PM)
-
Welcome Oliver
-
Cami Cabrera to Everyone (12:06 PM)
-
Welcome Oliver
-
Me to Everyone (12:09 PM)
-
First issue: https://github.com/openmobilityfoundation/mobility-data-specification/issues/749
-
William Henderson (ceo @ Ride Report, he/him) to Everyone (12:15 PM)
-
Who should be in charge of whether a vehicle in a weird state is considered in the PROW?
-
Sharada strasmore (DDOT) to Everyone (12:24 PM)
-
@michael, standardized look back period with the chance to opt out?
-
William Henderson (ceo @ Ride Report, he/him) to Everyone (12:25 PM)
-
opt out = look back period is 0 (uknown vehicles immediately dont count)?
-
its not clear that is shouldnt count
-
some cities, in some areas, will want it to count
-
Alex Demisch (SFMTA) to Everyone (12:30 PM)
-
I like the idea of using the vehicles endpoint to count devices, but don't we still need to have consensus over how 'unknown' is implemented?
-
William Henderson (ceo @ Ride Report, he/him) to Everyone (12:31 PM)
-
@alex yep! just making the case that we need an unknown state (and an explicit incentive for operators to put it in that state in a timely way)
-
im saying we replace the "look back” period with a Policy object where it's a time limit for vehicles in the uknown state
-
and we have a suggested default
-
Jay Williams (Bird) to Everyone (12:35 PM)
-
I get that, and I kind of like it, just trying to wrap up the discussion for now 🙂
-
William Henderson (ceo @ Ride Report, he/him) to Everyone (12:35 PM)
-
👍🏻
-
Thank you Jay!
-
Steve Brining, Blue Systems to Everyone (12:38 PM)
-
Matt Davis (Populus, he/him) to Everyone (12:38 PM)
-
https://docs.google.com/document/d/134DrPFjSpapW1auTT2M_BuL2E9tdO1At0yu6VII1cPA/edit#
-
Me to Everyone (12:39 PM)
-
Steve Brining, Blue Systems to Everyone (12:42 PM)
-
Emma with Blue Systems > but also off today unfortunately > I'll ask for clarifications on responses to her post proposing an option 5!
-
Me to Everyone (12:43 PM)
-
Ah gotcha Steve. Just posted a comment here about that: https://github.com/openmobilityfoundation/mobility-data-specification/issues/759#issuecomment-1138769299
-
William Henderson (ceo @ Ride Report, he/him) to Everyone (12:45 PM)
-
i think option 4 is the essentially what what i originally proposed? agree with Marie - i dont think option 5 meets the aims there
-
Jean Kao (Populus, she/her) to Everyone (12:48 PM)
-
I have to go - fire alarm - apologies!
-
Me to Everyone (12:48 PM)
-
Jean ok be safe!
-
William Henderson (ceo @ Ride Report, he/him) to Everyone (12:49 PM)
-
Option 1 feels like a half-step. I'm a bit torn on whether that's a good thing or a bad thing
-
William Henderson (ceo @ Ride Report, he/him) to Everyone (12:53 PM)
-
Anyone from Oslo here?
-
would love to know what they are using Agency. my educated guess is that it is because it is easier for new operators to implement
-
Me to Everyone (12:56 PM)
-
William Henderson (ceo @ Ride Report, he/him) to Everyone (12:58 PM)
-
+1
-
@Oliver i sugggested that as well
-
William Henderson (ceo @ Ride Report, he/him) to Everyone (12:58 PM)
-
Me to Everyone (1:00 PM)
-
Oliver I see now that you are @mrsimpson in the comments. Thanks for attending!
-
William Henderson (ceo @ Ride Report, he/him) to Everyone (1:00 PM)
-
IMO it's a tension between the original design goals and the actual use of MDS in practice today
-
Marie Maxham (Lacuna) to Everyone (1:00 PM)
-
Agreed @William
-
Angela Giacchetti (OMF) to Me (Direct Message) (1:01 PM)
-
Is this something to bring in the tech council to weigh in on/discuss?
-
William Henderson (ceo @ Ride Report, he/him) to Everyone (1:01 PM)
-
correct me if i am wrong, but i dont think any operator has built a Generalized Policy Interpreter. most of them are not even automatically consuming the API yet
-
some of them are consuming it any ignoring everything besides no parking/ride zones
-
Marie Maxham (Lacuna) to Everyone (1:02 PM)
-
LA has one 🙂
-
oh
-
Provider
-
yeah correct
-
William Henderson (ceo @ Ride Report, he/him) to Everyone (1:02 PM)
-
yeah
-
Oliver Jägle to Everyone (1:02 PM)
-
If there’s going to be a „task force“ on „the rule type“ I’ll be happy to join
-
Marie Maxham (Lacuna) to Everyone (1:02 PM)
-
Well we're trying to FOSS ours 🙂
-
Yes @Oliver, reach out to @Jean
