Public transportation networks

[1ec5]

Public transportation infrastructure, such as stations, stops, routes, vending machines, and ticket validators, are tagged with network and operator tags. name-suggestion-index could help mappers and data consumers work with the network tag, which currently poses a couple challenges:

• The network tag is quite overloaded, being used for everything from ATMs to road routes. iD can’t rely on taginfo to populate a list of suggestions, because those suggestions can be polluted with popular values for other kinds of features.
• By convention, network often contains an acronym, which may or may not be unique even within a single state. At the same time, it’s usually the name of the agency, not a colloquial name like “RTA” or “Metro” that most people would initially turn to.

By pairing network values with ISO 3166 subnational codes, friendly names and disambiguators, and network:wikidata tags, name-suggestion-index could both help mappers choose the right values and give data consumers machine-readable data to work with. For example, a mapper in Los Angeles could search iD’s presets for “metro” and choose between “ Metro (Los Angeles)” and “ Muni Metro”, both of which operate in California. A router could display a route number in an agency specific style by keying off the network:wikidata tag instead of performing point-in-polygon or line-in-polygon tests to distinguish one VTA from another.

Per #2863 (comment), we could maintain the canonical networks in a networks/ folder. Since many public transportation agencies offer multiple modalities (like bus and rail) but most are limited in geographical scope, it might make sense to structure this folder by geography, similar to editor-layer-index. There would also need to be changes to the schema and build system to support this new tree.

Editors like iD would need to handle networks a little differently than brands. Network presets shouldn’t match features based on their names, because the name tags on public transportation features aren’t usually supposed to refer to the network. It may make some sense to match relations based on relation types, but the type tag is also used on non-relations for various other purposes.

In the future, similar infrastructure could be repurposed to generate presets for road and cycle route networks.

/ref #2863 #2243 (comment)

[quincylvania]

I've been looking into this and encountered a question. Transit agencies like MBTA operate multiple types of transit, some of which with their own wiki items. Currently the network and tags seem to be generally tied to just the parent agency. Would it be preferable to target these kinds of "subnetworks" instead where possible?

[1ec5]

Some agencies operate each mode as distinct networks, with distinct branding, segregated facilities, and often uncoordinated schedules. Examples include Amtrak (trains versus Thruway motor coaches); San Francisco (Muni buses versus Metro subway lines); Washington, D.C. (Metrobus versus Metrorail); and Cincinnati (Metro buses versus the Cincinnati Bell Connector streetcar). In these cases, I think network:wikidata should at least be more specific for the more specialized service, whereas operator:wikidata (if we use it) could still refer to the agency.

In cases where the services are less differentiated, I think it’d be fine for two services to share a single network:wikidata. We can also start things out this way but eventually get more granular as we discover reasons to make a distinction and more specific Wikidata items are created.

Maybe a useful rule of thumb could be whether there’s any overlap in the route numbering scheme used for buses versus rail etc. That would be consistent with how we decide when to distinguish between two road route networks.

[quincylvania]

In these cases, I think network:wikidata should at least be more specific for the more specialized service, whereas operator:wikidata (if we use it) could still refer to the agency.

I like this approach. But it leaves the question of whether the network tag should also match the subnetwork or should continue to use the agency acronym, e.g. MBTA Commuter Rail vs. MBTA. Using the former would be a divergence from current OSM convention, so it's probably best to use the latter to avoid drawing ire.

[quincylvania]

Another issue I've run into: separate transit offerings sometimes share a station. While "MBTA Commuter Rail Station", "MBTA Subway Station", and "Amtrak Train Station" should all be separate entries in the index, what should the mapper do if they're all the same station?

[1ec5]

Another issue I've run into: separate transit offerings sometimes share a station. While "MBTA Commuter Rail Station", "MBTA Subway Station", and "Amtrak Train Station" should all be separate entries in the index, what should the mapper do if they're all the same station?

The same thing can happen with store brands, albeit less commonly: #2847. Some segregated facilities would be mapped separately with simple network values, but it’s true that the overall station area would have a combined network value.

I think it’s more likely to happen with stations that are already mapped, so the impact would be that the editor wouldn’t be able to match an existing network, rather than making it harder for the station to be mapped in the first place.

In some places, like near county lines in the U.S., a single bus stop may be served by multiple agencies, but maybe iD could encourage mappers to draw a point for each service and combine them. The downside is that the networks may be combined in any order, whereas the mapper may intend for one to come before another.

It’s worth pointing out that public transportation networks may not be especially conducive to presets. With store brands, a mapper may search for the brand name; similarly, with road networks, it would be nice if a mapper could search the relation presets for the network. But I’m unsure if mappers would first search for the public transportation network versus the specific kind of infrastructure. NSI could power autocompletion suggestions for the Network field in any case.

[peternewman]

Should this be closed now #4231 is in progress?

[bhousel]

Should this be closed now #4231 is in progress?

I forgot all about this issue! But yeah we should definitely circle back and make sure that the #4231 and recent changes to NSI are addressing the ideas here. It sounds like we're doing most of this now.

[bhousel]

Seems good to close this one - lots of progress has been made in the last month on transit networks!