Thanks Stevea, I really liked your examples. And thank you Mikel - I agree. OSM already has substantial amount of non-physical but relevant information (e.g. many IDs pointing to external registries), and as Stevea points out - even naming for something local could be contradictory (e.g. two fairly large groups of people could refer to the same place/object by different names). I also think OTG should be a general guideline/goal, simply because map could not be complete without some of that information, and the map should be able to reflect difference of opinions to some "reasonable" degree (an intentionally vague term).
On Fri, Feb 7, 2020 at 2:15 PM stevea <stevea...@softworkers.com> wrote: > Without touching the Crimea specifically, I'd like to chime in that > "on-the-ground" (OTG) is a good rule, but in reality it must be approached > more like a goal to be achieved where it can be, as we must acknowledge > that realistically, this rule both cannot be and is not applied everywhere > under all circumstances. That is the simple truth and OSM should not > pretend otherwise. Maybe we need to tighten up our language about how we > define OTG to better acknowledge this, clearly and explicitly. > > A well-known example is (national, other) boundaries, which frequently do > not exist "on the ground," but our map data would be remiss if it excluded > these. So we do our best to include boundaries even as they are not > on-the-ground, but exist in both de pure and de facto ways in the real > world, so OSM expresses them. Yes, when boundaries are disputed, this is > difficult: there is no way around that and it isn't unique to OSM. I like > Mikel's recent suggestion positing that OSM can better develop tagging that > accommodates a wide array of disputes, as we do have plastic tagging and it > can evolve well. > > Other examples include large bodies of water and mountain ranges. I've > lived on the Pacific coast most of my life and been to dozens of beaches, > but never once on any beach have I seen a sign which reads "Pacific > Ocean." Same with no signs at the edge of or in the middle of "Rocky > Mountains" or "The Alps." (I've been, and I haven't seen). Yet, OSM maps > oceans and mountain ranges. How do we know their names without anything on > the ground? It's a tricky question which usually starts with some > hand-waving (especially for enormous, major-chunk-of-planet-sized entities > like oceans), and progresses to "well, everybody simply KNOWS that's the > Pacific Ocean..." and we are faced with OTG and an inherent contradiction > of what we should do, then we do it anyway. (Name something without having > a solid OTG reality). > > To a lesser (weaker) extent, OTG flexibility might also apply to newly > developed routes (bicycle routes are a good example) as these may not be > signed (or well signed), yet a government (whether local, state or > national) expresses these as real (on a public map — just as with a > boundary) and poorly signs or doesn't sign them at all in the real world. > OSM uses "unsigned_ref" to denote these, but it's a fuzzy semantic that > doesn't have wide agreement or even consensus. I have seen the opinion > that these shouldn't be in OSM at all, which seems a shame for things which > many local users (of a bike route decreed by a government, for example) > agree do "exist," yet there isn't any OTG evidence for this. While one > tenet of OSM is "don't copy from other maps," when the only evidence that > something exists is ONLY from a PUBLIC map (yielding us ODbL permission), > we have to reconcile that with OTG. Today, we don't do that very well. > > So, rather than being fully enthusiastic about the absolute application of > OTG (we simply can't), let's realize that it is a good guideline which > should be followed where it can, yet it must include some flexibility which > allows for exceptions. I haven't seen that said (here, yet, perhaps it is > elsewhere) and I believe it is important to be explicit about it. > > SteveA > California > _______________________________________________ > talk mailing list > talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk >
_______________________________________________ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk