wendorff at uni-paderborn.de
Thu Aug 26 23:11:18 BST 2010
On 26.08.2010 23:52, Tobias Knerr wrote:
> On 26.08.2010 22:25, Peter Wendorff wrote:
>> My approach would be - and I would like to get your opinions on that:
>> - a sidewalk is tagged like every other footway
> I understand why you like this approach: The mappers will essentially
> draw the routing graph for you. ;-)
Well - yes, that's a good aspect, too - but not the only one.
> Generally, individual ways for sidewalks and cycleways make it easier to
> use the data for navigation, while adding tags (or relations) to the
> roads themselves appears somewhat easier for renderers.
> I happen to write a (3D) renderer at the moment, so I assume this will
> create some challenges for me. Simply drawing the footways and roads
> independently will certainly look bad - there will either be gaps
> between the sidewalk and the road or they will overlap. Unless, of
> course, the distance between the sidewalk way and the road way is
> exactly half the sum of their respective width tags' values ... which is
> unlikely, to say the least. *g*
That's true, yes. I would like to add one (but not sure what is the
best) of the multilane-proposals - perhaps even the area proposal to it,
but that should be compatible AFAIK. If applied, you could decide wether
to render sidewalks separately or with a different implementation from
the informations you get via the relations.
Only using the relations I fear your problem is not solved, too:
Consider a street where at the side is a sidewalk, and in between
constantly changing a strip of grass, parking line, both of them, nothing.
How would you render that only using tags or relations?
I think there are issues where simply using the relations will fail, too.
> So I will need to associate sidewalks with road sections. And therefore
>> - no geometric analysis necessary (finding parallel streets to unnamed
> ... I *will* need to do geometric analysis.
I agree - but did you think you can write a RENDERER without doing
> It's still possible, though (or so I hope, at least...), so your
> proposed solution would be acceptable for me. It's actually nice that it
> works well with today's editors, while other approaches require editor
> or even API improvements. This will probably lead to fast adoption by
>> 2) dedicated sidewalks make it a lot more simple to tag crossing details
>> like islands etc.
> Could you describe crossing layouts in more detail? I assume you would
> model them like this
> A B C
> | | |
> | | |
> | | |
> | | |
> where A and C are sidewalks, B is a road, and *o are junction nodes.
> If we use the existing tagging for crossings, then node o should be
> tagged highway=crossing + crossing=island/...
except of that I prefer to explicitly tag crossings, yes.
> So how would you tag the horizontal way? May I suggest that it is tagged
> differently from A and C to make it easier to distinguish in software?
Currently I don't tag it differently. It's a footway/path as the
sidewalks are, too.
I use to add sloped_curb and tactile_paving to every crossing, but you
are right - that should be optional perhaps.
Applying sloped_curb and tactile_paving allows me to identify the way
you propose to tag different as "the way between sloped-curb and
sloped-curb with highway=crossing on the node(s) in between".
But you are totally right.
Any ideas how to call the crossing-way?
Highway=crossing is ambiguous with the crossing node itself and
therefore I would like to find another tag here.
More information about the Tagging