<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /></head><body style='font-size: 10pt; font-family: Verdana,Geneva,sans-serif'>
<p>On 2020-02-12 09:28, Martin Koppenhoefer wrote:</p>
<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0">
<div dir="ltr">
<div class="gmail_quote">
<div class="gmail_attr" dir="ltr">I believe it is a misconception to think it must be "visible" on the ground, rather it must be determinable on the ground / "in loco". There might well be nothing to "see", but you could still check on the ground, by talking to the local people, how to map something (particularly, how to call it).</div>
<div> </div>
<div> </div>
<blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left: 1px solid #cccccc; padding-left: 1ex;">Start with "If A, then B" where A is "it is on the ground" and B is "you may map it." Now, try the contrapositive "If not B, then not A" (in logic notation: ¬B -> ¬A). </blockquote>
<div> </div>
<div> </div>
<div>this is not how complex situations work. "If its black it is not colored" does not mean that if its not colored it must be black (could be white, gray, etc.).</div>
<div> </div>
</div>
</div>
</blockquote>
<div dir="ltr">
<div class="gmail_quote">
<div> And this is why we should not try to map a continuum of possibilities onto a binary model. The OTG rule/guideline needs to accommodate these shades of grey. A rule that leads to so much discussion and so many exceptions is clearly not a good rule in its current form. Lets do some process improvement here!</div>
<div> </div>
<div>I want to come back to a point I made a few days ago as well, concerning location accuracy. If a point (possibly on an admin boundary) is imported into OSM from a source which has used cm-level surveying equipment, it is nothing short of WRONG if Joe Bloggs comes along with his $100 smartphone and moves that point based on a 3-satellite 2D GPS fix with a 100m GDOP. Where a boundary coincides with the centre line of a road for example, and there is a discrepancy in OSM between the locations of the two, there should be a recognition that the professionally surveyed locations are more likely to be correct - so in this example the highway should be moved to fit the boundary, and not the other way around! This professional data provides an extremely important collection of reference points, to which other data should be aligned - just like the trig points of older survey systems. OTG IS NOT ALWAYS BETTER!</div>
<div> </div>
<div>Elevations suffer from the same issues - except that the accuracy from GPS is even worse. Don't get me started on the differing definitions of "sea level" leading to meaningless elevations in OSM (because they don't specify to which datum they are relative).</div>
<div> </div>
<div> </div>
<div> </div>
<div> </div>
<div> </div>
</div>
</div>
</body></html>