[Talk-us] GNIS Issues to be aware of (was: dubious church node)

[Mike Thompson]

Here are a few other GNIS issues to be aware of:

1) Duplicates  - As someone else pointed out, the GNIS points were
digitized off of the USGS topo maps.  If a feature is actually in multiple
map sheets (such as a mountain), it may appear multiple times. I believe it
was done by state, so if a feature appears in multiple states there will be
multiple entries in the GNIS (sometimes with slightly different names).  I
have pointed out a large number of such cases to the Board on Geographic
names, but that was after the import to OSM, so you may still encounter
them.

2) Classification - It seems that the GNIS used an automated query to
classify some of the GNIS points.  For example, a "park", particularly in
the western US, can be a broad flat relatively treeless valley. Many of
these types of parks were mis-classified in the GNIS as the recreational
type of park.  I pointed out some of these to the Board on Geographic
names, but again, that was after the import.

Mike
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] GNIS POI populations

[Minh Nguyen]

On 2015-01-28 07:52, Simon Poole wrote:

According to overpass turbo there is the small number of 394 such nodes
(historical hospitals) remaining in the US (excluding Alaska and
Hawaii). Given that this is bad data that actually might have disastrous
consequences, I would suggest that fixing these (and other GNIS junk
that might be misleading) has a slightly higher priority than updating
population numbers.


Eventually we'll have to review every hospital imported from GNIS. 
Since the GNIS data was collected, lots of hospitals in smaller towns 
have been closed or turned into outpatient facilities, with emergency 
services being consolidated into a regional facility. According to the 
wiki, amenity=hospital doesn't imply emergency=yes, but I wonder if that 
nuance is made clear in any OSM clients.


--
m...@nguyen.cincinnati.oh.us


___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] GNIS POI populations

[Simon Poole]

Am 13.01.2015 um 21:29 schrieb Wolfgang Zenker:
...
> In Montana I have removed rather than changed these POIs, as they definitely
> no longer existed before the GNIS import. Removing these for all of the US
> would be a good thing, especially for hospitals. We definitely don't want
> people in an emergency to end up in the middle of an empty field because
> they followed their navigation device to Podunk Hospital (historical).
...

According to overpass turbo there is the small number of 394 such nodes
(historical hospitals) remaining in the US (excluding Alaska and
Hawaii). Given that this is bad data that actually might have disastrous
consequences, I would suggest that fixing these (and other GNIS junk
that might be misleading) has a slightly higher priority than updating
population numbers.

Simon



signature.asc
Description: OpenPGP digital signature
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] GNIS POI populations

[Wolfgang Zenker]

* Minh Nguyen  [150128 09:12]:
> [..]
> It doesn't sound like Paul was proposing to systematically eliminate 
> place=hamlet POIs. It sounds like he was evaluating each one on its merits.

> I do delete GNIS POIs fairly regularly, but not just because they're 
> tagged place=hamlet. It's usually because it's a mobile home park that I 
> can turn into a more accurate landuse=residential. Or it's the name of a 
> railroad junction torn out a century ago that now sits in the middle of 
> wilderness. (There is place=isolated_dwelling in the event that a small 
> cluster of houses is still called by that name.)

I used to delete these now unpopulated railroad junction POIs earlier,
but nowadays I just reclassify them as place=locality because the names
seem to be still in use in many cases.

Wolfgang

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] GNIS POI populations

[Minh Nguyen]

On 2015-01-27 22:42, Greg Morgan wrote:

OSM Inspector[1] has a nice tool to check issues with these
city/town/village/hamlet  POIs.  I updated a bunch of the POIs in
Arizona to the 2010 numbers.  I see that some mappers changed the
values to the estimated value.  Another mapper would change it back to
the 2010 actual numbers.  I have don't have an issue with the
mechanical edits unless the edits would remove gnis id tags or other
useful data.  Just as with the manual edits both the estimated value
and actual 2010 values were close enough.  They correctly raised the
value closer to the 2010 number from the 2000 number.


The original GNIS import was also wildly incorrect in some cases. For 
example, Mount Pleasant, Delaware County, Indiana [1], was given a 
population of 12,459, but it's really an unincorporated community with a 
couple hundred residents at most. The Census doesn't keep any data on 
its population.


Should the mechanical edit remove population tags on places that don't 
correspond to any Census division? Or maybe just flag them for manual 
followup? I guess a local could unofficially guesstimate the population 
of a community like Mount Pleasant.


[1] https://osm.org/changeset/28225500


Deleting?  I question this.  I am not in favor of it.  I think there
is a mismatch between rural America and Metro America areas.  I have a
sense that Metro mappers have a lower value of some POIs that are
essential to rural areas. Vicksburg Junction[2] could be a possible
deletion target.  I am not sure if there is an actual boundary for the
area. Cleator Arizona[3] is another example.  People live there with
real addresses even though it looks like a ghost town.  The best I
could do is make a residential landuse area. There are any number of
small named areas from the Census that are significant names that the
locals use. How do you know that you are not deleting valuable named
data?  Moreover, you can query on "Moon Valley Arizona" and find a
well known area in metro Phoenix.  Sure someday that POI can be made
into an area.  I have wondered what kind of a polygon would be the
correct one for this area. There's no real legal boundary for the
area.  I have already had to dig that POI out of the trash bin once.


It doesn't sound like Paul was proposing to systematically eliminate 
place=hamlet POIs. It sounds like he was evaluating each one on its merits.


I do delete GNIS POIs fairly regularly, but not just because they're 
tagged place=hamlet. It's usually because it's a mobile home park that I 
can turn into a more accurate landuse=residential. Or it's the name of a 
railroad junction torn out a century ago that now sits in the middle of 
wilderness. (There is place=isolated_dwelling in the event that a small 
cluster of houses is still called by that name.)


On the other hand, I have been aggressive about preventing TIGER CDP 
boundaries from rendering, but they're a whole different animal than 
GNIS POIs. They usually end up being so precise as to be inaccurate. 
When I delete a CDP boundary, the map usually continues to show the 
local name thanks to a well-placed GNIS POI.



Finally, why would you want to dash the hopes of a new mapper[1]?  I
shared the excite with a mapper as he talked about his recent project.
He had just put in the Phoenix Urban Planning Villages or whatever
they are called.  Now you can look for "alhambra arizona" and find one
of these areas as a POI.  I am afraid that his victory would fall prey
to your deletions.  If you don't know the area or are not sure, then
just leave it alone.


Phoenix's distinction between Urban Planning Villages and council 
districts reminds me of how other cities distinguish between 
neighborhoods and electoral wards. I favor mapping the former as 
boundary=administrative and admin_level=10, or as a place=suburb POI if 
the boundary is unknown. But I'd leave the latter out of the picture, 
just as I'd avoid mapping state legislative districts. Alhambra [2] 
looks good to me.


[2] https://osm.org/node/150948276

--
m...@nguyen.cincinnati.oh.us


___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] GNIS POI populations

[Greg Morgan]

On Wed, Jan 14, 2015 at 2:29 AM, Paul Norman  wrote:
> On 1/13/2015 5:34 AM, Minh Nguyen wrote:
>>
>> It looks like most of the place=city/town/village/hamlet POIs from GNIS
>> are tagged with 2000 Census populations in the population tag. These
>> population tags allow renderers to label places with font sizes
>> corresponding to population, which is a pretty common use case.

OSM Inspector[1] has a nice tool to check issues with these
city/town/village/hamlet  POIs.  I updated a bunch of the POIs in
Arizona to the 2010 numbers.  I see that some mappers changed the
values to the estimated value.  Another mapper would change it back to
the 2010 actual numbers.  I have don't have an issue with the
mechanical edits unless the edits would remove gnis id tags or other
useful data.  Just as with the manual edits both the estimated value
and actual 2010 values were close enough.  They correctly raised the
value closer to the 2010 number from the 2000 number.


> Although I somewhat like the idea of updating the population tags, I think
> we should give higher priority to fixing their tagging. When I did some
> cleanup of Washington place=city POIs I found that I ended up retagging
> most, deleting many, and only a few were place=city.


Deleting?  I question this.  I am not in favor of it.  I think there
is a mismatch between rural America and Metro America areas.  I have a
sense that Metro mappers have a lower value of some POIs that are
essential to rural areas. Vicksburg Junction[2] could be a possible
deletion target.  I am not sure if there is an actual boundary for the
area. Cleator Arizona[3] is another example.  People live there with
real addresses even though it looks like a ghost town.  The best I
could do is make a residential landuse area. There are any number of
small named areas from the Census that are significant names that the
locals use. How do you know that you are not deleting valuable named
data?  Moreover, you can query on "Moon Valley Arizona" and find a
well known area in metro Phoenix.  Sure someday that POI can be made
into an area.  I have wondered what kind of a polygon would be the
correct one for this area. There's no real legal boundary for the
area.  I have already had to dig that POI out of the trash bin once.

Finally, why would you want to dash the hopes of a new mapper[1]?  I
shared the excite with a mapper as he talked about his recent project.
He had just put in the Phoenix Urban Planning Villages or whatever
they are called.  Now you can look for "alhambra arizona" and find one
of these areas as a POI.  I am afraid that his victory would fall prey
to your deletions.  If you don't know the area or are not sure, then
just leave it alone.

A mechanical edit for populate is safe.  I just don't agree with the
deletion idea!

Regards,
Greg

[1] 
http://tools.geofabrik.de/osmi/?view=places&lon=-112.09991&lat=33.59617&zoom=14&overlays=megacities,largecities,cities,towns,villages,hamlets,islands,suburbs,farms,localities,municipalities,errors_unknown_place_type,errors_population_format,errors_place_without_name,errors_population_number_format,errors_pop_type_mismatch,population

[1] https://www.openstreetmap.org/node/150948419#map=14/33.7224/-113.7690

[3] https://www.openstreetmap.org/node/150957968

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] GNIS POI populations

[Marc Gemis]

Or Overpass + Level0   :-)

regards

m.



On Tue, Jan 13, 2015 at 7:50 PM, Richard Fairhurst 
wrote:

> Minh Nguyen wrote:
> > I think we should consider a mechanical edit to update these tags
>
> While you're thinking about GNIS mechanical edits, could I suggest one for
> GNIS-sourced POIs with "(historical)" in the name?
>
> There are several gazillion amenity=post_office, name=Fred Creek Post
> Office
> (historical) in the database. Clearly these aren't actually post offices
> any
> more. Ideally I guess they should be disused:amenity=post_office, or
> historic:amenity, or something.
>
>
> https://www.google.co.uk/search?q=site%3Aopenstreetmap.org+gnis+historical&gws_rd=ssl
>
> I'd do it myself but this is about the one area where you _do_ need JOSM
> rather than P2. ;)
>
> cheers
> Richard
>
>
>
>
>
> --
> View this message in context:
> http://gis.19327.n5.nabble.com/GNIS-POI-populations-tp5829895p5829925.html
> Sent from the USA mailing list archive at Nabble.com.
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] GNIS POI populations

[Minh Nguyen]

On 2015-01-14 01:29, Paul Norman wrote:

On 1/13/2015 5:34 AM, Minh Nguyen wrote:

It looks like most of the place=city/town/village/hamlet POIs from
GNIS are tagged with 2000 Census populations in the population tag.
These population tags allow renderers to label places with font sizes
corresponding to population, which is a pretty common use case.


I had done a PR which would have added population sorting for place
names, but as a style maintainer I'm interested in what styles use
population for sizes.


Here are a couple that use it:

https://github.com/Citytracking/Terrain
as seen at: http://maps.stamen.com/terrain/
https://github.com/migurski/OSM-Solar

I do see quite a few instances of population-based sorting on GitHub:

https://github.com/search?q=planet_osm_point+population&type=Code

But the difference between 2006 and 2010 populations is unlikely to be 
large enough to matter much for this use case.


Still, weighting city labels by population is a common enough practice 
dating back to the days of paper maps. Someone trying to emulate it with 
OSM data would find the `population` tag much more convenient than 
conflating with an external source, since precision would be less 
important than accuracy.



I think we should consider a mechanical edit to update these tags to
the 2010 Census figures en masse. I've been updating individual places
as I edit them for other reasons, but this tag is most useful when its
vintage is consistent across the board.

Although I somewhat like the idea of updating the population tags, I
think we should give higher priority to fixing their tagging. When I did
some cleanup of Washington place=city POIs I found that I ended up
retagging most, deleting many, and only a few were place=city.


In Ohio and surrounding states, I've seen lots of incorrect `place=city` 
on boundary relations, but all the `place=city` POIs were correct. I 
think the `place` tags on those relations were set to whatever the TIGER 
classification happened to be. On the other hand, there are plenty of 
`place=hamlet`s on POIs that should either be deleted or turned into 
named landuse areas (mostly trailer parks).


--
m...@nguyen.cincinnati.oh.us


___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] GNIS POI populations

[Paul Norman]

On 1/13/2015 5:34 AM, Minh Nguyen wrote:
It looks like most of the place=city/town/village/hamlet POIs from 
GNIS are tagged with 2000 Census populations in the population tag. 
These population tags allow renderers to label places with font sizes 
corresponding to population, which is a pretty common use case.


I had done a PR which would have added population sorting for place 
names, but as a style maintainer I'm interested in what styles use 
population for sizes.


