Re: [Tagging] Feature Proposal - RFC - Turn Lanes
bkmap: When we already have numbers for the track positions, why we do not use them thus? So the data consumer knows the location without the lanes:location tag. lanes=4 lanes:turnleft=3;4 lanes:merge=1 lanes:through=2;3 I considered this notation, but it has many drawbacks, the major one being the difference in meaning of values of similar-named tags: lanes, lanes:psv and lanes:hgv contain number of lanes, and other lanes:* therefore also should. And yes, I also considered using this notation for lanes:*:location - but it is very error-prone, depending on users to calculate lane numbers, and left/right wouldn't fit in it. IZ ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Turn Lanes
Am 18.10.2011 13:17, schrieb Ilya Zverev: bkmap: When we already have numbers for the track positions, why we do not use them thus? So the data consumer knows the location without the lanes:location tag. lanes=4 lanes:turnleft=3;4 lanes:merge=1 lanes:through=2;3 I considered this notation, but it has many drawbacks, the major one being the difference in meaning of values of similar-named tags: lanes, lanes:psv and lanes:hgv contain number of lanes, and other lanes:* therefore also should. It is not too late to change this. We must change about 11+2+7=20 tags worldwide if we consider to modify the notation of the lanes:*:tag. 362 lanes:psv=1 11 lanes:psv=2 4 lanes:psv=backward 2 lanes:psv=3 75 lanes:bus=1 7 lanes:bus=2 38 lanes:hgv=share_psv_lane 5 lanes:hgv=1 And yes, I also considered using this notation for lanes:*:location - but it is very error-prone, depending on users to calculate lane numbers, and left/right wouldn't fit in it. Using verbal values like left and right (except turn...) is IMO more fault-prone than defined lane numbers. We need anyway suitable editor tools for lanes. I know that we need a pattern for lanes. I like this beginning first also well. But I have, taken as a whole, no good feeling with this proposal. It leaves open too many issues which could appear later: How to tag the lane width, different surfaces and restrictions like forbidden lane change? How the data consumer knows, how the lanes of the road segments are connected together? And so on... cheers, Burkhard ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Turn Lanes
bkmap: It is not too late to change this. We must change about 11+2+7=20 tags worldwide if we consider to modify the notation of the lanes:*:tag. I'm strictly against global retagging. And it's impossible to unambigously resolve number of lanes to lane numbers in most of those cases. Using verbal values like left and right (except turn...) is IMO more fault-prone than defined lane numbers. We need anyway suitable editor tools for lanes. Actually, this proposal was designed with the aim of not requiring special editors or plugins to mark turn lanes... It leaves open too many issues which could appear later: How to tag the lane width, different surfaces and restrictions like forbidden lane change? How the data consumer knows, how the lanes of the road segments are connected together? And so on... ...and obviously, this implies some restrictions on tagging scheme: it's unpractical to add information for every lane into tags: there would be too many tags for each road segment. So in the proposal there are no properties for separate lanes: this can be impoved later, possibly with relations. For example, Tordanik is drafting out http://wiki.openstreetmap.org/wiki/Proposed_features/Lanes_as_Relations with exactly those points in mind. IZ ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Turn Lanes
Am 11.10.2011 13:29, schrieb Martin Koppenhoefer: 2011/10/11 Ilya Zverevzve...@textual.ru: Martin Koppenhoefer wrote: There was a proposal for tagging type of divider, but it has been abandoned for several years: http://wiki.openstreetmap.org/wiki/Proposed_features/Divider There is also a proposal for a relation to unify dual carriageways (e.g. often pedestrians can cross but cars can't, dependent on the kind of divider) which also allows for tagging of the divider (either implicitly or explicitly): http://wiki.openstreetmap.org/wiki/Relations/Proposed/Area How would you tag a lane according to this proposal that allows at the same time e.g. to go straight and left? Lanes separately are not tagged, only lane groups. In this case there are one lane group for turning left and one — for going straight. So it would be lanes=N, lanes:turnleft=1, lanes:through=N. If the left lane was used _only_ for turning left, lanes:through tag could be omitted. how would the data consumer know, where the lanes are? E.g. a lane to turn left might also be right of the through-lanes, and this is crucial for routers to give good indications. When we already have numbers for the track positions, why we do not use them thus? So the data consumer knows the location without the lanes:location tag. lanes=4 lanes:turnleft=3;4 lanes:merge=1 lanes:through=2;3 cheers, Burkhard ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Turn Lanes
Hi, I wonder if in this case: http://wiki.openstreetmap.org/w/images/6/69/Simpleuklanes.jpg it would not be better to draw 2 ways (and add a relation to say that you could - against the traffic rules or maybe as a pedestrian - cross the street from one way to another? Otherwise there should be a way to indicate that you cannot use the opposite lanes (say for takeovers) because of the area in the middle of them (diagonal white markings). How would you tag a lane according to this proposal that allows at the same time e.g. to go straight and left? Cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Turn Lanes
Martin Koppenhoefer wrote: I wonder if in this case: http://wiki.openstreetmap.org/w/images/6/69/Simpleuklanes.jpg it would not be better to draw 2 ways (and add a relation to say that you could - against the traffic rules or maybe as a pedestrian - cross the street from one way to another? Yes, my opinion is that all highways that are more that 4 lanes wide should be drawn as two ways. Alas, it seems that most mappers recommend drawing one way if there is no physical divider, even if there are 4 lanes in each direction. Otherwise there should be a way to indicate that you cannot use the opposite lanes (say for takeovers) because of the area in the middle of them (diagonal white markings). There was a proposal for tagging type of divider, but it has been abandoned for several years: http://wiki.openstreetmap.org/wiki/Proposed_features/Divider How would you tag a lane according to this proposal that allows at the same time e.g. to go straight and left? Lanes separately are not tagged, only lane groups. In this case there are one lane group for turning left and one — for going straight. So it would be lanes=N, lanes:turnleft=1, lanes:through=N. If the left lane was used _only_ for turning left, lanes:through tag could be omitted. IZ ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Turn Lanes
2011/10/11 Ilya Zverev zve...@textual.ru: Martin Koppenhoefer wrote: There was a proposal for tagging type of divider, but it has been abandoned for several years: http://wiki.openstreetmap.org/wiki/Proposed_features/Divider There is also a proposal for a relation to unify dual carriageways (e.g. often pedestrians can cross but cars can't, dependent on the kind of divider) which also allows for tagging of the divider (either implicitly or explicitly): http://wiki.openstreetmap.org/wiki/Relations/Proposed/Area How would you tag a lane according to this proposal that allows at the same time e.g. to go straight and left? Lanes separately are not tagged, only lane groups. In this case there are one lane group for turning left and one — for going straight. So it would be lanes=N, lanes:turnleft=1, lanes:through=N. If the left lane was used _only_ for turning left, lanes:through tag could be omitted. how would the data consumer know, where the lanes are? E.g. a lane to turn left might also be right of the through-lanes, and this is crucial for routers to give good indications. cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Turn Lanes
Martin Koppenhoefer: how would the data consumer know, where the lanes are? E.g. a lane to turn left might also be right of the through-lanes, and this is crucial for routers to give good indications. Specially for data consumers and advanced mappers there is a section in the proposal explaining step by step how to get the lane arrangement from proposed tags: http://wiki.openstreetmap.org/wiki/Proposed_features/Turn_Lanes#Building_lane_directions Default positions for turn lanes (when no *:location is given; for example, that lanes:turnleft are the leftmost lanes etc.) are explicitly stated in the proposal. IZ ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] Feature Proposal - RFC - Turn Lanes
Hi! lanes:directions tag was bad, and I acknowledge that. Yesterday we finally chose a good alternative for it: lanes:X:location. It denotes the location of lane group for X. Self-evident example: lanes:merge:location=left. This tag removes some of mine doubts about the proposal, and I hope, some of yours. http://wiki.openstreetmap.org/wiki/Proposed_features/Turn_Lanes IZ ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] Feature Proposal - RFC - Turn Lanes
Hi! I've changed proposal a bit: now lanes:directions (still no good alternative to this tag, despite long discussion in russian forum) values are separated by commas, not semicolons: l,s,sr. This was done because a semicolon is used to enumerate simultaneous, not consequent, values (so l;s;sr means that there are three directions at once for a single lane, not one for each). Other changes are (and will be) recorded in the change log: http://wiki.openstreetmap.org/wiki/Proposed_features/Turn_Lanes#Change_Log Also, for those who are reluctant to split ways, UtilsPlugin2 (for JOSM) now has Select Highway action that selects either a whole highway with name/ref like on the selected way, or a shortest route between two selected ways. IZ ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[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
