[Tagging] Discussion about Multivalued Keys

Colin Smale colin.smale at xs4all.nl
Wed Jan 27 19:59:20 UTC 2016


Hi Marc, 

On 2016-01-27 20:30, Marc Gemis wrote:

> On Wed, Jan 27, 2016 at 6:58 PM, Colin Smale <colin.smale at xs4all.nl> 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 at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20160127/5fe46eef/attachment.html>


More information about the Tagging mailing list