[Talk-us] GNIS tag removal proposal

Greg Morgan dr.kludge.gm at gmail.com
Sat Aug 24 19:22:12 UTC 2013


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_intags 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-us/attachments/20130824/9c60bad5/attachment.html>


More information about the Talk-us mailing list