I see two separate issues getting mixed up: firstly, what types of data "belong" in OSM as a matter of principle, and secondly what quality criteria would apply. Clearly for the second point the data needs to be suitably licensed (if it is externally sourced) and it needs to be verifiable so "Joe Public" without any form of privileged access can verify its correctness. These are clearly principles which have existed in OSM for a long time. But a statement that certain whole categories of data do not belong in OSM *because* it sometimes might not be easily verifiable, is going a bit far.
On 2015-09-02 12:30, moltonel 3x Combo wrote: > On 02/09/2015, Colin Smale <colin.sm...@xs4all.nl> wrote: > >> Are you suggesting that parcel boundaries have no place in OSM, or that >> only verifiable sources should be used? Suppose there was a suitably >> licensed source of such boundaries, with authoritative provenance. Would >> you be against this being in OSM on principle? Or is it only your >> supposition that such information cannot be sufficiently verifiable >> which gives rise to your concern? >> >> Anyway, fences, signs etc are not reliable indicators of parcel >> boundaries (where there are land registries), unless the boundary is >> legally described with reference to these physical artefacts. > > I always understood that land property was out of scope for OSM. Do > you know of any osm data which records property ? > > IMHO verifyability is a major issue here. Real-world barriers don't > match the legal ones, borders change regularly (that's a major > difference with admin boundaries), and even the authoritative source > is often murky (I'm now 3-4 months into the process of figuring out > wether I own a piece of land at the back of my garden). > > On top of that, whenever you need to know about land ownership, you > are legally obliged to refer to the authoritative source. Looking up > the info in a crowdsourced db, even if it was completely correct, > would most often be a waste of time.
_______________________________________________ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