I think we should consider a mechanical edit to update these tags to 
the 2010 Census figures en masse. I've been updating individual places 
as I edit them for other reasons, but this tag is most useful when its 
vintage is consistent across the board. 
Although I somewhat like the idea of updating the population tags, I 
think we should give higher priority to fixing their tagging. When I did 
some cleanup of Washington place=city POIs I found that I ended up 
retagging most, deleting many, and only a few were place=city.


___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] GNIS POI populations

[stevea]

What a fantastic set of discussions we now enjoy here.  Thank you 
Minh and all who contribute.


I essentially agree with every bit of good sense I see in this 
Digest's current era (circa Vol 86, Issue 23):


A way to bot-update (partly, part "smart manual," too) something as 
basic / sensible as cities, towns, suburbs and so on with population 
data (and font-sized renderings...) in our complex data fifty united 
states adds welcome "street cred" to our project.  We have CDPs (with 
and without centroids) we have population entries (thanks, Kristen 
and team!) where we didn't before, we have fresh public numbers every 
decade thanks to our Constitution.  We have moved to harmonize these 
in these talk pages, too, and this shows in histories of our project 
-- this is obvious from the great bridges and roadway we have built. 
Part of this includes documenting how a set of tags achieves a 
specific rendering with commonly used render engines.


I like Serge's idea of incorporating all of these ideas.  These are 
short-to-describe tasks (describing them WELL with AGREEMENT might be 
difficult) and then there is the "accept ownership" aspect (I or a 
team) then takes on.  No doubt, this is some of the hardest work we 
do:  good ideas achieving goal.  OSM being decennial puts us on track 
to being ready for our (the USA's) next decennial census, yes?


But:  good ideas that die because they don't match up with folks to 
do them (well)?  That would be a shame.


Who is for spinning up a skeletal WikiProject page ("US_Cities and 
Census" or somesuch)?  That makes it a wider community essentially 
automagically.  There is nothing like a WikiProject page to instruct, 
achieve and report status (I say from personal experience):  OSM has 
many successful examples.  (Minh was here, too!)


There are some aspects of editing OSM well where JOSM is a superior 
editor compared to iD or Potlatch.  Let's not kid ourselves about 
that.  iD (and Potlatch?) have their place, complex relation editing 
probably isn't a good overlap.  There are clever (and not-so-clever) 
upload scripts, too, but beware hair trigger paint buckets all over 
the map:  Serge is correct to apply quality with manual editing. 
Now, manual editing CAN enter truly high quality data.  However, it 
is manual, and takes time and effort.  This is a balance we juggle.


Shortly said:  keeping or tossing historical objects is a serious 
conversation about semantics and rendering rules.  That said, we see 
what we are doing, especially when spec'd well up front.  Let's spec 
well up front.  (Saying what we mean with semantics of syntax/tagging 
standards, rendering them in reasonable tile time spans, et cetera). 
This works, though takes time, as it is complex to build.  Sausage 
recipes, anybody?  We have those and they keep getting better, too. 
However, volunteer chefs to bake a great map?  Step right up!


(A bit of "want to help," a bit of "project leadership," a bit of 
"technical geekery where required..." we know how to do this).  I 
like the way our map grows; OSM is a great project.


OSM is a feedback loop that looks at itself and looks to improve.  On 
talk-us, we have fifty states, and (tens of, hundreds of?) thousands 
of people who look and care and volunteer.  In OSM, we have millions 
of people looking and caring.  I won't be surprised as that surpasses 
billions (though my measurements are fuzzy, I admit, so in some sense 
it may already be trillions, too).  Lots of people like and use our 
map.  Let's continue to make it as awesome as possible with 
continuing execution of sensible projects.


SteveA
California

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] GNIS POI populations

[Minh Nguyen]

On 2015-01-13 07:22, Serge Wroclawski wrote:

Mihn,

If we do any en-mass edit, there are a few things I think we want to consider:

1. Before anything else, we need to make sure it's community approved,
source data and code examined and approved by the community.


Sure. The code isn't ready yet. My e-mail was more of an early-morning 
musing. :-)


In particular, I noticed that plenty of POIs have an additional 
`census:population` tag that takes the form "1234;2006", where 2006 is a 
year and 1234 is a number that usually doesn't match the value in 
`population`. I'd like to update `population` and replace 
`census:population` with `population:date`, which is far more common 
worldwide.



2. I think that in principle this is a good idea, but we'll also
encounter some issues where census data shows that objects:

a. Have moved
b. Have been renamed
c. Are present in one dataset but not the other


We want to flag these for secondary processing (likely manual).

3. I think it'd be nice, if we're doing en mass mechanical edits, to
connect objects to Wikidata


At the moment, boundary relations are mostly linked to Wikipedia, but 
unfortunately few POIs are part of those relations. (They'd have a role 
of "label", which I think is poorly named, but that's a topic for 
another day.) Since they come from TIGER, the boundary relations also 
generally have the official census name in `tiger:NAMELSAD`, which would 
make step 2 easier.



While it makes sense to keep our own copy of various attributes (like
town/city classifications) in OSM, if we connect the data with
Wikidata, in the future we could pull the data out of Wikidata for
what's classified as what.

They're going to be more inclined to have this kind of data updated
regularly than we are, so this seems like a good way of moving towards
this model, even if today we don't have a way of retrieving the data
from the two datasets and reconciling them.


I'd be okay with #3 being left to a separate task, but I think it
deserves some thought.

- Serge

On Tue, Jan 13, 2015 at 8:34 AM, Minh Nguyen
 wrote:

It looks like most of the place=city/town/village/hamlet POIs from GNIS are
tagged with 2000 Census populations in the population tag. These population
tags allow renderers to label places with font sizes corresponding to
population, which is a pretty common use case.

I think we should consider a mechanical edit to update these tags to the
2010 Census figures en masse. I've been updating individual places as I edit
them for other reasons, but this tag is most useful when its vintage is
consistent across the board.

--
m...@nguyen.cincinnati.oh.us


___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us


___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us




--
m...@nguyen.cincinnati.oh.us


___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] GNIS POI populations

[Wolfgang Zenker]

* Richard Fairhurst  [150113 19:50]:
> Minh Nguyen wrote:
>> I think we should consider a mechanical edit to update these tags

> While you're thinking about GNIS mechanical edits, could I suggest one for
> GNIS-sourced POIs with "(historical)" in the name?

> There are several gazillion amenity=post_office, name=Fred Creek Post Office
> (historical) in the database. Clearly these aren't actually post offices any
> more. Ideally I guess they should be disused:amenity=post_office, or
> historic:amenity, or something.

> https://www.google.co.uk/search?q=site%3Aopenstreetmap.org+gnis+historical&gws_rd=ssl

> I'd do it myself but this is about the one area where you _do_ need JOSM
> rather than P2. ;)

In Montana I have removed rather than changed these POIs, as they definitely
no longer existed before the GNIS import. Removing these for all of the US
would be a good thing, especially for hospitals. We definitely don't want
people in an emergency to end up in the middle of an empty field because
they followed their navigation device to Podunk Hospital (historical).

Checking the other POIs if they have been changed to (historical) status
since the import might also be a good idea.

Wolfgang

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] GNIS POI populations

[Minh Nguyen]

On 2015-01-13 10:50, Richard Fairhurst wrote:

I'd do it myself but this is about the one area where you _do_ need JOSM
rather than P2. ;)


That makes two of us. ;-)

--
m...@nguyen.cincinnati.oh.us


___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] GNIS POI populations

[Richard Fairhurst]

Minh Nguyen wrote:
> I think we should consider a mechanical edit to update these tags

While you're thinking about GNIS mechanical edits, could I suggest one for
GNIS-sourced POIs with "(historical)" in the name?

There are several gazillion amenity=post_office, name=Fred Creek Post Office
(historical) in the database. Clearly these aren't actually post offices any
more. Ideally I guess they should be disused:amenity=post_office, or
historic:amenity, or something.

https://www.google.co.uk/search?q=site%3Aopenstreetmap.org+gnis+historical&gws_rd=ssl

I'd do it myself but this is about the one area where you _do_ need JOSM
rather than P2. ;)

cheers
Richard





--
View this message in context: 
http://gis.19327.n5.nabble.com/GNIS-POI-populations-tp5829895p5829925.html
Sent from the USA mailing list archive at Nabble.com.

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] GNIS POI populations

[Kam, Kristen]

Clifford,

In March 2014,  Chris Zontine (cc’d) and I ADDED city population values for 
nodes that _*did not*_ have a  'population' tag.  We focused on nodes that had 
a "place=city" or "place=town" tag.  We reviewed approximately 625 nodes, 
updated bout 560 of them.  This was a manual editing process that included 
obtaining population figures from the American Factfinder (Census 201).

Just an FYI.

Best,

Kristen


---
Kristen Kam
OSM Profile → http://www.openstreetmap.org/user/KristenK

From: Clifford Snow [mailto:cliff...@snowandsnow.us] 
Sent: Tuesday, January 13, 2015 5:49 AM
To: Minh Nguyen
Cc: talk-us
Subject: Re: [Talk-us] GNIS POI populations


On Tue, Jan 13, 2015 at 5:34 AM, Minh Nguyen  
wrote:
I think we should consider a mechanical edit to update these tags to the 2010 
Census figures en masse. I've been updating individual places as I edit them 
for other reasons, but this tag is most useful when its vintage is consistent 
across the board.

+1



-- 
@osm_seattle
osm_seattle.snowandsnow.us
OpenStreetMap: Maps with a human touch
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] GNIS POI populations

[Serge Wroclawski]

Mihn,

If we do any en-mass edit, there are a few things I think we want to consider:

1. Before anything else, we need to make sure it's community approved,
source data and code examined and approved by the community.

2. I think that in principle this is a good idea, but we'll also
encounter some issues where census data shows that objects:

a. Have moved
b. Have been renamed
c. Are present in one dataset but not the other


We want to flag these for secondary processing (likely manual).

3. I think it'd be nice, if we're doing en mass mechanical edits, to
connect objects to Wikidata

While it makes sense to keep our own copy of various attributes (like
town/city classifications) in OSM, if we connect the data with
Wikidata, in the future we could pull the data out of Wikidata for
what's classified as what.

They're going to be more inclined to have this kind of data updated
regularly than we are, so this seems like a good way of moving towards
this model, even if today we don't have a way of retrieving the data
from the two datasets and reconciling them.


I'd be okay with #3 being left to a separate task, but I think it
deserves some thought.

- Serge

On Tue, Jan 13, 2015 at 8:34 AM, Minh Nguyen
 wrote:
> It looks like most of the place=city/town/village/hamlet POIs from GNIS are
> tagged with 2000 Census populations in the population tag. These population
> tags allow renderers to label places with font sizes corresponding to
> population, which is a pretty common use case.
>
> I think we should consider a mechanical edit to update these tags to the
> 2010 Census figures en masse. I've been updating individual places as I edit
> them for other reasons, but this tag is most useful when its vintage is
> consistent across the board.
>
> --
> m...@nguyen.cincinnati.oh.us
>
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] GNIS POI populations

[Harald Kliems]

I wonder if this isn't something that could be more elegantly solved via
wikidata [1]. It looks like population data is not yet routinely included
in the entries of cities and towns, but to me this would make a lot of
sense. Much easier to maintain than having to regularly do mass mechanical
edits in OSM. Thoughts?

http://wiki.openstreetmap.org/wiki/Proposed_features/Wikidata

On Tue, Jan 13, 2015, 07:50 Clifford Snow  wrote:

>
> On Tue, Jan 13, 2015 at 5:34 AM, Minh Nguyen  > wrote:
>
>> I think we should consider a mechanical edit to update these tags to the
>> 2010 Census figures en masse. I've been updating individual places as I
>> edit them for other reasons, but this tag is most useful when its vintage
>> is consistent across the board.
>
>
> +1
>
>
>
> --
> @osm_seattle
> osm_seattle.snowandsnow.us
> OpenStreetMap: Maps with a human touch
>  ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] GNIS POI populations

[Clifford Snow]

On Tue, Jan 13, 2015 at 5:34 AM, Minh Nguyen 
wrote:

> I think we should consider a mechanical edit to update these tags to the
> 2010 Census figures en masse. I've been updating individual places as I
> edit them for other reasons, but this tag is most useful when its vintage
> is consistent across the board.


+1


-- 
@osm_seattle
osm_seattle.snowandsnow.us
OpenStreetMap: Maps with a human touch
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-us] GNIS POI populations

[Minh Nguyen]

It looks like most of the place=city/town/village/hamlet POIs from GNIS 
are tagged with 2000 Census populations in the population tag. These 
population tags allow renderers to label places with font sizes 
corresponding to population, which is a pretty common use case.


I think we should consider a mechanical edit to update these tags to the 
2010 Census figures en masse. I've been updating individual places as I 
edit them for other reasons, but this tag is most useful when its 
vintage is consistent across the board.


--
m...@nguyen.cincinnati.oh.us


___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] GNIS updating

[Bryce Nesbitt]

On Thu, Jan 9, 2014 at 10:19 PM, Clifford Snow wrote:

>
> On Thu, Jan 9, 2014 at 6:27 PM, Jason Remillard  > wrote:
>
>> If you
>> find a problematic GNIS node (especially natural feature), you should
>> consider sending an email to gnis_mana...@usgs.gov as another QA point
>> for OSM, rather than just deleting it.
>>
>
> Great advise. Can you add this to the gnis wiki?
>

And if you find a notable feature in OSM that's not in GNIS, and are
willing to provide some
documentation beyond OSM itself, there's a form for that.

Example: I found Exclamation Point Point (7702ft) in OSM and finding the
name so neat,
dragged up the documentation on it, and it's now in GNIS.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] GNIS updating

[Clifford Snow]

On Thu, Jan 9, 2014 at 6:27 PM, Jason Remillard
wrote:

> If you
> find a problematic GNIS node (especially natural feature), you should
> consider sending an email to gnis_mana...@usgs.gov as another QA point
> for OSM, rather than just deleting it.
>

Great advise. Can you add this to the gnis wiki?


-- 
Clifford

OpenStreetMap: Maps with a human touch
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-us] GNIS updating

[Jason Remillard]

Hello Everybody,

My winter OSM project is to merge all of the imported GNIS reservoir
points in MA with the actual water ways. It is a manual process, I am
about 60% through it. I have been getting very, very familiar with the
GNIS data set. When I find a confusing, wrong GNIS point, or duplicate
point, I have been sending mail to the GNIS administrator via the
gnis_mana...@usgs.gov. It can take a couple of weeks for them to
respond, but when the do, they send back detailed descriptions of what
they found that often results in more corrections back in OSM. If you
find a problematic GNIS node (especially natural feature), you should
consider sending an email to gnis_mana...@usgs.gov as another QA point
for OSM, rather than just deleting it.

Thanks
Jason

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] GNIS tag removal proposal

[Martin Koppenhoefer]

Am 08/set/2013 um 10:39 schrieb Serge Wroclawski :

> * Reclassify objects which are currently gnis but should be other
> datasets (non-gnis).


being derived from one data set or the other is not an osm classification. Our 
strength is crowd sourced data collection and maintenance / update. All these 
imported tags pointing to external datasets really cramp the db mostly without 
any further use.
It would be great if future imports (if they will be done) would not introduce 
any particular data set tags on object level including source and note. If the 
attribution requirement cannot be fullfilled with attribution in the wiki and 
on changeset level we would simply not import their data.


cheers,
Martin
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] GNIS tag removal proposal

[Paul Norman]

> From: Serge Wroclawski [mailto:emac...@gmail.com]
> Sent: Sunday, September 08, 2013 1:39 AM
> Cc: talk-us@openstreetmap.org; OSM Imports List
> Subject: Re: [Talk-us] GNIS tag removal proposal
> 
> Paul,
> 
> Agreed- and most of why I put this away was that I felt the discussion
> had gone off the rails, with people loudly objecting to things which had
> never been proposed.
> 
> The other suggestions were:
> 
> * Rename identifier tags which have the incorrect tag (feature_id which
> are not feature_id).
> 
> * Reclassify objects which are currently gnis but should be other
> datasets (non-gnis).
> 
> These two suggestions cannot be done "organically" without a concerted
> effort, so we may want to create a separate proposal just to handle
> them, separate from this proposal.

Yes - there's a lot of other cleanup, but I'd like us to start getting 
the benefits of adding it to the discard list right away, then we can 
start working out if/what mechanical edits are necessary to change tags 
or conditionally delete tags.


___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] GNIS tag removal proposal

[Serge Wroclawski]

Paul,

Agreed- and most of why I put this away was that I felt the discussion
had gone off the rails, with people loudly objecting to things which
had never been proposed.

The other suggestions were:

* Rename identifier tags which have the incorrect tag (feature_id
which are not feature_id).

* Reclassify objects which are currently gnis but should be other
datasets (non-gnis).

These two suggestions cannot be done "organically" without a concerted
effort, so we may want to create a separate proposal just to handle
them, separate from this proposal.

- Serge


On Sun, Sep 8, 2013 at 4:54 AM, Paul Norman  wrote:
> To recap and hopefully move forwards, I'm bringing this up again.
>
>> From: Serge Wroclawski [mailto:emac...@gmail.com]
>> Sent: Tuesday, August 20, 2013 1:55 PM
>> Subject: [Talk-us] GNIS tag removal proposal
>>
>> Hi all,
>>
>> I've been looking at the GNIS data and it's quite a mess.
>>
>> 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:
>>
>> gnis:ST_num
>> gnis:ST_alpha
>> gnis:feature_type
>> gnis:created
>> gnis:state_id
>> gnis:county_id
>> gnis:county_name
>> gnis:feature_type
>> gnis:import_uuid
>> gnis:reviewed
>> gnis:edited
>> gnis:description
>> gnis:County
>> gnis:Class
>> gnis:County_num
>
> To summarize the discussion
>
> - Several people objected to the removal of gnis:feature_id, and it's
>   removal was never proposed.
>
> - There was objection to this changing the last edited user, which it
>   wouldn't, it only removes tags when a user is editing the object
>   anyways.
>
>> In addition, I suggest that we remove two other tags conditionally.
>>
>> I suggest we remove the "ele" tag unless the tag natural=peak is present
>> and that we remove "source" if the value for that tag is "USGS Geonames"
>> (which is just GNIS).
>
> - Other cases where ele is useful were pointed out (aeroway)
>
> Given that we don't currently have the technical ability to do this while
> adding to the discarded tag list is easy, I suggest we put this on hold
> until later. We need to have a better look at what GNIS data has an ele=*
> tag and where it is silly.
>
> Unless there are serious objections I plan to open a pull request adding
> listed tags to the discard list.
>
> To reiterate, this does NOT impact gnis:feature_id and the tags will ONLY
> be removed if someone is already editing the object.
>

___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] GNIS tag removal proposal

[Paul Norman]

To recap and hopefully move forwards, I'm bringing this up again.

> From: Serge Wroclawski [mailto:emac...@gmail.com]
> Sent: Tuesday, August 20, 2013 1:55 PM
> Subject: [Talk-us] GNIS tag removal proposal
> 
> Hi all,
> 
> I've been looking at the GNIS data and it's quite a mess.
> 
> 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:
> 
> gnis:ST_num
> gnis:ST_alpha
> gnis:feature_type
> gnis:created
> gnis:state_id
> gnis:county_id
> gnis:county_name
> gnis:feature_type
> gnis:import_uuid
> gnis:reviewed
> gnis:edited
> gnis:description
> gnis:County
> gnis:Class
> gnis:County_num

To summarize the discussion

- Several people objected to the removal of gnis:feature_id, and it's 
  removal was never proposed.   

- There was objection to this changing the last edited user, which it 
  wouldn't, it only removes tags when a user is editing the object 
  anyways.

> In addition, I suggest that we remove two other tags conditionally.
> 
> I suggest we remove the "ele" tag unless the tag natural=peak is present
> and that we remove "source" if the value for that tag is "USGS Geonames"
> (which is just GNIS).

- Other cases where ele is useful were pointed out (aeroway)

Given that we don't currently have the technical ability to do this while 
adding to the discarded tag list is easy, I suggest we put this on hold 
until later. We need to have a better look at what GNIS data has an ele=*
tag and where it is silly.
 
Unless there are serious objections I plan to open a pull request adding 
listed tags to the discard list.

To reiterate, this does NOT impact gnis:feature_id and the tags will ONLY
be removed if someone is already editing the object.


___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] GNIS tag removal proposal

[Jason Remillard]

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  wrote:
>
>
> On Tue, Aug 20, 2013 at 1:54 PM, Serge Wroclawski  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 t

Re: [Talk-us] GNIS tag removal proposal

[Greg Morgan]

On Sat, Aug 24, 2013 at 12:26 PM, Ian Dees  wrote:

> On Sat, Aug 24, 2013 at 2:22 PM, Greg Morgan wrote:
>
>>
>>
>> On Tue, Aug 20, 2013 at 1:54 PM, Serge Wroclawski 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.
>>
>
> Greg, please watch your language. This is a public forum and we're all
> equals here working to improve the map.
>
> Please refrain from using superlatives like "horrible" and maintain a
> positive discourse so that we can all enjoy our time working on this
> volunteer project.
>
>
I am sorry about that.  I thought that I was trying to make a factual
response.

Regards,
Greg
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] GNIS tag removal proposal

[Ian Dees]

On Sat, Aug 24, 2013 at 2:22 PM, Greg Morgan  wrote:

>
>
> On Tue, Aug 20, 2013 at 1:54 PM, Serge Wroclawski 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.
>

Greg, please watch your language. This is a public forum and we're all
equals here working to improve the map.

Please refrain from using superlatives like "horrible" and maintain a
positive discourse so that we can all enjoy our time working on this
volunteer project.

-Ian (as talk-us moderator)
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] GNIS tag removal proposal

[Greg Morgan]

On Tue, Aug 20, 2013 at 1:54 PM, Serge Wroclawski  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
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

[Talk-us] GNIS tag removal proposal

[Ivan Privaci]

> On Aug 21, 2013, at 10:19, Apollinaris Schoell  wrote:
> > The ele tag is of unknown accuracy. It can be off by much more for
> > mountains. This is the case when it's a real steep cliff between the
> > sampling of NED data. found one peak where it was off by 300ft this is
> > simply wrong and not useful.> 
> I'm hesitant to simply remove everything simply because some are inaccurate.
> I'd prefer to find a way to fix the incorrect ones.
> 
> Darrell

I'm a shiny new inexperienced guy here, but I tend to agree with this for
what that's worth. I saw someone else suggest applying "ele:status=estimated" 
for the GNIS-derived elevation tags.

I would also suggest that it's possible some of those "ele=" tags might 
potentially have been 
added or corrected previously, so this process would remove those tags with the 
GNIS ones, right?
(Or am I mistaken about them getting removed? Like I said, I'm "shiny new"...)

In any case, my personal opinion is that having "rough" elevation data is 
better than
having none at all.
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] GNIS tag removal proposal

[Paul Norman]

> From: Serge Wroclawski [mailto:emac...@gmail.com]
> Subject: Re: [Talk-us] GNIS tag removal proposal
> 
> There was another, gnis:fcode, I believe, which people wanted preserved.
> My solution to this ambiguity is to explicitly list the tags to remove,
> rather than say "All gnis tags except X,Y ,Z"

Anything with gnis:fcode is probably not gnis, but badly-converted NHD.

The same applies with gnis:feature_type but that can be safely removed 
because it can be inferred from fcode.

Cleaning up badly imported NHD is a separate matter.


___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] GNIS tag removal proposal

[Darrell Fuhriman]

On Aug 21, 2013, at 10:38, Steven Johnson  wrote:

> I am strenuously in favor of keeping whichever feature ID enables us to know 
> the lineage and provenance of the GNIS point. That bit of metadata can be 
> useful for downstream uses. 

I agree. While I know some are not fans of the various feature ids that many 
imports have, I think they're valuable, and would lean to keeping them where 
possible.

Darrell




smime.p7s
Description: S/MIME cryptographic signature
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] GNIS tag removal proposal

[Serge Wroclawski]

On Wed, Aug 21, 2013 at 1:09 PM, Jason Remillard
 wrote:
> Hi Serge,
>
> - If there are two tags for the feature id, we should pick one and
> change the other one.

There aren't two tags for feature_id, there's only feature_id.

This UUID tag appears to be related to the import script itself, and
isn't part of the GNIS dataset.

> - I would be ok with removing all of the gnis:* tags except the
> feature id. There is no reason for us to maintain the other data.


There was another, gnis:fcode, I believe, which people wanted
preserved. My solution to this ambiguity is to explicitly list the
tags to remove, rather than say "All gnis tags except X,Y ,Z"

> - You might want to keep the ele tags.

We don't keep elevation data in OSM- there are other datasets for
that, and they do a far better job.

There were some objections raised about removing elevation for peaks
(and now another POI), but for schools and other places, elevation is
not part of the data.

- Serge

___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] GNIS tag removal proposal

[Darrell Fuhriman]

On Aug 21, 2013, at 10:19, Apollinaris Schoell  wrote:

> The ele tag is of unknown accuracy. It can be off by much more for mountains. 
> This is the case when it's a real steep cliff between the sampling of NED 
> data. found one peak where it was off by 300ft this is simply wrong and not 
> useful. 
> 

I'm hesitant to simply remove everything simply because some are inaccurate. 
I'd prefer to find a way to fix the incorrect ones.

Darrell



smime.p7s
Description: S/MIME cryptographic signature
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] GNIS tag removal proposal

[Steven Johnson]

I am strenuously in favor of keeping whichever feature ID enables us to
know the lineage and provenance of the GNIS point. That bit of metadata can
be useful for downstream uses.

There are instances where the ele tag is useful, even if only as a rough
guide, but I don't have strong feelings about it.

But I agree with the general sentiment expressed here so far, that the rest
of the tags can safely be deleted.

-- SEJ
-- twitter: @geomantic
-- skype: sejohnson8

There are two types of people in the world. Those that can extrapolate from
incomplete data.


On Wed, Aug 21, 2013 at 1:19 PM, Apollinaris Schoell wrote:

