[Tagging] Formally informal sidewalks

Svavar Kjarrval svavar at kjarrval.is
Sun Jul 16 12:24:09 UTC 2017

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

More information about the Tagging mailing list