Re: [Tagging] Tagging problem for a river running in a culvert below a track / wiki votes enforcement

2016-01-26 21:30 GMT+01:00 Mateusz Konieczny : > I would add to path tag bridge=low_water_crossing (documented at > http://wiki.openstreetmap.org/wiki/Key:bridge ) and layer=1, without > tagging culverts, without splitting waterway polygon. > > tagging this footway as bridge=low_water_crossing (do

Re: [Tagging] Feature Proposal - Voting - (Remove name_1 and alt_name_1 from wiki)

2016-01-27 2:14 GMT+01:00 moltonel 3x Combo : > Andy has already given some good answers and I've rambled for too long > on the subject, but since you ask again I'll dig up > http://www.openstreetmap.org/relation/5257865 again, which cannot be > satisfyingly tagged with foo_name variations. Its na

Re: [Tagging] Feature Proposal - Voting - (Remove name_1 and alt_name_1 from wiki)

On Wed, Jan 27, 2016 at 10:15 AM, Martin Koppenhoefer wrote: > can hardly believe you don't have official versions of names for > administrative areas in France, so the current tagging definitely is > improvable (because you cannot see which is this official name by looking at > the current tags).

Re: [Tagging] Feature Proposal - Voting - (Remove name_1 and alt_name_1 from wiki)

2016-01-27 10:39 GMT+01:00 Marc Gemis : > France ? The example boundary is in Ireland > ;-) anyway, s/France/Ireland/ and the statement remains. I bet also the Irish have official names for their administrative units. Cheers, Martin ___ Tagging ma

Re: [Tagging] Feature Proposal - RFC - Government offices

This didn't get any responses yet on the list. II would be interested to hear what other mappers think of this proposal! -- Matthijs On 26 January 2016 at 00:13, Matthijs Melissen wrote: > Hi all, > > I have created a proposal to use the tag office=government for the > tagging of government offi

Re: [Tagging] Feature Proposal - RFC - Government offices

On 27/01/2016 13:26, Matthijs Melissen wrote: This didn't get any responses yet on the list. II would be interested to hear what other mappers think of this proposal! -- Matthijs On 26 January 2016 at 00:13, Matthijs Melissen wrote: Hi all, I have created a proposal to use the tag office=gov

[Tagging] Artwork AND Memorial at the same time

Hi, One of the rules we use is the "one feature, one OSM element” [1] This makes sense for a lot of elements, e.g. if something has the tag: higway=residential it would be silly to also have amenity=restaurant on the same element. But it is not very uncommon to have a memorial that was created a

Re: [Tagging] Feature Proposal - RFC - Government offices

Hi, On 01/27/16 14:26, Matthijs Melissen wrote: > This didn't get any responses yet on the list. II would be interested > to hear what other mappers think of this proposal! 1. In many western civilizations you have a division of state powers in an executive, a legislature, and a judiciary. I beli

Re: [Tagging] Feature Proposal - Voting - (Remove name_1 and alt_name_1 from wiki)

On 27 January 2016 10:09:51 GMT+00:00, Martin Koppenhoefer wrote: >2016-01-27 10:39 GMT+01:00 Marc Gemis : > >> France ? The example boundary is in Ireland >> > > >;-) >anyway, s/France/Ireland/ and the statement remains. I bet also the >Irish >have official names for their administrative u

Re: [Tagging] Feature Proposal - Voting - (Remove name_1 and alt_name_1 from wiki)

On 27 January 2016 09:15:10 GMT+00:00, Martin Koppenhoefer wrote: >the current tagging definitely is >improvable (because you cannot see which is this official > name by looking at the current tags). If I were to add a tag for the official name, we'd end up with name=x official_name=x name_1=

Re: [Tagging] Feature Proposal - Voting - (Remove name_1 and alt_name_1 from wiki)

Hoi. To me it seems as if we suffer much from discussing too many aspects at once, and that prevents us from finding solutions. I see these separate problems: 1) Are multi-values necessary? -- I don't see general agreement on this. They might even be only necessary for a few explicit corner c

[Tagging] Discussion about Multivalued Keys

Dear all, I have created a proposal page as a channel for constructive debate about the way forward. I hope you will all take a look and participate! Although this subject is a bit more than just a proposal for a new tag, I have used the same template. I will try and flesh it out a bit more in

Re: [Tagging] Discussion about Multivalued Keys

As real world examples: * cuisine * ref on Street cabinets * destinations ? On Wed, Jan 27, 2016 at 4:09 PM, Colin Smale wrote: > Dear all, > > I have created a proposal page as a channel for constructive debate about > the way forward. I hope you will all take a look and participate! > > Altho

Re: [Tagging] Discussion about Multivalued Keys

Excellent, thanks. I have to admit I don't know much about refs on street cabinets... Could you maybe illustrate this with some examples? --colin On 2016-01-27 16:26, Marc Gemis wrote: > As real world examples: > > * cuisine > * ref on Street cabinets > * destinations > > ? > > On Wed, Jan 2

Re: [Tagging] Discussion about Multivalued Keys

W dniu 27.01.2016 16:26, Marc Gemis napisał(a): As real world examples: * cuisine * ref on Street cabinets * destinations ? * shop types (as already mentioned on proposition page) * amenity types (like fast_food + pub) * long inscriptions on monuments/memorials (above 255 chars) It would be

Re: [Tagging] Discussion about Multivalued Keys

Hi Colin, Thanks for getting this discussion started. I agree it's fine to use the proposal template also for proposals that are not about proposing a concrete tag. One thing to take into account in this discussion is that multi-valued keys often move the problem to the data consumer. For that re

Re: [Tagging] Discussion about Multivalued Keys

Seems like the mapper should simply report what is there. The data consumer should decide, based on its focus, what is more important. > On Jan 27, 2016, at 7:52 AM, Matthijs Melissen > wrote: > > Hi Colin, > > Thanks for getting this discussion started. I agree it's fine to use > the proposa

Re: [Tagging] Discussion about Multivalued Keys

Thanks Matthijs I am stating that the "list of values" syntax, whatever it turns out to be, should *at this level* not make any assumptions about ordering. No special status is conferred on the first or last value for example. This level of semantics is going to vary by tag. In some cases it may

Re: [Tagging] Discussion about Multivalued Keys

Matthijs Melissen wrote: > Take for example your example shop=supermarket, > shop=bakery. Independent of the exact way of tagging, > using a multivalued tagging scheme forces the renderer > to make a decision between a supermarket and a bakery > icon. Basically, there is no possible way for the

Re: [Tagging] Discussion about Multivalued Keys

> Thanks for getting this discussion started. I agree, thank you Colin Colin, Matthijs, good luck on this one, I hope something will come out positively. > One thing to take into account in this discussion is that multi-valued > keys often move the problem to the data consumer. For that reason I

Re: [Tagging] Discussion about Multivalued Keys

Hi, On 01/27/2016 04:09 PM, Colin Smale wrote: > I have created a proposal page as a channel for constructive debate > about the way forward. I hope you will all take a look and participate! One thing that I would like to see discussed is ordering. For example in the semicolon word, is "shop=a;b"

Re: [Tagging] Artwork AND Memorial at the same time

On Wed, 27 Jan 2016 15:00:37 +0100 Marc Zoutendijk wrote: > Hi, > > One of the rules we use is the "one feature, one OSM element” [1] > This makes sense for a lot of elements, e.g. if something has the > tag: higway=residential it would be silly to also have > amenity=restaurant on the same elem

Re: [Tagging] Tagging problem for a river running in a culvert below a track / wiki votes enforcement

On Wed, 27 Jan 2016 09:53:14 +1100 Warin <61sundow...@gmail.com> wrote: > On 27/01/2016 8:50 AM, Clifford Snow wrote: > > > > On Tue, Jan 26, 2016 at 1:14 PM, Warin <61sundow...@gmail.com > > > wrote: > > > > layer=-1 to me says this is below natural ground level

Re: [Tagging] Discussion about Multivalued Keys

