Web conference notes, 2022.06.23 (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:
31 Attendees
Main Topics
- Kickoff - Sebastian Berthaud, Blue Systems (5 mins)
- Policy Use Cases (main topic)
- Unification - date of working meeting
- July 6 (Wed) or 8 (Fri) at 9am PT/12 ET/6 CET
- 'Delivery' mode instead of 'Delivery Robots'?
WGSC Meeting Organizers
- Host: Sebastian Berthaud, Blue Systems
- Facilitator: Michael Schnuerle, OMF
- Outreach: Michael Schnuerle, OMF
- Note taker: Nivedya Madankara Kottayi, SANDAG
- PR: Suggest in spec Policy conversion to or from GeoJSON through tools as needed for human readability
- PR: Improve
descriptionfield description in Policy to require more human readable details - Michael create new document for Unification work - done see here
- Marie pick meeting date for Unification working session July 6 or 8, then email WG
- 'Delivery' mode instead of 'Delivery Robots'?
- Welcome and kick-off from Sebastien
- New member introduction
- Craig from San Jose DOT
- Housekeeping items from Michael
- Next week is the OMF board meeting for board members, hybrid meeting in San Francisco
- Andrew Glass Hybrid (in chat): Board meeting on Tuesday will be hosted in Seattle and virtually
SB: Discussion (issue 764) on reimagining the policy, and make API easier and greatly adopted by the city
Collect feedback and make proposal to simplify
Collect top priority use case which is used a lot on day-to-day basis.
Highlight 8 use cases – 1) operating area, 2) no riding, 3) no parking, 4) parking, 5) parking time limit 6) speed limits, 7) distribution policies 8) Provider caps or minimums
Are we ok with this definition? How can we improve the use case and definition?
MS: Looks like preferred parking and required parking is merged as just parking. Idea is if there is a way in the description to specify if it is required or preferred
SB: if the rule is not respected, it can be different. For the sake of simplicity those two are merged. Any other feedback?
Oliver Jagle: How to picture the use cases to current API. Is there a need to change API.
SB: We met on Github discussion. Absolutely, we have to go in API evolution. Goal is to make good foundation and we can discuss where we should be going.
SB: Some of the use case depending on which system is publishing it the rules, that could be different way while using it in MDS. To avoid additional complexity, so rule type homogenization proposal was discussed. For eg. rule type time can be used for no parking.
SB: Discuss on two points :1) These suggestions staying with the APIs where it is and putting deadline how it is being used. Same implementation of API is used consistently.
- Maybe we should to geoproximity (making less generic by having rule type and mapping of these use cases).
May be we can say that mission is the adoption of MDS policy. So, the objective is machine readability and other point is may be human readability is not considered enough.
MS: background: choosing a reco, everyone seems to be in agreement. We are going to pick one and agree to that. For eg time or speed etc. are machine readable.
Pick one and describe in the spec and helps in readability effort. For eg time etc and this is what it means. Second one is that adding a link to external resource to describe this policy. For eg. in your permit doc that published by your city can be checked by someone. OMF has defined these use cases and can be externally referenced.
Having another set of human readable API. In the policy right now, there is an area for description and city can put in detail description. For eg. what does no parking really mean and it makes it consistent across jurisdiction.
More thoughts on human readability standardization.
Oliver: when we implemented the policy editor, it is easy for compliance engine to pipeline all those rules evaluation (vehicle movement, speed, count) and to check which one matched and then which one violated.
It is a need to map use cases. To me, I came to the conclusion that while we need translation from use case to machine for agency to provide and communication processes, it is actually not necessary to see what the intention is but, how can it be validated. So may not make sense to introduce to second recommendation on how to document in the specification or how to map. The letter should be great with user face authoring API which host those use cases and may be a small library which maps it and leave the specification as is currently because it is optimized for machine readability.
SB : My understanding is fairly similar to what MS had i.e. documentation and make sure we have clear definition of use case and clear implementation guideline linked. Is that you have in mind and have similar concept Oliver?
Oliver: sounds like that
Michael: I was thinking about - we have requirements end point. It is with in policy and define what a city government entity can ask or what you are providing publicly, which already exist for MDS 1.2. We are discussing about the adding links to the policies and data you are requesting. Proposal is Requirements defined by adding use cases: https://github.com/openmobilityfoundation/mobility-data-specification/issues/681
So it says, here is why we are asking this data or providing and makes it human readable.
Second is Authoring API and link is https://github.com/openmobilityfoundation/mobility-data-specification/pull/497 which overlaps with this a bit.
Oliver: I am aware of the requirement end point. Are you saying that the agency can publish the way it translates particular use cases to rules?
MS. The way it is proposed now is here is our policy API and here is the use cases. Not the level you are talking. Proposal is more of making sure that an agency thinks about the use cases and in connection to the data they are asking for and it allows for it to be explicitly defined.
SB: For clarity, we can use same use case definition as well. We have rules like no riding zone and no riding use case definition. Then in the req API it is a policy for non riding. We can point to the same and in terms functionally it is super consistent.
MS: Yeah
Jay Williams: Discussion about machine vs human readable. Isn’t it easily machine readable? Some cities set speed limit zero for no parking zone. Machine readability aspect can’t be clear with human readability. It has to be standardized.
Oliver: I object to it. Make two rules for no parking and no riding. Machine can check - rule is checking movement or rule is checking location, vehicle count. You can’t violate in same time in same dimensions. Make sure if there is a nice mapping. Provide a library for the authoring.
SB: Consensus to have a use case to code up. There is a one way to define those use case in policy API. By adding an additional implementation guideline is an acceptable solution. So, there is one way of implementing the given use case. Give enough documentation to fulfill human readability.
MS: Ok
Oliver: The biggest issue is the No riding. Fact of riding is something in movement and picture to that a speed. What about implementation each use cases. For eg. No riding, whether speed or time.
SB: We need to agree that no vehicle be in there, no parking zone as well. Eg from Jay n riding speed 0 people to park scooter and cause issue. Would like perspective from operators.
Frederic Robinet: Make the shorter process to read API directly. We ended up on Geojson format and use human readable format and adoption and speed up a lil bit and apply the rules which cities trying to express.
MS: in description field: propose and required and add with a certain level of detail to describe the use case. For the policy rules that apply to geojson, for eg. provider caps that may not be a Geojson component for that.
Description is required: Geography is also required so geojson concept works.
SB: json to geojson with meta data. Easier to interpret.
Michael: Program co-ordinator made GIS file to MDS policy rule type names and states. Company converted into MDS format.
SB: Wrapping up, documented guidelines, to enhance human readability the goal is streamline making one way to implement each of the use case. Way to enhance human readability is by constraining, clear use cases documented guideline, geojson is good one. Debate between speed and time need to be clarified and need further discussion.
Jean Kao: Just want to point out that the No Riding use case includes no parking within it.
MS: That makes sense Jean. The flip of No parking does not mean mean no riding though.
MS: Authoring API - PR - Marie is this the same concept? https://github.com/openmobilityfoundation/mobility-data-specification/pull/497
MM: Yes, sort of - at Lacuna we are using the Policy Author API, but we have added some extensions based on real-world experience that are not yet in the spec
Oliver, I think generally when cities want to implement a No Riding area they mean no scooters in this area. Like a No Operating area.
Oliver : in chat I can definitely say that there are use cases where it's fine for a city to move a scooter into an area without riding it (speed 0) and then to park it inside: Think about a crowded riverside: don't ride there (for safety), but you may park it in front of a restaurant.
July 6 (Wed) or 8 (Fri) at 9am PT/12 ET/6 CET
MM: Smaller grp of people. Looking for feedback and collect. Collect feedback in meeting minutes and male public document by MS. We will have something by the time we publish the meeting.
Tristan Charreton: Should we restrict to only robots as there are other forms of delivery. Having all forms of delivery in MDS 2.0. Any thoughts on it.
Michael: It is an interesting idea – we have been discussing. For new modes in MDS 2.0, Taxis, car share and sidewalk delivery robots were suggested. I think about it more broadly as delivery. How it can be structured, a pull request. Or having a potentially a private vehicle – remote operated robot: If they are trivial, we need to have a delivery mode. Like to explore those.
We would like to have some participation from the companies that are doing deliveries. To discuss what is possible by MDS and for city’s policy or regulatory purposes.
SB: Point taken.
Action items: leave you thoughts
