[Osmf-talk] Toward resolution of controversies related to iD

[Roland Olbricht]

 > I would appreciate receiving thoughts on how a dispute resolution /
 > adjudication mechanism could work, rather than scolding the iD
 > developers. Thank you for any input you can offer.

I would like to contribute.

The following aims at a process to resolve tagging controversies.
Another important issue is as mentioned third party data sources and
implicit mechanical edits, but I'd prefer not to mix these two.
Everything else is, from my experience as a developer, often better
disucssed in the issue tracker, because it is easily off topic for OSM
channels (think of JavaScript questions or details of deployment
mechanisms).

The tag controversies have mostly suffered from misunderstandings. The
developers have modeled something important for the part of the US they
live in that does not exist elsewhere (e.g. in Europe), and used for it
tags that are already with a different meaning in widespread use.
Reusing established tags for a non-existing problem from the POV of the
affected local community created confusion and finally a backlash.

I'll get into details further down. Language is a weak tool when it
comes to precision or comprehensiveness. Partly better fare forms,
because they force you to reflect at least on some topics. For this
reason I suggest to ask in any controversy the participants first to
answer a set of questions:

What is the scope of the issue?

What is the intended effect on rendering?
What is the intended effect on routing? For which types of vehicles?
Are there other use cases that use this information?
For all three: Which combination of tags are meant exactly, and to what
shall default all possible variants?

How often should the features exist due to their definition in the real
world?
How often is the feature already tagged?
What would be a practical mitigation if a difference exists (e.g. accept
a regionally varying definition, refine the tagging, start a retagging
effort)?

To answer this questions does take for each case several hours. This is
intended, because diffcult problems do require to step back and look at
the whole picture, and instant replies are of no help.

How could answering these questions help? Let me give an iD-related example:

In the highway=track controversy it ultimately turned out in
https://github.com/openstreetmap/iD/issues/4092#issuecomment-307452585
that Brian intended to document maintenance for the difference between
"highway=track" and "highway=service". I'm willing to accept that the
clearing time of obstacles after disasters varies significantly in the
US, or maybe some part of the US.

This does not apply to elsewhere. In urbanized Europe, the desire to
have emergency vehicles ready really everywhere and at any time means
that even hiking routes are usually cleared after disasters in less than
24 hours. From a German (as well as Dutch or French and probably other
perspectives), I would tell a road that remains blocked for weeks or
longer rather abandoned than "highway=". In that model, "highway=track"
would be basically unusable because the concept does not exist. Yet
there is a need to distinguish between agriculutural and other uses.

Another situation exists in Iceland: half of the country (the highlands)
are routinely locked of any traffic during winter and spring. This
affects a whole road hierarchy up to secondary roads. Similar situations
apply to mountain passes in the Alps and probably elsewhere. While this
fits the "sometimes not maintained" concept, it is add odds with coding
this in highway, because the tag is needed on the same objects for road
hierarchy.

It took quite a time until we got at this conclusion. We need to educate
ourselves to come up with these regional constraints much earlier.

Had it helped to require answers to the questions first? I would like to
try:

What is the scope of the issue?

Ways tagged with highway=service and ways tagged with highway=track.
Not in scope are all other ways or objects.
In particular those with other values for highway are understood as
being by default for motor vehicles ("motorway" ...
"unclassified"/"residential") or for non-motorized traffic ("cycleway",
"footway", "path", etc.).

What is the intended effect on routing? For which types of vehicles?
Are there other use cases that use information?

In particular here we had figured out earlier that one side understands
"service" to be routable and "track" not. The other side understood
"track" to be routable by default for cyclists and pedestrians, but not
to motor vehicles because of legal restrictions.

It admittetly remains tricky the the whole concept of "unmaintained" way
does not exist here and would be understood synonymus for "abandoned". I
have so far not figured out and question that reliably could detect such
a problem on reflecting how to answer it. Please note that the thing
gets pinpointed if you reflect on whether you would route cyclists or
emergency vehicles along that way (Existing "track" yes, iD-intended
"track" apparently not).

How often should the features exist due to their definition?
How often is the feature already tagged?

Here in Western Europe, the tracks form together with the normal street
grid a complete network to access all parts of all forests for
agricultural vehicles. For the sake of precision, "wood" is usually an
euphemism in Western Europe, because there are no unmanaged bunches of
trees here; in the few intentional wild areas there is management to
minimize human impact. Service roads play no role in that network and
are by default forbidden for the often very heavy forest machines. Again
a point that might have conveyed the difference much earlier.

I do think that other controversies profit from the same approach. I
have sketched the answers for the questions for the problem of zebra
crossings (an issue with iD) and abandoned railways (not an issue with
iD, but currenlty creating substantial traffic on the lists), but I
would like leave that as an exercise to fellow readers. I hope that
somebody else coming up pinpointing those problems along that lines does
confirm that the approach is viable.

Why not use the Wiki Proposal Process?

A short answer could be https://en.wikipedia.org/wiki/Indiana_Pi_Bill
It sums up much of the problems that I can confirm from developer's
perspective. The universe does not crash if a logically impossible law
is ratfied. A software does crash if it gets into a logically impossible
state.

A longer answer is that the important but painful task is to gather
information, for overlapping scopes, accept that universal consent is
neither possible nor desired. We need to encourage people to come up
with relevant information and at the same time be bold not to inundate
everybody with details. Even further, we need to keep people encouraged
to go out and do mapping.

By contrast, the purpose of a voting is always to signal to the minority
that resistance is futile. It is discouraging by nature.

Thus, I suggest to start off with a new process that both keeps people
encouraged to do mapping and to gather the necessary information to make
sense of existing tagging and make tags for existing objects in an
appropriate local context. I'm confident that the list of questions
sketched above can be a starting point.

Best regards,

Roland