See, data always have a backstory. Thinking you know what it is, or that you can improve upon OSM by erasing existing data that has a backstory, hmmm, give that one a good, long think first before you do anything. Discuss with others, research, think about past, present and even future data/tagging schemes that might truly improve what you attempt to improve. Doing this is complex and deserves complex treatment, not a gloss-over and quick action.
SteveA > On Mar 17, 2020, at 4:38 PM, stevea <stevea...@softworkers.com> wrote: > > I would like to stress once again how easily it is for intended semantics of > what is meant to be tagged, "improve-tagged" or "tag-modernized so that > people understand the historical context of this tag" to diverge from the > semantics that OTHER volunteers / contributors to OSM glean from these. It > is SO easy for these to be far apart and people to misunderstand one another. > > This entire endeavor is fraught with peril and is one of the most slippery > and dangerous (in the sense of hurt feelings due to misunderstandings, > usually unintentional) in any scheme that has to do with "tagging," as in OSM > with our tags (and their meant-to-be-static, though actually change through > time) semantics. > > Please, let's better understand the very wide aspects of what's going on > here: people invent a tag to mean "something" and perhaps it does for a > while, but it might get stretched with time and might morph to something > else. And/or other tags emerge that better or "more newly" describe a scheme > to tag. Meantime, there are rendering issues (some positive, some negative) > happening in parallel. Even as people are mostly well-intentioned, this > process (especially as the project gets more mature and stretches across > generations of this happening, each cycle might be years or a decade) really > is complex and gives rise to all kinds of tangly, snarly misunderstandings. > Tread lightly, be cautious, try to be open-minded, have both a historical > understanding of how "meanings change over time" (even as we wish they > didn't" and "renderers change over time" (not always exactly in-line with > tagging schemes) as well as a willingness to expand context to the future. > > And perhaps several other things I'm forgetting to mention... and we MIGHT be > able to better solve these issues. We can solve them, we have to be smart, > patient and knowledgable about our past, looking to the future and aware of > how things drift and evolve. That's tough, but doable. > > Whew! > SteveA > >> On Mar 17, 2020, at 4:17 PM, Joseph Eisenberg <joseph.eisenb...@gmail.com> >> wrote: >> >> Unlike some of those who responded, I was not intending this status to >> be a "mark of shame", but rather informative. >> >> As mentioned, some imported tags like "gnis:feature_id=*" are useful >> to keep the Openstreetmap database object directly linked to an object >> in an external database. >> >> That's why I am not suggesting the use of "deprecated" or "obsolete", >> since these tags should not necessarily be removed. >> >> The main reason to mark them is so that mappers and database users >> will understand where the tag came from, and it may suggest that >> mappers will not want to add these tags to objects in the future, >> unless they are also importing features from the same source. >> >> Besides the tags mentioned above, I was thinking about tags like >> "object:postcode=" and "object:housenumber" - this tag is only used in >> Germany on "highway=street_lamp" features which appear to have been >> imported mostly in 2015: http://wiki.openstreetmap.org/wiki/Key:object >> and see taghistory: >> https://taghistory.raifer.tech/#***/object:postcode/ and >> >> So, though the usage numbers are moderately high, it is helpful to >> know that these tags are not really being used, except in that >> particular context. Apparently it makes sense in the context of the >> addressing system there, at least according to the mappers who >> imported the objects. >> >> If a tag which was first used in an imported then becomes popular and >> used frequently by. mappers for new or updated features, then it could >> change to "in use" or even "de facto", just like a "draft" or >> "proposed" tag can change status due to usage over time. >> >> So, just like the status "draft", the status "import" would be a hint >> for mappers and database users, but would not suggest that the tag >> needs to be removed, and it might change status in the future based on >> use by mappers. >> >> -- Joseph Eisenberg >> >> On 3/18/20, Jmapb <jm...@gmx.com> wrote: >>> On 3/17/2020 10:52 AM, Wayne Emerson, Jr. via talk wrote: >>>> However, among your examples you cite "gnis:feature_id=*" The wiki >>>> page for this key notes: >>>> "Unlike other imported tags such as gnis:created=* and >>>> gnis:import_uuid=*, gnis:feature_id=* is meaningful beyond the import. >>>> In fact, some mappers actively add gnis:feature_id=* to features to >>>> cite a verifiable source for the POI's existence or its name." >>> >>> Agree with clemency for gnis:feature_id -- it's handy to be able to >>> crossreference features with the GNIS database, which you can search by >>> feature id here: https://geonames.usgs.gov/apex/f?p=138:1:0::::: >>> >>> J >>> >>> >>> _______________________________________________ >>> talk mailing list >>> talk@openstreetmap.org >>> https://lists.openstreetmap.org/listinfo/talk >>> >> >> _______________________________________________ >> talk mailing list >> talk@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk > > > _______________________________________________ > talk mailing list > talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk _______________________________________________ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
