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

[Allan Mustard]

Roland,

Thank you for this very thoughtful set of constructive ideas and
suggestions.

Your cautionary note about voting on solutions is noted.

cheers,
apm

On 6/14/2020 2:56 AM, Roland Olbricht wrote:
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/osmf-talk/attachments/20200614/66737795/attachment.htm>