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
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,
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.
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
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
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
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
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
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,
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
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
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
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
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
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
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
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
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
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
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
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
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
22 matches
Mail list logo
