-
Notifications
You must be signed in to change notification settings - Fork 231
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add MDS Stops RT Specification (Agency & Provider) #427
Add MDS Stops RT Specification (Agency & Provider) #427
Conversation
quick question: how would stops with charging capabilities be reflected? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
More of a nitpick, but I would rather see this PR focused on the specific changes for docks/stops/etc. and save all the formatting fixes elsewhere in the doc for another cleanup PR. This makes review a lot easier, and tracing the history becomes less cumbersome when we can see exactly why a particular line was changed.
c6535ee
to
5defa37
Compare
@thekaveman Resolved your previous nit. Also cleaned up the commit history a bit in the process. |
@thekaveman I've also removed any |
I guess this PR does not define vehicle_type yet. In order to support charging, we could define them as following with the
e.g.:
|
@dirkdk Vehicle Types are defined here https://github.com/openmobilityfoundation/mobility-data-specification/tree/dev/provider#vehicle-types already, I can add a hyperlink to the line that references that enum. |
yes thinking if we need to include |
I'm not as familiar with GBFS so this might not be compatible with that, but instead of listing vehicle counts and having to invent increasingly complex keys for that I'd rather see a list of vehicles with associated attributes so end users can group and count those as needed. |
There are some relevant changes likely coming to GBFS here: MobilityData/gbfs#219 Worth making sure we have alignment with those (especially around valet and virtual stations) in whatever we implement. |
Hi, I must say that I like this approach very much since:
I'm not that sure about the However, I think that #441, while maybe going maybe too far for a first step in my opinion, also makes some very interesting points, most notably:
I also think that their approach with arrays of MDS-compatible vehicle types, propulsion types, vehicles and docks is cleaner and more informative than multiple dictionaries of vehicles and spaces counts, which sounds very GBFS-y :) So to sum it up I'd say that in my opinion, we can find a best of both worlds by merging some of the fields in that other PR with this one and still be generic and simple enough for a first approach. |
Here is a doc we put together with MobilityData and NABSA to provide additional guidance on how GBFS and MDS should align with each other: https://github.com/openmobilityfoundation/governance/blob/master/technical/GBFS_and_MDS.md |
@vperron I agree, having just a boolean for Agreed having a pointer to The The I'd be okay with switching from using the mapped values to a more explicit array of docks/vehicles, however I'm not sure that's entirely necessary (and may have some downsides). Having the maps certainly makes deriving counts of certain vehicle types at the Stops faster (constant time lookup as opposed to having to iterate through the entire array), and explicitly encoding an array of vehicles (with essentially all of the information for the vehicle) within the stop seems like duplicating data that is already available via the |
a7286ba
to
c3623e2
Compare
also use link references
elevate 5-minute requirement from /vehicles to this section use reference links
@thekaveman thank you for the rebase! It looks like 'spaces' is the consensus term to replace 'spots' with 4 votes. @avatarneil what happened to the 'Place' option, or did I just make that up? Let's also talk about the differences between MDS and GBFS here.
Thoughts on changes here are welcome, even though the release candidate will be made this Monday. During the release approval process the OMF Tech Council and Board can discuss tweaks to this proposal, and comments made here will help influence those decisions. |
I'll replace 'spots' with 'spaces'.
'Place' totally slipped my mind, but I do remember that from the call -- don't think you made it up :)
It's an object with the properties, e.g. {
"is_installed": true,
"is_renting": false,
"is_returning": true,
}
I think we ought to keep it as one endpoint (at least for now) -- this aligns well with how we report on
This confusion is one of the reasons why I was pushing for having simple
That sounds fine by me. Cc. @schnuerle |
Thank you for the updates and clarifications @avatarneil! I think this PR is ready for the 1.0.0 Release Candidate today. For discussion during the review process:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approved for the 1.0.0 release candidate.
Some updates from the Provider Services call today:
No opinion one way or the other. I like "Place."
Heidi Guenin with MobilityData who runs GBFS said that there is a PR to change bikes to vehicles. Car sharing is a new use case. Bottom line is don't align to GBFS terminology right now. |
@schnuerle Have we considered |
Yes we did, it was in the poll we took (though Place was missing) and didn't get any votes. Based on the feedback/votes on the City Services call today and the Provider Services call last week, I'm going to rename |
Explain pull request
This PR is a work in progress to resolve #374 .
Is this a breaking change
A breaking change would require consumers or implementors of the API to modify their code for it to continue to function (ex: renaming of a required field or the change in data type of an existing field). A non-breaking change would allow existing code to continue to function (ex: addition of an optional field or the creation of a new optional endpoint).
Impacted Spec
Which spec(s) will this pull request impact?
Provider
Agency
Additional context
Stops
are intended to be a strict superset of GTFS/GBFS -- keep that in mind when seeing some fields that are unnecessary for the base scope of MDS currently.