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
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
* Minh Nguyen m...@nguyen.cincinnati.oh.us [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
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
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
On Wed, Jan 14, 2015 at 2:29 AM, Paul Norman penor...@mac.com 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
Or Overpass + Level0 :-)
regards
m.
On Tue, Jan 13, 2015 at 7:50 PM, Richard Fairhurst rich...@systemed.net
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
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
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
Nguyen
Cc: talk-us
Subject: Re: [Talk-us] GNIS POI populations
On Tue, Jan 13, 2015 at 5:34 AM, Minh Nguyen m...@nguyen.cincinnati.oh.us
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
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
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
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
On Tue, Jan 13, 2015 at 5:34 AM, Minh Nguyen m...@nguyen.cincinnati.oh.us
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
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
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
* Richard Fairhurst rich...@systemed.net [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
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
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
On Thu, Jan 9, 2014 at 10:19 PM, Clifford Snow cliff...@snowandsnow.uswrote:
On Thu, Jan 9, 2014 at 6:27 PM, Jason Remillard remillard.ja...@gmail.com
wrote:
If you
find a problematic GNIS node (especially natural feature), you should
consider sending an email to gnis_mana...@usgs.gov as
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
On Thu, Jan 9, 2014 at 6:27 PM, Jason Remillard
remillard.ja...@gmail.comwrote:
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
, Paul Norman penor...@mac.com 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
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
Am 08/set/2013 um 10:39 schrieb Serge Wroclawski emac...@gmail.com:
* 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
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
On Tue, Aug 20, 2013 at 1:54 PM, Serge Wroclawski emac...@gmail.com wrote:
Hi all,
I've been looking at the GNIS data and it's quite a mess.
This is a horribly crafted proposal. You haven't shown your research why
but you declare the GNIS tags as a mess. Your proposal is as good as me
On Sat, Aug 24, 2013 at 2:22 PM, Greg Morgan dr.kludge...@gmail.com wrote:
On Tue, Aug 20, 2013 at 1:54 PM, Serge Wroclawski emac...@gmail.comwrote:
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
On Sat, Aug 24, 2013 at 12:26 PM, Ian Dees ian.d...@gmail.com wrote:
On Sat, Aug 24, 2013 at 2:22 PM, Greg Morgan dr.kludge...@gmail.comwrote:
On Tue, Aug 20, 2013 at 1:54 PM, Serge Wroclawski emac...@gmail.comwrote:
Hi all,
I've been looking at the GNIS data and it's quite a mess.
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
On Aug 21, 2013, at 10:19, Apollinaris Schoell ascho...@gmail.com 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
On Wed, Aug 21, 2013 at 1:09 PM, Jason Remillard
remillard.ja...@gmail.com 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
On Aug 21, 2013, at 10:38, Steven Johnson sejohns...@gmail.com 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
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
On Aug 21, 2013, at 10:19, Apollinaris Schoell ascho...@gmail.com 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
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:
On Sun, Jun 16, 2013 at 4:20 PM, Thomas Colson thomas_col...@nps.govwrote:
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
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,
On Mon, Jun 17, 2013 at 2:49 AM, Mike N nice...@att.net 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
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
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
On Mon, Jun 17, 2013 at 7:56 AM, Clifford Snow cliff...@snowandsnow.uswrote:
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
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
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
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
, 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
On Sun, Jun 16, 2013 at 4:20 PM, Thomas Colson thomas_col...@nps.govwrote:
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
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
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
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
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).
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.4038lon=-105.52128zoom=15layers=B000FTF)
there is a prominent rock formation called Twin Owls. It is shown
on the
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
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
On Fri, Apr 10, 2009 at 1:28 PM, Adam Schreiber sa...@clemson.edu wrote:
On Fri, Apr 10, 2009 at 12:01 PM, Ian Dees ian.d...@gmail.com wrote:
On Fri, Apr 10, 2009 at 10:50 AM, Adam Schreiber sa...@clemson.edu wrote:
Is there an easy way to merge the tags from the nodes to areas that
have
On Fri, 10 Apr 2009 11:01:08 -0500
Ian Dees ian.d...@gmail.com 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.
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
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
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
On Thu, Mar 12, 2009 at 10:26 AM, Ian Dees ian.d...@gmail.com wrote:
On Thu, Mar 12, 2009 at 8:54 AM, Adam Schreiber sa...@clemson.edu wrote:
On Thu, Mar 12, 2009 at 9:29 AM, Ian Dees ian.d...@gmail.com wrote:
3. If there are already OSM features in your area for a certain node
that I
On Thu, Mar 12, 2009 at 10:45 AM, Ted Mielczarek
ted.mielcza...@gmail.comwrote:
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
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
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
On Thu, Mar 12, 2009 at 11:02 AM, Matt Maxon o...@mattmaxon.com 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
On Thu, Mar 12, 2009 at 11:43 AM, David Lynch djly...@gmail.com 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
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
66 matches
Mail list logo
