-
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 Jurisdiction spec (Need a way to describe the attributes of a regulating agency) #491
Comments
Pull request here: #492 |
Can you clarify how this relates to Policy and the /geometries endpoint in particular? It's confusing to me that geometries is a part of Policy but Jurisdiction is a separate thing that references geometries. |
Policy and Geography are presently together in the same spec because Policy was the only service that used Geography. We will be explicitly making Geography stand-alone in an upcoming PR. Apologies for not doing that first. |
It’s not clear to me why this problem is best solved with a new Jurisdiction spec. It seems to me that the same goal could be achieved by amending the Geographies spec. It's very possible that I'm just not understanding the actual problems that this issue seeks to solve, because there's some stuff (eg The proposed Jurisdiction spec’s README shows that one of the main purposes of this spec is to associate the string fields Why not add those fields to the Geography spec, rather than making a new+separate Jurisdiction spec? The issue says that:
I don’t think that “the metadata can be arbitrary” is a compelling argument, because the Geography spec is a specification, and can clearly mandate the names+shapes of these fields. “it is desirable to keep each object type as atomic as possible” is a reasonable argument, but I think that adding a new spec specifically just for these three string fields will greatly increase MDS’s surface area and maintenance burden for not much gain. Under “alternatives you’ve considered”, this issue says:
I’m not sure what this means 🙂 I do notice that in the proposed Jurisdiction spec’s README, there’s some discussion of the notion of time, and of the ability to see which Jurisdictions were “active” at a particular point in time. If that’s the main use case that you have in mind, could you please explain it in more detail in this issue? Thank you! |
Some use cases that we are calibrated to for the Jurisdictions spec:
|
Here's a generic diagram of what's going on in Louisville (though I think it covers a lot of scenarios elsewhere). These are some of the geographies that need to be accounted for. The most interesting to me is the 'Area of Interest' where the city wants to know trips/deployments happening outside of its own jurisdiction. It is in some ways responsible to the surrounding cities/areas since they do not have operating agreements and the devices are there because of the first city. |
I don't feel strongly about separating Elaborating on what @jrheard has proposed, might we wrap the geography objects in some metadata that contains the properties we're trying to track? something like
We could also consider using the For my own sanity, threads on this topic can be found across these issues:
Sort-of related: |
and it looks like there's a proposal in PR #487 to add a |
So, I'd like to reframe what the purpose of the jurisdiction spec is, to modify this issue as originally written, and as was previously discussed on one of the city services working group calls but perhaps not yet succinctly captured in this issue: Is your feature request related to a problem? Please describe.City and transportation agencies need to regulate mobility within their own legal jurisdictions. Within a collection of agencies under a single MDS instance, those agencies need to coordinate and share relevant data between one another when their jurisdictions overlap for a given geographic area. The key problems to solve here are:
Describe the solution you'd likeA description of an agency as a first-class, immutable object in MDS, with attributes that can describe the agency's regulatory purview by mobility mode and infrastructure type |
Note that with the merged PR #582 the new Geography API is now available in the 'dev' branch. Please take a look and see how it may impact this Issue. |
This Thursday is the public Working Group meeting dedicated to Jurisdictions. Besides the presentation, it may be good to have a Pull Request ready to review as well. With about 2-3 weeks left in the release, we will need community consensus and feedback and a detailed idea this week to include it in the 1.1.0 timeframe. Tagging @brianngca (who is presenting this week), @Karcass, @avatarneil, as well as @janedotx the Issue originator. |
Could Jurisdictions help cities handle in the future single-fare multi-modal trips that may occur within abutting jurisdictions? I know this is not an applicable use-case for most cities right now, but I see how starting to develop this may benefit both cities and mobility operators in the future. |
@andrearjona Interesting. To understand a little more, what do multiple jurisdictions need to do/what do they need to know in a single-fare multi-modal trip? |
Completed this with the Jurisdictions API now in MDS. |
Is your feature request related to a problem? Please describe.
It is necessary for cities and transportation agencies to be able to designate certain geofenced areas as being legally significant. The most obvious example is delineating the boundaries of a city. We used to fulfill that need through the use of service areas, but those are being deprecated, as they mingled too many concerns together. A plain Geography is not enough, even though it is possible to annotate such an object with metadata, because the metadata can be arbitrary, and it is desirable to keep each object type as atomic as possible.
Describe the solution you'd like
A new Jurisdiction type and service need to be defined.
Is this a breaking change
Impacted Spec
This is a call for a brand new spec.
Describe alternatives you've considered
It's possible to annotate certain Geographies using GeographyMetadata, but that gives us a less clean ontology.
The text was updated successfully, but these errors were encountered: