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

[Martin Koppenhoefer]

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


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


>>> 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).


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


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


> 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).

cheers,
Martin