Re: [Tagging] Discussion about Multivalued Keys

[Daniel Koć]

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 valid examples, a pub serving fast food is still
a pub, a shop fitting into several shop types is likely none of these


And probably a fast food serving beer is still a fast food. But you have 
to choose what is "main" feature before making such statement and it's 
not always clear.



shop types (but a different one), and circumventing the maximum value
length shouldn't be done by distributing the value over several keys
(if we wanted people to write essays in the tag values we could remove
the 256 byte restriction).


This is a real life tagging problem I had once and you seem to not 
propose any way to resolve it in a different way.


It has nothing to do with promoting long entries, it is just an issue to 
be solved somehow.


--
"Завтра, завтра всё кончится!" [Ф. Достоевский]

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Discussion about Multivalued Keys

[Martin Koppenhoefer]

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 overlapping ways, something for linear
features, and maybe also something for nodes (e.g. different traffic signs
on the same pole). Using multivalues
There is already a proposal for these:
https://wiki.openstreetmap.org/wiki/Relations/Proposed/Node
The line relation might be expressed as a route (e.g. route=barrier), but
it would be better to allow for non-continuous ways as well (often bigger
barriers tend to have bifurcations and deadends, e.g. the chinese wall).

Cheers,
Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Discussion about Multivalued Keys

[Warin]

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

barrier=fence
fence=wire_electric
voltage=300
layer=1

Would need two ways ... messy. Not good.


* information: board / map. for those information spots that show a
map of the area + a description of the history, the nature and / or
the access rules.

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!

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 the
coming days, but everyone is of course welcome to add their stuff.

http://wiki.openstreetmap.org/wiki/Proposed_features/Multivalued_Keys



--colin




___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Discussion about Multivalued Keys

[Martin Koppenhoefer]

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, a shop fitting into several shop types is likely none of these shop
types (but a different one), and circumventing the maximum value length
shouldn't be done by distributing the value over several keys (if we wanted
people to write essays in the tag values we could remove the 256 byte
restriction).

But there are keys which might require multiple values, like the mentioned
cuisine and destination. Not sure for ref, typically these would be
different kind of refs, i.e. would be better in this case to specify the
kind of ref (e.g. ref:vatin).

Cheers,
Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Discussion about Multivalued Keys

[moltonel 3x Combo]

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 established. foo[1] looks
>> better than foo_1 to my programer eyes, but is has no technical
>> advantage (?) and I suspect that most people will find foo_1 more
>> pleasing, it's also one less character to type, less annoying to parse
>> with a regexp, and much more established in taginfo.
>
> Would you feel any different about your foo:1 example if it were written
> foo%1, avoiding any clash with namespacing?

I don't really care wether it's _1, %1 or [1], except that the first
one is already popular. But

> By the way, I am trying to maintain the distinction between the "suffix
> notation" where the index value is actually the final part of the key
> segment, and the "hierarchical/seamark" notation where the index value
> is a separate segment of the full key string.

As far as I'm aware, the "suffix notation" has always meant "suffix
within a namespace", not "suffix at the very end of the key". We
already have a significant number of "*name_1:*" keys in the db, for
example.

> Maybe we should look at some technical use cases, like "in a navigation
> map creator, find all the categories for a POI" or "find the per-lane
> destination (and destination:ref and turn-lane stuff) information so I
> can construct a simulated road sign". Some will be done with a
> programming language, others may naturally tend towards SQL.
>
>> Concerning using '.' as a separator instead of ':', I don; t see what
>> it brings us, beside familiarity to users of some programing languages
>> (but change language and sudenly ':' becomes more familiar).
>
> Sometimes using a familiar character (such as the ":" here) with new
> semantics can lead to confusion. There comes a point when it is better
> to make a clean break so there is no confusion. Whether it is a colon or
> a dot or some other character is "detail" really.

Yes, but in the "lane[1].destination=Paris" example, you use '.' for
something (namespacing) that we've always happily used ':' before. I
don't see a need for the change, my best guess was "it looks more
familiar to users of some programming languages" but IMHO it's not
worth the confusion it'll bring to most people.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Discussion about Multivalued Keys

[markus schnalke]

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

Initially, I wanted to add a section to the talk page of the wiki
page but my text now appears to be better suited for an email. Please
feel free to integrate any part of my considerations into the wiki
page.



