[OSM-talk] Review of name and boundary tagging - revised and amended guidelines to address and resolve disputes

Bert -Araali- Van Opstal bert.araali.afritastic at gmail.com
Tue Jul 13 11:55:32 UTC 2021

On 12/07/2021 22:15, Christoph Hormann wrote:
> On Monday 12 July 2021, Bert -Araali- Van Opstal wrote:
>> So your comments and opinions are respected, known and repeated
>> multiple times, taken into account, shared by many.
> Small but important correction here:  I did not just express an opinion
> shared by many, i made statements of fact.  You are welcome to
> challange those - but please keep in mind that the validity of these
> statements does not depend on how many people share them as opinions.
Noted and I agree. I will try my best in the rationale to distinguish 
between facts and opinions.
>> [...]
>> A. where are the limits of "on the ground truth" and "verifiability"
>> in OSM,
> The principle of verifiability in mapping in OSM finds its limits in
> (and only in) the fact that there are no firm rules in OSM.  So
> individual mappers are free to ignore the verifiability principle and
> add non-verifiable data (which happens frequently, sometimes to the
> benefit of the project, sometimes to its damage).  But you cannot
> create policy that abolishes or constrains the verifiability
> principle - because that would clash with the principle that there are
> no firm rules in OSM.

I disagree:

Most principles have constraints, even those in OSM. Like for example 
"the freedom of speech" has a constraint when it comes to the targetted 
use or expression of racism, incitement of violence, sexual, religious 
exclusion etc....
With the principle of verifiability we have a guideline that says local 
knowledge may prevail (not on the general page but spread on different 
other wiki pages), by asking locals is a broadly accepted practice. This 
is a strong principle, we should not abandon it but it brings major 
issues. First of all how representative is the "local", single or 
multiple representative for a broader community. How large is the 
"local" community, especially for larger geographical features, f.i. for 
the Pacific Ocean do we have to ask and allow the term and all the local 
language variants of each and every country, islands and islets in the 
Pacific Ocean to be adopted in the name field ? Not only will this cause 
technical issues but also practical issues. Yet any failure to do so is 
exclusive, might be an expression or a targeted policy to cause harm to 
these local communities.
Secondly, to what extend are the locals free and unthreatened to express 
their personal or community preferences. It can be verified with 
surveys, but also surveys, as we all know can be biased.
"No firm rules" is true for most of the guidelines, not for policies, 
especially those adopted and implemented by the OSMF. We have an 
etiquette, it tries to define where the limits are, as a community we 
should be obliged to translate these limits in proper constraints on our 
principle guidelines, have fall back and arbitrary procedures in place 
that clearly define how we react and act if those constraints are 
violated or technically and practically not feasible.
This applies to many tags but is most prominent a challenge with the 
name tagging schemes and boundaries. Abandoning these tags will probably 
lead to a rather empty map and abandoning our objective or principle 
"you are free to use any tag you want" .

It also relates to mapping physical features, advertisements, boundary 
pillars, guideposts, signposts, street names etc... in the "on the 
ground" truth principle. Practices in regard to encroachment (purposely 
or unintended), territory and jurisdiction disputes etc... . We are 
obliged, we MUST address these issues with proper constraints, 
enforcement and arbitrary procedures. It is a MUST in the same line as 
is expected by the world community from f.i. social media. Failure to do 
so makes OSM a perfect vehicle to practice and promote malpractices 
which are not considered appropriate by the world community. Avoiding or 
failure to do so is not an option if we choose to abide to these 
principles, being it strict rules or guidelines.

> So a classical dilemma:  To attack the verifiability principle you would
> need to use the fact that there are no firm rules in OSM.  But that in
> return would thwart any meaningful attack against the verifiability
> principle - because as the wiki used to say (regarding verifiability):
> "By virtue of common sense, it has become an official policy without
> anyone consciously declaring it as such."
What we forget to mention here is how we enforce these guidelines. 
Actions are taken by the DWG, let it be clear in "good faith" (another 
principle) against users participating in editing wars under the 
justification of "vandalism". An expression by individual or small group 
of users of their local values or practices is considered to be resolved 
by a local community. Local communities which are by definition not 
necessarily representative or non-biased in the context. In the cases 
where the editing war doesn't stop we expect the DWG to resolve the 
issue or take corrective and arbitrary actions. Based on what ? 
Principles or guidelines which are not strict, have no constraints or 
strict limits, blocking users based on what, reverting edits to what 
state ? The biased complaint from some part of a local community or 
individual ? With my upmost respect on how the DWG has handled these 
issues so far, but they need a reference framework as a justification 
for the actions we expect them to take. Failure to do so will and has 
lead to subjective, biased actions. May lead to threads of physical harm 
and personal threads.We should, we are obliged, to the DWG to offer them 
a framework of strict rules and references to make decisions and take 
actions which reflect the community consensus, a framework which offers 
them respect and a secure environment to fullfil their challenging mission.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20210713/92aec770/attachment.htm>

More information about the talk mailing list