search

openmobilityfoundation / mobility-data-specification

A data standard to enable right-of-way regulation and two-way communication between mobility companies and local governments.
https://www.openmobilityfoundation.org/about-mds/
Other
687 stars 232 forks source link

Extract Geography API from Policy API #500

Closed janedotx closed 4 years ago

janedotx commented 4 years ago

Is your feature request related to a problem? Please describe.

Right now, Geographies are not first class objects. They're basically embedded into Policies. Having Geographies be first class objects would make it easier to support other use cases that need to specify some kind of geofence, such as Jurisdictions or Stops. E.g. a Stop could contain a reference to a Geography to indicate the area it covers. Keeping Geographies as second-class objects tightly bound with Policies means they're forced to share the same access control logic.

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).

Describe alternatives you've considered

The other types of geofences we'd like to have could each contain their own geography data, but this would cause a lot of data duplication and possible confusion over what the ultimate source of truth was. Relatedly, we could argue for a fatter Geography object that supports Stop, Jurisdiction, and Policy functionality, but it could get messy. It is easier to reason about Geographies if they exist on their own and other types that rely on geospatial data merely contain references to the relevant Geography. This way, no type has to ever be aware of another.

schnuerle commented 4 years ago

Note to keep this non breaking Geographies will have to be left in Policy for the 1.1.0 release, and duplicated via a new optional endpoint.

johnclary commented 4 years ago

@janedotx would you mind updating your github profile to include more info about your affiliations?

schnuerle commented 4 years ago

PR #499 is merged to a 'feature branch' in the MDS repo so we can see how it fits into the larger spec, allow the community and staff to do PRs against it, merge other related PRs into it, and see how it will fit into dev when it's ready with PR #582.

See the 'feature-geography' branch for details.

schnuerle commented 4 years ago

With the merged PR #582 the new Geography API is now available in the 'dev' branch, so this issue can be closed.