[Tagging] [OSM-talk] Cycle lanes & cycle tracks - my findings and a proposal

Martin Vonwald imagic.osm at gmail.com
Wed May 23 12:00:58 BST 2012


2012/5/23 Martin Koppenhoefer <dieterdreist at gmail.com>:
> 2012/5/23 Martin Vonwald <imagic.osm at gmail.com>:
>> Let's have a look at a street around here: it has two general lanes,
>> one cycle lane and two side walks. I should map this with:
>> * one way is "main" way
>> * two ways for the lanes
>> * one way for the cycle lane
>> * two ways for the side walk
>> * one relation
>> So this gives me seven ways and one relation just for one street.
> First of all: it is not "just for one street", it is 5 "lanes".

It still is "just one street" - with five "lanes" ;-)

> Suggestion (for the same street), high level of detail (i.e. I would
> use this only for special cases, not for the average road without
> irregularities):
> ....
> So I end up with 4 ways (highway, 2 sidewalks, cyclelane), one
> relation (area) and some nodes (lowered kerbs). Of course this is more
> complex, but you also get a whole lot more of detail,

I see it the other way around: the increase in complexity does not
justify the increase in detail.

> especially if
> there is more stuff to take into account (geometry not perfectly
> parallel, barriers which are (partially) between the sidewalk and the
> road, ability to map barriers on the sidewalk only, etc.

If one would allow to change the width of the xway-parts, you could
map geometry that is not perfectly parallel.

> You will not map every street with this detail I guess, but you could
> do it for situations that are complex in the real world.

See - that's the main problem of this approach. It is much too complex
for the common situations, so we should only use it in complex
situations. And this will lead to a continuous switch between this
approach and "standard" mapping. Imagine that: every now and then a
simple road, specified by one way with some tags, magically changes to
four, five, (how many was it) ways and a relation and just a few
meters further collapses back to a single way. Do you think, that this
is understandable? Maintainable?

A solution that doesn't cover both - simple and complex - will fail
IMO. Another possibility would be a solution, that seamless extends
the simple case to the complex. The area-relation is missing this
"seamlessness".

> Doing it with
> tags instead of dedicated geometry would in most (complex) cases
> result in much less readable map data than explicit geometry (IMHO).

I agree on this. I just question this particular geometry approach.

>> If I
>> want to move the "street" I have to move seven ways.
> why would you want to move a street that you have surveyed up to this
> level of detail? I think this is hypothetical (and btw: it is 6 in
> your example).

Japan moved a few meters not so long ago.

>> If I want to add
>> a junction I have to add a node to every way.
> Yes, (see above, really not likely that you map a street with 5 ways
> in every detail and then you discover that you "forgot" a whole
> junction).

I didn't forget the junction - it was just built. Facts changes!

> Of course the junction will be more complex to map compared
> to a simple node, but this is also one of the reasons you are doing
> it: to get more details how the junction looks like.
>> If the connecting road
>> is also represented by seven ways I would have to connect... no, I
>> don't count now... a lot of ways.
> actually you would have to connect only those ways that are
> intersecting in reality, not all of them (see above).

I know, but this is still "a lot" compared to "one".

>> Now I want to add a route relation for a bicycle route. For this I
>> have to split the "street".
> not at all, you will have the cyclelane where you put the relation to
> and you will _not_ have to split the street.

Then I misunderstood the proposal. That would be good.

>> I have to split all seven ways, even if
>> the bicycle route only refers to the bicycle lane. Excuse me, I'll
>> stop right here.
> I don't understand you here, can you explain this?

Same as above. I erroneously assumed a statement which is valid for
steps should also apply to other areas.

>> BTW:
>>> you will not get the support of who is interested
>>> in the details of shape.
>> If one would allow to change the width of each part at each node of
>> the xway, you could quite nicely cover the shape of many features.
> how would you know how to interpolate between two widths? It could be
> a sharp corner or a smooth change. (almost) every corner at every
> intersection is rounded. Will we split every x-way in y parts at any
> of these points? Won't it be very difficult to get the center and
> widths right in the case that the change of width is all on one side
> of the street surface while the other keeps going straight? (This is
> almost always the case btw.).

The way I think about it, it would be quite simple: just draw the
ways/lanes/barriers/whatever as they are, but they magically glue
together and the width of each part is automatically determined. Don't
ask me about details! I figured this out just a few hours ago.

> Cheers,
> Martin

Same,
Also

;-)



More information about the Tagging mailing list