> The ele tag is of unknown accuracy. It can be off by much more for
> mountains. This is the case when it's a real steep cliff between the
> sampling of NED data. found one peak where it was off by 300ft this is
> simply wrong and not useful.
>
>
> On Aug 21, 2013, at 10:09 AM, Jason Remillard 
> wrote:
>
> > Hi Serge,
> >
> > - If there are two tags for the feature id, we should pick one and
> > change the other one.
> > - I don't think the ele tag should be renamed just because it is only
> > accurate to 60m. Everything in the database is an estimate.
> > - I would be ok with removing all of the gnis:* tags except the
> > feature id. There is no reason for us to maintain the other data.
> > - You might want to keep the ele tags.
> >
> > Thanks
> > Jason
> >
> >
> >
> >
> >
> > On Tue, Aug 20, 2013 at 9:24 PM, Kevin Kenny 
> wrote:
> >> On 08/20/2013 04:54 PM, Serge Wroclawski wrote:
> >>>
> >>> In addition, I suggest that we remove two other tags conditionally.
> >>>
> >>> I suggest we remove the "ele" tag unless the tag natural=peak is
> >>> present and that we remove "source" if the value for that tag is "USGS
> >>> Geonames" (which is just GNIS).penny stove
> >>
> >>
> >> ele= is certainly meaningful for aeroways. And I suspect that the
> >> UUID will be meaningful when trying to cross-reference back to the
> >> original data.
> >>
> >>
> >> On 08/20/2013 06:04 PM, Apollinaris Schoell wrote:
> >>>
> >>> go for it.
> >>> actually the ele tag is quite wrong on peaks and should be removed too
> or
> >>> renamed to something like estimated ele
> >>
> >>
> >> Please don't. If you want to add a tag like ele:status=estimated, that
> would
> >> be a better solution. There's always imprecision in elevations; even GPS
> >> usually has considerable vertical dilution of position. An elevation
> derived
> >> from photogrammetric contour lines is better than no elevation at all.
> >>
> >> --
> >> 73 de ke9tv/2, Kevin
> >>
> >>
> >>
> >> ___
> >> Talk-us mailing list
> >> Talk-us@openstreetmap.org
> >> http://lists.openstreetmap.org/listinfo/talk-us
> >
> > ___
> > Talk-us mailing list
> > Talk-us@openstreetmap.org
> > http://lists.openstreetmap.org/listinfo/talk-us
>
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] GNIS tag removal proposal

[Apollinaris Schoell]

The ele tag is of unknown accuracy. It can be off by much more for mountains. 
This is the case when it's a real steep cliff between the sampling of NED data. 
found one peak where it was off by 300ft this is simply wrong and not useful. 


On Aug 21, 2013, at 10:09 AM, Jason Remillard  wrote:

> Hi Serge,
> 
> - If there are two tags for the feature id, we should pick one and
> change the other one.
> - I don't think the ele tag should be renamed just because it is only
> accurate to 60m. Everything in the database is an estimate.
> - I would be ok with removing all of the gnis:* tags except the
> feature id. There is no reason for us to maintain the other data.
> - You might want to keep the ele tags.
> 
> Thanks
> Jason
> 
> 
> 
> 
> 
> On Tue, Aug 20, 2013 at 9:24 PM, Kevin Kenny  wrote:
>> On 08/20/2013 04:54 PM, Serge Wroclawski wrote:
>>> 
>>> In addition, I suggest that we remove two other tags conditionally.
>>> 
>>> I suggest we remove the "ele" tag unless the tag natural=peak is
>>> present and that we remove "source" if the value for that tag is "USGS
>>> Geonames" (which is just GNIS).penny stove
>> 
>> 
>> ele= is certainly meaningful for aeroways. And I suspect that the
>> UUID will be meaningful when trying to cross-reference back to the
>> original data.
>> 
>> 
>> On 08/20/2013 06:04 PM, Apollinaris Schoell wrote:
>>> 
>>> go for it.
>>> actually the ele tag is quite wrong on peaks and should be removed too or
>>> renamed to something like estimated ele
>> 
>> 
>> Please don't. If you want to add a tag like ele:status=estimated, that would
>> be a better solution. There's always imprecision in elevations; even GPS
>> usually has considerable vertical dilution of position. An elevation derived
>> from photogrammetric contour lines is better than no elevation at all.
>> 
>> --
>> 73 de ke9tv/2, Kevin
>> 
>> 
>> 
>> ___
>> Talk-us mailing list
>> Talk-us@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-us
> 
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-us


___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] GNIS tag removal proposal

[Jason Remillard]

Hi Serge,

- If there are two tags for the feature id, we should pick one and
change the other one.
- I don't think the ele tag should be renamed just because it is only
accurate to 60m. Everything in the database is an estimate.
- I would be ok with removing all of the gnis:* tags except the
feature id. There is no reason for us to maintain the other data.
- You might want to keep the ele tags.

Thanks
Jason





On Tue, Aug 20, 2013 at 9:24 PM, Kevin Kenny  wrote:
> On 08/20/2013 04:54 PM, Serge Wroclawski wrote:
>>
>> In addition, I suggest that we remove two other tags conditionally.
>>
>> I suggest we remove the "ele" tag unless the tag natural=peak is
>> present and that we remove "source" if the value for that tag is "USGS
>> Geonames" (which is just GNIS).penny stove
>
>
> ele= is certainly meaningful for aeroways. And I suspect that the
> UUID will be meaningful when trying to cross-reference back to the
> original data.
>
>
> On 08/20/2013 06:04 PM, Apollinaris Schoell wrote:
>>
>> go for it.
>> actually the ele tag is quite wrong on peaks and should be removed too or
>> renamed to something like estimated ele
>
>
> Please don't. If you want to add a tag like ele:status=estimated, that would
> be a better solution. There's always imprecision in elevations; even GPS
> usually has considerable vertical dilution of position. An elevation derived
> from photogrammetric contour lines is better than no elevation at all.
>
> --
> 73 de ke9tv/2, Kevin
>
>
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-us

___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] GNIS tag removal proposal

[Serge Wroclawski]

On Tue, Aug 20, 2013 at 9:24 PM, Kevin Kenny  wrote:

> And I suspect that the
> UUID will be meaningful when trying to cross-reference back to the
> original data.

Are you confusing the UUID with gnis:feature_id ?

- Serge

___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] GNIS tag removal proposal

[Kevin Kenny]

On 08/20/2013 04:54 PM, Serge Wroclawski wrote:

In addition, I suggest that we remove two other tags conditionally.

I suggest we remove the "ele" tag unless the tag natural=peak is
present and that we remove "source" if the value for that tag is "USGS
Geonames" (which is just GNIS).penny stove


ele= is certainly meaningful for aeroways. And I suspect that the
UUID will be meaningful when trying to cross-reference back to the
original data.

On 08/20/2013 06:04 PM, Apollinaris Schoell wrote:

go for it.
actually the ele tag is quite wrong on peaks and should be removed too 
or renamed to something like estimated ele 


Please don't. If you want to add a tag like ele:status=estimated, that 
would be a better solution. There's always imprecision in elevations; 
even GPS usually has considerable vertical dilution of position. An 
elevation derived from photogrammetric contour lines is better than no 
elevation at all.


--
73 de ke9tv/2, Kevin


___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] GNIS tag removal proposal

[Jason Remillard]

Hi Serge,

I am 100% OK, removing these tags.

Thanks
Jason.

On Tue, Aug 20, 2013 at 4:54 PM, Serge Wroclawski  wrote:
> Hi all,
>
> I've been looking at the GNIS data and it's quite a mess.
>
> 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:
>
> gnis:ST_num
> gnis:ST_alpha
> gnis:feature_type
> gnis:created
> gnis:state_id
> gnis:county_id
> gnis:county_name
> gnis:feature_type
> gnis:import_uuid
> gnis:reviewed
> gnis:edited
> gnis:description
> gnis:County
> gnis:Class
> gnis:County_num
>
>
> In addition, I suggest that we remove two other tags conditionally.
>
> I suggest we remove the "ele" tag unless the tag natural=peak is
> present and that we remove "source" if the value for that tag is "USGS
> Geonames" (which is just GNIS).
>
> I'd like to open a discussion about these tags, or other tags people
> suggest removing from gnis data.
>
> - Serge
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-us

___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] GNIS tag removal proposal

[Bryce Nesbitt]

I'd be more excited by a proposal to de-dupe GNIS data... but the tag
cleanup is basically OK.
It would be nice if the editors more loudly removed these tags.  Silent is
bad. That said:

*Explicitly Preserve:* gnis:feature_id gnis:id
*Consider deprecating*: gnis:edited, gnis:Cell, gnis:review,
gnis:import_UUID, import_uuid=gnis.*

I'm not sure I'm smart enough to conclude that natural=peak is the only use
for ele=.  Any aeroway tag is a candidate to keep.  But definitely keep the
ele=, it's useful, and the best we have in many many many cases, despite
limited resolution.

I've created a wiki page so that editors which link to the wiki have
somewhere to go:
http://wiki.openstreetmap.org/wiki/Key:gnis:feature_id
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] GNIS tag removal proposal

[Mike Thompson]

The elevation attached to a GNIS point is taken from the National Elevation
Dataset (NED) which has a 30 meter resolution in many cases (can be as high
a resolution as 1 meter and as low a resolution as 60 meters depending on
the location).  This means that you don't get the highest elevation, only
*an* elevation within the 30 meter square.  The problem is further
compounded by the fact that GNIS locations are often not precise, and
therefore the elevation is drawn from the wrong location within the NED.

Agree that for peaks it should be renamed (if it hasn't been edited by a
human).



On Tue, Aug 20, 2013 at 4:04 PM, Apollinaris Schoell wrote:

> go for it.
> actually the ele tag is quite wrong on peaks and should be removed too or
> renamed to something like estimated ele
>
>
> On 8/20/2013 1:54 PM, Serge Wroclawski wrote:
>
>> Hi all,
>>
>> I've been looking at the GNIS data and it's quite a mess.
>>
>> 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:
>>
>> gnis:ST_num
>> gnis:ST_alpha
>> gnis:feature_type
>> gnis:created
>> gnis:state_id
>> gnis:county_id
>> gnis:county_name
>> gnis:feature_type
>> gnis:import_uuid
>> gnis:reviewed
>> gnis:edited
>> gnis:description
>> gnis:County
>> gnis:Class
>> gnis:County_num
>>
>>
>> In addition, I suggest that we remove two other tags conditionally.
>>
>> I suggest we remove the "ele" tag unless the tag natural=peak is
>> present and that we remove "source" if the value for that tag is "USGS
>> Geonames" (which is just GNIS).
>>
>> I'd like to open a discussion about these tags, or other tags people
>> suggest removing from gnis data.
>>
>> - Serge
>>
>> __**_
>> Talk-us mailing list
>> Talk-us@openstreetmap.org
>> http://lists.openstreetmap.**org/listinfo/talk-us
>>
>
>
> __**_
> Talk-us mailing list
> Talk-us@openstreetmap.org
> http://lists.openstreetmap.**org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] GNIS tag removal proposal

[Apollinaris Schoell]

go for it.
actually the ele tag is quite wrong on peaks and should be removed too 
or renamed to something like estimated ele


On 8/20/2013 1:54 PM, Serge Wroclawski wrote:

Hi all,

I've been looking at the GNIS data and it's quite a mess.

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:

gnis:ST_num
gnis:ST_alpha
gnis:feature_type
gnis:created
gnis:state_id
gnis:county_id
gnis:county_name
gnis:feature_type
gnis:import_uuid
gnis:reviewed
gnis:edited
gnis:description
gnis:County
gnis:Class
gnis:County_num


In addition, I suggest that we remove two other tags conditionally.

I suggest we remove the "ele" tag unless the tag natural=peak is
present and that we remove "source" if the value for that tag is "USGS
Geonames" (which is just GNIS).

I'd like to open a discussion about these tags, or other tags people
suggest removing from gnis data.

- Serge

___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us



___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] GNIS tag removal proposal

[Peter Dobratz]

+1


On Tue, Aug 20, 2013 at 4:54 PM, Serge Wroclawski  wrote:

> Hi all,
>
> I've been looking at the GNIS data and it's quite a mess.
>
> 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:
>
> gnis:ST_num
> gnis:ST_alpha
> gnis:feature_type
> gnis:created
> gnis:state_id
> gnis:county_id
> gnis:county_name
> gnis:feature_type
> gnis:import_uuid
> gnis:reviewed
> gnis:edited
> gnis:description
> gnis:County
> gnis:Class
> gnis:County_num
>
>
> In addition, I suggest that we remove two other tags conditionally.
>
> I suggest we remove the "ele" tag unless the tag natural=peak is
> present and that we remove "source" if the value for that tag is "USGS
> Geonames" (which is just GNIS).
>
> I'd like to open a discussion about these tags, or other tags people
> suggest removing from gnis data.
>
> - Serge
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

[Talk-us] GNIS tag removal proposal

[Serge Wroclawski]

Hi all,

I've been looking at the GNIS data and it's quite a mess.

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:

gnis:ST_num
gnis:ST_alpha
gnis:feature_type
gnis:created
gnis:state_id
gnis:county_id
gnis:county_name
gnis:feature_type
gnis:import_uuid
gnis:reviewed
gnis:edited
gnis:description
gnis:County
gnis:Class
gnis:County_num


In addition, I suggest that we remove two other tags conditionally.

I suggest we remove the "ele" tag unless the tag natural=peak is
present and that we remove "source" if the value for that tag is "USGS
Geonames" (which is just GNIS).

I'd like to open a discussion about these tags, or other tags people
suggest removing from gnis data.

- Serge

___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] GNIS?

[Bryce Nesbitt]

On Mon, Jun 17, 2013 at 7:56 AM, Clifford Snow wrote:
>
> At last years SOTM-US conference, USGS showed a pilot  program using a
> modified version of Potlatch2 to update GNIS database with volunteers. If
> they use this plan, the id tag could be used to compare OSM with the new
> data. It would us to compare the existing OSM data with the new GNIS data.
> For now I would suggest leaving that tag in OSM.
>

