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.