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. - 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
> 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
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
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
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