, 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:
14 matches
Mail list logo
