> On May 13, 2018, at 11:58 AM, Paul Johnson <[email protected]> wrote: > > On Sun, May 13, 2018 at 1:36 PM, Johnparis <[email protected] > <mailto:[email protected]>> wrote: > Back to this again, Paul. It is getting tiresome. If you don't like how the > tag is defined, create a new one. Don't vandalize the old one. > > Improvement=vandalism. Got it. > > The *:lanes suffix is unrelated to the lanes=* tag. Get over it. > > That's literally not how any editor works. Plus, bike LANE literally has > lane in the name. When is a lane not a lane? Apparently, to OSM, when the > wiki says so.
Don’t think of them as words but as key identification strings. I think you are too wedded to the concept that the key identification string, if it matches an English word, must exactly match some dictionary definition of that word. In a sense it does but with our wiki being the dictionary. OSM is filled with a host of pragmatic partial solutions that are found later to be woefully inadequate. This is one. The project has gotten far by using “good enough for now” and/or “better than what we have now” as a guide rather than looking for perfection at each step. Back when a five character key identifier string was selected to describe the number of lanes a common motor vehicle could use the definition of that key definition was, in retrospect, deficient. But it is in wide spread use with nearly all mappers and data consumers using the existing definition of the key. With more experience, we find that there are more things, and more complicated things, we’d like to describe when mapping the cross section of a road. The pragmatic way forward, the OSM way forward, is to create a new key string or tagging system for that better definition. I suggest a you work on a proposal for a new tagging system including new keys that better fits our current mapping needs. You might even come up with a key string that has the letters ‘a', ‘e', ‘l', ’n' and ’s' in it. There is the tradition in OSM that keys strings and value strings be based on relatively current UK usage of words but there seems to be little resistance to key strings created from compounds of words so you might consider that option. If the scheme is well defined, makes sense to mappers (not just people on the tagging lists), is easy enough to work with, and adds enough value (“its better than what we have now”) then adoption will follow and the existing inadequate key can be deprecated. I’d probably start with looking at the *:lanes suffix tagging system as I think it covers a lot of cases better. And I think it likely it can be extended to include cycle lanes including those separated from motor vehicle traffic by a parking lane or those which might allow bi-directional bicycle traffic on a way that only allows one direction of motor vehicle traffic. And it might be extended to cover the case common in my area where the through cycle lane is between one or more right turn lanes and the through lanes for motorized vehicles. But that is to be expected: The *:lanes key identifier suffix was developed more recently and reflects many lessons learned. Maybe it is flexible enough to be used in conjunction with your new key string(s) for describing the total number of components a road way contains. If you decide that the current key that describes the number of motor vehicle lanes can be extended to cover other types of lanes, then you should be prepared to show a path to adoption that allows the millions of things tagged using the current wiki definition to be handled sanely by data consumers.
_______________________________________________ Tagging mailing list [email protected] https://lists.openstreetmap.org/listinfo/tagging