Any conflation (matting of new data to OSM data) should use multiple fuzzy
clues: location, name, type.
The gnis id tag is useful as a fuzzy clue.
Every clue is useful.

I think *keeping* the tag makes sense, even though *depending* on the tag
would be asking too much.
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] GNIS?

[Mike N]

On 6/17/2013 10:56 AM, Clifford Snow wrote:

At last years SOTM-US conference, USGS showed a pilot  program using a
modified version of Potlatch2 to update GNIS database with volunteers.
If they use this plan, the id tag could be used to compare OSM with the
new data. It would us to compare the existing OSM data with the new GNIS
data. For now I would suggest leaving that tag in OSM.


 I got a chance to catch his presentation on this year's video (Thanks 
SOTM-US video production crew and posters!).   I will be looking forward 
to being able to use the results of MapCorps efforts.


  I agree that leaving the tag in OSM is the best course, but it's 
likely to only be an advisory clue when merging data, if it's used at all:


 -  Many times, local churches or schools had a new building built 
anywhere from a mile away to across town.  If the name was retained, I 
simply moved the GNIS node.   The updated GNIS information may simply 
mark this as XYZ school (historical) and keep its position.Or they 
may delete it and assign a new ID to whatever the building is now used 
for.


 - If someone has already added a node or way representing the new GNIS 
object, the conflation process still needs to handle the case of same or 
similar name but no GNIS ID.




___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] GNIS?

[the Old Topo Depot]

Jim McAndrew, one of the US Board Members, gave a presentation on the USGS
National Map Corps project status on June 9th (
http://stateofthemap.us/sunday.html#schedule/sunday/usgs-national-map-corps).
 I recommend the community work with Jim and his colleagues to ensure the
most effective exchange of data updates between OSM and the USGS mapping
community.




On Mon, Jun 17, 2013 at 7:56 AM, Clifford Snow wrote:

>
> On Mon, Jun 17, 2013 at 2:49 AM, Mike N  wrote:
>
>> At one time, there was a plan for the USGS to use updated GNIS from OSM,
>> but I think that plan has become stranded on the island of license
>> incompatibility.   Therefore, even the GNIS id tag isn't critical IMO.
>
>
> At last years SOTM-US conference, USGS showed a pilot  program using a
> modified version of Potlatch2 to update GNIS database with volunteers. If
> they use this plan, the id tag could be used to compare OSM with the new
> data. It would us to compare the existing OSM data with the new GNIS data.
> For now I would suggest leaving that tag in OSM.
>
>
> --
> Clifford
>
> OpenStreetMap: Maps with a human touch
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-us
>
>


-- 
John Novak
585-OLD-TOPOS (585-653-8676)
http://www.linkedin.com/in/johnanovak/
OSM ID:oldtopos
OSM Heat Map: http://yosmhm.neis-one.org/?oldtopos
OSM Edit Stats:http://hdyc.neis-one.org/?oldtopos
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] GNIS?

[Clifford Snow]

On Mon, Jun 17, 2013 at 2:49 AM, Mike N  wrote:

> At one time, there was a plan for the USGS to use updated GNIS from OSM,
> but I think that plan has become stranded on the island of license
> incompatibility.   Therefore, even the GNIS id tag isn't critical IMO.


At last years SOTM-US conference, USGS showed a pilot  program using a
modified version of Potlatch2 to update GNIS database with volunteers. If
they use this plan, the id tag could be used to compare OSM with the new
data. It would us to compare the existing OSM data with the new GNIS data.
For now I would suggest leaving that tag in OSM.


-- 
Clifford

OpenStreetMap: Maps with a human touch
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] GNIS?

[Mike N]

On 6/16/2013 7:20 PM, Thomas Colson wrote:

Is it preferable to keep the original GNIS tags if updating a GNIS object in
OSM?


 It's fine to leave or delete all GNIS tags.  If creating an object 
with an area, I just copy all GNIS tags and merge tags from duplicate 
objects.


  At one time, there was a plan for the USGS to use updated GNIS from 
OSM, but I think that plan has become stranded on the island of license 
incompatibility.   Therefore, even the GNIS id tag isn't critical IMO.



___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] GNIS?

[Bryce Nesbitt]

On Sun, Jun 16, 2013 at 4:20 PM, Thomas Colson wrote:

> Is it preferable to keep the original GNIS tags if updating a GNIS object
> in
> OSM?


I preserve the GNIS id number, even if I convert the feature from node to
way (or vice versa).
I do this not so much for later conflation, but as it acts effectively as a
"source" tag, adding useful
richness to the node history.

The GNIS import created many duplicates: there I tend to merge tags rather
than delete information
someone may have a use for in the future.  We're not sort of disk space,
and it's hard to predict
what's useful later.
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] GNIS?

[Mike Thompson]

> For bench marked peaks, we stick with the NGS-published elevation, which
I believe most of them have been converted to the latest and greatest Geoid
model.
Sounds like a great approach!


>  However, we do have a lot of GNIS peaks that aren’t bench marked. For
some (the ones the peak baggers blog about), we send up a team with a
survey-grade GPS and get an OPUS solution of the elevation, which is within
4-6 in of true.
I would volunteer for helping do that.

Mike
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] GNIS?

[Thomas Colson]

For bench marked peaks, we stick with the NGS-published elevation, which I
believe most of them have been converted to the latest and greatest Geoid
model. However, we do have a lot of GNIS peaks that aren't bench marked. For
some (the ones the peak baggers blog about), we send up a team with a
survey-grade GPS and get an OPUS solution of the elevation, which is within
4-6 in of true. 

 

From: Mike Thompson [mailto:miketh...@gmail.com] 
Sent: Sunday, June 16, 2013 8:13 PM
Cc: talk-us
Subject: Re: [Talk-us] GNIS?

 

> BTW, for most peaks are there not "official" elevations?  

The National Geodetic Survey maintains a datasheet for each benchmark,
including those on peaks (http://www.ngs.noaa.gov/cgi-bin/ds_radius.prl).
The datasheet lists the official elevation.  Much easier, although less fun,
than summit each peak with GPS equipment.  

 

___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] GNIS?

[Mike Thompson]

> BTW, for most peaks are there not "official" elevations?
The National Geodetic Survey maintains a datasheet for each benchmark,
including those on peaks (http://www.ngs.noaa.gov/cgi-bin/ds_radius.prl).
 The datasheet lists the official elevation.  Much easier, although less
fun, than summit each peak with GPS equipment.
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] GNIS?

[Clifford Snow]

On Sun, Jun 16, 2013 at 4:20 PM, Thomas Colson wrote:

> Is it preferable to keep the original GNIS tags if updating a GNIS object
> in
> OSM? E.g. updating say the location and elevation, everything else is the
> same. In context, GNIS mountain is here, but really it's there (which is
> usually the case for GNIS).
>
> Or, just leave the GNIS object alone, and add a new OSM feature? Not sure
> how folks feel about GNIS.
>

According to the wiki, http://wiki.openstreetmap.org/wiki/GNIS feel free to
modify or remove the tag. The wiki does suggest leaving tag gnis:feature_id
unless the node is being removed. If you are adding a building polygon, for
example a fire station, merge the gnis tags with the building outline.


-- 
Clifford

OpenStreetMap: Maps with a human touch
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] GNIS?

[Mike Thompson]

The wiki (http://wiki.openstreetmap.org/wiki/GNIS) doesn't mention "source
date", but it does mention:

   - gnis:created = *MM/DD/ when the GNIS entry was created  *

*
*
I presume that "source date" is the date of the export from the GNIS which
was then imported to OSM.  Might be useful if someone wants to compare OSM
to GNIS in the future as the two sources will diverge over time.

BTW, for most peaks are there not "official" elevations?

Mike


On Sun, Jun 16, 2013 at 5:42 PM, Thomas Colson wrote:

> We’re using Lidar (+/- 19 cm vertical precision) and/or OPUS GPS for
> elevations of highest point as determined by zonal statistics, or the brass
> disc found on many peaks. On that note, though, while preserving the tags,
> if you modify the elevation, do you keep the GNIS source date?
>
> ** **
>
> *From:* Mike Thompson [mailto:miketh...@gmail.com]
> *Sent:* Sunday, June 16, 2013 7:33 PM
> *To:* Thomas Colson
> *Subject:* Re: [Talk-us] GNIS?
>
> ** **
>
> I preserve the tags.  It is easy to do.
>
> ** **
>
> BTW, the reason the elevation of the GNIS mountain peaks is incorrect is
> that GNIS takes the elevation from the National Elevation Dataset.  This is
> a gridded dataset.  The value for any particular grid cell will generally
> not be the same as any particular surveyed spot height within it.
>
> ** **
>
> Mike
>
> ** **
>
> On Sun, Jun 16, 2013 at 5:20 PM, Thomas Colson 
> wrote:
>
> Is it preferable to keep the original GNIS tags if updating a GNIS object
> in
> OSM? E.g. updating say the location and elevation, everything else is the
> same. In context, GNIS mountain is here, but really it's there (which is
> usually the case for GNIS).
>
> Or, just leave the GNIS object alone, and add a new OSM feature? Not sure
> how folks feel about GNIS.
>
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-us
>
> ** **
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-us
>
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] GNIS?

[Thomas Colson]

We're using Lidar (+/- 19 cm vertical precision) and/or OPUS GPS for
elevations of highest point as determined by zonal statistics, or the brass
disc found on many peaks. On that note, though, while preserving the tags,
if you modify the elevation, do you keep the GNIS source date?

 

From: Mike Thompson [mailto:miketh...@gmail.com] 
Sent: Sunday, June 16, 2013 7:33 PM
To: Thomas Colson
Subject: Re: [Talk-us] GNIS?

 

I preserve the tags.  It is easy to do.

 

BTW, the reason the elevation of the GNIS mountain peaks is incorrect is
that GNIS takes the elevation from the National Elevation Dataset.  This is
a gridded dataset.  The value for any particular grid cell will generally
not be the same as any particular surveyed spot height within it.

 

Mike

 

On Sun, Jun 16, 2013 at 5:20 PM, Thomas Colson 
wrote:

Is it preferable to keep the original GNIS tags if updating a GNIS object in
OSM? E.g. updating say the location and elevation, everything else is the
same. In context, GNIS mountain is here, but really it's there (which is
usually the case for GNIS).

Or, just leave the GNIS object alone, and add a new OSM feature? Not sure
how folks feel about GNIS.


___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

 

___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] GNIS?

[Jason Remillard]

Hi Thomas,

I don't know if we/OSM have a policy for dealing with the gnis imported data.

I have been deleting all of the gnis tags except gnis:feature_id. The
justification for deleting them is that given the gnis:feature_id and
its position, the rest of the tags can be recreated from original data
source. Not sure why they were imported. Sometimes I feel like we
should not even be maintaining the gnis id. I know other mappers just
delete all of the gnis: tags when merging them with other OSM
features. I am not sure when the import was done we signed up for
maintaining the gnis:feature_id going forward for all of our points of
interest.

The gnis nodes are usually deleted and merged with another feature,
usually a building. The imported gnis node accuracy is not that great,
I have seem then several hundred yards off. Don't be afraid of moving
them if you know where the node should be with higher accuracy. Also,
if you have better elevation data, feel free to update it.

For sure, don't leave them alone.

Thanks
Jason.

On Sun, Jun 16, 2013 at 7:20 PM, Thomas Colson  wrote:
> Is it preferable to keep the original GNIS tags if updating a GNIS object in
> OSM? E.g. updating say the location and elevation, everything else is the
> same. In context, GNIS mountain is here, but really it's there (which is
> usually the case for GNIS).
>
> Or, just leave the GNIS object alone, and add a new OSM feature? Not sure
> how folks feel about GNIS.
>
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-us

___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

[Talk-us] GNIS?

[Thomas Colson]

Is it preferable to keep the original GNIS tags if updating a GNIS object in
OSM? E.g. updating say the location and elevation, everything else is the
same. In context, GNIS mountain is here, but really it's there (which is
usually the case for GNIS). 

Or, just leave the GNIS object alone, and add a new OSM feature? Not sure
how folks feel about GNIS. 


___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] GNIS points improvement

[Ian Dees]

On Mon, Dec 19, 2011 at 12:04 PM, Martijn van Exel  wrote:

>
> Another thing: I queried for the occurence gnis:feature_id but there
> is also features with other sets of GNIS tags. Are those different
> imports / are they from different datasets?
>
> Example of 'type 1'
> http://www.openstreetmap.org/browse/node/150937600 (having a
> 'gnis:id')
> Example of 'type 2'
> http://www.openstreetmap.org/browse/node/356682786 (having a
> 'gnis:feature_id')


Your "type 1" was imported by beej71 before I did an import of "type 2".
There was another GNIS import at some point that brought in some other GNIS
feature types that I didn't do and I seem to remember that there may have
been some sort of change to my GNIS import to change the "hospitals" with
"clinic" or "nursing home" in their names to something more specific than
"hospital". That may account for your large number of v2 elements.
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

[Talk-us] GNIS points improvement

[Martijn van Exel]

I just ran a query on the database for GNIS imported points features
against version:

"count" "version"
680175  1
193999  2
57436   3
74944
16615
309 6
103 7
30  8
14  9
4   10
5   11
3   12
3   13
1   14
1   15
1   22

I would love to believe that v2 GNIS points are actually
human-improved - or was there another bot run over the GNIS import?

Another thing: I queried for the occurence gnis:feature_id but there
is also features with other sets of GNIS tags. Are those different
imports / are they from different datasets?

