These two seem to be about trail networks, not transit relations. (As are the first few posts in this thread, before it was derailed into public transit relations and before Mateusz took the initiative on the PT wiki page.)
Regarding the trail networks, was there ever a recommendation to name things (part $country $num)? If not, changes there seem uncontroversial. Wouldn’t cleaning those up be a natural first step? Though that would require work in OSM to actually update the name tags, and work in tooling to make it feasible to still work with the trail relations afterwards, rather than complaints on the mailing list or on the forum or on wiki talk pages…
Every thread eventually comes back to this point. I don’t think we can fully separate any kind of route relation from PTv2 norms (except for route=railway), because it was PTv2 that introduced the useful concept of unidirectional route relations joined by a superrelation of some sort. In practice, this creates a need to disambiguate route relations with overlapping geometries. name=* has been PTv2’s expedient answer for that.
There might be informal recommendations on the wiki to arbitrarily disambiguate route names by section, but I think it’s always been mainly a shortcut that mappers used to optimize their mapping workflows. If we want any prohibition against these suffixes to be durable, we need editors to automatically surface a disambiguator using additional keys, similar to the from=*/to=* solution for disambiguating opposite directions of a route. We’d need to align on a tagging scheme for that.
Some types of route relations, such as highway routes in the U.S., are generally split along administrative boundaries, so we use keys such as is_in:state=* to disambiguate. Wherever the relations are split more arbitrarily for technical reasons, we’ve used from=* and to=*, which are compatible with more software. So, right back to that PTv2 discussion.
The ideas for keys like disambiguator=* or label=* haven’t really taken off, but they would be easier for software to support than a panoply of is_in:*=* keys.
If anyone thinks that in this case it was a bad edit, feel free to revert it.
I know that it potentially may be tricky, that is why I announced it here and in wiki talk page where discussion on that topic is ongoing for years.
Note that I have NOT removed info that complex public transport schema proposal recommends it. And info that it was controversial was there and is still there.
I also deliberately posted info here, so if people think that full-sized proposal is needed to note that misuse of name is bad, they can revert this wiki edit.
I am still quite sure that we have consensus that name misuse is bad even if recommended by some proposal.
I don’t think so, at a global level. If anything, any time I tried to find documentation about “nested route relations” for recreational routes in the wiki, the problem was lack of documentation rather than overly prescriptive documentation.
I think this kind of recommendation is more likely to be found in pages about specific countries or routes. The more formal public transport documentation may well have had an influence by analogy, and by legitimizing the concept of descriptive/redundant name tags. But I think it is at least partly convergent evolution. Both public transport and recreational trail mapping give rise to relations with no name or with identical names. That’s awkward to map with, at least in JOSM where a lot of relation mapping is done. Arguably it is less than optimal in end user applications that use only the name as a label. So mappers have employed similar strategies in both cases.
Arguably the bad precedent here was allowing a small number of people voting on a specialized topic to contradict the normal use of one of the most widely used tags in OSM.
As well as the from/to/via tags, more visibility for the ref and stage tags would help for recreational route relations in some contexts. Probably not for situations where a route has been arbitrarily split for mapper convenience, but there are also routes where the “sub routes” are official stages visible on the ground, either with their own ref or with some kind of identifiable stage number or reference.
In the long run, yes. My point is that, in the short term, editor UIs are probably the reason why we didn’t toss out the formulaic naming guideline any sooner. The JOSM patch hasn’t gotten accepted yet. There will probably be annoyed mappers if someone goes around cleaning up name tags.
We’ve seen a similar story play out in OpenHistoricalMap. The wiki used to recommend putting date ranges inside name=*, until iD and the website started computing the label automatically based on start_date=* and end_date=*. Some mappers continue to put dates in names, despite redundant labeling on the site and in rendered maps, because identical labels in JOSM’s Relation pane are difficult to work with.
It’s not an issue of the JOSM users … it’s an issue of the JOSM developers if anybody, literally nothing is stopping them from using my presets as the default, or at least applying the same updates.
And it is a non-problem because JOSM has a mechanism to address the issue @Minh_Nguyen was pointing out, no development required.
PS: there is a posting from XXXXXXX 2014 pointing out the solution with name_template in a discussion on PTv2 in this forum.
Fundamentally, the flat hierarchy “Relations” box isn’t the best method to browse through them anyway. You can always look at them through the type=route_master listed below (alphabetically by default?).
No, it is still a problem. People (including me, who uses Josm only when absolutely necessary) simply have no idea how to do that. If it should be easy, document it and evangelise that documentation.
iD is also an issue - I’ve had pushback from removing descriptive non-names (where from and to are already set), and unfortunately I have to agree that iD really does not make what’s there clear.
You’re certainly welcome to try, but my experience with the OSM wiki is that the editor base there is more hostile than the map or Wikipedia. Actually on the fence as to whether or not it serves anything other than a historical purpose and call for its deprecation, as taginfo’s examples (other than what has been pulled from the wiki) has pretty much entirely replaced the wiki for me.
Not OWL, it was an email from the server the has the database for map.atownsend.org.uk. Every morning I check the number of certain types of relation in the polygon table there. If there are a different number of relations I get an email, like this:
Loading the first of those in JOSM I can immediately see the problem. Here is the first of those boundaries and here is the other (there’s a spur on the boundary relations and a roundabout is on it; neither are topologically valid multipolygons**). As far as I can see from the changeset, the mapper didn’t ignore any warnings (although I haven’t tried to reproduce myself)
** Obviously at some point I’ll fix it so that they become valid again, hence me giving a description here.
