On 2020-02-12 09:28, Martin Koppenhoefer wrote:
> 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).
>
>> 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).
>
> 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.).
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!
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!
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).
_______________________________________________
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk
