Closed Phyks closed 4 years ago
Hmm, tweaking the penalty for a particular case does not seem right to me. As there are opposite cases too high pushing penalty lead to excessive detours.
I may consider to set minimal pushing penalty as function of MTB factor, increasing it for its negative values.
For a bit more context, there are actually three "sensible" routes here:
In my opinion, the last one is the best one for bikes. Pushing bike in town on an opposite oneway, on small sidewalks super crowded should be a last resort option in my opinion.
Hmm, tweaking the penalty for a particular case does not seem right to me.
I totally agree that settings in the parameters should not be done without considering multiple cases. It makes me think about https://github.com/abrensch/brouter/issues/116.
On the other hand, I tweaked the route a bit (starting and ending point) to try to check the minimal weight required while not affecting other similar routes. That's how I came up with the slight increase which seemed reasonable in my area.
You can see the choice of the destination in the example is very tricky.
If you move the destination to slightly left from the middle of the Rue Gabriel Peri segment( so taking pushing northern path should be even more compelling) , the routing takes the desired southern path.
The reason to take northern pushing path was very high cost of the terminal segment toward original destination via southern path.
Additional notes:
The overall route has to be compared in context of total cost scores and cost contributions.
The particular cost policy has to be considered "caseless", not addressing any particular scenario. How long ideal way should be equivalent to pushing 1 km this way ? What eventual initial cost should be used ?
The reverse one-way penalty logic is ovetaken from the standard Trekking profile.
I have noticed there is not involved the (un)mounting extra initial cost in way context, to be implemented in next template version.
I may reconsider eventual additional residual reverse oneway penalty to the basic foot access penalty, but no promise.
The only existing reality in the BRouter context is the OSM data subset in BRouter rd5 files. What is not there does not exist The major northern road is not high traffic city road, but an ordinary secondary road. The pushed through oneway road is not a crowded road, but an ordinary residential road.
The crowdyness( or lack of ) does not depend on if foot only access is related to a one-way or not.
The Trekking-Poutnik template is aimed for bike trekking in the first place. There is no city/noncity hint in rd5 files. If the cost policy is tailored for cities, it will get biased for the country.
I may consider to implement city switch in the template, but there is dedicated Jacob's city/street profile (see readme), IMHO better suited for city biking.
The reason to take northern pushing path was very high cost of the terminal segment toward original destination via southern path.
Thanks for taking a deeper look into it and for the extra notes!
I have noticed there is not involved the (un)mounting extra initial cost in way context, to be implemented in next template version.
Nice!
The only existing reality in the BRouter context is the OSM data subset in BRouter rd5 files. What is not there does not exist The major northern road is not high traffic city road, but an ordinary secondary road. The pushed through oneway road is not a crowded road, but an ordinary residential road.
In OSM data, the hierarchy of the roads is still present. "Rue Gabriel Péri" (secondary, 50km/h, no bike lanes) should have more traffic than "Avenue de la République" (tertiary, 50km/h, no bike lanes) than "Rue Sylvine Candas" (residential, 50km/h, no bike lanes). For the same reason of hierarchy of the roads, I would have expected the northern route to actually pass through the paralell lane https://www.openstreetmap.org/way/224483437.
Secondary (and tertiary to some extent) are (at least in France) roads dedicated for global transit (large number of vehicles going through the city) whereas residential is only meant for local transit.
Sure about the one way road though, it might be difficult to penalize it even more.
The Trekking-Poutnik template is aimed for bike trekking in the first place. There is no city/noncity hint in rd5 files. If the cost policy is tailored for cities, it will get biased for the country.
Indeed, this is an issue to keep in mind. There might be some ways to detect city/noncity at a upper level though (typically checking whether straight aerial route always stay in OSM cities or move to the country as well). Having two profiles might be an option.
I may consider to implement city switch in the template, but there is dedicated Jacob's city/street profile (see readme), IMHO better suited for city biking.
Thanks for pointing this to me! I think I should do some deeper profiles comparison / study. I missed this one…
Addressed by 168840be985a69c0c3f56cdf2de435de6c4b6126
Hi,
I think the penalty for pushing bike in a oneway in opposite direction might not be high enough. I came up with this situation where I'm going from the point on the left to the point on the right:
The
Trekking-dry
profile makes me take the one way in opposite direction and then a major street while there is an alternative way on the south which is about as long but without opposite oneway and calmer streets.Increasing https://github.com/poutnikl/Trekking-Poutnik/blob/master/Trekking-Poutnik.brf#L249 a bit up to 6.0 seems to be perfectly fine to fix this.
What do you think? Thanks!
EDIT: The route can be seen at https://brouter.phyks.me/#map=18/48.81836/2.31871/OpenStreetMap&lonlats=2.316879,48.817792|2.31918,48.818427&profile=Trekking-dry (although my instance might be quite slow to compute).