[Tagging] Discussion about Multivalued Keys

Marc Gemis marc.gemis at gmail.com
Wed Jan 27 20:08:51 UTC 2016


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]. 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 <colin.smale at xs4all.nl> wrote:
> 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



More information about the Tagging mailing list