[Talk-us] GNIS tag removal proposal

Jason Remillard remillard.jason at gmail.com
Sat Aug 24 20:24:25 UTC 2013


Hi Greg,

I think in all the back and forth you missed the fact that the gnis
feature id is staying put. Nobody has suggested removing it. Looking
at the node history it will be obvious if a feature was imported
(which is why we have the history function). The rest of the tags are
going because there is no benefit in maintaining them in OSM, given
the feature id, anybody can look the rest of them up trivially from
the public domain GNIS text file that is available here.

http://geonames.usgs.gov/domestic/download_data.htm

Jason

On Sat, Aug 24, 2013 at 3:22 PM, Greg Morgan <dr.kludge.gm at gmail.com> wrote:
>
>
> On Tue, Aug 20, 2013 at 1:54 PM, Serge Wroclawski <emacsen at gmail.com> wrote:
>>
>> Hi all,
>>
>> I've been looking at the GNIS data and it's quite a mess.
>
>
>
> This is a horribly crafted proposal.   You haven't shown your research why
> but you declare the GNIS tags as a mess.  Your proposal is as good as me
> declaring that all the wikipedia tags are a mess and that they should be
> removed.  You don't explain why you are dead set on damaging the map.  OSM
> advertises itself as a the wiki of maps.  In wikis there is the concept of
> interlinking of wiki data.  The beauty of providing a link to the Wikipedia
> is that is shows corroboration of the map data. Further more, it allows
> people that use the data a way to go to a wiki article and look at more
> information.  Users of the data have the primary key into another database.
>
> Likewise, the gnis information provides that link for corroboration and
> checking the data.  By seeing these tags, I know that this peak is not
> vandalism http://www.openstreetmap.org/browse/node/359252038.  How did the
> thought police miss that name from the colorful West's past?  Moreover, I
> know the name "iandees" as the importer because I have seen his id on many
> features.
>
> Several things happen with these types of automated edits.  One, it changes
> iandees' user id to mine.  The tiger tag removal was horrible for that
> reason.  Now I go in an area an wonder how I did such a bad job on the tiger
> review for some of the streets that were touched. The tiger tag removal
> removed several key names in my area: davehansentiger and balrug kon or
> something like that.
>
> Two, tags like these give me more information on how I should treat a
> feature.  For example, If I all I have is peak= and name=, I have to treat
> this as data that should be carefully handled.   I really appreciate all the
> work that importers have done.  They give me plenty work without having a
> blank map to look at.  Sometimes, I need to make radical edits to what was
> imported because the area changed.  Having those gnis* tags takes away my
> fear that I have just destroyed data that someone spent time putting into
> the map to share with others.
>
> Third, the gnis dates also help me know how old the data that was imported
> is on a number of levels.  When I see NHD data with dates of early 2000, I
> know that the source aerials from that time period may not be of the same
> quality of what we have available now.  I know that the NHD data can be
> improved because there have been a number of floods in my area that have
> changed the line data.  I also know that the original quality of the line
> work may not be as good as what I can generate now with the current aerials.
>
> Fourth, you will be deleting data that I have put in since the imports.  I
> add two tags when I have time to add them.  One is the gnis:feature_id.  I
> do that because it is easy for someone down stream of OSM to have the
> primary key into the GNIS database without parsing any other information.
> In addition, I put in a source tag with the link to the geonames database
> following geonames faq like so
> http://geonames.usgs.gov/pls/gnispublic/f?p=gnispq:3:::NO::P3_FID:1238.
> Using this form removes your session id from a cut and paste link found in a
> browser.
>
> Fifth, I cannot rely on the jurisdiction areas that have been added to the
> map.  There have been enough new mappers in the Phoenix area that all the
> city boundaries are broken and no longer render.  If the areas are intact,
> then they have been bumped enough that I don't think the data is reliable.
> By removing the state and county names you also remove mappers chance of
> adding the beginnings of the http://wiki.openstreetmap.org/wiki/Key:is_in
> tags based on this gnis data. In addition, the state_id and county_id are
> the beginning parts of the census key.
>
>>
>> As a step towards cleaning up the mess, I'd like to discuss removing
>> some extranious gnis tags in the editors (just as we do with TIGER and
>> other tags).
>>
>> I would like to suggest that the editors remove the following tags
>> entirely:
>>
>
> There was a case where someone went through and automatically changed the
> deprecated tag of building:entrance to entrance = main.   That change was
> rolled back because there was more going on and human judgement need to be
> involved.  There is human judgement that needs to be applied here too.
>
> You have say more than this is a "mess".   As I have shown, your proposal
> damages the map data and makes it more difficult on mappers to make changes
> to imported data where it is needed.  Your proposal would make a mess.
>
> Regards,
> Greg
>
> _______________________________________________
> Talk-us mailing list
> Talk-us at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-us
>



More information about the Talk-us mailing list