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

Pierre Béland pierzenh at yahoo.fr
Tue Feb 11 23:07:04 UTC 2020


Feb 11, 15:59, stevea wrote :
> 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.
 
I agree with this and I adds some other aspects to take into account below. The areas not yet mapped in OSM have characteristics quite different than the industrialiased regions / countries. And we cannot realistically count on mappers to walk or cycle through huge isolated areas. We cannot expect people that figth to survive, that have no good internet connexion to map intensively there neighboorhood. And more then mappers, we need to think where we need to revise OSM. 

In Africa, I have often used ne highres imagery to retrace official imported border limits that had been traced prior to the availability of detailed aerial imageries.
Also there are remote areas like lake North of Quebec, where we cannot realistically go and walk to trace every lake contour or follow thousand of km of Power lines (+ bears, mosquitos), and we need some assistance for example to trace hundred of thousand lakes like this one (imagery, assisted mapping, imports ??).https://www.openstreetmap.org/way/75891758#map=11/61.3877/-73.4622
Mappers dont add wood cuts for roads and map styles take care of this. Could we have a similar rule applied for Power lines, rivers and lakes ? And any possibility to approach the landcover differently ? Mappers, Schema or Developpers problem ?

What can we do to approach more realistically the problems, to establish good basis for more mapping to come ?
Yes, let's avoid the problem saying this is the bad Canada imports. Or maybe, we should think to revise the OSM schema which is not well adapted for such areas.
There exist distinct Landcover layers like on this Maptiler OSM Vectorial Map  with a distinct Landcover layer
https://openlayers.org/en/latest/examples/mapbox-style.html
If we could keep the wood landcover outside of OSM, it would greatly simplify mapping of such areas and dramatically reduce the Mulipolygons problems where huge multipolygons are created with inner for lakes and all the problems related to this.
Yes the problems must be realistically adressed if we want to progress.
 
Pierre 
 

    Le mardi 11 février 2020 15 h 59 min 12 s UTC−5, stevea <steveaosm at softworkers.com> a écrit :  
 
 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/0ea0756c/attachment-0001.htm>


More information about the talk mailing list