Thanks Colin, this proposal makes some good points. Some comments : For completeness, you should mention the possibility of an API-level implementation[1]. Even if this'll be met with a "patches welcome" and if we need a pragmatic solution in the meantime, supporting MV at the API level has some i

Re: [Tagging] Discussion about Multivalued Keys

On 27 January 2016 at 17:18, Richard Fairhurst wrote: > Matthijs Melissen wrote: >> Take for example your example shop=supermarket, >> shop=bakery. Independent of the exact way of tagging, >> using a multivalued tagging scheme forces the renderer >> to make a decision between a supermarket and a b

Re: [Tagging] Discussion about Multivalued Keys

Hmm, I think the semicolon separated tags are necessarily ordered. Jochen has it a bit wrong in the blog with his example about coincident highways. For example US 1-9 by NYC is tagged `ref=US 1;US 9`. It would be a mistake to treat that as equivalent with US 9-1, as it’s definitely not called

Re: [Tagging] Discussion about Multivalued Keys

On 27/01/2016 17:02, Matthijs Melissen wrote: Do you have an demo rendering (screenshot is fine) for that? http://opennauticalchart.org/?permalink=true&zoom=18&lat=53.73980&lon=-0.33991&seamarks=true&coordinate_grid=true Here you will see examples with 1, 2 & 3 values

Re: [Tagging] Discussion about Multivalued Keys

