Skip to content
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

Closed
janedotx opened this issue May 16, 2020 · 4 comments · Fixed by #499 or #582
Closed

Extract Geography API from Policy API #500

janedotx opened this issue May 16, 2020 · 4 comments · Fixed by #499 or #582
Assignees
Labels
Geography Items related to the Geography API Policy Specific to the Policy API
Milestone

Comments

@janedotx
Copy link
Contributor

janedotx commented May 16, 2020

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

  • No, not breaking

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.

@marie-x marie-x changed the title Add geography and geography author service Extract Geography API from Policy API Jul 8, 2020
@marie-x marie-x self-assigned this Jul 8, 2020
@marie-x marie-x added this to the 1.1.0 milestone Jul 8, 2020
@schnuerle schnuerle added the Policy Specific to the Policy API label Aug 13, 2020
@schnuerle
Copy link
Member

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.

This was linked to pull requests Aug 26, 2020
@schnuerle schnuerle removed a link to a pull request Aug 26, 2020
@schnuerle schnuerle linked a pull request Aug 26, 2020 that will close this issue
@johnclary
Copy link
Contributor

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

@schnuerle
Copy link
Member

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 schnuerle added the Geography Items related to the Geography API label Sep 30, 2020
@schnuerle schnuerle linked a pull request Sep 30, 2020 that will close this issue
@schnuerle schnuerle pinned this issue Oct 2, 2020
@schnuerle
Copy link
Member

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

@schnuerle schnuerle unpinned this issue Jan 27, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment