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

sent from a phone > Am 15.01.2016 um 22:48 schrieb moltonel 3x Combo : > > I don't recall encountering a multiple-name object that ought to > be broken down in two objects. No stats, just your subjectivity > against mine :p this part of my mail was more generally referring to multivalues in f

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 one. Then I will work on

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 extension this week. Al

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 t

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 phrased

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

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

On 15/01/2016, Martin Koppenhoefer wrote: >> Am 15.01.2016 um 18:03 schrieb moltonel 3x Combo : >> To get back to my http://www.openstreetmap.org/relation/5257865 >> example, I've got 3 names to tag. One of them distinguishes itself by >> also appearing on an out-of-copyright map, the other two ar

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

sent from a phone > Am 15.01.2016 um 22:13 schrieb Warin <61sundow...@gmail.com>: > > To tag a function; > office=public for an office of an agency or department of the national/state > government. If these are the intended classes I suggest to be way more explicit with the value names, e.g.

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 awa

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: http:

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] 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 ___ Taggin

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. > > I'm thinking ab

[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: http://wiki.openstreetmap.org/wiki/Proposed_features/Di

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

sent from a phone > Am 15.01.2016 um 18:03 schrieb moltonel 3x Combo : > > The problem is that all those name key variations carry semantic > meaning. A loc_name isn't the same thing as an alt_name which isn't > the same thing as an old_name. yes, but a name, an alt_name and a nat_name are qu

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 the trick, but outright ban

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 differentiate between all the superma

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 don't

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 inappropriate and extremely offe

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 people. As always, conta

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 unacceptabl

[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 a