[Tagging] Formally informal sidewalks

Nick Bolten nbolten at gmail.com
Sun Jul 16 18:33:11 UTC 2017


> You can tag the curbs at each side of a crossing using left/right tags,
and you can find out the length by looking at the road's width (or estimate
it from the number of lanes). It's not perfect, but at least there are good
enough ways to deal with this

But you can't handle the directional features without forcing an
azimuth-style annotation: if you want to describe the curbs or APS at each
end, you have to have a notion of start/end, so you also need a direction.
Both the azimuth and the width are ways to compensate for representing a
linear feature as a node, and for good reason you'd be hard-pressed to find
any examples of that having been annotated. highway=crossing is really for
car routing (where it causes a delay penalty) and maybe sometimes
rendering, and does not factor into any current pedestrian routing
solutions outside of some toy examples. There really aren't good enough
ways to deal with this, and no one really tries to route the totality of
pedestrians: the data model doesn't support it and the data largely doesn't
exist yet.

> The same cannot be said for the problems caused by sidewalks mapped as
separate ways. Drawing a sidewalk way next to the road produces just that:
Two ways with no machine-readable semantic relationship to each other.

This is an important point that should be addressed via tagging
improvements: by default, separate sidewalks have no metadata-based
relationship to their street, which can be useful. This is basically the
only thing that's inherently better by labeling streets with sidewalk
information, and also basically the only thing anyone can currently use as
a result. This can be addressed in a few ways that probably fall outside
the scope of this thread: (1) just keep the sidewalk=right/left/both/no
tags and use them for this sole purpose, (2) use an associated street tag
(how many buildings are coded to streets), or (3) an associated street
relation (how many other buildings are coded to streets).

Also, with that said, associating sidewalk lines with street lines is a
core part of workflows I use, so it's not totally impossible.

> From personal experience: I'm rendering sidewalks in a 3D renderer. It
works pretty well with lane-like sidewalk tagging, but separate ways
prevent pretty much everything I would like to do with them: I can't draw
the kerbs, because I cannot easily determine whether I'm on the left or the
right of the street. I can't make sure that the sidewalk is at comparable
elevation to the road on hilly terrain. And the sidewalk and road will
always have random gaps or overlap each other, because they are never
really accurately drawn.

As part of our workflow, we also figure out left/right associations (some
straightforward vector stuff), but it would be much better to use one of
the 3 solutions above. I'm not sure if I understand the elevation issue -
is there any chance you're not interpolating? And the issue of overlapping
streets/sidewalks indicate data errors, not tagging errors: either the
sidewalks are drawn in the wrong place or (more commonly) the street widths
are inaccurate. I've fixed so many incorrect-unit-width streets.....
> Other applications have similar problems:

> Want to make sidewalks into a part of the road's line style? You can't –
instead you end up drawing them as separate lines, which looks ok at
detailed zooms, but stops
working as you zoom out. Want to show routing instructions such as "follow
the right sidewalk of Foobar Road"? Doesn't work, because we don't know
which road this sidewalk is the sidewalk of.


All good points that could hopefully be addressed by those 3 options.

> Want your pedestrian router to cross smaller roads anywhere, which is an
integral part of how pedestrians typically navigate street networks? Again,
you
can't – you need to hope the mapper has drawn "virtual crossings" at
semi-regular intervals (or even at all).

This was addressed earlier in the thread, and the crossings aren't virtual,
they're just unmarked (and are part of current tagging schemas).

> Yes, separate sidewalk geometries allow for nice details like telephone
poles on a sidewalk. But they lose information that's a lot more
fundamental: The semantic connection with the road.

That's not a detail, it's a fundamental barrier to anyone in a wheelchair.

> That's only a problem if you map this lowering of the kerb as a property
of the highway way. I believe it may be feasible to map this as the
property of the junction and crossing nodes instead.

I don't see how this would work. It also seems like an argument against
sidewalk:*:kerb in general?

> Plus, drawing separate ways only seems easier because you are omitting
essential information, as described above. If you actually were to
express the relationship between the sidewalk and the road with a
relation for each section of sidewalk, it would very quickly stop being
simple.

But it would nicely separate concerns - and a relation isn't the only
option.

On Sun, Jul 16, 2017, 5:25 AM Svavar Kjarrval <svavar at kjarrval.is> wrote:

