<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /></head><body style='font-size: 10pt; font-family: Verdana,Geneva,sans-serif'>
<p>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.</p>
<div> </div>
<p>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.</p>
<p>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.</p>
<p>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...</p>
<p>//colin</p>
<p>On 2016-01-27 21:08, Marc Gemis wrote:</p>
<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0"><!-- html ignored --><!-- head ignored --><!-- meta ignored -->
<div class="pre" style="margin: 0; padding: 0; font-family: monospace">The main problem is that the lane tagging is established tagging with<br /> several 10.000's of mapped ways. Do you really want to change that ?<br /> It will take years before they are all converted to whatever new<br /> syntax we come up with. Not to mention data consumers (e.g. OsmAnd)<br /> that have to be adapted to support both syntaxes.<br /><br /> I don't want to be against new proposals, but do we have to rethink<br /> each and every tag ? Sometimes you have legacy (as in software<br /> development) that you have to live with because the cost of redoing it<br /> is just too high. Let's first focus on tags that really need a<br /> solution (the others in your list) and let destination/lane/etc alone.<br /><br /> As for the surface, I'm thinking about a road with only 1 (or 1.5)<br /> lanes such as [<a href="https://xian.smugmug.com/OSM/OSM-2015/2015-11-21-Bazel-Kruibeke/i-KDSHQNR/0/X3/DSC_8025-X3.jpg">1</a>]. I don't see how it can be split into lanes. a car /<br /> tractor needs the three "lanes" then....<br /><br /><br /> [1] <a href="https://xian.smugmug.com/OSM/OSM-2015/2015-11-21-Bazel-Kruibeke/i-KDSHQNR/0/X3/DSC_8025-X3.jpg">https://xian.smugmug.com/OSM/OSM-2015/2015-11-21-Bazel-Kruibeke/i-KDSHQNR/0/X3/DSC_8025-X3.jpg</a><br /><br /><br /> regards<br /><br /> m<br /><br /><br /> On Wed, Jan 27, 2016 at 8:59 PM, Colin Smale <<a href="mailto:colin.smale@xs4all.nl">colin.smale@xs4all.nl</a>> wrote:
<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0">Hi Marc,<br /><br /> On 2016-01-27 20:30, Marc Gemis wrote:<br /><br /> On Wed, Jan 27, 2016 at 6:58 PM, Colin Smale <<a href="mailto:colin.smale@xs4all.nl">colin.smale@xs4all.nl</a>> wrote:<br /><br /> Excluding the argument that "that's the way it is now, why change", are<br /> there any arguments in favour of a value-based approach? If we were looking<br /> at this problem as if we were designing OSM on a clean whiteboard, what<br /> reasons are there to say that that the "multivalued keys" problem is best<br /> addressed in the Value domain?<br /><br /><br /> For destination:lanes you could have Paris|Rome;Milan|Berlin;Munich<br /> for 3 lanes with different destinations. The middle lane has<br /> destinations Rome and Milan. I have no idea how you can solve this<br /> with a key based approach: destination_1:lane_2 = Rome ??<br /><br /><br /> I would definitely start with the lane, and let the destination be an<br /> attribute of the lane rather than the other way round.<br /><br /> One way, using a "subscript syntax" with a "data structure" construct using<br /> a "." as a separator":<br /> lane[<a href="https://xian.smugmug.com/OSM/OSM-2015/2015-11-21-Bazel-Kruibeke/i-KDSHQNR/0/X3/DSC_8025-X3.jpg">1</a>].destination=Paris<br /> lane[2].destination[<a href="https://xian.smugmug.com/OSM/OSM-2015/2015-11-21-Bazel-Kruibeke/i-KDSHQNR/0/X3/DSC_8025-X3.jpg">1</a>]=Rome<br /> lane[2].destination[2]=Milan<br /> lane[3].destination[<a href="https://xian.smugmug.com/OSM/OSM-2015/2015-11-21-Bazel-Kruibeke/i-KDSHQNR/0/X3/DSC_8025-X3.jpg">1</a>]=Berlin<br /> lane[3].destination[2]=Munich<br /><br /> Alternatively, using a "suffix syntax", something like you suggest<br /> lane_1:destination=Paris<br /> lane_2:destination_1=Rome<br /> lane_2:destination_2=Milan<br /> etc.<br /><br /> Thirdly, using the "seamark" construction:<br /> lane:1:destination:1=Paris<br /> lane:2:destination:1=Rome<br /> lane:2:destination:2=Milan<br /> etc.<br /><br /> The "lane" is a definite candidate here for a "data structure" definition -<br /> each lane has many attributes: width, access/vehicle types, destination,<br /> turn direction,.....<br /><br /><br /><br /> Also the semi-colon is used a lot as separator in the opening_hours tag.<br /><br /> Even if we are not considering solutions, please add the functional<br /> specification for destination:lanes and all xxx:lanes (e.g.<br /> turn:lanes) to the list of things to consider.<br /><br /><br /> Do any of these present any unique issues? I suspect they can be addressed<br /> in the same way as with the destination-per-lane above.<br /><br /><br /><br /> I thought of some extra examples of things needing multiple values<br /><br /> sport=multi needs a solution<br /> traffic_calming in case of e.g. a table + choker combination<br /><br /><br /> Good examples, I will add them to the list<br /><br /><br /> street names for streets that form the border between 2 villages and<br /> have different names on both sides<br /> surface, e.g. concrete lanes with cobblestones in the middle, or a<br /> track that is half dirt half asphalt for cyclists.<br /><br /> I am not sure I agree with you here. The two names/surfaces do not refer to<br /> the same bit of road, and I think you should solve this by splitting the<br /> road into lanes, and having a single name and a single surface for each<br /> lane.<br /><br /><br /><br /><br /> _______________________________________________<br /> Tagging mailing list<br /><a href="mailto:Tagging@openstreetmap.org">Tagging@openstreetmap.org</a><br /><a href="https://lists.openstreetmap.org/listinfo/tagging">https://lists.openstreetmap.org/listinfo/tagging</a></blockquote>
</div>
</blockquote>
</body></html>