I would like to see more UI safeguards in iD to help with some of these issues. A large part of interface design is protecting people from themselves, after all.

E.g. it’s frustrating to see possibly bad edits from a new user that just has “(no comment)” -> stronger message / barrier before uploading, like in josm?

It’s too easy to delete stuff that’s part of a relation without knowing it -> iD modal dialog warning whenever something from certain types of relations is deleted?

Google Maps can have the full route with separate bus stops – it’s dependent on what the transit agency provides in their GTFS feed. Any public transportation effort in OSM should probably get familiarized with GTFS to understand how that data is modeled.

For example, a GTFS file can provide stop coordinates, the route polyline (for a visual overlay), as well as data on where each stop corresponds to on the polyline. But, these fields could be missing depending on whether the software exporting the GTFS feed (DoubleMap is only one example of transit software that has GTFS export) supports each feature and whether the agency even entered that data.

Also, not to avoid the question of placing stops… you’ll notice that we always show two separate stops on either side of the route if the bus goes both directions. This is partly to make clear where people actually wait for the bus, and also because of our internal data model. If it were up to me, I’d just put the bus stops besides the road line and call it a day instead of separately modeling where on the road line the bus stops, but there are probably OSM folk who have more thought-out opinions.

Personally, I’m not even sure if OSM should try to keep track of bus routes. Mapping bus shelters is easy, but routes constantly change and have all sorts of business rules that change by day. I admit I’m not familiar with the nuances of OSM’s public transit schema, but here are some obstacles.

The Public Transport page on the wiki says of service relations, “In particular, this makes it possible to provide public transport routing services.” You’d need a lot of metadata (an understatement) to understand bus routes enough to provide routing. Consider these (real) scenarios:

• a stop that is only visited on weekends
• a stop that is only visited before 7pm
• a stop that is only visited on request
• a route that changes paths for morning/evening rush hours
• an express variant of a route that runs 3 trips each day at specific times in addition to the regular time
• a stop that temporarily moves locations because of months-long construction
• routes that might stop at any intersection if someone wants to board/alight there
• a bus route that runs when the temperature outside is below a certain threshold

Fares are a whole ‘nother layer of complexity. Also, all of this changes annually, or sometimes multiple times per year. And most OSM contributors do not notice transit relations when editing.

You’d need a service that slurps published GTFS data from each agency every day to check for changes and import that into OSM. And I don’t think you’d get the community or DWG to approve an import cron job like that, especially when even GTFS data is full of problems and tricky cases.

Apologies if that was too much info! Even enterprise bus-routing software cannot always capture all the logic of bus routes.