Re: [Tagging] any tag you like, but why create parallel systems for established tags? DCGIS
On Sat, Mar 10, 2012 at 6:38 AM, Martin Koppenhoefer wrote: > I recently stumbled upon an import in the US prefixed with "dcgis". > While this tagging makes it possible to have these data inserted > parallely to other OSM data I still wonder why someone would do that. > > In particular I am refering to this: > http://taginfo.openstreetmap.org/keys/dcgis%3Aaddress > > I don't see the point why this is not the usual "addr:street" etc. > > > and there seem to be also other issues: > http://taginfo.openstreetmap.org/search?q=dcgis > > The most used tag in this "namespace" is "dcgis:captureyear" > http://taginfo.openstreetmap.org/keys/dcgis%3Acaptureyear > which can be found 93 022 times in the db but isn't documented in the wiki [1] It seems that you didn't ask any of the users who were involved in this import. This import was done four years ago, with many users and a variety of processes, but I don't get the impression you checked with any of us. I don't see any actual questions in your mail. If you have specific questions, feel free to ask them. - Serge ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] any tag you like, but why create parallel systems for established tags? DCGIS
Il giorno 10/mar/2012 15:25, "Josh Doe" ha scritto: > > On Sat, Mar 10, 2012 at 6:38 AM, Martin Koppenhoefer > wrote: > > Looking at the key name and values this looks like the date when the > > external database included the object in their system. Why on earth > > should we keep track of this in OSM? Doesn't seem to be a > > geoinformation to me. > > I've made a practice of removing all tiger:* tags, and most gnis:* > tags (except feature_id) after verifying a feature. The only external > data that I think belongs in OSM is a reference number (i.e. primary > key, e.g. gnis:feature_id) that can be easily maintained (e.g. no > tiger:tlid), and that should end if/when we have persistent IDs. And I > think we shouldn't use a private namespace but put it under the ref:* > namespace, which makes clear the purpose of the data. > > -Josh > +1 I think that for correlating imported items to the original dataset it's needed only a tag that references the primary key. In italy there's a similar case with lombardy. Stefano > ___ > Tagging mailing list > Tagging@openstreetmap.org > http://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] any tag you like, but why create parallel systems for established tags? DCGIS
On Sat, Mar 10, 2012 at 6:38 AM, Martin Koppenhoefer wrote: > Looking at the key name and values this looks like the date when the > external database included the object in their system. Why on earth > should we keep track of this in OSM? Doesn't seem to be a > geoinformation to me. I've made a practice of removing all tiger:* tags, and most gnis:* tags (except feature_id) after verifying a feature. The only external data that I think belongs in OSM is a reference number (i.e. primary key, e.g. gnis:feature_id) that can be easily maintained (e.g. no tiger:tlid), and that should end if/when we have persistent IDs. And I think we shouldn't use a private namespace but put it under the ref:* namespace, which makes clear the purpose of the data. -Josh ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] any tag you like, but why create parallel systems for established tags? DCGIS
I recently stumbled upon an import in the US prefixed with "dcgis". While this tagging makes it possible to have these data inserted parallely to other OSM data I still wonder why someone would do that. In particular I am refering to this: http://taginfo.openstreetmap.org/keys/dcgis%3Aaddress I don't see the point why this is not the usual "addr:street" etc. and there seem to be also other issues: http://taginfo.openstreetmap.org/search?q=dcgis The most used tag in this "namespace" is "dcgis:captureyear" http://taginfo.openstreetmap.org/keys/dcgis%3Acaptureyear which can be found 93 022 times in the db but isn't documented in the wiki [1] Looking at the key name and values this looks like the date when the external database included the object in their system. Why on earth should we keep track of this in OSM? Doesn't seem to be a geoinformation to me. How should a mapper deal with these tags if he modifies an object? E.g. if there is a dcgis:acquired=6 ( http://taginfo.openstreetmap.org/keys/dcgis%3Aacquired ) on an object he splits? I suggest to modify [1] to not further encourage people to import all of the information from dcgis into osm, but only those that are useful. E.g. these sentences could be modified: "SSL and AID - The AID and SSL attributes are used to correlate the data with the DC MAR (Master Address Record) and should generally be preserved." "Pubdate - DC-GIS data includes a pubdate in the supplementary XML file. This should be included in the features as dcgis:pubdate and the date should be reformatted to -MM-DD" "Dataset - In order to preserve the origin of the data, the dataset should be specified. The naming of these datasets should map to the naming of the zipfile, ie PostOfficePt or ParkPly, the resulting key, value pair would be dc-gis:dataset=ParkPly" These are the keys named in the wiki, but the actual data contains much more keys, which aren't obvious in their meaning (at least to me), or which are almost pointless in a spatial database, or which would be much better suited for a changeset comment then for a tag on the object, e.g. dcgis:area dcgis:gis dcgis:length dcgis:list_info dcgis:nr_eligibl dcgis:update_date dcgis:url cheers, Martin [1] http://wiki.openstreetmap.org/wiki/Washington_DC/DCGIS_imports ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging