Re: [Tagging] any tag you like, but why create parallel systems for established tags? DCGIS

2012-03-10 Thread Serge Wroclawski
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

2012-03-10 Thread sabas88
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

2012-03-10 Thread Josh Doe
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

2012-03-10 Thread Martin Koppenhoefer
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