Example of 'type 1'
http://www.openstreetmap.org/browse/node/150937600 (having a
'gnis:id')
Example of 'type 2'
http://www.openstreetmap.org/browse/node/356682786 (having a
'gnis:feature_id')
-- 
martijn van exel
geospatial omnivore
1109 1st ave #2
salt lake city, ut 84103
801-550-5815
http://oegeo.wordpress.com

___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] GNIS - All Feature_Classes Imported?

[Mike Thompson]

Alan,

Thanks for your reply.

Does anyone have an issue if I work on adding these for Colorado?  The
GNIS defines a "Pillar" (I misspoke when I said Pinnacle) as

===
Pillar  Vertical, standing, often spire-shaped, natural rock formation
(chimney, monument, pinnacle, pohaku, rock tower).
===

tagstat (http://tagstat.hypercube.telascience.org/tagdetails.php?tag=natural)
shows that "natural:rock" is being used.  Would that be appropriate in
this case?

Mike

On Thu, Feb 11, 2010 at 2:13 PM, am12  wrote:
>
>> It seems that not all GNIS Feature_Classes were imported
>
> Correct.
>
> I worked on part of it.  I don't remember the details, but there were
> feature classes that overlapped with other data sources (like NHD) so did
> not appear to be useful to import.  There were also many that did not map
> cleanly into OSM tags.  I don't recall the pinnacles in particular, but
> there certainly was *not* one big GNIS import.
>
> And as mentioned, it could have been deleted also.
>
> - Alan
>
>
>
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-us
>

___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] GNIS - All Feature_Classes Imported?

[am12]

> It seems that not all GNIS Feature_Classes were imported

Correct. 

I worked on part of it.  I don't remember the details, but there were
feature classes that overlapped with other data sources (like NHD) so did
not appear to be useful to import.  There were also many that did not map
cleanly into OSM tags.  I don't recall the pinnacles in particular, but
there certainly was *not* one big GNIS import.

And as mentioned, it could have been deleted also.

- Alan




___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] GNIS - All Feature_Classes Imported?

[Apollinaris Schoell]

or someone deleted them?
Potlatch has an undo mode open the area where you expect it to be and use u or 
U. tend to forget which one is correct

On 10 Feb 2010, at 16:17 , Mike Thompson wrote:

> It seems that not all GNIS Feature_Classes were imported, at least not
> in Rocky Mountain National Park in Colorado.  For example, in this
> area 
> (http://www.openstreetmap.org/?lat=40.4038&lon=-105.52128&zoom=15&layers=B000FTF)
> there is a prominent rock formation called "Twin Owls".  It is shown
> on the 7.5' topo map, and there are signs in the area showing how to
> hike to its base.  It is not in OSM.  The GNIS Feature_Class is
> "pinnacle", and I have noticed other missing features with the same
> class.   I am happy to work on importing such features, but wanted to
> see what the group thought first.
> 
> I posted a similar question on the wiki discussion page for GNIS, but
> have not gotten an answer.  I also posted something to the user
> diaries and got one response which stated that all features had been
> imported and it was probably a rendering issue.  I am pretty sure the
> data is not there and that it is not a rendering issue. I downloaded
> the data for the area and searched for this feature, and it was not
> present.
> 
> Mike
> 
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-us


___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

[Talk-us] GNIS - All Feature_Classes Imported?

[Mike Thompson]

It seems that not all GNIS Feature_Classes were imported, at least not
in Rocky Mountain National Park in Colorado.  For example, in this
area 
(http://www.openstreetmap.org/?lat=40.4038&lon=-105.52128&zoom=15&layers=B000FTF)
there is a prominent rock formation called "Twin Owls".  It is shown
on the 7.5' topo map, and there are signs in the area showing how to
hike to its base.  It is not in OSM.  The GNIS Feature_Class is
"pinnacle", and I have noticed other missing features with the same
class.   I am happy to work on importing such features, but wanted to
see what the group thought first.

I posted a similar question on the wiki discussion page for GNIS, but
have not gotten an answer.  I also posted something to the user
diaries and got one response which stated that all features had been
imported and it was probably a rendering issue.  I am pretty sure the
data is not there and that it is not a rendering issue. I downloaded
the data for the area and searched for this feature, and it was not
present.

Mike

___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] GNIS Import

[Alan Millar]

> There's a "copy tags" feature in JOSM that doesn't seem to work. That's
> about the only way I know of right now.

Pasting tags from node to way did not work for me, as recently as just a
few weeks ago.  However, I tried it just now on the current version 1515
and it worked.

If there are tags on the way which you don't want to overwrite, just
delete those tags from the node before copying.  Not a good solution for
the general case, but for the GNIS import, the node is just going to get
deleted anyways.

- Alan



___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] GNIS Import

[Adam Schreiber]

I had no problem copying nodes tags to ways with latest.

Adam

On 4/10/09, Joseph Jon Booker  wrote:
> On Fri, 10 Apr 2009 11:01:08 -0500
> Ian Dees  wrote:
>> There's a "copy tags" feature in JOSM that doesn't seem to work.
>> That's about the only way I know of right now.
>
> Perhaps it is similar to potlatch, which only allows you to copy way
> tags to other ways, and nodes to other nodes.
>
> --
> Joseph Booker
>

___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] GNIS Import

[Joseph Jon Booker]

On Fri, 10 Apr 2009 11:01:08 -0500
Ian Dees  wrote:
> There's a "copy tags" feature in JOSM that doesn't seem to work.
> That's about the only way I know of right now.

Perhaps it is similar to potlatch, which only allows you to copy way
tags to other ways, and nodes to other nodes.

-- 
Joseph Booker


signature.asc
Description: PGP signature
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] GNIS Import

[Adam Schreiber]

On Fri, Apr 10, 2009 at 1:28 PM, Adam Schreiber  wrote:
> On Fri, Apr 10, 2009 at 12:01 PM, Ian Dees  wrote:
>>
>>
>> On Fri, Apr 10, 2009 at 10:50 AM, Adam Schreiber  wrote:
>>>
>>> Is there an easy way to merge the tags from the nodes to areas that
>>> have already been mapped?  I just noticed a lot of nodes show up for
>>> buildings at my university.
>>
>> There's a "copy tags" feature in JOSM that doesn't seem to work. That's
>> about the only way I know of right now.
>
> In josm-latest, the pasting tags seems to work, but it ought to be
> modified to prompt the user to merge any conflicting tags.  I'll file
> a trac issue for it.

http://josm.openstreetmap.de/ticket/2406

If anyone wants to follow it.

Adam

___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] GNIS Import

[Adam Schreiber]

On Fri, Apr 10, 2009 at 12:01 PM, Ian Dees  wrote:
>
>
> On Fri, Apr 10, 2009 at 10:50 AM, Adam Schreiber  wrote:
>>
>> Is there an easy way to merge the tags from the nodes to areas that
>> have already been mapped?  I just noticed a lot of nodes show up for
>> buildings at my university.
>
> There's a "copy tags" feature in JOSM that doesn't seem to work. That's
> about the only way I know of right now.

In josm-latest, the pasting tags seems to work, but it ought to be
modified to prompt the user to merge any conflicting tags.  I'll file
a trac issue for it.

Adam

___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] GNIS Import

[Ian Dees]

On Fri, Apr 10, 2009 at 12:15 PM, Adam Schreiber  wrote:

>
> At first blush this would seem better than manually doing this work,
> but some of the building names have changed or the GNIS data has a
> more complete name, but the area should be the one that is kept.  I'm
> not terribly familiar with the mechanical turk approach, but I thought
> it was too simplistic to do this?


If there is an area for the building, just copy the gnis tags over to the
building if you're absolutely sure that they represent the same thing. Then,
delete the GNIS-imported node.

Eventually I will do a grep through all X million node/tags for the
gnis:id's and see what has changed.
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] GNIS Import

[Adam Schreiber]

On Fri, Apr 10, 2009 at 12:01 PM, Ian Dees  wrote:
>
>
> On Fri, Apr 10, 2009 at 10:50 AM, Adam Schreiber  wrote:
>>
>> Is there an easy way to merge the tags from the nodes to areas that
>> have already been mapped?  I just noticed a lot of nodes show up for
>> buildings at my university.
>
> There's a "copy tags" feature in JOSM that doesn't seem to work. That's
> about the only way I know of right now.
>
> I can't think of a way to automate it, though. It looks like something that
> could be pretty easy to put in to Amazon's mechanical turk: "which one of
> these is better?"

At first blush this would seem better than manually doing this work,
but some of the building names have changed or the GNIS data has a
more complete name, but the area should be the one that is kept.  I'm
not terribly familiar with the mechanical turk approach, but I thought
it was too simplistic to do this?

Cheers,

Adam

___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] GNIS Import

[Ian Dees]

On Fri, Apr 10, 2009 at 10:50 AM, Adam Schreiber  wrote:

> Is there an easy way to merge the tags from the nodes to areas that
> have already been mapped?  I just noticed a lot of nodes show up for
> buildings at my university.
>

There's a "copy tags" feature in JOSM that doesn't seem to work. That's
about the only way I know of right now.

I can't think of a way to automate it, though. It looks like something that
could be pretty easy to put in to Amazon's mechanical turk: "which one of
these is better?"
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

[Talk-us] GNIS Import

[Adam Schreiber]

Is there an easy way to merge the tags from the nodes to areas that
have already been mapped?  I just noticed a lot of nodes show up for
buildings at my university.

Cheers,

Adam

___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] GNIS Import Done

[Eric Wolf]

> Well, I'm not planning on making a list of all my OSM edits to send back
> to GNIS, so I'm hoping the diff or other extract method works out.  I'm
> finding errors and I'm just fixing them in OSM.

It really should be the impetus of the USGS to mine the OSM for GNIS
updates. Don't sweat it.

> ID number.  Often there would be one node located right on top of the
> school building, and the other node on the street in front.  (Looks like
> perhaps two datasets got loaded into GNIS, one perhaps geolocated by
> address?  Who knows.)

This is very common. It happens at the edges of the 7.5' quad sheets.
A feature would be indicated on both sheets but not in exactly the
same location. It makes sense when you see the sheets as separate maps
- but combined it just looks screwy.

> I hope the diff or extract method will be able to capture deletions like
> this and feed them back to GNIS.  Right now, they probably know there are
> duplicates but don't know which one is correctly positioned.  Our crack

Generally they are both "correctly" positioned because they are point
features representing something that's actually a polygon. It makes
perfect sense to just keep the first one encountered and throw out the
others in a batch import. Then let crowd-sourcing take over!

-Eric

___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] GNIS Import Done

[Alan Millar]

>>> 2. I'm planning on taking the planet dump and grepping out all of the
>>> GNIS
>>> data. This will be used to generate diffs that we can send back to the
>>> GNIS
>>> board, who has the option of putting it back into their data set.

> Also, please report
> anything you find. It would be great if the USGS had the wherewithall
> to create an automated method to pull any changes out of OSM and back
> into our databases.

Well, I'm not planning on making a list of all my OSM edits to send back
to GNIS, so I'm hoping the diff or other extract method works out.  I'm
finding errors and I'm just fixing them in OSM.

I've been looking at schools and churches in the Portland and Seattle
area.  It didn't surprise me to find duplicates between GNIS-loaded nodes
and previously-entered OSM nodes.  The JOSM validator duplicate name
detection and node merge make them easy to fix.  If two identical names
are within 0.0005 degrees of each other, they're probably a duplicate of
the same item.

However, it did surprise me to find quite a few duplicates within the GNIS
data.  For example, I found duplicate nodes for schools, with identical
names, within a few hundred feet of each other, but each with its own GNIS
ID number.  Often there would be one node located right on top of the
school building, and the other node on the street in front.  (Looks like
perhaps two datasets got loaded into GNIS, one perhaps geolocated by
address?  Who knows.)

In the case of duplicated GNIS nodes, I've been keeping the one located on
the building or school grounds, and deleting the one at the street.

I hope the diff or extract method will be able to capture deletions like
this and feed them back to GNIS.  Right now, they probably know there are
duplicates but don't know which one is correctly positioned.  Our crack
team of highly skilled OSM cartographers, as well as nerds like me, can
help clean it up.

- Alan



___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] GNIS Import Done

[Apollinaris Schoell]

it's just surprising that the old scanned maps seem to be more accurate than
any newer data available in electronic formats. have used them  in Pathaway
and always found these maps more accurate than Garmin maps. Garmin, TomTom
have the same errors as Tiger data and seems the same errors as this data.
Interesting question where all the precise data from the old paper maps got
lost.



On Fri, Mar 13, 2009 at 10:05 AM, Eric Wolf  wrote:

