openstreetmap
Public transport presets inappropriately suggest to change type or name of features
Describe the bug Per bug reports in the OSM Community Forum and in NSI Github issues, iD suggests to change an Irish Commuter train to an InterCity train, and a London Underground station to an Overground station.
Reports with discussion indicating that problem lies in iD:
- https://github.com/osmlab/name-suggestion-index/issues/10469
- https://github.com/osmlab/name-suggestion-index/issues/10167#issuecomment-2496485504
- https://community.openstreetmap.org/t/bad-name-suggestions-for-train-routes-in-spain-problem-with-preset-or-with-the-concept/125234
To Reproduce I didn't run into this bug so I'm unsure. See discussions linked.
Expected behavior Feature types are not incorrectly suggested to be "upgraded".
Screenshots
To Reproduce
Edit this relation
The "issue" appears immediately, even though the route is correctly tagged (including operator, network, and the wikidata tags).
Further background As well as offering an incorrect suggestion, the wording "tag as not the same InterCity" is especially confusing here, as the route is not currently tagged as any kind of InterCity.
The NSI preset for the InterCity network is correct in the sense that it contains the right tags for a route on the InterCity network. If the mapper had already selected network=InterCity, the preset would work to check that the wikidata tags for network and operator are consistent. But as commuter and InterCity networks in Ireland have the same operator, the operator alone can not tell us which kind of network a given route belongs to, which may be what ID is assuming. This can not be solved by "geofencing" the presets, as the two types of network run alongside each other in cities.
This is not an isolated situation, and it has a real impact on the map. I found 4 long distance train routes in Spain wrongly tagged as belonging to commuter (CercanÃas) networks, created by 4 different mappers who either assumed the ID "upgrade" was correct, or accidentally accepted the upgrade while focused on an unrelated change. The common thread is that like Irish Rail, Renfe operates both commuter and long distance networks in the same area.
From what I remember we wrote the transit code to prefer matching on network, but fallback to matching on operator.
The best way to fix problems like this is probably to just add the transit networks to NSI that you want the validator to support. (Generally you can fix any problem with NSI by just adding more stuff to NSI).
Edit this relation
seems to not reproduce bug anymore? or has someone broke data by following bad suggestion?
https://www.openstreetmap.org/edit?relation=10377553#map=12/53.2888/-8.8966 was given as an example
Reports with discussion indicating that problem lies in iD:
maybe - probably iD should not use public transport and school parts of NSI for suggesting "upgrades".
But why it is reported in id-tagging-schema? As far as I can see nothing at all can be changed here that would stop such bad suggestions.
But why it is reported in id-tagging-schema?
Primarily because I am not familiar with the several different repos that control iD's overall behaviour, and I would suggest that most iD users are not either. (Should I open an issue to create a guide to where to open issues with iD's behaviour?)
In this particular case, when I opened the issue in @osmlab/name-suggestion-index it was suggested that this was an iD problem in https://github.com/osmlab/name-suggestion-index/issues/10469#issuecomment-2632459799, and this repo was the closest I could find
OK, then likely I have not missed anything deep. I will wait for someone with rights to move it to a correct issue tracker then.