Re: [Tagging] Discussion about Multivalued Keys

W dniu 28.01.2016 10:45, Martin Koppenhoefer napisał(a): 2016-01-27 16:45 GMT+01:00 Daniel Koć : * shop types (as already mentioned on proposition page) * amenity types (like fast_food + pub) * long inscriptions on monuments/memorials (above 255 chars) those all don't seem

Re: [Tagging] Discussion about Multivalued Keys

2016-01-28 6:59 GMT+01:00 Warin <61sundow...@gmail.com>: > Use the layer key? > > barrier=fence > fence=barbed_wire > layer=0 ... not required > > barrier=fence > fence=wire_electric > voltage=300 > layer=1 > > Would need two ways ... messy. Not good. > we could use a relation to avoid

Re: [Tagging] Discussion about Multivalued Keys

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 vertical order here. Use the layer key? barrier=fence fence=barbed_wire layer=0

Re: [Tagging] Discussion about Multivalued Keys

2016-01-27 16:45 GMT+01:00 Daniel Koć : > * shop types (as already mentioned on proposition page) > * amenity types (like fast_food + pub) > * long inscriptions on monuments/memorials (above 255 chars) > those all don't seem valid examples, a pub serving fast food is still a pub,

Re: [Tagging] Discussion about Multivalued Keys

On 27/01/2016, Colin Smale wrote: > On 2016-01-27 22:54, moltonel 3x Combo wrote: >> Concerning foo_1 vs foo[1] vs foo:1, I this the last one can be safely >> thrown to the idea bin (despite being used by seamarks) because ':' >> clashes with namespacing, which is firmly

Re: [Tagging] Discussion about Multivalued Keys

Hoi, I'd like to share some thoughts about the ``How to implement MV in OSM'' question, as opened in: http://wiki.openstreetmap.org/wiki/Proposed_features/Multivalued_Keys I'd prefer to first have explicit agreement that we actually need MV ... but as the implementation discussion is already

Re: [Tagging] Discussion about Multivalued Keys

2016-01-27 18:00 GMT+01:00 moltonel 3x Combo : > You barely broach the subject of how MV and namespaces combine. For > example if an object has multiple refs with sources, it should be > clear wether an MV tag corresponds to "multiple sources for all the > refs" or to "source

Re: [Tagging] Discussion about Multivalued Keys

On 28/01/2016 8:51 PM, Martin Koppenhoefer wrote: 2016-01-27 18:00 GMT+01:00 moltonel 3x Combo >: You barely broach the subject of how MV and namespaces combine. For example if an object has multiple refs with sources, it should be

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 &

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

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

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

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

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

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

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

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 -

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,

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

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

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

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 >