Matthijs Melissen wrote: > Do you have an demo rendering (screenshot is fine) for that? There's actually a couple of ways you can do it, but http://crt.systemed.net/ uses one method - look for the brown service icons which are next to each other. It's not OSM data in this case (it's the Canal & Ri

Re: [Tagging] Discussion about Multivalued Keys

On 27/01/2016 16:36, Frederik Ramm wrote: One thing that I would like to see discussed is ordering. There should be allowance for both ordered and unordered multiple values. Whether this is left to the producer/consumer tools or indicated in the tag template is debatable. In the former case t

Re: [Tagging] Discussion about Multivalued Keys

I think refs on highways is definitely one of the cases where ordering might be significant in real life, as the shields next to the roads and on overhead signs will be in a particular order which may be said to infer some kind of weighting or priority to the largest, or topmost, signs. But there o

Re: [Tagging] Discussion about Multivalued Keys

> On Jan 27, 2016, at 9:29 AM, Malcolm Herring > wrote: > > On 27/01/2016 16:36, Frederik Ramm wrote: >> One thing that I would like to see discussed is ordering. > > There should be allowance for both ordered and unordered multiple values. > Whether this is left to the producer/consumer tool

Re: [Tagging] Discussion about Multivalued Keys

A fundamental choice is whether we fix this in the Key domain or in the Value domain. Personally I tend towards the Key domain, as there are too many issues with "semicolon syntax" which compromise its suitability for the longer term. For example, the maximum length is going to be a problem soone

Re: [Tagging] Discussion about Multivalued Keys

[2016-01-27 09:40] Tod Fitch > > Or, following the example of turn lanes, use semicolon for unordered > and vertical bar for ordered. It seems to me that a comma might be too > common a character in real world values to have a special use. While > an escape mechanism needs to be defined, it would

Re: [Tagging] Discussion about Multivalued Keys

On 27/01/2016 18:06, markus schnalke wrote: When we agree on the conceptual need,*then* we can and should discuss implementations. +1 ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Discussion about Multivalued Keys

Colin Smale wrote: > If we were looking at this problem as if we were > designing OSM on a clean whiteboard When OSM was first designed on a clean whiteboard[1], multiple values were in fact possible. An object could have name=Bridge Street name=Banbury Road and the API was happy - thou

Re: [Tagging] Discussion about Multivalued Keys

Now THAT I didn't see coming! Is this an alternative to add into the mix? If it was working at an API level, I am curious what considerations led to the decision to actively remove it in API0.6. --colin On 2016-01-27 19:45, Richard Fairhurst wrote: > Colin Smale wrote: > >> If we were looki

Re: [Tagging] Discussion about Multivalued Keys

Hi, On 01/27/2016 07:53 PM, Colin Smale wrote: > Is this an alternative to add into the mix? If it was working at an API > level, I am curious what considerations led to the decision to actively > remove it in API0.6. If I remember correctly, the main issue was that there was practially no editor

Re: [Tagging] Discussion about Multivalued Keys

On Wed, Jan 27, 2016 at 6:58 PM, Colin Smale wrote: > Excluding the argument that "that's the way it is now, why change", are > there any arguments in favour of a value-based approach? If we were looking > at this problem as if we were designing OSM on a clean whiteboard, what > reasons are there

Re: [Tagging] Discussion about Multivalued Keys

Hi Marc, On 2016-01-27 20:30, Marc Gemis wrote: > On Wed, Jan 27, 2016 at 6:58 PM, Colin Smale wrote: > >> Excluding the argument that "that's the way it is now, why change", are >> there any arguments in favour of a value-based approach? If we were looking >> at this problem as if we were de

Re: [Tagging] Discussion about Multivalued Keys

The main problem is that the lane tagging is established tagging with several 10.000's of mapped ways. Do you really want to change that ? It will take years before they are all converted to whatever new syntax we come up with. Not to mention data consumers (e.g. OsmAnd) that have to be adapted to

Re: [Tagging] Discussion about Multivalued Keys

Converting existing data can be done, if it is considered worth while to do it. As far as I am concerned we can also agree to do absolutely nothing about it, but I don't believe for one second that the issue will never be discussed again. I don't want the discussion to entirely revolve around "how

Re: [Tagging] Discussion about Multivalued Keys

On 27/01/2016, Marc Gemis wrote: > The main problem is that the lane tagging is established tagging with > several 10.000's of mapped ways. Do you really want to change that ? > It will take years before they are all converted to whatever new > syntax we come up with. Not to mention data consumers

Re: [Tagging] Discussion about Multivalued Keys

On 27/01/2016, Colin Smale wrote: > One way, using a "subscript syntax" with a "data structure" construct > using a "." as a separator": > lane[1].destination=Paris > lane[2].destination[1]=Rome > lane[2].destination[2]=Milan > lane[3].destination[1]=Berlin > lane[3].destination[2]=Munich > > Alte

Re: [Tagging] Discussion about Multivalued Keys

On 2016-01-27 22:54, moltonel 3x Combo wrote: > On 27/01/2016, Colin Smale wrote: > >> One way, using a "subscript syntax" with a "data structure" construct >> using a "." as a separator": >> lane[1].destination=Paris >> lane[2].destination[1]=Rome >> lane[2].destination[2]=Milan >> lane[3].des

Re: [Tagging] Feature Proposal - RFC - Government offices

On 28/01/2016 1:03 AM, Frederik Ramm wrote: Hi, On 01/27/16 14:26, Matthijs Melissen wrote: This didn't get any responses yet on the list. II would be interested to hear what other mappers think of this proposal! 1. In many western civilizations you have a division of state powers in an execu

Re: [Tagging] Discussion about Multivalued Keys

On 27-01-16 18:40, Tod Fitch wrote: On Jan 27, 2016, at 9:29 AM, Malcolm Herring wrote: On 27/01/2016 16:36, Frederik Ramm wrote: One thing that I would like to see discussed is ordering. There should be allowance for both ordered and unordered multiple values. Whether this is left to th

Re: [Tagging] Discussion about Multivalued Keys

Other keys that might need multiple values: * barrier / fence_type : barbed wire with an electrified wire on top. A wall with barbed wire on top ,... We need some kind of vertical order here. * information: board / map. for those information spots that show a map of the area + a description of th

Re: [Tagging] Discussion about Multivalued Keys

On Thu, Jan 28, 2016 at 6:59 AM, Warin <61sundow...@gmail.com> wrote: > On 28/01/2016 4:52 PM, Marc Gemis wrote: >> >> Other keys that might need multiple values: >> >> * barrier / fence_type : barbed wire with an electrified wire on top. >> A wall with barbed wire on top ,... We need some kind of