>
>
> On lau 15.júl 2017 11:13, marc marc wrote:
> >
> > Your demonstration is only that a wrong map create sometimes a wrong
> > routing :-)
> > What will your reaction be when Mapzen tell you to cross a road where it
> > is impossible ? However this is exactly the current map for [2]
> > You would not agree that the routing would make you drive from one road
> > to another because they are close and it save 1km. Therefore I do not
> > understand why you would want the routing to do this when you are
> walking.
> > If the map is wrong, first fix the map, not the routing engine.
> My example was rather the inconsistency in the assumptions the routers
> are making based on the current data. I do think that the routers should
> be programmed to evaluate when it's safe to suggest to the user to cross
> the street without a specifically mapped crossing. Due to the potential
> legal and logistics issues, I do assume the routers would need more map
> data than is currently provided. The data isn't innocent. Some routers
> assume living streets have that property but one (currently) can't tell
> the router it may assume the same regarding a specific segment of
> another highway type. Is a part of the solution to implement such a tag?
> I don't know.
> >
> >> but GraphHopper directs the user to take a complicated path
> > Complicated because the map is wrong in this case.
> > GraphHopper will not make you cross a road where a mapper tell
> > (unintentionally but erroneously) it is impossible.
> > Is it bad? IMHO no, it is the best reply.
> > I think that is the problem. You would like the routing to guess errors
> > and guess where we can jump from one path to the other in the absence of
> > connection.
> > But the simplest/efficient/only solution is to fix the map.
> To continue from my point before. GraphHopper is ready to determine the
> user has reached the destination when on the street itself, therefore
> assuming no barriers from that location to the destination, but is not
> ready to (properly) take into account the same situation from the
> starting point to the street itself. If the routing engine had done that
> from the beginning, it would've suggested the user to cross the street
> instead of the much longer route. In another case I tested, Mapzen
> suggested that I would start on a footway on the other side of the house
> across the street, therefore starting my journey on foot by jumping over
> a house. There is a street between the houses, which could lead to the
> destination albeit by a little longer route, so it wasn't absolutely
> forced in its decision. When it comes to start and end positions
> compared to the calculated path between them, there is a big routing
> bias favouring the former.
>
> I think it's unavoidable for routers to guess mapping errors, although
> we should always aim to limit the type of guesses they need to make,
> especially when it comes to the aforementioned jumps. If the routing
> software is mainly written to work efficiently in areas with perfect
> mapping data, they start to become much worse where the data is
> incomplete/incorrect. The aim is, of course, to have perfect mapping
> data, but it's not realistic to expect that to apply everywhere at any
> time.
>
> There has been some effort to detect where mapping data has the
> potential to cause problems in routing calculations, and I'm all for
> that. Then there are situations where the cause is based on our own
> limits, like the availability of officially accepted tags to deal with
> certain situations. There are official accepted tags to indicate tha
> location of a barrier but none (that I know of) to indicate the absence
> of them. The router doesn't *really know* there are no barriers in the
> space between; for all it knows, the footway and the street could be
> separated by a local black hole. In the GraphHopper case, it's more
> afraid of local black holes when it leaves no. 73 than when it suggests
> stopping on the street in front of no. 42. So, how can we help the
> routers deal with this? Deleting the footways is not a realistic action
> in this case, IMHO.
> >> Just to be clear: Is it valid, in your opinion, to connect the end of a
> >> footway along a street, directly to the street itself?
> >> I'm not objecting to such a method, I've just been hesitant to apply it
> >> without approval by documentation or the community.
> > Guidelines for roads is very easy: split a road in 2 when you can NOT
> > switch from one to the other (for example a road with a island). and
> > create connection where you can switch. But do NOT cut a road into 2 if
> > you switch everywhere from one to the other (for example a street with 2
> > lanes must be keep as one street, not 2).
> > Just do the same with the sidewalk as if the sidewalk was a lane
> > reserved for pedestrians. I never see a problem with that.
> The data is already there. I'd see myself as a vandal if I were to start
> deleting footways en masse, for that purpose. There might also be valid
> future cases where it becomes necessary to keep them separete, which
> would then urge the community to draw/import them again, wasting its
> time. So I'm rather looking for solutions which would not entail
> deletion of data in that manner.
>
> With regards,
> Svavar Kjarrval
>
>
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20170716/4bb47216/attachment.html>


More information about the Tagging mailing list