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 feat
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
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 a
* 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 be
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 ba
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 wi
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 "
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
correspond
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 co
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 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.
* 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=po
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
h
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
(histor
y, 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
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
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
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 acro
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 conside
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
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 wi
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
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
> 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 d
13 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
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
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 the
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 prop
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
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 a
> 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 no
> 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 "A
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 fea
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
i
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
> use
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
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:
> H
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
featu
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
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
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
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
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
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 dis
+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).
>
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 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
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 ex
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 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 conferenc
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, ther
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
> 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
ith 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" elevation
> 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
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 th
pson [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 in
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 Elev
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 da
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
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.
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 th
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
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 i
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 Par
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 t
> 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
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 simil
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 Boo
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
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.
>
> Ther
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 wit
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.
>
> Ther
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. Th
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.openstreet
> 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
>>> 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 gr
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 da
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, ther
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 mount
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
info
>
> 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
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, landform
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 U
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 g
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 m
> 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
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 f
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, 20
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
>>
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 n
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 fro
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 fro
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 ha
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 featur
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,
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 GN
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 a
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 fair
99 matches
Mail list logo
