[Tagging] Feature Proposal - RFC - Turn Lanes
Hi! Following discussions in this list and in couple of forum threads (and since there are some eager nav software programmers that wish to use the first proposal they see), I studied all of the proposals for tagging turn lanes and made a compound tagging scheme, which is not hard to use, but addresses mapping simplicity, presentation and routing. Please check it, and I'd be glad to answer your questions (but please use wiki talk page if possible: keeping mailing list threads is hard when you receive messages in digests). http://wiki.openstreetmap.org/wiki/Proposed_features/Turn_Lanes IZ ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Turn Lanes
n Thu, Oct 6, 2011 at 8:17 AM, Ilya Zverev zve...@textual.ru wrote:
I was thinking about something similar excepted one important thing :
I think that many contributors don't like to break the way in many
small segments just for turning lanes. I think that adding a simple
node when the turning lane appears would be enought. To know until
where the turning_lane is valid, we can use a similar naming as the
highway *_link (remember the secondary_link, tertiary_link, etc) e.g.
trunk_turnlanes:left:forward=1 meaning that from this point we have a
left turning lane till the next intersection with a trunk highway
('forward' or 'backward' being relative to the osm way direction as
usual). For sure, the naming could be improved or changed like
turnlanes:next highway category:left or right:forward or
backward=1..x . The tag lanes should be reserved for the straight
forward lanes.
As a result, we just add a node for a minor information and do not
damage the existing highways. Probably a similar schema will be
developed to locate the traffic lights (with nodes on the highway) if
it is not already the case.
Pieren
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Turn Lanes
e.g. trunk_turnlanes:left:forward=1 meaning that from this point we
have
a left turning lane till the next intersection with a trunk highway
('forward' or 'backward' being relative to the osm way direction as
usual).
So, are you suggesting to use :forward/backward on nodes? I don't think
that would go well. It is worse that using relations, since the node is
implicitly related with a) direction of a way; b) the fact that way is
not split at that point; c) the highway tag value of some other way far
ahead.
As a result, we just add a node for a minor information and do not
damage the existing highways.
The big problem is that mappers think splitting ways is damaging them.
Why?
Also, on such level of micromapping (turning lanes are usually several
meters in length) I guess it is acceptable to work with small ways and
split them whenever neccessary.
IZ
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Turn Lanes
The tag lanes should be reserved for the straight forward lanes. At a T-junction, the road ending there would then be lanes=0, given that wording. Nice. As a result, we just add a node for a minor information and do not damage the existing highways. There's bound to be, eventually, enormous amounts of data beside the roads, from buildings and their entrances, to curved ditches, fences, hedges and scrubs, just to name a few. I find it strange that roads should somehow be frozen at the lengths of n2 block spanning ways. What value does it add, to try to keep the roads from being split midblock? Bus routes and parking restrictions already make it necessary to split at most urban junctions, anyway, and longer rural roads have very few turning lanes per distance. -- Alv ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Turn Lanes
On Thu, Oct 6, 2011 at 10:52 AM, Ilya Zverev zve...@textual.ru wrote: So, are you suggesting to use :forward/backward on nodes? I don't think that would go well. It is worse that using relations, since the node is implicitly related with a) direction of a way; b) the fact that way is not split at that point; c) the highway tag value of some other way far ahead. We already have many tags related to the direction of the way. Your point a) is supported by OSM editors (reversing the direction should modify the tag); b) if someone split the way just at that point, it's because he wants to put the turnlanes on the way, not on the point. That's ok and is valid if the turnway is just between two intersections.; c) if the highway value is wrong, then the tag is wrong. We cannot avoid mistakes. A QA tool could check the distance between the node and the expected intersection and raise a warning if it exceeds a certain number. The big problem is that mappers think splitting ways is damaging them. Why? It's just painful to work with many small segments (to add or rename tags or use route relations). People editing on such areas know what I mean. Pieren ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Turn Lanes
On Thu, 6 Oct 2011, Pieren wrote: On Thu, Oct 6, 2011 at 10:52 AM, Ilya Zverev zve...@textual.ru wrote: The big problem is that mappers think splitting ways is damaging them. Why? It's just painful to work with many small segments (to add or rename tags or use route relations). People editing on such areas know what I mean. Agreed, this is a serious editor problem (and I kind of understand people saying this), however, it should not be solved using some data klugde but making the tasks you mention easy to do in editors even if the ways would contain only two nodes each. -- i. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Turn Lanes
2011/10/6 Kytömaa Lauri lauri.kyto...@aalto.fi: What value does it add, to try to keep the roads from being split midblock? For the same reasons why the first OSM api had segments and was replaced by ways. It makes editing and maintenance painful, you don't see where your street is starting and finishing. Relations using the street will contain only a segment of it. The data become unreadable for humans. The same complain was said about splitting ways for routes, something that does not correspond to any thing on the physical world. And they are also alternative solutions for that. Pieren ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Turn Lanes
On Thu, 6 Oct 2011, Kytömaa Lauri wrote: The tag lanes should be reserved for the straight forward lanes. At a T-junction, the road ending there would then be lanes=0, given that wording. Nice. ...And it gets even funnier if you have an intersection where all those straight forward lanes are extra ones. In such intersections, there is a nice contradiction between the given definition of extra lanes (that should not be tagged) and straight forward ones (that should) :-). -- i.___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Turn Lanes
Hi. Some remarks have been mentioned here already, why this proposal is not well designed. Another one is, that it's tackling the lanes-problem, but not solving it. You propose something for turning lanes - but again restrict it to cars. The talk page in the wiki contains a question about cycle lanes, that has been rejected to be solved by the proposal. To go a little step further, it's even worse for sidewalks/footpaths/pavements, which are unsolved wether to tag as separate lanes, tags at the street way or whatever. I don't think, these unfinished proposals are a good idea in this case, as long as they don't solve the multi-lane problem in general (or are at least designed to be extendable to solve the problem). Here I cannot see this extendability. regards Peter Am 06.10.2011 08:17, schrieb Ilya Zverev: Hi! Following discussions in this list and in couple of forum threads (and since there are some eager nav software programmers that wish to use the first proposal they see), I studied all of the proposals for tagging turn lanes and made a compound tagging scheme, which is not hard to use, but addresses mapping simplicity, presentation and routing. Please check it, and I'd be glad to answer your questions (but please use wiki talk page if possible: keeping mailing list threads is hard when you receive messages in digests). http://wiki.openstreetmap.org/wiki/Proposed_features/Turn_Lanes IZ ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Turn Lanes
Peter Wendorff wrote: Some remarks have been mentioned here already, why this proposal is not well designed. Another one is, that it's tackling the lanes-problem, but not solving it. You propose something for turning lanes - but again restrict it to cars. It was not my decision, but was the outcome of a recent discussion in this very list: http://lists.openstreetmap.org/pipermail/tagging/2011-September/thread.html#8532 Proposed taging scheme just refines lanes tag value, not touching other proposed and approved features. To go a little step further, it's even worse for sidewalks/footpaths/pavements, which are unsolved wether to tag as separate lanes, tags at the street way or whatever. I guess you should discuss that on the corresponding proposals pages, for example, http://wiki.openstreetmap.org/wiki/Proposed_features/Advanced_footway_and_cycleway My opinion is that all sidewalks, cycleways and whatever should be drawn as separate ways. I don't think, these unfinished proposals are a good idea in this case, as long as they don't solve the multi-lane problem in general (or are at I don't think it's possible to solve all multi-lane problems, both encountered and imaginary. And it's certainly not possible to make that solution simple enough for potlatch users, for example. I took a part of that problem that I could deal with, and formed a proposal. It is not finished, because it's in RFC stage. But it's close enough. IZ ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Turn Lanes
On Thu, Oct 6, 2011 at 11:10 AM, Ilpo Järvinen ilpo.jarvi...@helsinki.fi wrote: however, it should not be solved using some data klugde but making the tasks you mention easy to do in editors even if the ways would contain only two nodes each. Making the task easier in editor does not work if your schema is complex. You can see the current turning lane plugin on JOSM.. . I was also thinking about a solution like yours but again, we split ways for what I consider a minor information (turning lanes). And the results are quicly becoming unreadable, ex.: lanes:directions:backward=s;s;p My idea is to stay simple, only for car turning lanes because most of the contributors will not spend many time for such things (to not say that most of the contributors do not tag lanes at all). Complex intersections with psv or cycle lanes will need new drawings (polylines for each lane) because the geometry is too complex and offer too many cases for a translation into tags only. Pieren ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Turn Lanes
On Thu, 6 Oct 2011, Pieren wrote: On Thu, Oct 6, 2011 at 11:10 AM, Ilpo Järvinen ilpo.jarvi...@helsinki.fi wrote: however, it should not be solved using some data klugde but making the tasks you mention easy to do in editors even if the ways would contain only two nodes each. Making the task easier in editor does not work if your schema is complex. You can see the current turning lane plugin on JOSM.. . I was also thinking about a solution like yours but again, we split ways for what I consider a minor information (turning lanes). Quote from you: It's just painful to work with many small segments (to add or rename tags or use route relations) I don't understand how the turning lanes plugin has anything to do with the basics tasks you describe. It should be relatively easy to have some form of router in editor to handle route relation building, it would help even with longer ways enormously (I think there might be some routing plugin for josm but I haven't tried it and it's not enough to route as some splitting is occassionally needed). The first task could be as simple as right-clicking on the tag you want to extend the selection for (mostly one would be doing names). Kind of auto-find without need to write the actual find line (but needs to take connectivity into account I suppose). And the results are quicly becoming unreadable, ex.: lanes:directions:backward=s;s;p I also dislike this format. Such shorts are horrible. And if autogenerated by tools anyway why not autogenerate the full versions!?! My idea is to stay simple, only for car turning lanes because most of the contributors will not spend many time for such things (to not say that most of the contributors do not tag lanes at all). I don't have any idea what you're now talking about. What are the simple (and useful) tasks you can do, if the most roads are there already, which do not involve stuff you'd define minor information (which I find highly subjective btw, I find the physical number of lanes pretty relevant)? -- i.___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
