Routing ignores access=no attribute about brouter-web HOT 10 CLOSED

I'm not the author of the profiles - @abrensch is - but my understanding is this:

access=no of way 100538429 is not ignored in the trekking profile (defaultaccess), but overruled because the way is also member of the bicycle route "Pont de Claix - Vif" (2808169) (bikeaccess).

I guess the logic is like "if it's part of a cycle route then you must be able to access". Perhaps there is an official detour signposted for the route, which could be changed accordingly?

from brouter-web.

right guess, but somewhat more complicated:

I had an issue with cycle-relations over motorroads, which I considered dangerous. So I added a "filter-profile" to decide on access-conflicts:
https://github.com/abrensch/brouter/blob/master/misc/profiles2/softaccess.brf

The preprocessor writes a log of access-conflicts, and for your example it writes:

** relation access conflict for wid = 100538429 tags:highway=track tracktype=grade1 surface=asphalt access=no (ok=true)

You can see the full report (whole planet) here:
http://brouter.de/brouter_bin/relation_access_conflicts.txt

This pre-processor filtering is sort of a hack, the logic should be part of the normal profile-logic. However, by fixing the data instead of the profiles I was able to deploy that more quickly

from brouter-web.

Could not the pre-processor filtering ignore access=no routes in anycase? In which situation a non-accessible route should be still considered as ok? Is that often because bicycles generally can goes in one-way opposite direction?
@nrenner: I do not think that the bicycle route should be modified (because it is probably an official route and the non-access is temporary), so I guess more of an issue with the pre-processor filtering?

from brouter-web.

Hi,

I don't get why access=no tags need to be ignored if we are on a cycleroute. I mean, I would expect bikeaccess to be false if access is not possible, even for a cycleroute. This one in particular has been closed for almost 3 years apparently.

@abrensch I get the part about the pre-processor, but I don't get why the profiles should not take into account the access tag for cycleroutes. I'm not sure also to see how not taking into account the access tags can create issues with cycle-relations over motorroads. Could you detail this a bit more?

Thanks!

EDIT: I'm not sure to understand correctly but apparently the mapcreator (and the pre-processing task) is just here to keep all segments of ways, even if they have access=no (in the case that they are part of a cycleroute). This seems to be fine, the road network in BRouter is probably just overcomplete. On the profile side, on the contrary, I tend to think such segments should have a high cost (or be enabled by a configuration variable).

from brouter-web.

@abrensch I get the part about the pre-processor, but I don't get why the profiles should not take into account the access tag for cycleroutes. I'm not sure also to see how not taking into account the access tags can create issues with cycle-relations over motorroads. Could you detail this a bit more?

Regardless whether the logic is implemented in the pre-processor (->to be avoided...) or in the runtime-profile (->preferred):

It needs a good balance between the optimistic approach (if there are contradicting infomations, take the one allowing more access) and the pessimistic approach (take the one allowing less access).

My experience is that bike-routing works best with the optimistic approach, but for car routing I prefer the pessimistic approach.

There is simply too much bad access tagging that would cut the bicycle-route network into fragment. On the other hand, if there's a bicycle-route on a motorroad, it's better to assume that it's a motorroad and not a bicycle-route...

from brouter-web.

Just to be clear, could you describe more precisely in depth what you mean by:

There is simply too much bad access tagging that would cut the bicycle-route network into fragment.

Do you mean access=no is used too wildly, or something else?

ps: in the mean time I agree with your experience; the optimistic approach better fits bike-routing than the other one.

from brouter-web.

Do you mean access=no is used too wildly, or something else?

I have actually the same question. I quickly checked on a dump from Ile de France. Might not be fully representative (very urban) but there are quite a lot of cycle routes.

I only found three segments which could be argued to be excessively access=no, the others all have notes mentionning works are in progress or a bicycle tag permissive enough and overloading the access:

• https://www.openstreetmap.org/way/101335487 which is noted as submersible as well
• https://www.openstreetmap.org/way/516871811
• https://www.openstreetmap.org/way/345912079

from brouter-web.

Do you mean access=no is used too wildly, or something else?

You can check the current conflict report: http://brouter.de/brouter/relation_access_conflicts_world.txt

My research is some years old, and meanwhile in Germany the number of such conflict is very low, I think because they are reported also by QS tools like OSMI

Typical conflicts with private access are routes in a small valley that cross private property (mills, camp-sites etc - but my first such finding was the Biblis nuclar power station at the Rhine river)

Another group are constructions where the access tagging is done just with cars in mind.

from brouter-web.

You can check the current conflict report: http://brouter.de/brouter/relation_access_conflicts_world.txt

Thanks! I tried to analyze it a bit and extracted about 400 such cases in France (where I know about typical infrastructures and what to expect). However, it seems this is for all relations and not only bikes. Then, there are some hiking routes for instance and it's a bit difficult to filter them out of the file.

Not sure how difficult this would be, but I guess it could be super useful to have this file outputted in http://brouter.de/brouter/segments4/ along the rd5 files with an extra info with the relation id. This could be useful for QA tools as well I guess.

My research is some years old, and meanwhile in Germany the number of such conflict is very low, I think because they are reported also by QS tools like OSMI

I played a bit with it and tried to find the typical cases. Some of them are indeed private access routes in the countryside (https://www.openstreetmap.org/way/20004171 for instance). Not sure what should be done for these ones. I'd tend to think it is better to have a longer route planned and discover on site that you can take a shortcut rather than the other way round (discovering on site that you have a 4km detour because a road is private and blocked).

There are quite a few which seems to be tagging errors indeed, such as https://www.openstreetmap.org/way/182168434 or https://www.openstreetmap.org/way/516871811.

Concerning the motorways, I found quite a lot of them are apparently in anglosaxon countries (US and Australia mainly). Among these, most of them do have appropriate tagging to specify that bike access is allowed on the shoulder (even though that seems totally unsafe to me, it seems to be a valid use case there).

If I filter out from the files the ways with correct bike access (overloading the general access tag) and proposed/construction, there are about 5k access problems remaining worldwide (not all of them being for bikes, as said before).

Overall, I still most of them are actually tagging issues and trying to fix them automatically in BRouter:

1. Hides the issue to the users, whereas they could potentially leave an OSM note or fix the tagging themselves appropriately.
2. Introduces other issues such as when a road is really blocked for a reason, such as http://www.openstreetmap.org/way/100538429.

Maybe the best solution would be to take into account the access tag at the profile level and leave a configuration variable (same as ignore_cycleroute) to ignore access tags. I can probably write a MR for this.

from brouter-web.

I'm closing this one, as it is not related to brouter-web but more to brouter.

from brouter-web.