Transit networks #2921
Transit networks #2921
Conversation
| @@ -0,0 +1,67 @@ | |||
| { | |||
| "public_transport/platform/bus|MBTA Bus Stop": { | |||
There was a problem hiding this comment.
If we have a separate entry for each kind of feature that can be associated with the network, then there will be a lot of duplication, not just between the various entries in this file but also among each file. It would also become tedious to add support for associating a network with, say, ticket vending machines with networks after the fact.
Instead of orienting these files around presets, how about focusing on networks and indicating the applicable modes of transportation as fields on each network?
There was a problem hiding this comment.
Could you go into more detail? Do you mean like defining "this is the network and then these are the things that can be part of this network"?
There was a problem hiding this comment.
Yes. For example, most county transportation agencies would be defined by a single entry describing the network. There would be a bus property set to true, and elsewhere NSI or iD would take that to mean that the network should apply to the existing Bus Stop, Bus Station, and Bus Route presets. If the same agency operates a bus rapid transit line that’s part of the same network, with ticket vending machines along the route, then setting vending_machine to true would automatically associate the network with that preset too.
That’s the simple case, anyways. I’m sure there are edge cases that maybe we can address by specifying overrides of individual tags.
| "public_transport/platform/bus|MBTA Bus Stop": { | ||
| "countryCodes": { | ||
| "us": { | ||
| "ma": true |
There was a problem hiding this comment.
This is a clever way to avoid duplicates and make life easier for clients. Do you think we should change the existing brand entries to also structure countryCodes as an object? Each country code could be set to just true if it applies nationally but to an object if we want to get more granular.
Alternatively, it’d be simpler for contributors (less verbose syntax) if we stick to a flat array of codes that could be ISO 3166-2 codes. But that could be more difficult for a client to use Nominatim for, so maybe the build script could transform the flat array into this object structure.
There was a problem hiding this comment.
Looking into it more, I suppose using the combined codes like ad-07 in an array might be easier for most people. My developer brain wanted to keep the country and subdivision codes separate and hierarchical but it's no big deal to parse them out later.
| @@ -0,0 +1,67 @@ | |||
| { | |||
There was a problem hiding this comment.
What folder should interstate agencies or multi-state private carriers go into?
There was a problem hiding this comment.
I figure it'd be similar to the osm-community-index structure where interstate carriers terminate under the country folder, like networks/north-america/us/greyhound.json.
I suppose I already introduced a case where a local agency has a service that crosses state lines with "MBTA Commuter Rail" also reaching Rhode Island. We'll have to decide how strict to be with the structure.
bhousel
added
the
considering
|
Going to close this for now. Soon I'm going to swap out the countryCodes for location-conflation-style locationSets like we use on osm-community-index and imagery-index, which will let us define better regions for things like transit agencies. The other restructuring stuff to allow |
|
@bhousel Sounds good. This was pretty stale, I'd nearly forgotten about it. |
This is an incomplete draft addressing #2864. Feedback is encouraged as we figure out how to best implement this feature.