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

Martin Vonwald imagic.osm at gmail.com
Thu May 24 10:43:31 BST 2012

2012/5/23 Martin Koppenhoefer <dieterdreist at gmail.com>:
> 2012/5/23 Martin Vonwald <imagic.osm at gmail.com>:
>>> 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.
> I fail to understand this sentence. Did you mean it the other way
> round? (increase in detail does not justify the increasing
> complexity?)

double complexityIncrease=newComplexity/oldComplexity-1.0;
double detailIncrease=newDetail/oldDetail-1.0;
boolean notGoodIdea=(complexityIncrease > detailIncrease);

Better? ;-)

>>> 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.
> what exactly are these xways? How would they end up in the database?
> Is it another osm-feature (besides ways, nodes, rels), or is it a way
> with special tags? How do they relate to current ways?

Yes, I do think about them as new feature. And yes, before you start:
I know it is completely unrealistic. I just wanted to state how I
think that it could(!) work.
Maybe it is possible to simulate their properties with existing
features, but I'm afraid it would be too fragile.

>>>> 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.
> this won't be a problem and you know this: simply move the whole of
> Japan, as it is an island this is trivial (if the movement is the same
> everywhere).

Your question was "why would you want to move a street...?". This was
one answer out of approx. 1.2 quadrillions possible. Once again: Facts

>>>> 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!
>  I don't see what is the particular problem (whether you have to
> integrate something later or map it from scratch), see below:
>>> 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".
> Well, won't those parallels in your "xway" somehow have to be
> connected or not as well? How do they magically intersect?

Magically they don't. At least I don't know how they could. The
connection of those "parts" would be the same effort as with the
area-relation (more or less).

>>>> 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 apologize for the current state of this proposal, it really
> isn't documented very well and I wouldn't even be astonished to find
> some contradictions in it. Definitely needs some illustrations and
> examples as well.

I could have read more carefully. But illustrations are never a bad idea.

>> 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.
> you will at some point have to tell the editor/database/dataconsumer
> which lanes and barriers and stuff belong together. I don't yet
> understand how you would achieve this, as you seem to refuse to use a
> relation for this. It is not  possible to do it just spatially (at
> least not in some cases).

The xway consist of "parts" (think of them as lanes or similar),
therefore the parts belong to the xway. It's just the same as a lot of
ways and the area-relation, but without an explicit relation and with
improved handling of the "parts".

BTW: You seem to have missed my main objection:

>> 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?

Once more: I think, that it would be possible to simulate this
"xway-feature" with the current available features, but you would need
strong editor support that hides a lot of the complexity. As long as
(just my favorite example) you have to move <x> ways to move a street
by a few meters, this will no succeed. At least in my opinion. But I
would be happy if you prove me wrong :-)


More information about the Tagging mailing list