[OSM-talk] OTG rule, borders & mountains existing | Re: Crimea situation - on the ground

Mikel Maron mikel.maron at gmail.com
Tue Feb 11 21:36:07 UTC 2020


btw, I think it's entirely compatible to follow On the Ground, with tagging that recognizes the distinction between political boundaries and control boundaries.
* Mikel Maron * +14152835207 @mikel s:mikelmaron 

    On Tuesday, February 11, 2020, 03:55:48 PM EST, stevea <steveaosm at softworkers.com> wrote:  
 
 On Feb 11, 2020, at 12:05 PM, Mark Wagner <mark+osm at carnildo.com> wrote:
> Have you actually been to the US-Canada border?  For thousands and
> thousands of kilometers, it's really obvious:
> https://upload.wikimedia.org/wikipedia/commons/a/aa/US-Canada_border_at_Crawford_State_Park_20130629.jpg
> 
> Even when it's not as obvious as in that photo, there are still
> frequent boundary cairns.  And yes, they're mapped in OSM:
> https://www.openstreetmap.org/node/1997617997

I have been there, and in British Columbia, as is your example.  There will always be counter-examples to a claim of "boundaries are not always obvious or indicated on-the-ground," (as you did, here, with a cutline in the real world some of these being mapped in OSM).  Same with mountain ranges, oceans / bodies of water, etc. that have no signage or evidence of them (named as they are) being OTG.  Simply stated, there ARE (and always will be) things we map which are not OTG, making OTG not a rule strictly followed.

However, we map these anyway, and by the thousand.  My point is that OSM shouldn't pretend that the OTG "rule" is absolute, as it isn't.  While I think all of us (even its original proponent in 2007, as Mikel stated earlier) agree that OTG is "an excellent guideline to be followed where it can be," others (Colin, Yuri) here have chimed in or infer that it can't realistically be absolute (as it isn't, and it can't).  Me, too.  There seems to be consensus that "Independent verifiability" is a crucial component of Good Practice in those cases where OTG cannot STRICTLY be followed, as in cases of invisible boundaries, oceans without signage, and mountain ranges where we are forced to concede "well, everybody simply KNOWS that these are 'The Alps' or 'The Rocky Mountains.'"  The solution here is "this (and its correct name) can be independently verified, that's "good enough for OSM" even without OTG evidence.

https://wiki.osm.org/wiki/Talk:Good_practice#Supplementing_and_clarifying_the_On_The_Ground_.22rule.22 has input from Yuri and jeisenberg and I discussing whether unsigned routes qualify for this treatment (we can't see them OTG, but we map them anyway, as a public agency asserts their existence, though it hasn't signed them well).  While routes like this are a relatively minor (lesser) concern about OTG, broader discussion continues here (in talk).  (I'm OK with that).  But lest my suggestion that we modify/soften OTG from a "hard rule" (which it isn't and cannot be) into a wishy-washy, too-ill-defined "guideline," please understand I'm stating OTG isn't a rule.  Rather, it is an excellent guideline to be followed where it can be and is, but it is a fact that it cannot be and is not always followed.  The particulars of how we better apply OTG going forward might be difficult to describe well and reach consensus upon, but we shouldn't let that deter us, even with disagreement.

Rather than get snarled in counter-examples, let's discuss how OTG isn't and can't be strictly followed in many cases.  It IS followed in the majority of cases, but in those corner cases where it isn't, because it can't be ("nothing" is OTG), must be realistically addressed, likely in our wiki where we state the "rule" today, though going forward much better state a "guideline".  I think we can get there, but it remains under discussion / construction.

SteveA
_______________________________________________
talk mailing list
talk at openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk
  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20200211/41057b58/attachment.htm>


More information about the talk mailing list