> Good sleuthing, David!
>
> There are some mountain tops that are accurate. If you climb a
> mountain and find a USGS monument, then I'll bet the GNIS data is
> accurate. If there isn't one, it could easily be off by as much as 30m
> (lowest expected accuracy of NED).
>
> I'm sure, someplace at The Survey, there is an inventory of monuments.
> It might be worth tracking that down and creating an accuracy
> attribute during the import.
>
> -Eric
>
> -=--=---===---=--=-=--=---==---=--=-=-
> Eric B. Wolf  720-209-6818
> USGS Geographer
> Center of Excellence in GIScience
> PhD Student
> CU-Boulder - Geography
>
>
>
>
> On Fri, Mar 13, 2009 at 9:55 AM, David Lynch  wrote:
> > If you go to the Board of Geographic Names site
> > (http://geonames.usgs.gov/), it indicates that all elevations are from
> > the National Elevation Dataset. (Which is probably what Garmin uses as
> > well.) NED doesn't really have the spatial resolution to resolve
> > features as small as the exact tops of mountains.
> >
> > On Fri, Mar 13, 2009 at 01:41, Apollinaris Schoell 
> wrote:
> >> How accurate is this data and how does it fit match with USGS maps? Just
> >> checked one Peak I had entered some time ago.
> >> USGS map 9735ft =2967m, GNIS import 2965m & position shift ~20m  (Garmin
> >> TopoUS 2008 2964m)
> >> position of USGS map and Yahoo matches exactly with my gpx tracks.
> >>
> >> Interesting to see USGS must have different data. And like in many other
> >> cases Garmin has the wrong data 
> >>
> >>
> >> On Thu, Mar 12, 2009 at 6:29 AM, Ian Dees  wrote:
> >>>
> >>> Hi everyone,
> >>>
> >>> I completed the GNIS node import yesterday. Please see the wiki page
> [1]
> >>> for more details.
> >>>
> >>> As several of you have messaged me and posted on this list, there are
> some
> >>> problems with this data. Let me try to explain my thought process:
> >>>
> >>> 1. Since the resolution of the information is fairly low (i.e. a
> clinic,
> >>> hospital, doctor's office, retirement home, etc. are all tagged
> "hospital"
> >>> in their data set), I have absolutely zero problem with retagging data
> if
> >>> you come across a feature that is incorrectly tagged. Not like you need
> my
> >>> approval, but that higher resolution of info might convince the GNIS
> board
> >>> to add some more tags to their data set.
> >>>
> >>> 2. I'm planning on taking the planet dump and grepping out all of the
> GNIS
> >>> data. This will be used to generate diffs that we can send back to the
> GNIS
> >>> board, who has the option of putting it back into their data set.
> >>>
> >>> 3. If there are already OSM features in your area for a certain node
> that
> >>> I imported, feel free to delete my node, but please merge at least the
> >>> gnis:feature_id tag from the GNIS data so that we can keep track of
> future
> >>> name changes.
> >>>
> >>> -Ian
> >>>
> >>> [1] http://wiki.openstreetmap.org/wiki/USGS_GNIS
> >>>
> >>> ___
> >>> Talk-us mailing list
> >>> Talk-us@openstreetmap.org
> >>> http://lists.openstreetmap.org/listinfo/talk-us
> >>>
> >>
> >>
> >> ___
> >> Talk-us mailing list
> >> Talk-us@openstreetmap.org
> >> http://lists.openstreetmap.org/listinfo/talk-us
> >>
> >>
> >
> >
> >
> > --
> > David J. Lynch
> > djly...@gmail.com
> >
> > ___
> > Talk-us mailing list
> > Talk-us@openstreetmap.org
> > http://lists.openstreetmap.org/listinfo/talk-us
> >
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] GNIS Import Done

[Eric Wolf]

Good sleuthing, David!

There are some mountain tops that are accurate. If you climb a
mountain and find a USGS monument, then I'll bet the GNIS data is
accurate. If there isn't one, it could easily be off by as much as 30m
(lowest expected accuracy of NED).

I'm sure, someplace at The Survey, there is an inventory of monuments.
It might be worth tracking that down and creating an accuracy
attribute during the import.

-Eric

-=--=---===---=--=-=--=---==---=--=-=-
Eric B. Wolf  720-209-6818
USGS Geographer
Center of Excellence in GIScience
PhD Student
CU-Boulder - Geography




On Fri, Mar 13, 2009 at 9:55 AM, David Lynch  wrote:
> If you go to the Board of Geographic Names site
> (http://geonames.usgs.gov/), it indicates that all elevations are from
> the National Elevation Dataset. (Which is probably what Garmin uses as
> well.) NED doesn't really have the spatial resolution to resolve
> features as small as the exact tops of mountains.
>
> On Fri, Mar 13, 2009 at 01:41, Apollinaris Schoell  wrote:
>> How accurate is this data and how does it fit match with USGS maps? Just
>> checked one Peak I had entered some time ago.
>> USGS map 9735ft =2967m, GNIS import 2965m & position shift ~20m  (Garmin
>> TopoUS 2008 2964m)
>> position of USGS map and Yahoo matches exactly with my gpx tracks.
>>
>> Interesting to see USGS must have different data. And like in many other
>> cases Garmin has the wrong data 
>>
>>
>> On Thu, Mar 12, 2009 at 6:29 AM, Ian Dees  wrote:
>>>
>>> Hi everyone,
>>>
>>> I completed the GNIS node import yesterday. Please see the wiki page [1]
>>> for more details.
>>>
>>> As several of you have messaged me and posted on this list, there are some
>>> problems with this data. Let me try to explain my thought process:
>>>
>>> 1. Since the resolution of the information is fairly low (i.e. a clinic,
>>> hospital, doctor's office, retirement home, etc. are all tagged "hospital"
>>> in their data set), I have absolutely zero problem with retagging data if
>>> you come across a feature that is incorrectly tagged. Not like you need my
>>> approval, but that higher resolution of info might convince the GNIS board
>>> to add some more tags to their data set.
>>>
>>> 2. I'm planning on taking the planet dump and grepping out all of the GNIS
>>> data. This will be used to generate diffs that we can send back to the GNIS
>>> board, who has the option of putting it back into their data set.
>>>
>>> 3. If there are already OSM features in your area for a certain node that
>>> I imported, feel free to delete my node, but please merge at least the
>>> gnis:feature_id tag from the GNIS data so that we can keep track of future
>>> name changes.
>>>
>>> -Ian
>>>
>>> [1] http://wiki.openstreetmap.org/wiki/USGS_GNIS
>>>
>>> ___
>>> Talk-us mailing list
>>> Talk-us@openstreetmap.org
>>> http://lists.openstreetmap.org/listinfo/talk-us
>>>
>>
>>
>> ___
>> Talk-us mailing list
>> Talk-us@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-us
>>
>>
>
>
>
> --
> David J. Lynch
> djly...@gmail.com
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-us
>

___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] GNIS Import Done

[David Lynch]

If you go to the Board of Geographic Names site
(http://geonames.usgs.gov/), it indicates that all elevations are from
the National Elevation Dataset. (Which is probably what Garmin uses as
well.) NED doesn't really have the spatial resolution to resolve
features as small as the exact tops of mountains.

On Fri, Mar 13, 2009 at 01:41, Apollinaris Schoell  wrote:
> How accurate is this data and how does it fit match with USGS maps? Just
> checked one Peak I had entered some time ago.
> USGS map 9735ft =2967m, GNIS import 2965m & position shift ~20m  (Garmin
> TopoUS 2008 2964m)
> position of USGS map and Yahoo matches exactly with my gpx tracks.
>
> Interesting to see USGS must have different data. And like in many other
> cases Garmin has the wrong data 
>
>
> On Thu, Mar 12, 2009 at 6:29 AM, Ian Dees  wrote:
>>
>> Hi everyone,
>>
>> I completed the GNIS node import yesterday. Please see the wiki page [1]
>> for more details.
>>
>> As several of you have messaged me and posted on this list, there are some
>> problems with this data. Let me try to explain my thought process:
>>
>> 1. Since the resolution of the information is fairly low (i.e. a clinic,
>> hospital, doctor's office, retirement home, etc. are all tagged "hospital"
>> in their data set), I have absolutely zero problem with retagging data if
>> you come across a feature that is incorrectly tagged. Not like you need my
>> approval, but that higher resolution of info might convince the GNIS board
>> to add some more tags to their data set.
>>
>> 2. I'm planning on taking the planet dump and grepping out all of the GNIS
>> data. This will be used to generate diffs that we can send back to the GNIS
>> board, who has the option of putting it back into their data set.
>>
>> 3. If there are already OSM features in your area for a certain node that
>> I imported, feel free to delete my node, but please merge at least the
>> gnis:feature_id tag from the GNIS data so that we can keep track of future
>> name changes.
>>
>> -Ian
>>
>> [1] http://wiki.openstreetmap.org/wiki/USGS_GNIS
>>
>> ___
>> Talk-us mailing list
>> Talk-us@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-us
>>
>
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-us
>
>



-- 
David J. Lynch
djly...@gmail.com

___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] GNIS Import Done

[Eric Wolf]

Ian,

Email gnis_mana...@usgs.gov with that question. Also, please report
anything you find. It would be great if the USGS had the wherewithall
to create an automated method to pull any changes out of OSM and back
into our databases.

And yes, one of the beauties of OSM is that it will contain
information that no one has bothered to collect because it's not of
immediate commercial value. Especially in the US where you can get
complete datasets for streets that just need a little tweaking.

-Eric

-=--=---===---=--=-=--=---==---=--=-=-
Eric B. Wolf  720-209-6818
USGS Geographer
Center of Excellence in GIScience
PhD Student
CU-Boulder - Geography




On Fri, Mar 13, 2009 at 8:51 AM, Karl Newman  wrote:
>> While GNIS might not be perfectly accurate in geoposition, it is the
>> authoritative set of geographic names for the US. It contains features
>> that are on no other map or spatial database.
>
> Until now, anyway. ;-)
>
> Karl
>

___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] GNIS Import Done

[Karl Newman]

>
> While GNIS might not be perfectly accurate in geoposition, it is the
> authoritative set of geographic names for the US. It contains features
> that are on no other map or spatial database.
>

Until now, anyway. ;-)

Karl
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] GNIS Import Done

[Eric Wolf]

Much of the GNIS data was extracted during the scanning and color
separation of the 1:24K 7.5' topo sheets. Those maps were made from
survey information - not GPS or satellite. And, because those were
hand made maps, cartographic convention sometimes required things to
be shifted. However, landforms - like peaks would have been the last
to shift.

The USGS usually has published accuracy standards. Unfortunately, GNIS
defaults to the accuracy standards of the input data:
http://geonames.usgs.gov/domestic/metadata.htm#quality.2

While GNIS might not be perfectly accurate in geoposition, it is the
authoritative set of geographic names for the US. It contains features
that are on no other map or spatial database.

-Eric

-=--=---===---=--=-=--=---==---=--=-=-
Eric B. Wolf  720-209-6818
USGS Geographer
Center of Excellence in GIScience
PhD Student
CU-Boulder - Geography




On Fri, Mar 13, 2009 at 12:41 AM, Apollinaris Schoell
 wrote:
> How accurate is this data and how does it fit match with USGS maps? Just
> checked one Peak I had entered some time ago.
> USGS map 9735ft =2967m, GNIS import 2965m & position shift ~20m  (Garmin
> TopoUS 2008 2964m)
> position of USGS map and Yahoo matches exactly with my gpx tracks.
>
> Interesting to see USGS must have different data. And like in many other
> cases Garmin has the wrong data 
>
>
> On Thu, Mar 12, 2009 at 6:29 AM, Ian Dees  wrote:
>>
>> Hi everyone,
>>
>> I completed the GNIS node import yesterday. Please see the wiki page [1]
>> for more details.
>>
>> As several of you have messaged me and posted on this list, there are some
>> problems with this data. Let me try to explain my thought process:
>>
>> 1. Since the resolution of the information is fairly low (i.e. a clinic,
>> hospital, doctor's office, retirement home, etc. are all tagged "hospital"
>> in their data set), I have absolutely zero problem with retagging data if
>> you come across a feature that is incorrectly tagged. Not like you need my
>> approval, but that higher resolution of info might convince the GNIS board
>> to add some more tags to their data set.
>>
>> 2. I'm planning on taking the planet dump and grepping out all of the GNIS
>> data. This will be used to generate diffs that we can send back to the GNIS
>> board, who has the option of putting it back into their data set.
>>
>> 3. If there are already OSM features in your area for a certain node that
>> I imported, feel free to delete my node, but please merge at least the
>> gnis:feature_id tag from the GNIS data so that we can keep track of future
>> name changes.
>>
>> -Ian
>>
>> [1] http://wiki.openstreetmap.org/wiki/USGS_GNIS
>>
>> ___
>> Talk-us mailing list
>> Talk-us@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-us
>>
>
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-us
>
>

___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] GNIS Import Done

[Apollinaris Schoell]

How accurate is this data and how does it fit match with USGS maps? Just
checked one Peak I had entered some time ago.
USGS map 9735ft =2967m, GNIS import 2965m & position shift ~20m  (Garmin
TopoUS 2008 2964m)
position of USGS map and Yahoo matches exactly with my gpx tracks.

Interesting to see USGS must have different data. And like in many other
cases Garmin has the wrong data 


On Thu, Mar 12, 2009 at 6:29 AM, Ian Dees  wrote:

> Hi everyone,
>
> I completed the GNIS node import yesterday. Please see the wiki page [1]
> for more details.
>
> As several of you have messaged me and posted on this list, there are some
> problems with this data. Let me try to explain my thought process:
>
> 1. Since the resolution of the information is fairly low (i.e. a clinic,
> hospital, doctor's office, retirement home, etc. are all tagged "hospital"
> in their data set), I have absolutely zero problem with retagging data if
> you come across a feature that is incorrectly tagged. Not like you need my
> approval, but that higher resolution of info might convince the GNIS board
> to add some more tags to their data set.
>
> 2. I'm planning on taking the planet dump and grepping out all of the GNIS
> data. This will be used to generate diffs that we can send back to the GNIS
> board, who has the option of putting it back into their data set.
>
> 3. If there are already OSM features in your area for a certain node that I
> imported, feel free to delete my node, but please merge at least the
> gnis:feature_id tag from the GNIS data so that we can keep track of future
> name changes.
>
> -Ian
>
> [1] http://wiki.openstreetmap.org/wiki/USGS_GNIS
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-us
>
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] GNIS Import Done

[Sam Vekemans]

Hi all, thanks for the tips about tagging schools / hospitals and such. :)
 I'm carefully following along and learning as i go, as i don't want to
repeat any of the same mistakes made before (but knowone is perfect, so im
sure i'll make more blunders as i have done before)

Anyway, i too have the generic for hospitals.
what i tend todo is put "emergency=no/yes"

for schools, same here i just have the basic.
point,CODE,2010420,amenity,school
point,CODE,2010420,college,yes
point,CODE,2010420,university,yes
point,CODE,2010420,elementary,yes
point,CODE,2010420,post_secondary,yes
point,CODE,2010420,seminary,yes

so then when people physically varify the data on the ground, they can
either change it to "no" or remove it... there are some cases of a
'polytechnic' university, which is both university and college.  ... also in
the USA you say "college" which is different than Canadian 'college'.
 Personally, i would merge 'college' & 'post_secondary' as it means the same
thing.

In the wiki, there is amenity=college, amenity=university,
amenity=kindergarden. .. and i don't see one for grades 1 - 12.. perhaps it
should be proposed? (if i have time i'll get around to it, but dont wait for
me) :)

IMO, when mapping it's best to map your area as you see fit, and not be too
concerned about 'official naming', like some else said "alt:name" written as
the official name, or something like that.
So for me, i would write canvec:name=* and have 'name=*' as the name it's
known as.

I'm using Tagwatch to look around and see what else is being used,

I am also going through the painful process of creating WIKI pages for those
tags that i think should get it's own icon, and be used. As well as
commenting on various talk pages on tags that i think need more explanation
This way, there is a better chance that the tag will become "common" :-)
 and by posting it to a wiki, there's a good chance that someone else would
mention some ideas that weren't thought of before. ...

Hope that helps some people,

Cheers,
Sam Vekemans
Across Canada Trails
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] GNIS Import Done

[Minh Nguyen]

Ngày 3/12/09 8:47 AM, Ian Dees vie^'t:
On Thu, Mar 12, 2009 at 10:45 AM, Ted Mielczarek 
mailto:ted.mielcza...@gmail.com>> wrote:


Yeah, I deleted quite a few POIs for things that no longer exist.
Sorry if I sounded mad in my message. :) I still question the
value of this data given my (brief, informal) survey of what it
brought to my local area. I think I may have also deleted a few
nodes where I had already mapped the feature. I can go back and
transfer the GNIS tags to the existing feature if you think that
would be helpful.


 It would be helpful to have the GNIS feature_id on existing data if 
it's talking about the same thing.


There are lots of nodes where the name has "(historic)" or similar at 
the end, which means that the feature no longer exists but is recorded 
for historical purposes. I thought I had deleted those from the data 
before import, but it looks like most of them got imported. I was 
planning on searching for those IDs and deleting them when I scrape 
through the planet dump next week.
How about tagging their names as old_name? I don't think any renderer 
currently supports that key, but it could be useful in the future.


--
Minh Nguyen
AIM: trycom2000; Jabber: m...@1ec5.org; Blog: http://notes.1ec5.org/

___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] GNIS Import Done

[Matthew Schneider]

> If you know that Zavala School and Zavala Elementary School are the 
> same thing, then you should delete the "less correct" node (along with 
> its gnis:feature_id). That would eventually push a "delete the less 
> correct data point" change into GNIS, which is a good thing I think.
I hope soon to start some analysis based on the names of GNIS nodes. 
Initially to attempt to recategorize secondary medical facilities such 
as clinics from true hospitals. I will note that I'm not sure what to do 
with secondary facilities once I have sorted them out; amenity = 
hospital really doesn't see appropriate; all other proposed tags seem to 
have been voted down. We might drop them, or assign them a non-standard 
tag for later reclassification.

On top of that, it might be appropriate to perform some sort of name 
based analysis on nodes with the same class and within a distance of N 
units from each other. For items like schools, stripping common words 
from the names ("Elementary", "High", "Junior", "Middle", "School") and 
comparing the remaining values one word at a time might provide a quick 
list of redundant nodes for review.

If anyone is interested in participating with this effort on a more 
national level, I'd welcome the help.

___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] GNIS Import Done

[Ian Dees]

On Thu, Mar 12, 2009 at 11:43 AM, David Lynch  wrote:

> Another thing I'm seeing as I look around is duplicates and
> near-duplicates ("Zavala School" vs. "Zavala Elementary School", for
> instance.) For now, I'm putting both feature IDs into one point,
> separated by a semicolon. Does that work for your purposes of
> reporting back to GNIS?


If you know that Zavala School and Zavala Elementary School are the same
thing, then you should delete the "less correct" node (along with its
gnis:feature_id). That would eventually push a "delete the less correct data
point" change into GNIS, which is a good thing I think.
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] GNIS Import Done

[David Lynch]

Another thing I'm seeing as I look around is duplicates and
near-duplicates ("Zavala School" vs. "Zavala Elementary School", for
instance.) For now, I'm putting both feature IDs into one point,
separated by a semicolon. Does that work for your purposes of
reporting back to GNIS?

On Thu, Mar 12, 2009 at 11:26, Ian Dees  wrote:
>
>
> On Thu, Mar 12, 2009 at 11:18 AM, David Lynch  wrote:
>>
>> Another what-if tagging situation -- what about places where there are
>> two nodes for the same object, one containing an out-of-date name, one
>> containing the current name?
>
> Delete the old (out of date) name and keep the new one.
>
> If they are the same structure and they have a new name, copy the
> gnis:feature_id tag and value over.
>
> There is a pretty specific procedure that the GNIS board goes through when
> coming up with names for things because they want to make everyone (local,
> city, state, federal governments and citizens) happy. Keep that in mind when
> looking at the difference in names.
>



-- 
David J. Lynch
djly...@gmail.com

___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] GNIS Import Done

[Ian Dees]

This didn't make it to the list:

On Thu, Mar 12, 2009 at 11:26 AM, Ian Dees  wrote:

>
>
> On Thu, Mar 12, 2009 at 11:18 AM, David Lynch  wrote:
>
>> Another what-if tagging situation -- what about places where there are
>> two nodes for the same object, one containing an out-of-date name, one
>> containing the current name?
>>
>
> Delete the old (out of date) name and keep the new one.
>
> If they are the same structure and they have a new name, copy the
> gnis:feature_id tag and value over.
>
> There is a pretty specific procedure that the GNIS board goes through when
> coming up with names for things because they want to make everyone (local,
> city, state, federal governments and citizens) happy. Keep that in mind when
> looking at the difference in names.
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] GNIS Import Done

[Ian Dees]

On Thu, Mar 12, 2009 at 11:02 AM, Matt Maxon  wrote:

> Ian Dees wrote:
>
>> that we can send back to the GNIS board, who has the option of putting it
>> back into their data set.
>>
>> 3. If there are already OSM features in your area for a certain node that
>> I imported, feel free to delete my node, but please merge at least the
>> gnis:feature_id tag from the GNIS data so that we can keep track of future
>> name changes.
>>
> I'm thinking how would GNIS board know if a deleted point wasn't just
> excluded for some reason and not deleted because it wasn't there anymore.
>
> Is there some way to tag these so they will eventually be removed


My plan was to take the planet dump from yesterday and the diffs from the
rest of the week to find the node ids for all of the nodes I imported, then
see which ones were deleted and modified.

If anyone else has a better way to do this, let me know.
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] GNIS Import Done

[Matt Maxon]

Ian Dees wrote:
> that we can send back to the GNIS board, who has the option of putting 
> it back into their data set.
>
> 3. If there are already OSM features in your area for a certain node 
> that I imported, feel free to delete my node, but please merge at 
> least the gnis:feature_id tag from the GNIS data so that we can keep 
> track of future name changes.
I'm thinking how would GNIS board know if a deleted point wasn't just 
excluded for some reason and not deleted because it wasn't there anymore.

Is there some way to tag these so they will eventually be removed

There are a good many in my area that haven't existed for 30 years or more

Matt

___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] GNIS Import Done

[Matt Maxon]

Ian Dees wrote:
> that we can send back to the GNIS board, who has the option of putting 
> it back into their data set.
>
> 3. If there are already OSM features in your area for a certain node 
> that I imported, feel free to delete my node, but please merge at 
> least the gnis:feature_id tag from the GNIS data so that we can keep 
> track of future name changes.
I'm thinking how would GNIS board know if a deleted point wasn't just 
excluded for some reason and not deleted because it wasn't there anymore.

Is there some way to tag these so they will eventually be removed

There are a good many in my area that haven't existed for 30 years or more

Matt

___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] GNIS Import Done

[Ian Dees]

On Thu, Mar 12, 2009 at 10:45 AM, Ted Mielczarek
wrote:

> Yeah, I deleted quite a few POIs for things that no longer exist. Sorry if
> I sounded mad in my message. :) I still question the value of this data
> given my (brief, informal) survey of what it brought to my local area. I
> think I may have also deleted a few nodes where I had already mapped the
> feature. I can go back and transfer the GNIS tags to the existing feature if
> you think that would be helpful.
>

 It would be helpful to have the GNIS feature_id on existing data if it's
talking about the same thing.

There are lots of nodes where the name has "(historic)" or similar at the
end, which means that the feature no longer exists but is recorded for
historical purposes. I thought I had deleted those from the data before
import, but it looks like most of them got imported. I was planning on
searching for those IDs and deleting them when I scrape through the planet
dump next week.
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] GNIS Import Done

[Ted Mielczarek]

Yeah, I deleted quite a few POIs for things that no longer exist. Sorry if I
sounded mad in my message. :) I still question the value of this data given
my (brief, informal) survey of what it brought to my local area. I think I
may have also deleted a few nodes where I had already mapped the feature. I
can go back and transfer the GNIS tags to the existing feature if you think
that would be helpful.

-Ted
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] GNIS Import Done

[Adam Schreiber]

On Thu, Mar 12, 2009 at 10:26 AM, Ian Dees  wrote:
>
>
> On Thu, Mar 12, 2009 at 8:54 AM, Adam Schreiber  wrote:
>>
>> On Thu, Mar 12, 2009 at 9:29 AM, Ian Dees  wrote:
>> > 3. If there are already OSM features in your area for a certain node
>> > that I
>> > imported, feel free to delete my node, but please merge at least the
>> > gnis:feature_id tag from the GNIS data so that we can keep track of
>> > future
>> > name changes.
>>
>> What about features that are polygons in OSM but nodes in the GNIS data?
>
> Since all features in GNIS are nodes, I will just take the centroid of the
> polygon to be the point that might end up in GNIS. Feel free to apply the
> gnis tags to polygonal ways.
>
> The more important data I think would be changes to the name or
> classification and whether or not it even exists.

Will you also be grepping the planet dump for features GNIS includes
but doesn't have an item for?

___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] GNIS Import Done

[Ian Dees]

On Thu, Mar 12, 2009 at 8:54 AM, Adam Schreiber  wrote:

> On Thu, Mar 12, 2009 at 9:29 AM, Ian Dees  wrote:
> > 3. If there are already OSM features in your area for a certain node that
> I
> > imported, feel free to delete my node, but please merge at least the
> > gnis:feature_id tag from the GNIS data so that we can keep track of
> future
> > name changes.
>
> What about features that are polygons in OSM but nodes in the GNIS data?
>

Since all features in GNIS are nodes, I will just take the centroid of the
polygon to be the point that might end up in GNIS. Feel free to apply the
gnis tags to polygonal ways.

The more important data I think would be changes to the name or
classification and whether or not it even exists.
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] GNIS Import Done

[Adam Schreiber]

On Thu, Mar 12, 2009 at 9:29 AM, Ian Dees  wrote:
> 3. If there are already OSM features in your area for a certain node that I
> imported, feel free to delete my node, but please merge at least the
> gnis:feature_id tag from the GNIS data so that we can keep track of future
> name changes.

What about features that are polygons in OSM but nodes in the GNIS data?

Cheers,

Adam

> -Ian
>
> [1] http://wiki.openstreetmap.org/wiki/USGS_GNIS
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-us
>
>

___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

[Talk-us] GNIS Import Done

[Ian Dees]

Hi everyone,

I completed the GNIS node import yesterday. Please see the wiki page [1] for
more details.

As several of you have messaged me and posted on this list, there are some
problems with this data. Let me try to explain my thought process:

1. Since the resolution of the information is fairly low (i.e. a clinic,
hospital, doctor's office, retirement home, etc. are all tagged "hospital"
in their data set), I have absolutely zero problem with retagging data if
you come across a feature that is incorrectly tagged. Not like you need my
approval, but that higher resolution of info might convince the GNIS board
to add some more tags to their data set.

2. I'm planning on taking the planet dump and grepping out all of the GNIS
data. This will be used to generate diffs that we can send back to the GNIS
board, who has the option of putting it back into their data set.

3. If there are already OSM features in your area for a certain node that I
imported, feel free to delete my node, but please merge at least the
gnis:feature_id tag from the GNIS data so that we can keep track of future
name changes.

-Ian

[1] http://wiki.openstreetmap.org/wiki/USGS_GNIS
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us