I see two general ways to solve the problem of MV in OSM:

1) Allow multiple identical keys per object (as is was before API
0.6, I learned). This means tag names of one object need *not* be
unique. When we talk about tag names being unique, we should
distinguish between being unique in the data storage and being
unique at the surface (GUI). It seems ... well, what does it seem?
Are we more concerned about the technical storage level or at the
user experience? Which of them are we discussing?


2) Make multiple identical keys by some *technical* measurement
unique. This is the currently assumed way to go, at least as such
it appears to me.

I (now) think that it is important to keep the value domain free
from logic and thus have it reserved for literal data. This means,
MV need to be implemented in the key domain.

Currently, we mostly discuss with concrete examples. The assumption
is, that the user would have to deal with these suffixes. Maybe he
doesn't have to. It might be possible to abstract the user's view
from the internal storage. Then the actual encoding becomes
irrelevant from the user's perspective. Multiple identical keys
could be presented to him (even grouped) ... and they'd be
translated (e.g.  by appending arbitrary suffixes (e.g. hashes of
the value)) at the interface to the data storage layer. (I focus
on unordered MVs here.)

As a user, I'd never want to have to deal with this MV problem at
all, which means no encoding should be required by me, neither in
the value *nor* in the key domain. If there are two refs, then I'd
want to tag: ref=foo + ref=bar. The internal storage should not be
the user's problem.

Of course, it's not that easy, because raw data is dealt with much
too often. Nonetheless we should kept in mind, that a separation
of the user's view from the data storage can solve colliding wishes.


Concerning the choice, of how to add such a suffix:

We should realize what we try to do here: We're violating the
first normal form for relational databases, by encoding two
separate bits of information in one field (the key's name and some
unique suffix). We already came to the opinion, that encoding
multiple values in one field in the value domain is bad ... but it
is equally bad in the key domain.

And it is even worse if the separator is not (technically)
reserved for that specific purpose. If we would use the underscore
(_) to separate the key's name from the unique suffix, then the
technical separation of name and suffix would be pretty fragile,
because names already contain underscores. The split would be
rather guessing, based on the suffix to be a number.

Hence, if we do encode two separate values in one field, then we
better try hard to make the separator reserved. This not only
spares us escaping, but also allows us to search for exact key
names, because the search engine can then be enabled to know which
is the name to compare and which is the suffix to ignore.

The underscore approach fails in this respect equally as the colon
approach. Of the currently discussed approaches, only the subscript
(bracket) syntax satisfies this need. (Assuming that there are no
brackets in key names, currently.) However, it's closing bracket
is technically superfluous and only motivated by the thinking that
humans have to see these suffixes.


What we need in my opinion is one single character, that must
never be part of any key name and never be part of any suffix.
Using this separator, we encode two separate bits of information
in one field (the key field) ... and thus have effectively three
columns in a two-column table.

At the surface (GUI) we should rather hide the technical suffix
stuff.


meillo


P.S.
Ordered MVs are not considered here. It is not clear if we need
to consider them.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Discussion about Multivalued Keys

[Martin Koppenhoefer]

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 for the 2nd ref". In suffix syntax, this could be
> distriinguished by "ref_1=x ref_2=y source_1:ref=a source_2:ref=b" vs
> "ref_1=x ref_2=y source:ref_1=a source:ref_2=b", even though this is
> becoming hairy.
>



I believe we should restructure the way we use metadata aside with data in
the particular tags source and maybe note and fixme (but not description).
We are trying to convince people to add source tags on the changesets, but
putting them on individual objects still has strong advocates, so we will
likely have to live with it. As an idea, the source information could
become a subtag of another tag, i.e. rather than being attached to an
object it would be attached to a tag (or to the position). This could also
become more refined with several, optional formalized source tags, e.g. for
the source date, a source link, a source license(?), etc.

cheers,
Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Discussion about Multivalued Keys

[Warin]

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
clear wether an MV tag corresponds to "multiple sources for all the
refs" or to "source for the 2nd ref". In suffix syntax, this could be
distriinguished by "ref_1=x ref_2=y source_1:ref=a source_2:ref=b" vs
"ref_1=x ref_2=y source:ref_1=a source:ref_2=b", even though this is
becoming hairy.



Errr I would rather see

ref_1=x
source:ref_1=y

Keep the value the same from the first key to the delimited referrer = 
makes it easier for all to recognise and sort.



I believe we should restructure the way we use metadata aside with 
data in the particular tags source and maybe note and fixme (but not 
description). We are trying to convince people to add source tags on 
the changesets, but putting them on individual objects still has 
strong advocates, so we will likely have to live with it.


Some of my change sets have more than one source, I document to 
discriminate the sources  as well as I can. But it is a good deal clear 
to me if I put it on the way/node/relationship.
As an idea, the source information could become a subtag of another 
tag, i.e. rather than being attached to an object it would be attached 
to a tag (or to the position). This could also become more refined 
with several, optional formalized source tags, e.g. for the source 
date, a source link, a source license(?), etc.


name:source= ? Rather than source:name=... humm That would make people 
think about the source being part of some characteristic of the object.


cheers,
Martin


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Discussion about Multivalued Keys

[Colin Smale]

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].destination[1]=Berlin
>> lane[3].destination[2]=Munich
>> 
>> Alternatively, using a "suffix syntax", something like you suggest
>> lane_1:destination=Paris
>> lane_2:destination_1=Rome
>> lane_2:destination_2=Milan
>> etc.
>> 
>> Thirdly, using the "seamark" construction:
>> lane:1:destination:1=Paris
>> lane:2:destination:1=Rome
>> lane:2:destination:2=Milan
>> etc.
> 
> 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 established. foo[1] looks
> better than foo_1 to my programer eyes, but is has no technical
> advantage (?) and I suspect that most people will find foo_1 more
> pleasing, it's also one less character to type, less annoying to parse
> with a regexp, and much more established in taginfo.

Would you feel any different about your foo:1 example if it were written
foo%1, avoiding any clash with namespacing? 

By the way, I am trying to maintain the distinction between the "suffix
notation" where the index value is actually the final part of the key
segment, and the "hierarchical/seamark" notation where the index value
is a separate segment of the full key string. 

Maybe we should look at some technical use cases, like "in a navigation
map creator, find all the categories for a POI" or "find the per-lane
destination (and destination:ref and turn-lane stuff) information so I
can construct a simulated road sign". Some will be done with a
programming language, others may naturally tend towards SQL. 

> Concerning using '.' as a separator instead of ':', I don; t see what
> it brings us, beside familiarity to users of some programing languages
> (but change language and sudenly ':' becomes more familiar).

Sometimes using a familiar character (such as the ":" here) with new
semantics can lead to confusion. There comes a point when it is better
to make a clean break so there is no confusion. Whether it is a colon or
a dot or some other character is "detail" really. 
  ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Discussion about Multivalued Keys

[Tijmen Stam]

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 the producer/consumer tools or indicated in the tag 
template is debatable. In the former case the tag definition should be 
documented to indicate the interpretation of multiple values. In the latter 
case, a solution such as different delimiter characters would be needed - maybe 
semicolon for unordered and commas for ordered?



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 be nice if it were seldom needed.

Assuming, of course, that a delimiter syntax in the value domain is used.


Even within a lanes "namespace", the semicolon-lists have an ordering. 
For example in the destination:lanes, the first item in the semicolon 
(sub)list is meant to be the top one on signs: see the second-last 
example on http://wiki.openstreetmap.org/wiki/Key:destination.





___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Discussion about Multivalued Keys

[Marc Gemis]

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 the history, the nature and / or
the access rules.

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!
>
> 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 the
> coming days, but everyone is of course welcome to add their stuff.
>
> http://wiki.openstreetmap.org/wiki/Proposed_features/Multivalued_Keys
>
>
>
> --colin
>
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Discussion about Multivalued Keys

[Marc Gemis]

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!
>
> 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 the
> coming days, but everyone is of course welcome to add their stuff.
>
> http://wiki.openstreetmap.org/wiki/Proposed_features/Multivalued_Keys
>
>
>
> --colin
>
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Discussion about Multivalued Keys

[Colin Smale]

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 be true
that a mulivalent shop has a dominant characteristic, but this forces
the mapper to make a choice, which in some cases is actually quite hard.
So I would like to defer that discussion to tag-level as much as
possible, although it may be reasonable to discuss a generic
construction like nominating one of the multiple values as "primary" for
example. 

