Web conference notes, 2021.06.24 (Joint Working Group)
Joint Working Group - City Services
- Every other week call at 9am PT / 12pm ET / 6pm CET
Meeting ID: 841 7098 9462 - Passcode 612987
https://us02web.zoom.us/j/84170989462?pwd=WTRlY25wOVhNeS8wQk1iM2QzYkQvUT09
One tap mobile: +19294362866,,84170989462#,,,,*612987# US (New York)
Dial by phone: +1 929 436 2866 (US) (Find your local number)
Add your own name, link, and organization during call
- Steve Brining, Blue Systems
- Michael Schnuerle, OMF
- William Henderson, Ride Report
- Matt Davis, Populus
- Frederic Robinet, Vianova
- 24 attendees
Main Topics
-
Policy Program Requirements - work session
- Work on getting Requirements over the finish line and resolving open issues.
- Will involve doing pull requests edits and resolving comments during the meeting.
WGSC Meeting Organizers
- Host: Steve Brining
- Facilitator: Michael Schnuerle
- Outreach: ...
- Note taker: Steve Brining
MS: Talking about the policy requirements pull request
- Was an idea from WH on how agencies can share policy requirements digitally
- Grew into something a little more than was suggested.
- Focus for today is looking at any unresolved discussion items.
Pull request: https://github.com/openmobilityfoundation/mobility-data-specification/pull/646
MS – we're going to the most recent commits
- MS added a few examples, changed GBFS in metadata example to Boolean true/false, added vehicle types
- Added update frequency - pulled some items over into a paragraph for us to review today.
- MS – Update frequency, suggest not more than monthly, but can put in there, so providers
- MS - WH brings up a point on min update interval - should be this vs max
- SS - likes this frequency
- Update later in the PR
MS - new vehicles types array - if you leave out, it assumes all vehicles
- Opportunity to mix and match and be clear about it.
- Thinks mostly it will be the same for all providers and vehicle types
- MS - MM does this get you your support for modes?
- MM - Yes
- JFH: This makes sense, but we should make sure the documentation is clear re: simple use case vs. the more complex scenarios.
- WH – This is a good change. We should future proof. Generally you'll have one policy per vehicle type, but you want to say, for these different programs, there are different requirements. Not always 1:1 with vehicle types.
- MS – are you suggesting a policy id that adds a set of rules that applies to everything in the section?
- WH – were talking about tying requirements to a specific program
- MS – I could see adding an array that wouldn't be required.
- WH – it would be just like the vehicles type?
- WH - MM – hasn't had time to evaluate the proposal. Programs generally map onto modes (scooter / bike share / taxi)
- She still wants to specify the mode, like "this is for scooters"
- SN : Should we keep vehicle types in separate "documents" instead of within one? Might keep things simpler?
- MS: all usually in the one file
- SS: With our programs in Dc, we would be fine except for the difference between docked and Dockless bikes.
- I can't tell, but is that an option?
- We'd apply same policies to dockless bikes part of docked bike share as other dockless bikes, but different for docked bikeshare.
- MS – different providers?
- SS – yes,
- MS - Would need to specify the version of MDS provider for each
- We don't have documented use cases for all scenarios, but if you comment on the issue or PR, it would be a nice way to document it.
- WH: Yes, exactly what Sharada's saying
- Cities have different programs that don't fit all the time
- Is there a simple way to give to cities to say "this is my program" for dockless, docked bikes, scooters, car share, etc.
- Sanjiv: This is my point, I think.
- MS – wouldn't that be solved by what we're trying to do here?
- WH might want to take a step back. Do we want to take the time to come up with something that is simple but consistent?
- WH - Sanjiv is this what you were talking about?
- SN: Thought so, but I think there is enough complexity. You go down these tree branches that specify a bunch of things that may obfuscate.
- JFH: Agree w/ Sanjiv's point. I worry that we'll end up with something that isn't human readable.
- MS – I feel like what we have so far can solve for these scenarios, but maybe add a program name
- SS: Yes! Adding a program name would be great!
- WH: noting we're adding same fields from Policy into this thing, and we're striving for constancy, so maybe we should try to keep the same as much as possible.
- MS: How is it not the same
- WH: talked about a new field that's the same as the description field in Policy. Maybe we need to do some nesting.
- WH : from a system design perspective, may end up with some confusion. Originally proposed as a part of the policy api, and would be ok if it was 1:1. Maybe make it possible to adopt policy with no rules, to say this is my policy name, this is where the pdf lives, etc.
- It is usually one file (PDF) pre-MDS days
- MM- one layer of abstraction around the current stuff. Policy is a part of Requirements, a larger concept.
- MS – WH is making case to move most of the things in Requirement to Policy endpoint
- What should really be defined is which endpoints you're asking for as part of the policy.
- Some are saying move all into policy, other would be to keep on it's own and simpler.
- MS : noting also the possibility of hosting this for cities, but if this is more like policy API then it's not something we want to do.
- JFH, maybe philosophical question around bootstrapping, so Requirements would make it easy to bootstrap an implementation
- Appreciates that this is something is duplicative of policy api and weigh again - a separate place you can go so see MDS requirements before you go and implement.
- Maybe missing the point - that you'd need to connect to policy api vs having it available outside of it.
- WH - maybe we invert this - policy refers to Requirements?
- MS – seems weird to me, details in requirement seem higher level.
- WH - maybe rename to "Program Requirements"?
- Alex Demish: Agree with Jascha's comment - having Requirements embedded in Policy makes Requirements harder to implement, which takes away from the original intent
- MS - yes, putting Requirements in Policy would make it a breaking change.
- MS - so we still maybe have an open discussion
- NG: The way I tend to think about MDS Policy is that it expresses rules about vehicle behavior, and Requirements is more along the lines of pointers to endpoints/functional SLAs. Requirements are a 'policy', but I don't think they align with how we've currently defined 'MDS Policy' in many cases.
- Thinks that the way MDS policy works today - like you can only have x amount of vehicles here for x time.
- Requirements in my mind is more general information about the system. It's a Policy but different than MDS Policy AP
- MS – to follow up, we can point to all other agency-hosted files.
- NG: How about adding something like
modalityormode?carshare|micromobility|taxietc... You can also havevehicle_types, as for a given mode there could be multiple vehicle_types (e.g.carorcargo_vanor something for carshare) - MM: talking about state machine for taxis and robots being very different from current.
- MS/WH there is a need to talk about mode more
- WH – what if we break this out into adding more modes later?
- Like if robots doesn't go into 1.2, then we don't ship something outdated
- WH - Marie I would be happy to collaborate on this when you get to it. We're hoping to get carshare in 1.2 or 1.3, and there's dependency there as well (particularly because many cities have different "modes" even with car share - ie zipcar vs freefloating)
- Henri Espinosa - on possibly moving over to modes - like delivery vehicles are all cars but may have different vehicle types.
- Would like to have some clarity, it's getting a little muddled.
- MS – by adding concept of modes will have a ripple effect, will probably be discussed in more detail in another issue.
- WH: I'm starting to wonder if "modes" should be something that is extensible by cities – ie to add a new type of carshare
- MS – are you suggesting a policy id that adds a set of rules that applies to everything in the section?
MS - WH talking about hierarchy
- WH – wanted to add GBFS requirement as well
- What are we representing conceptually
- At bottom of hierarchy, you have fields required, endpoints required.
- Sounds like we're a little far from consensus, so maybe we do some conceptual mapping.
- It's worth it to get it right and make it simple.
- Thinks proposal might be outdated after this discussion.
- MS – yes maybe, we started talking a little higher level.
- Doesn't agree with moving start date up to meta data level.
- WH: Wanted it to align with the city's program
- Depends on where the idea of the program lives
- MS – the way this is proposed now, you could have separate programs with different start/end dates.
- MS – open question of how GBFS relates to this.
- Is it within the realm of this endpoint to specify everything related to GBFS.
Meeting end:
- Provide summary of next steps
- Action item: modes instead of vehicle types
- Action item: Discussion about merging into Policy
- Steering committee meeting July 7th (now July 19) on 1.2 feature status
- Note about next meeting date/time and that feedback is welcome
- Next meeting is 7/1
Angela Giacchetti (OMF) to Everyone (12:06 PM) If any members need help joining a member network, feel free to reach out and I'll get you added. The networks are car share, passenger services, and delivery robots.
Sharada Strasmore (DDOT) to Everyone (12:16 PM) would user weight also impact the energy consumption?
Dirk De Kok (Spin) to Everyone (12:17 PM) Yes Sharada! But we try to stay away from that. Definitely in hilly environments
Emmett McKinney to Everyone (12:18 PM) Environmental conditions, shape it too: batteries lose charge more quickly in cold environments.
Jascha Franklin-Hodge (OMF) to Everyone (12:18 PM) https://policydata.numo.global/use-case/environment/ https://public.tableau.com/views/20191202\_CO2byTransportVehicle/AVERAGECARBONEMISSIONSBYTRANSPORTMODE?:embed=y&:embed\_code\_version=3&:loadOrderID=0&:display\_count=y&publish=yes&:origin=viz\_share\_link&:showVizHome=no
Sharada Strasmore (DDOT) to Everyone (12:24 PM) This seems like maybe a beta option? that may not be turned into something more permanent?
Thibault Castagne to Everyone (12:26 PM) CO2 emissions/saving is clearly an important KPIs cities are looking at for shared mobility programmes. We see the requests for reporting this data across a number of city clients. The calculation is not straight forward and we would support having some sort of common understanding around this
Thibault Castagne to Everyone (12:32 PM) Also btw cities, operators and software providers often have to report this data to get grants or subsidies of some sort
Jascha Franklin-Hodge (OMF) to Everyone (12:34 PM) Some details on how this is calculated for electric cars: https://en.wikipedia.org/wiki/Miles\_per\_gallon\_gasoline\_equivalent
William Henderson (Ride Report, he/him) to Everyone (12:37 PM) That sounds like a good direction Jascha
Emmett McKinney to Everyone (12:38 PM) +1
Me to Everyone (12:39 PM) https://github.com/openmobilityfoundation/mobility-data-specification/issues/589
Sharada Strasmore (DDOT) to Everyone (12:44 PM) Is there a standard around the accuracy of the GPS?
Me to Everyone (12:46 PM) I think the things you see here are the standard data used to determine GPS accuracy. Someone can correct me if I'm wrong.
Jascha Franklin-Hodge (OMF) to Everyone (12:46 PM) https://www.trimble.com/OEM\_ReceiverHelp/V4.44/en/NMEA-0183messages\_MessageOverview.html
Sharada Strasmore (DDOT) to Everyone (12:46 PM) @william, I agree that the accuracy is important to city regulation.
New Attendees
N/A
