-
Notifications
You must be signed in to change notification settings - Fork 232
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
Extract Geography API from Policy API #500
Comments
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. |
@janedotx would you mind updating your github profile to include more info about your affiliations? |
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. |
With the merged PR #582 the new Geography API is now available in the 'dev' branch, so this issue can be closed. |
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.
The text was updated successfully, but these errors were encountered: