Re: [Tagging] Please don't think name_1 tags are errors.

2016-01-15 15:26 GMT+01:00 moltonel 3x Combo : > But I wonder if some people know about the iD editor behavior below, > and assume that a name_1 tag must have been created that way ? If so, > consider this email as a reminder that the _N suffix is used on > purpose by many

Re: [Tagging] Please don't think name_1 tags are errors.

Whichever iD developer thought that adding random _N suffixes was a good idea deserves to be taken out back and shot. While handling newbie mistakes (and teaching them the correct way of doing things) is most certainly encouraged, doing it in such a way that pollutes tagging is totally

[Tagging] Please don't think name_1 tags are errors.

Hi, I've just reverted http://www.openstreetmap.org/changeset/36573638 where the mapper thought that name_1 tags were typos. That user is on a key typo fixing spree, which is a good thing in itself, even if mistakes happen. But I wonder if some people know about the iD editor behavior below, and

Re: [Tagging] Please don't think name_1 tags are errors.

2016-01-15 16:01 GMT+01:00 Kieron Thwaites : > Whichever iD developer thought that adding random _N suffixes was a > good idea deserves to be taken out back and shot. > maybe this kind of language is common in your cultural context, but I believe it is completely

Re: [Tagging] Please don't think name_1 tags are errors.

On 15/01/2016, Kieron Thwaites wrote: > I completely endorse the removal of any and all *_N tags. If so, you've got a serious amount of work comming up just to figure how to say the same thing using different tags. Semicolons and various namespaced schemes sometimes do

Re: [Tagging] Please don't think name_1 tags are errors.

I am quite in favour of people coming forward to discuss the possibility of improving the iD Editor if it is causing problems. I object to the continuous use of naming new mappers as a problem. I will defend the reason for iD preventing new mappers from being given the option of inadvertently

Re: [Tagging] Please don't think name_1 tags are errors.

Kieron Thwaites wrote: > Whichever iD developer thought that adding random _N suffixes was > a good idea deserves to be taken out back and shot. Please withdraw that comment. Advocating violence to people is not funny. You might want to say a _feature_ should be taken outside and shot, but

Re: [Tagging] Please don't think name_1 tags are errors.

On Fri, Jan 15, 2016 at 4:02 PM, Martin Koppenhoefer wrote: > Obviously we wouldn't want people to tag the whole assortment of a > supermarket like this, but due to the amount of work the risk is low. I'll agree with what you wrote, but I still wonder how you

Re: [Tagging] Please don't think name_1 tags are errors.

sent from a phone > Am 15.01.2016 um 17:40 schrieb Marc Gemis : > > I'll agree with what you wrote, but I still wonder how you > differentiate between all the supermarket types. I don't yet, but it is indeed a field where we might want to map more detail in the future.

[Tagging] Feature Proposal - RFC - Discourage amenity=public_building

Hi all, Based on the discussion arising from my previous message, it seems that there is support to discourage the tag amenity=public_building. I have therefore created a proposal page to explicitly mark this tag as discouraged in the wiki:

Re: [Tagging] Please don't think name_1 tags are errors.

sent from a phone > Am 15.01.2016 um 17:25 schrieb Ralph Aytoun : > > Throughout the arid countries we now have these features > (wadi/ouadi/arroyo/dry gulch/ etc.) without an appropriate tag. time to make a proposal ;-) cheers Martin

Re: [Tagging] Please don't think name_1 tags are errors.

On Friday 15 January 2016, Ralph Aytoun wrote: > When I started a waterway=wadi was an accepted tag > but within a period of three months it was deprecated by a group that > did not really understand it's cartographic usage. I don't want to hijack this thread but the above is not quite correct -

Re: [Tagging] Feature Proposal - RFC - Discourage amenity=public_building

On 16/01/2016 7:03 AM, Matthijs Melissen wrote: Hi all, Based on the discussion arising from my previous message, it seems that there is support to discourage the tag amenity=public_building. I have therefore created a proposal page to explicitly mark this tag as discouraged in the wiki:

Re: [Tagging] Feature Proposal - RFC - Discourage amenity=public_building

How would you translate or apply these tags in e.g. the UK or the Netherlands (my home countries)? What is a "state government"? What is a "local government seat"? These things will mean different things to different people. Although this is phrased a bit rhetorically, I do think we should be

Re: [Tagging] Please don't think name_1 tags are errors.

On 15/01/2016 16:25, Ralph Aytoun wrote: I am quite in favour of people coming forward to discuss the possibility of improving the iD Editor if it is causing problems. Could a "this key already exists,,," dialog be displayed? I object to the continuous use of naming new mappers as a

Re: [Tagging] Feature Proposal - RFC - Discourage amenity=public_building

On 16/01/2016 3:40 PM, John Willis wrote: On Jan 16, 2016, at 9:12 AM, Colin Smale > wrote: If they should be improved .. or discouraged .. then do that as separate issues. If you want to fix a problem, don't replace it with another

Re: [Tagging] Feature Proposal - RFC - Discourage amenity=public_building

On 2016-01-16 00:12, Warin wrote: > On 16/01/2016 8:35 AM, Colin Smale wrote: > >> How would you translate or apply these tags in e.g. the UK or the >> Netherlands (my home countries)? What is a "state government"? What is a >> "local government seat"? These things will mean different things

Re: [Tagging] Feature Proposal - RFC - Discourage amenity=public_building

On 16/01/2016 8:35 AM, Colin Smale wrote: How would you translate or apply these tags in e.g. the UK or the Netherlands (my home countries)? What is a "state government"? What is a "local government seat"? These things will mean different things to different people. Although this is

Re: [Tagging] Feature Proposal - RFC - Discourage amenity=public_building

On Jan 16, 2016, at 9:12 AM, Colin Smale wrote: >> If they should be improved .. or discouraged .. then do that as separate >> issues. > If you want to fix a problem, don't replace it with another one. > Then I will work on a civic building / civic office something