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
<stevea...@softworkers.com> a écrit :
On Feb 11, 2020, at 12:05 PM, Mark Wagner <mark+...@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@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk
_______________________________________________
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk
