<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1251">
</head>
<body>
<p><font face="Helvetica, Arial, sans-serif">Roland,</font></p>
<p><font face="Helvetica, Arial, sans-serif">Thank you for this very
thoughtful set of constructive ideas and suggestions.</font></p>
<p><font face="Helvetica, Arial, sans-serif">Your cautionary note
about voting on solutions is noted.</font></p>
<p><font face="Helvetica, Arial, sans-serif">cheers,<br>
apm</font><br>
</p>
<div class="moz-cite-prefix">On 6/14/2020 2:56 AM, Roland Olbricht
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:d5cc82fa-07bf-eb08-d65a-144c57203d6e@gmx.de">> I
would appreciate receiving thoughts on how a dispute resolution /
<br>
> adjudication mechanism could work, rather than scolding the
iD
<br>
> developers. Thank you for any input you can offer.
<br>
<br>
I would like to contribute.
<br>
<br>
The following aims at a process to resolve tagging controversies.
<br>
Another important issue is as mentioned third party data sources
and
<br>
implicit mechanical edits, but I'd prefer not to mix these two.
<br>
Everything else is, from my experience as a developer, often
better
<br>
disucssed in the issue tracker, because it is easily off topic for
OSM
<br>
channels (think of JavaScript questions or details of deployment
<br>
mechanisms).
<br>
<br>
The tag controversies have mostly suffered from misunderstandings.
The
<br>
developers have modeled something important for the part of the US
they
<br>
live in that does not exist elsewhere (e.g. in Europe), and used
for it
<br>
tags that are already with a different meaning in widespread use.
<br>
Reusing established tags for a non-existing problem from the POV
of the
<br>
affected local community created confusion and finally a backlash.
<br>
<br>
I'll get into details further down. Language is a weak tool when
it
<br>
comes to precision or comprehensiveness. Partly better fare forms,
<br>
because they force you to reflect at least on some topics. For
this
<br>
reason I suggest to ask in any controversy the participants first
to
<br>
answer a set of questions:
<br>
<br>
What is the scope of the issue?
<br>
<br>
What is the intended effect on rendering?
<br>
What is the intended effect on routing? For which types of
vehicles?
<br>
Are there other use cases that use this information?
<br>
For all three: Which combination of tags are meant exactly, and to
what
<br>
shall default all possible variants?
<br>
<br>
How often should the features exist due to their definition in the
real
<br>
world?
<br>
How often is the feature already tagged?
<br>
What would be a practical mitigation if a difference exists (e.g.
accept
<br>
a regionally varying definition, refine the tagging, start a
retagging
<br>
effort)?
<br>
<br>
To answer this questions does take for each case several hours.
This is
<br>
intended, because diffcult problems do require to step back and
look at
<br>
the whole picture, and instant replies are of no help.
<br>
<br>
How could answering these questions help? Let me give an
iD-related example:
<br>
<br>
In the highway=track controversy it ultimately turned out in
<br>
<a class="moz-txt-link-freetext" href="https://github.com/openstreetmap/iD/issues/4092#issuecomment-307452585">https://github.com/openstreetmap/iD/issues/4092#issuecomment-307452585</a>
<br>
that Brian intended to document maintenance for the difference
between
<br>
"highway=track" and "highway=service". I'm willing to accept that
the
<br>
clearing time of obstacles after disasters varies significantly in
the
<br>
US, or maybe some part of the US.
<br>
<br>
This does not apply to elsewhere. In urbanized Europe, the desire
to
<br>
have emergency vehicles ready really everywhere and at any time
means
<br>
that even hiking routes are usually cleared after disasters in
less than
<br>
24 hours. From a German (as well as Dutch or French and probably
other
<br>
perspectives), I would tell a road that remains blocked for weeks
or
<br>
longer rather abandoned than "highway=". In that model,
"highway=track"
<br>
would be basically unusable because the concept does not exist.
Yet
<br>
there is a need to distinguish between agriculutural and other
uses.
<br>
<br>
Another situation exists in Iceland: half of the country (the
highlands)
<br>
are routinely locked of any traffic during winter and spring. This
<br>
affects a whole road hierarchy up to secondary roads. Similar
situations
<br>
apply to mountain passes in the Alps and probably elsewhere. While
this
<br>
fits the "sometimes not maintained" concept, it is add odds with
coding
<br>
this in highway, because the tag is needed on the same objects for
road
<br>
hierarchy.
<br>
<br>
It took quite a time until we got at this conclusion. We need to
educate
<br>
ourselves to come up with these regional constraints much earlier.
<br>
<br>
Had it helped to require answers to the questions first? I would
like to
<br>
try:
<br>
<br>
What is the scope of the issue?
<br>
<br>
Ways tagged with highway=service and ways tagged with
highway=track.
<br>
Not in scope are all other ways or objects.
<br>
In particular those with other values for highway are understood
as
<br>
being by default for motor vehicles ("motorway" ...
<br>
"unclassified"/"residential") or for non-motorized traffic
("cycleway",
<br>
"footway", "path", etc.).
<br>
<br>
What is the intended effect on routing? For which types of
vehicles?
<br>
Are there other use cases that use information?
<br>
<br>
In particular here we had figured out earlier that one side
understands
<br>
"service" to be routable and "track" not. The other side
understood
<br>
"track" to be routable by default for cyclists and pedestrians,
but not
<br>
to motor vehicles because of legal restrictions.
<br>
<br>
It admittetly remains tricky the the whole concept of
"unmaintained" way
<br>
does not exist here and would be understood synonymus for
"abandoned". I
<br>
have so far not figured out and question that reliably could
detect such
<br>
a problem on reflecting how to answer it. Please note that the
thing
<br>
gets pinpointed if you reflect on whether you would route cyclists
or
<br>
emergency vehicles along that way (Existing "track" yes,
iD-intended
<br>
"track" apparently not).
<br>
<br>
How often should the features exist due to their definition?
<br>
How often is the feature already tagged?
<br>
<br>
Here in Western Europe, the tracks form together with the normal
street
<br>
grid a complete network to access all parts of all forests for
<br>
agricultural vehicles. For the sake of precision, "wood" is
usually an
<br>
euphemism in Western Europe, because there are no unmanaged
bunches of
<br>
trees here; in the few intentional wild areas there is management
to
<br>
minimize human impact. Service roads play no role in that network
and
<br>
are by default forbidden for the often very heavy forest machines.
Again
<br>
a point that might have conveyed the difference much earlier.
<br>
<br>
I do think that other controversies profit from the same approach.
I
<br>
have sketched the answers for the questions for the problem of
zebra
<br>
crossings (an issue with iD) and abandoned railways (not an issue
with
<br>
iD, but currenlty creating substantial traffic on the lists), but
I
<br>
would like leave that as an exercise to fellow readers. I hope
that
<br>
somebody else coming up pinpointing those problems along that
lines does
<br>
confirm that the approach is viable.
<br>
<br>
Why not use the Wiki Proposal Process?
<br>
<br>
A short answer could be
<a class="moz-txt-link-freetext" href="https://en.wikipedia.org/wiki/Indiana_Pi_Bill">https://en.wikipedia.org/wiki/Indiana_Pi_Bill</a>
<br>
It sums up much of the problems that I can confirm from
developer's
<br>
perspective. The universe does not crash if a logically impossible
law
<br>
is ratfied. A software does crash if it gets into a logically
impossible
<br>
state.
<br>
<br>
A longer answer is that the important but painful task is to
gather
<br>
information, for overlapping scopes, accept that universal consent
is
<br>
neither possible nor desired. We need to encourage people to come
up
<br>
with relevant information and at the same time be bold not to
inundate
<br>
everybody with details. Even further, we need to keep people
encouraged
<br>
to go out and do mapping.
<br>
<br>
By contrast, the purpose of a voting is always to signal to the
minority
<br>
that resistance is futile. It is discouraging by nature.
<br>
<br>
Thus, I suggest to start off with a new process that both keeps
people
<br>
encouraged to do mapping and to gather the necessary information
to make
<br>
sense of existing tagging and make tags for existing objects in an
<br>
appropriate local context. I'm confident that the list of
questions
<br>
sketched above can be a starting point.
<br>
<br>
Best regards,
<br>
<br>
Roland
<br>
<br>
</blockquote>
</body>
</html>