Re: [Talk-us] GNIS tag removal proposal

2013-09-08 Thread 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

2013-09-08 Thread 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

2013-09-08 Thread 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


[Talk-us] the Battle Grid

2013-09-08 Thread Clifford Snow
Martijn,
For the upcoming #Editathon, we plan to fix road alignment in Washington
State. Eric Fischer pointed me to your Battle Grid website. I plan
introduce it at the #Editathon. Originally I was just going to list cities
and ask people to work on a city. However, you tool is much better. I'd
like to make one request of you. Is it possible to increase the size of the
color tiles? When opening in iD, they seem too small. You end up working on
surrounding areas before you know it. Since iD automatically brings in new
data as you scroll around, it's easy to be working in adjacent tiles. This
isn't a show stopper by any means. If it's too much work or doesn't make
any sense to you, just tell me to take a flying leap!

Thanks,
-- 
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] the Battle Grid

2013-09-08 Thread Steven Johnson
I had the same concern. If I could somehow overlay the grid squares in iD,
I'd be certain I was correcting all the alignments in the square and would
be easier to mark the square 'done'.

I'm also willing to take a flying leap. ;-)

SEJ

P.S. Great tool, BTW. I showed it to folks at Census Bureau where there was
quite a bit of interest in MapRoulette as a model of how to do QC on TIGER
data

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

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


On Sun, Sep 8, 2013 at 3:45 PM, Clifford Snow wrote:

> Martijn,
> For the upcoming #Editathon, we plan to fix road alignment in Washington
> State. Eric Fischer pointed me to your Battle Grid website. I plan
> introduce it at the #Editathon. Originally I was just going to list cities
> and ask people to work on a city. However, you tool is much better. I'd
> like to make one request of you. Is it possible to increase the size of the
> color tiles? When opening in iD, they seem too small. You end up working on
> surrounding areas before you know it. Since iD automatically brings in new
> data as you scroll around, it's easy to be working in adjacent tiles. This
> isn't a show stopper by any means. If it's too much work or doesn't make
> any sense to you, just tell me to take a flying leap!
>
> Thanks,
> --
> Clifford
>
> OpenStreetMap: Maps with a human touch
>
> ___
> 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