[Tagging] Roles of route members (was: Merging tagging scheme on wiki pages of Hiking, ...)
kevin.b.kenny at gmail.com
Mon Aug 19 15:51:23 UTC 2019
On Mon, Aug 19, 2019 at 11:02 AM Richard Fairhurst <richard at systemed.net> wrote:
> Let’s say we have a cyclist, new to OSM, who wants to add a newly opened
> section to an existing route. As Peter says, doing this to said
> specification “usually requires lots of JOSM”. The steps involved to do this
> in sorted order are:
> 1. spend half the afternoon trudging through contradictory pages on the OSM
> wiki to find out what you have to do
> 2. apparently it involves this thing called “JOSM”. Download that
> 3. apparently that involves this thing called “Java”. Download that too
> 4. learn to use this 80s throwback of a GIS program with the UI of a
> startled warthog
> 5. find route sorting stuff in JOSM somewhere
> 6. make edit
> 7. get shouted at by sociopaths in changeset comments because unwittingly
> you did something wrong
I'd much rather that the novice's task be:
1. Map the ways making up the new section of the route.
2. If you or your editor can't handle route relations of the
complexity that you encounter, don't worry about it. Either flag the
changeset for review or leave an OSM note indicating that the work is
3. Someone in the community who can handle relations will then have
the geometry already established, so tidying the topology becomes a
Of course, this depends on the solution to step (7) above, for which I
have no good answer.
I have absolutely no problem with tidying a route anywhere within a
hundred miles of my home base if a mapper can explain to me in words
what's in the field, and has created ways so that I have the geometry.
There aren't *that* many routes out there. I understand that route
relations can be complex, and there's no need for everyone to be able
to edit them. If we are a global collaborative community, can't we act
like one and admit that there may be cases that require specialists to
manage? (By the way, the "explain in words" may be a sticking point.
There seem to be a lot of people who want to give me a bucket of data
without explanation, and think that the data speak for themselves.)
There's also something to be said for using the ugly editors to prove
the concept, because at this point, we don't yet know how to do
everything, much less how to make it novice-friendly! The exception is
simple linear routes, and Sarah or I can give you algorithms - or at
least heuristics - for maintaining sort order on those. But we're
perfectly happy to consume those unsorted, precisely because we do
know how to automate cleaning them up.
I do want editors minimally to observe the 'don't break the route'
principle. About 80% of the broken-route problem can be solved simply
by, "when splitting a way, both the pieces become members of any route
relations in which the original way appeared, with the same role if
one is specified, preferably preserving continuity if either or both
endpoints was shared with the neighbouring way in the relation." At
least iD, Meerkartor and JOSM all do that. (It means downloading the
two neighbouring ways. This doesn't appear to be a problem for iD).
It's a purely local check, not requiring full analysis of the route.
I'm willing to delegate all the more complex stuff to a specialist
For what it's worth, I think that the "route editing is complex"
problem partly drives the 'startled warthog' and '1980s throwback'
issues. In my experience, newer and prettier UI's try so very hard to
be pretty and novice-friendly that in many cases, they simply reach a
ceiling of complexity beyond which they can't cope or become an
obstacle to the power user. (I'm looking at *you*, LabView!) Beyond
that point, "ugly but serviceable" starts looking a lot more like the
ideal approach. I'm not saying that any OSM editor falls in this
category, but I've used far too many applications where the UI
designer ruled, and the thing I want to do becomes impossible because
the designer couldn't figure out a way to make it attractive enough.
(I've even had the misfortune of developing applications in that sort
of political environment. They were less than 100% successful.) Of
course, I write this as a grumpy old man, so take my comment as senile
raving if you wish.
73 de ke9tv/2, Kevin
More information about the Tagging