Rendering a "printed" map is only one use to which the OSM data is put.
In that case I agree that mapnik et. al. have to make some tough
decisions. There are other use cases such as navigation (searching for
POIs) where you want the shop to be found under multiple categories,
where no one category takes precedence.

Of course any change of syntax (or indeed any change of tagging) imposes
a certain workload on data consumers. I believe that the hoops they have
to jump through to consume OSM data "accurately" are magnified
enormously by the myriad tagging conventions and exceptions. I hope that
the benefit of reducing this less productive side of their work will
outweigh the one-time investment that they will need to make to
accommodate a single, well-defined new syntax which can be re-used in
many, many situations. 

--colin 

On 2016-01-27 16:52, Matthijs Melissen wrote:

> 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 reason I'd
> recommend to avoid them in many cases.
> 
> 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
> renderer to support a multi-valued key here! The renderer might have a
> rule that considers supermarkers always more important than bakeries,
> or vice versa. But I think it's much more useful if the mapper decides
> what's the main function, supermarket or bakery, rather than forcing
> the renderer to make a choice.
> 
> -- Matthijs
> 
> On 27 January 2016 at 16:09, 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!
>> 
>> 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 the
>> coming days, but everyone is of course welcome to add their stuff.
>> 
>> http://wiki.openstreetmap.org/wiki/Proposed_features/Multivalued_Keys
>> 
>> --colin
>> 
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
 ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Discussion about Multivalued Keys

[Daniel Koć]

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 also good to indicate when the order is insignificant (so 
the numbers are only for technical reasons) - for example:


key:unordered:1=some_value
key:unordered:2=some_other_value

--
"Завтра, завтра всё кончится!" [Ф. Достоевский]

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Discussion about Multivalued Keys

[Colin Smale]

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 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!
>> 
>> 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 the
>> coming days, but everyone is of course welcome to add their stuff.
>> 
>> http://wiki.openstreetmap.org/wiki/Proposed_features/Multivalued_Keys
>> 
>> --colin
>> 
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
 ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Discussion about Multivalued Keys

[Tod Fitch]

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 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 reason I'd
> recommend to avoid them in many cases.
> 
> 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
> renderer to support a multi-valued key here! The renderer might have a
> rule that considers supermarkers always more important than bakeries,
> or vice versa. But I think it's much more useful if the mapper decides
> what's the main function, supermarket or bakery, rather than forcing
> the renderer to make a choice.
> 
> -- Matthijs
> 
> On 27 January 2016 at 16:09, 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!
>> 
>> 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 the
>> coming days, but everyone is of course welcome to add their stuff.
>> 
>> http://wiki.openstreetmap.org/wiki/Proposed_features/Multivalued_Keys
>> 
>> 
>> 
>> --colin
>> 
>> 
>> 
>> 
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>> 
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



smime.p7s
Description: S/MIME cryptographic signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Discussion about Multivalued Keys

[Richard Fairhurst]

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 renderer 
> to support a multi-valued key here!

That's not at all true. A rendering chain can choose to split out multiple
values and then render a different icon for each one. You don't even need
any preprocessing - you can do it on-the-fly with a SQL query, and I've done
exactly that in one (Mapnik-based) map I've produced.

I realise _openstreetmap-carto_ doesn't do that, but osm-carto takes a very
conservative approach of not doing much additional processing to the data. I
can understand that approach, but that doesn't mean "there is no possible
way" for anyone else to do it.

Richard



--
View this message in context: 
http://gis.19327.n5.nabble.com/Feature-Proposal-Voting-Remove-name-1-and-alt-name-1-from-wiki-tp5865654p5865995.html
Sent from the Tagging mailing list archive at Nabble.com.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Discussion about Multivalued Keys

[Matthijs Melissen]

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 reason I'd
recommend to avoid them in many cases.

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
renderer to support a multi-valued key here! The renderer might have a
rule that considers supermarkers always more important than bakeries,
or vice versa. But I think it's much more useful if the mapper decides
what's the main function, supermarket or bakery, rather than forcing
the renderer to make a choice.

-- Matthijs

On 27 January 2016 at 16:09, 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!
>
> 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 the
> coming days, but everyone is of course welcome to add their stuff.
>
> http://wiki.openstreetmap.org/wiki/Proposed_features/Multivalued_Keys
>
>
>
> --colin
>
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Discussion about Multivalued Keys

[Marc Gemis]

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 vertical
>> order here.
>
> 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.

yeah, I thought about that one as well. It depends on how detailed you
are mapping in 3D. For the moment, the tools are not adequate enough
to deal with this.
In some cases the multi-valued keys are needed because we do not map
enough detail.

The information board is the same. If we would map the different
sections on the board, we would have a board and a map section. No
need for multi valued keys.

A traffic calming that is a choker and a table. When we draw the width
of the road and the height of the table, no need for multi valued keys

If we would draw separate ways for lanes instead of 1 for the complete
street, Some multi-valued issues would disappear here as well.

House numbers or flat numbers are sometimes mapped with semi-colons
are well. When the building would be divided in smaller units, flat
numbers could go on the flats instead of having multiple on the
building.

So some multi-valued issues are caused by the level of detail that we
map nowadays. This is not true for all tags, e.g.  refs, cuisine, ...
need to be multi-valued.

m

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Discussion about Multivalued Keys

[Malcolm Herring]

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 the tag definition 
should be documented to indicate the interpretation of multiple values. 
In the latter case, a solution such as different delimiter characters 
would be needed - maybe semicolon for unordered and commas for ordered?



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Discussion about Multivalued Keys

[Malcolm Herring]

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

[moltonel 3x Combo]

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 impressive pros & cons.

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 for the 2nd ref". In suffix syntax, this could be
distriinguished by "ref_1=x ref_2=y source_1:ref=a source_2:ref=b" vs
"ref_1=x ref_2=y source:ref_1=a source:ref_2=b", even though this is
becoming hairy.

Concerning ordered vs unordered, I don't think we should define it at
this level. Wether a key is treated as ordered or not will depend both
on the key and the consumer. For example searching for a POI will
always treat the MV as unordered, but displaying it is likely to treat
it as ordered (either by displaying an ordered list, or only
displaying the first value). Conversely, a carefully ordered list
might get interpreted as unordered (Say I want to promote POIs with a
particular tag, and always disply that one first if present. Or I've
loaded the values in a language structure that doesn't conserve
order).

A syntax to specify wether a list is ordered or not will typically be
ignored by consumers, and will only make the spec messyer. IMHO,
producers should write every tag as if it was ordered, and keep in
mind that consumers will do their own thing anyway.


[1]:http://wiki.openstreetmap.org/wiki/API_v0.7#Multiple_Tags

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Discussion about Multivalued Keys

[Colin Smale]

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 other cases, with different tags, where ordering is
arbitrary and 1-2 is totally equivalent to 2-1. Which is why the syntax
at the level I am seeking to discuss now, should not force the list to
be interpreted as ordered - that depends on the key and we can have that
discussion (also about whether the values are actually ordered in real
life!) later.

--colin 

On 2016-01-27 18:16, Bryan Housel wrote:

> 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 that 
> nor signed that way:  http://www.openstreetmap.org/way/51509994 
> 
> I'm sure there are other examples of this, where the ordering of coincident 
> highway refs would look totally wrong if reversed. 
> 
> On Jan 27, 2016, at 11:36 AM, Frederik Ramm  wrote: 
> 
> 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" the same as "shop=b;a" or does the
> former mean that it is an "a" with attached "b" and the latter mean that
> it is a "b" with an attached "a"?
> 
> If a;b is identical to b;a then having both is of course a major pain
> and would shift a lot of preprocessing work on tools like taginfo.
> 
> On semicolons, also see
> https://blog.jochentopf.com/2013-09-23-semicolons-in-osm-tags.html
> 
> Bye
> Frederik
> 
> -- 
> Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Discussion about Multivalued Keys

[Richard Fairhurst]

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
& River Trust's GIS data), but it is Mapnik and the principle is equivalent:
pulling multiple values from a single text field.

There are a couple of reasons I wouldn't recommend it for osm-carto, but
maybe in a couple of years we'll all have moved to GL-based rendering and
the styling decisions will be different. ;)

cheers
Richard




--
View this message in context: 
http://gis.19327.n5.nabble.com/Feature-Proposal-Voting-Remove-name-1-and-alt-name-1-from-wiki-tp5865654p5866011.html
Sent from the Tagging mailing list archive at Nabble.com.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Discussion about Multivalued Keys

[Tod Fitch]

> 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 tools or indicated in the tag 
> template is debatable. In the former case the tag definition should be 
> documented to indicate the interpretation of multiple values. In the latter 
> case, a solution such as different delimiter characters would be needed - 
> maybe semicolon for unordered and commas for ordered?
> 

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 be nice if it were seldom needed.

Assuming, of course, that a delimiter syntax in the value domain is used.

smime.p7s
Description: S/MIME cryptographic signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Discussion about Multivalued Keys

[Colin Smale]

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 sooner or
later, and the low appetite for defining an "escape" mechanism to allow
the delimiter to be included in the data itself. Also its extensibility
towards "data structures" is much less obvious than a key-based
solution. 

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 to say that that the "multivalued
keys" problem is best addressed in the Value domain? 

--colin 

  ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Discussion about Multivalued Keys

[Matthijs Melissen]

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 bakery
>> icon. Basically, there is no possible way for the renderer
>> to support a multi-valued key here!
>
> That's not at all true. A rendering chain can choose to split out multiple
> values and then render a different icon for each one. You don't even need
> any preprocessing - you can do it on-the-fly with a SQL query, and I've done
> exactly that in one (Mapnik-based) map I've produced.

Do you have an demo rendering (screenshot is fine) for that?

-- Matthijs

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Discussion about Multivalued Keys

[Bryan Housel]

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 that nor 
signed that way:  http://www.openstreetmap.org/way/51509994 


I’m sure there are other examples of this, where the ordering of coincident 
highway refs would look totally wrong if reversed.



> On Jan 27, 2016, at 11:36 AM, Frederik Ramm  wrote:
> 
> 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" the same as "shop=b;a" or does the
> former mean that it is an "a" with attached "b" and the latter mean that
> it is a "b" with an attached "a"?
> 
> If a;b is identical to b;a then having both is of course a major pain
> and would shift a lot of preprocessing work on tools like taginfo.
> 
> On semicolons, also see
> https://blog.jochentopf.com/2013-09-23-semicolons-in-osm-tags.html
> 
> Bye
> Frederik
> 
> 
> -- 
> Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Discussion about Multivalued Keys

[markus schnalke]

[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 be nice if it were
> seldom needed.

Please try to avoid discussing implementations when discussing
concepts!

The topic is about the need of an ordering of values, not about
how to implement it. If we constantly fall into the implementation
discussion, then we are constantly forced to deal with the _1 vs. ;
question ... without solving the conceptual question.

It's fully enough to state that one thinks, we need to have both
possibilities -- marking some MV as ordered and some as unordered
-- however that might be represented in the future.

When we agree on the conceptual need, *then* we can and should
discuss implementations.


meillo

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Discussion about Multivalued Keys

[Colin Smale]

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 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 - though, in practice, no (/very little) software
> supported it.
> 
> This ability was only removed in API 0.6:
> 
> https://lists.openstreetmap.org/pipermail/talk/2009-January/033437.html
> 
> Richard
> 
> [1] beer mat
> 
> --
> View this message in context: 
> http://gis.19327.n5.nabble.com/Feature-Proposal-Voting-Remove-name-1-and-alt-name-1-from-wiki-tp5865654p5866023.html
> Sent from the Tagging mailing list archive at Nabble.com.
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
 ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Discussion about Multivalued Keys

[Frederik Ramm]

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 that handled this right; every programmer on the planet went "hey
great I'll use a hash map to store keys and values", and so the few
objects that did have multi-value keys were always at risk of being ruined.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Discussion about Multivalued Keys

[Richard Fairhurst]

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 - though, in practice, no (/very little) software
supported it.

This ability was only removed in API 0.6:

https://lists.openstreetmap.org/pipermail/talk/2009-January/033437.html

Richard

[1] beer mat



--
View this message in context: 
http://gis.19327.n5.nabble.com/Feature-Proposal-Voting-Remove-name-1-and-alt-name-1-from-wiki-tp5865654p5866023.html
Sent from the Tagging mailing list archive at Nabble.com.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Discussion about Multivalued Keys

[Marc Gemis]

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 to say that that the "multivalued keys" problem is best
> addressed in the Value domain?

For destination:lanes you could have Paris|Rome;Milan|Berlin;Munich
for 3 lanes with different destinations. The middle lane has
destinations Rome and Milan.  I have no idea how you can solve this
with a key based approach:  destination_1:lane_2 = Rome ??

Also the semi-colon is used a lot as separator in the opening_hours tag.

Even if we are not considering solutions, please add the functional
specification for destination:lanes and all xxx:lanes (e.g.
turn:lanes) to the list of things to consider.



I thought of some extra examples of things needing multiple values

sport=multi needs a solution
traffic_calming in case  of e.g. a table + choker combination
street names for streets that form the border between 2 villages and
have different names on both sides
surface, e.g. concrete lanes with cobblestones in the middle, or a
track that is half dirt half asphalt for cyclists.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Discussion about Multivalued Keys

[Colin Smale]

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 designing OSM on a clean whiteboard, what
>> reasons are there to say that that the "multivalued keys" problem is best
>> addressed in the Value domain?
> 
> For destination:lanes you could have Paris|Rome;Milan|Berlin;Munich
> for 3 lanes with different destinations. The middle lane has
> destinations Rome and Milan.  I have no idea how you can solve this
> with a key based approach:  destination_1:lane_2 = Rome ??

I would definitely start with the lane, and let the destination be an
attribute of the lane rather than the other way round. 

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 

Alternatively, using a "suffix syntax", something like you suggest 
lane_1:destination=Paris 
lane_2:destination_1=Rome 
lane_2:destination_2=Milan 
etc. 

Thirdly, using the "seamark" construction: 
lane:1:destination:1=Paris 
lane:2:destination:1=Rome 
lane:2:destination:2=Milan 
etc. 

The "lane" is a definite candidate here for a "data structure"
definition - each lane has many attributes: width, access/vehicle types,
destination, turn direction,. 

> Also the semi-colon is used a lot as separator in the opening_hours tag.
> 
> Even if we are not considering solutions, please add the functional
> specification for destination:lanes and all xxx:lanes (e.g.
> turn:lanes) to the list of things to consider.

Do any of these present any unique issues? I suspect they can be
addressed in the same way as with the destination-per-lane above. 

> I thought of some extra examples of things needing multiple values
> 
> sport=multi needs a solution
> traffic_calming in case  of e.g. a table + choker combination

Good examples, I will add them to the list 

> street names for streets that form the border between 2 villages and
> have different names on both sides
> surface, e.g. concrete lanes with cobblestones in the middle, or a
> track that is half dirt half asphalt for cyclists.

I am not sure I agree with you here. The two names/surfaces do not refer
to the same bit of road, and I think you should solve this by splitting
the road into lanes, and having a single name and a single surface for
each lane. 

> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
 ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Discussion about Multivalued Keys

[Colin Smale]

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 do we handle
tagX with its existing data" but more around the data metamodelling and
its representations. Nobody, especially me, says this is going to be
easy... And I have quite a bit of experience with data modelling and
transformation. 

The best way to help data consumers in the long run is through
consistency and uniformity. Even if some things are technically wrong
(like elevations being relative to local datum instead of WGS84) they
can be fixed up, as long as they are consistently wrong. 

If your road is only 1.5 lanes wide and you don't see how to tag its
three surface zones, I think you should raise this in a separate thread,
as the solution to that will be independent of the outcome of this
discussion, I'm sure... 

//colin 

On 2016-01-27 21:08, 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 (e.g. OsmAnd)
> that have to be adapted to support both syntaxes.
> 
> I don't want to be against new proposals, but do we have to rethink
> each and every tag ? Sometimes you have legacy (as in software
> development) that you have to live with because the cost of redoing it
> is just too high. Let's first focus on tags that really need a
> solution (the others in your list) and let destination/lane/etc alone.
> 
> As for the surface, I'm thinking about a road with only 1 (or 1.5)
> lanes such as [1 [1]]. I don't see how it can be split into lanes. a car /
> tractor needs the three "lanes"  then
> 
> [1] 
> https://xian.smugmug.com/OSM/OSM-2015/2015-11-21-Bazel-Kruibeke/i-KDSHQNR/0/X3/DSC_8025-X3.jpg
> 
> regards
> 
> m
> 
> On Wed, Jan 27, 2016 at 8:59 PM, Colin Smale  wrote: 
> 
>> 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 designing OSM on a clean whiteboard, what
>> reasons are there to say that that the "multivalued keys" problem is best
>> addressed in the Value domain?
>> 
>> For destination:lanes you could have Paris|Rome;Milan|Berlin;Munich
>> for 3 lanes with different destinations. The middle lane has
>> destinations Rome and Milan.  I have no idea how you can solve this
>> with a key based approach:  destination_1:lane_2 = Rome ??
>> 
>> I would definitely start with the lane, and let the destination be an
>> attribute of the lane rather than the other way round.
>> 
>> One way, using a "subscript syntax" with a "data structure" construct using
>> a "." as a separator":
>> lane[1 [1]].destination=Paris
>> lane[2].destination[1 [1]]=Rome
>> lane[2].destination[2]=Milan
>> lane[3].destination[1 [1]]=Berlin
>> lane[3].destination[2]=Munich
>> 
>> Alternatively, using a "suffix syntax", something like you suggest
>> lane_1:destination=Paris
>> lane_2:destination_1=Rome
>> lane_2:destination_2=Milan
>> etc.
>> 
>> Thirdly, using the "seamark" construction:
>> lane:1:destination:1=Paris
>> lane:2:destination:1=Rome
>> lane:2:destination:2=Milan
>> etc.
>> 
>> The "lane" is a definite candidate here for a "data structure" definition -
>> each lane has many attributes: width, access/vehicle types, destination,
>> turn direction,.
>> 
>> Also the semi-colon is used a lot as separator in the opening_hours tag.
>> 
>> Even if we are not considering solutions, please add the functional
>> specification for destination:lanes and all xxx:lanes (e.g.
>> turn:lanes) to the list of things to consider.
>> 
>> Do any of these present any unique issues? I suspect they can be addressed
>> in the same way as with the destination-per-lane above.
>> 
>> I thought of some extra examples of things needing multiple values
>> 
>> sport=multi needs a solution
>> traffic_calming in case  of e.g. a table + choker combination
>> 
>> Good examples, I will add them to the list
>> 
>> street names for streets that form the border between 2 villages and
>> have different names on both sides
>> surface, e.g. concrete lanes with cobblestones in the middle, or a
>> track that is half dirt half asphalt for cyclists.
>> 
>> I am not sure I agree with you here. The two names/surfaces do not refer to
>> the same bit of road, and I think you should solve this by splitting the
>> road into lanes, and having a single name and a single surface for each
>> lane.
>> 
>> 

Re: [Tagging] Discussion about Multivalued Keys

[moltonel 3x Combo]

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 (e.g. OsmAnd)
> that have to be adapted to support both syntaxes.

While it may not make sense to convert existing lane tags to whatever
gets decided here, the lane attribute is a good usecase to test an MV
scheme against. If an MV scheme can't handle a known important
usecase, we'll have a hard time recomending it as *the* MV scheme.

FWIW, I think the suffix scheme maps to the :lanes namespace in a very
logical and straightforward way. It's just... Much more verbose than
the currently established scheme. Even if editors started supporting
this kind of structured data in a nice way, it'd be a hard sell
compared to typing a handfull of ';' and '|'. This is certainly an
important reason why semicolon-MV remains popular despite its
technical issues compared to suffix_MV. Mappers do not (all) think
like programers.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Discussion about Multivalued Keys

[moltonel 3x Combo]

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
>
> Alternatively, using a "suffix syntax", something like you suggest
> lane_1:destination=Paris
> lane_2:destination_1=Rome
> lane_2:destination_2=Milan
> etc.
>
> Thirdly, using the "seamark" construction:
> lane:1:destination:1=Paris
> lane:2:destination:1=Rome
> lane:2:destination:2=Milan
> etc.


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 established. foo[1] looks
better than foo_1 to my programer eyes, but is has no technical
advantage (?) and I suspect that most people will find foo_1 more
pleasing, it's also one less character to type, less annoying to parse
with a regexp, and much more established in taginfo.

Concerning using '.' as a separator instead of ':', I don; t see what
it brings us, beside familiarity to users of some programing languages
(but change language and sudenly ':' becomes more familiar).

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging