Bad name suggestions for train routes in Spain: problem with preset or with the concept?

Yesterday I noticed some very strange tagging on train routes in Spain. I am going to clean up the examples I saw. My question is not about fixing these, but about how to avoid this in future.

As background, Spain has a number of distinct commuter train networks, known as Cercanías (or equivalent names where there are other official languages). Each network corresponds to a city or conurbation. Most of them are operated by Renfe. Renfe also operates many longer routes that are not part of these networks.

In OSM the Cercanías routes have tags such as network="Cercanías Sevilla", with matching wikidata tags.

The odd thing I noticed was that several long distance routes are tagged with apparently random references to “Cercanías Asturias” or “Cercanías Cádiz”. The routes were
hundreds of kilometres from those cities, and were not Cercanías routes.

Through changeset discussions it became clear that this arose from presets in ID. One mapper had added these tags without realising while changing something else; another accepted the ID suggestion assuming ID was correct - again while concentrating on some unrelated change.

I now see that the references to Asturias and Cádiz were not random. They are the first two presets for train routes in Spain in alphabetical order. As shown in the screenshot, if I create a new train route anywhere in Spain and add Renfe as the operator, ID immediately tries to persuade me to “upgrade” the network and network:wikidata tags to “Cercanías Asturias”. I can see in the change history of one route that a mapper valiantly tried to resist by choosing the “not that Cercanías Asturias” option, only for a later mapper to fall into the trap and set it to Cádiz.

Leaving aside well-known general issues such as the loaded “upgrade tags” language, is there anything that can be done here, short of deleting the presets? I suppose they do have some value in keeping the network and network:wikidata tags consistent. But I don’t know if there is a way they can be triggered only when one of those tags is already set. And if neither of those is set, there is no way of knowing whether the mapper wants to create a Cercanías route or not.

The presets start around line 200 here:

1 Like

Presets such as Cercanías Asturias are currently scoped to all of Spain, which is too broad. Please file an issue or contribute a fix that reduces the scope to a region or other geometry.

That might reduce the problem, but I don’t think it would solve it. Someone creating a non- Cercanías route in a region that happens to have Cercanías routes would still be prompted to “upgrade” to the incorrect tags, as far as I can see.

Put another way: if an operator runs services belong to two networks (or a network and not-a-network) in the same geographical region, how can a preset be possible?

So maybe this quite common, and I just wasn’t aware of it because I rarely use ID to edit route relations.

Here is another bad suggestion, this time in Ireland, on an existing route relation. The train route Cork - Cobh is tagged perfectly correctly as a commuter route. The proposal is to change it to an InterCity route, which would be completely wrong. And the option to “tag as not the same InterCity” is confusing, as it is not any kind of InterCity.

It feels like maybe the transit suggestions are based on analogies with brands that may not really hold, and people submitting presets may not be fully aware of that.

image

1 Like

It looks like iD’s preset-matching code is getting confused because both the Commuter and InterCity presets have the same operator tags. The code to match presets goes way over my head, but my understanding is that it doesn’t know the network tags are more relevant than the operator tags. Instead, it breaks ties based on the number of matching tags. The presence of both operator:en=* and operator:ga=* probably exacerbates the issue.

For better or worse, NSI’s architecture assumes that a feature is identified by one of brand, operator, network, or flag, but not a combination. This makes it difficult to standardize more than one of these attributes at the same time, even if they all have Wikidata items. In an ideal world, the presets would be scoped to individual fields rather than the whole feature – this is still a railway, not “a” Commuter. But iD hasn’t had any facility for “field presets” ever since NSI grew into more than just a name=* suggestion index. In the past, some presets have had to get trimmed down to avoid this sort of conflict.

I’d still recommend filing an issue about it, because clearly something isn’t right, whatever the solution will end up being.

3 Likes

I created the issue in NSI Github Train route presets inappropriately change type of train · Issue #10469 · osmlab/name-suggestion-index · GitHub

6 Likes

Thanks for that.

Separately, I may ask the Spanish forum if anyone is interested in improving the geographical scope of the presets - I’m not sure if there are regions where two networks overlap. That wouldn’t solve the issue in cities where Renfe operates both commuter and long distance routes, but it should help avoid the arbitrary priority given to Asturias.

Update: Train route presets inappropriately change type of train · Issue #10469 · osmlab/name-suggestion-index · GitHub suggests on NSI Github that the bug lies with iD, not with NSI, and further that it’s been in place since at least October 2024. I do not know if a bug has been filed with iD - I don’t see one linked, I haven’t done it either.

iD Github repository issues linked me to id-tagging-schema repository, where I created the report Public transport presets inappropriately suggest to change type or name of features · Issue #1437 · openstreetmap/id-tagging-schema · GitHub

1 Like