Adjust bicycle routing weights and ETAs #9692
No reviewers
Labels
No labels
Accessibility
Accessibility
Address
Address
Android
Android
Android Auto
Android Auto
Android Automotive (AAOS)
Android Automotive (AAOS)
API
API
AppGallery
AppGallery
AppStore
AppStore
Battery and Performance
Battery and Performance
Blocker
Blocker
Bookmarks and Tracks
Bookmarks and Tracks
Borders
Borders
Bug
Bug
Build
Build
CarPlay
CarPlay
Classificator
Classificator
Community
Community
Core
Core
CrashReports
CrashReports
Cycling
Cycling
Desktop
Desktop
DevEx
DevEx
DevOps
DevOps
dev_sandbox
dev_sandbox
Directions
Directions
Documentation
Documentation
Downloader
Downloader
Drape
Drape
Driving
Driving
Duplicate
Duplicate
Editor
Editor
Elevation
Elevation
Enhancement
Enhancement
Epic
Epic
External Map Datasets
External Map Datasets
F-Droid
F-Droid
Fonts
Fonts
Frequently User Reported
Frequently User Reported
Fund
Fund
Generator
Generator
Good first issue
Good first issue
Google Play
Google Play
GPS
GPS
GSoC
GSoC
iCloud
iCloud
Icons
Icons
iOS
iOS
Legal
Legal
Linux Desktop
Linux Desktop
Linux packaging
Linux packaging
Linux Phone
Linux Phone
Mac OS
Mac OS
Map Data
Map Data
Metro
Metro
Navigation
Navigation
Need Feedback
Need Feedback
Night Mode
Night Mode
NLnet 2024-06-281
NLnet 2024-06-281
No Feature Parity
No Feature Parity
Opening Hours
Opening Hours
Outdoors
Outdoors
POI Info
POI Info
Privacy
Privacy
Public Transport
Public Transport
Raw Idea
Raw Idea
Refactoring
Refactoring
Regional
Regional
Regression
Regression
Releases
Releases
RoboTest
RoboTest
Route Planning
Route Planning
Routing
Routing
Ruler
Ruler
Search
Search
Security
Security
Styles
Styles
Tests
Tests
Track Recording
Track Recording
Translations
Translations
TTS
TTS
UI
UI
UX
UX
Walk Navigation
Walk Navigation
Watches
Watches
Web
Web
Wikipedia
Wikipedia
Windows
Windows
Won't fix
Won't fix
World Map
World Map
No milestone
No project
No assignees
2 participants
Due date
No due date set.
Dependencies
No dependencies set.
Reference: organicmaps/organicmaps-tmp#9692
Loading…
Add table
Reference in a new issue
No description provided.
Delete branch "pastk-routing-cycling"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
A big review of weights and ETAs.
I've reviewed all the current integration tests - seems like some of them lost their value over time due to map changes or too similar to other tests. @vng I want to proceed and delete such tests, but first please review my comments in case I've missed something.
Then I've added a bunch of new tests.
Out of scope: some cases are not fixable by weights alone
Cases solved:
Improves:
detects horrific regressions that may be missed by trickier tests?
From "CyclewayPriority" it sounds like it tries to confirm that cycleway is treated as not worse than alternatives? though maybe case where cycleway is a bit longer would be better? Can find some case for that (with use_sidepath on road)
@ -157,4 +233,4 @@
mercator::FromLatLon(28.15865, -16.63704));
TEST_EQUAL(res.second, RouterResultCode::NoError, ());
TestRouteLength(*res.first, 26401);
this is AFAIK typically allowed also elsewhere? At least on service which is not
driveway
@ -150,4 +225,3 @@
}
// Test on riding up from Adeje (sea level) to Vilaflor (altitude 1400 meters).
UNIT_TEST(SpainTenerifeAdejeVilaflor)
I would say that https://www.openstreetmap.org/directions?engine=fossgis_valhalla_bicycle&route=50.082166%2C20.033060%3B50.082567%2C20.031853 is not really worse
I actually prefer it if I would arrive at phase when Kocmyrzowska has green and Obrońców Krzyża is waiting so you can go onto road and start waiting for green (and if you have no tolerance to car traffic you would not go into this road but detour via parks)
It is caused by fact that cycleway has two separate traffic lights - and you may be caught between two traffic lights between carriageways, while if you are in the middle of the crossing on road you can leave it
@ -150,4 +225,3 @@
}
// Test on riding up from Adeje (sea level) to Vilaflor (altitude 1400 meters).
UNIT_TEST(SpainTenerifeAdejeVilaflor)
@ -216,0 +326,4 @@
}
UNIT_TEST(UK_UseNocyclewayTertiary)
{
@ -216,0 +326,4 @@
}
UNIT_TEST(UK_UseNocyclewayTertiary)
{
maybe having synthetic tests would be better? Rather than specifying location, specify small routing graph/OSM data within test itself?
or specify date and use attic data to fetch OSM data frozen on some specific date? It would prevent tests rotting because someone changed OSM data (at cost of not spotting that preferred tagging changed for something, but this seems much less valuable and should be rare and deprecationists will usually create an issue to complain)
I would dispute "not meant for passing through". And even ones built for car traffic and not designed for passing through can be still very useful for cyclists as cycleway substitute due to typically lower traffic.
this is based on extensive experience from Poland where https://www.openstreetmap.org/directions?engine=fossgis_valhalla_bicycle&route=50.067527%2C20.003867%3B50.068148%2C20.004073 is normal and using service for bypasses - either intended by road design or not - is often a great idea
can list more examples
is there bonus for having a bicycle ramp? And maybe smaller for stroller/wheelchair one?
@ -56,2 +58,4 @@
{HighwayType::HighwayCycleway, InOutCitySpeedKMpH(SpeedKMpH(21.0, 18.0), SpeedKMpH(23.0, 20.0))},
{HighwayType::HighwayLivingStreet, InOutCitySpeedKMpH(SpeedKMpH(12.0, 10.0), SpeedKMpH(14.0, 12.0))},
// Steps have obvious inconvenience of a bike in hands.
{HighwayType::HighwaySteps, InOutCitySpeedKMpH(SpeedKMpH(1.0, 1.0))},
what are units for SpeedKMpH?
I tried looking at https://github.com/search?q=repo%3Aorganicmaps%2Forganicmaps+SpeedKMpH&type=code but managed to only learn that first is m_weight and second is m_eta (I guess to note that something may be faster but still less preferable - like cycling on trunk)
@ -56,2 +58,4 @@
{HighwayType::HighwayCycleway, InOutCitySpeedKMpH(SpeedKMpH(21.0, 18.0), SpeedKMpH(23.0, 20.0))},
{HighwayType::HighwayLivingStreet, InOutCitySpeedKMpH(SpeedKMpH(12.0, 10.0), SpeedKMpH(14.0, 12.0))},
// Steps have obvious inconvenience of a bike in hands.
{HighwayType::HighwaySteps, InOutCitySpeedKMpH(SpeedKMpH(1.0, 1.0))},
f2dcb90b21/routing_common/vehicle_model.hpp (L108)
notes "KMpH"are both in kilometers per hour? and ETA has real km/h while weight has a bit fake one, to adjust for desirability?
one more cases where penalty for points is needed, though tiny as these are often on preferred cycling routes
@ -150,4 +225,3 @@
}
// Test on riding up from Adeje (sea level) to Vilaflor (altitude 1400 meters).
UNIT_TEST(SpainTenerifeAdejeVilaflor)
may be too much detail...
If something goes so horrific wrong to break this case, then I'm sure it'll break many other tests also :)
@ -157,4 +233,4 @@
mercator::FromLatLon(28.15865, -16.63704));
TEST_EQUAL(res.second, RouterResultCode::NoError, ());
TestRouteLength(*res.first, 26401);
@vng should know the context better here
@ -150,4 +225,3 @@
}
// Test on riding up from Adeje (sea level) to Vilaflor (altitude 1400 meters).
UNIT_TEST(SpainTenerifeAdejeVilaflor)
Actually the speed/distance difference is very minor here, reducing the cycleway weight by just 1 point makes OM take the road. (also the cycleway option has 1m altitude difference?)
The preferred OM route might change after we add support for turns, crossings and lights.
good point!
@ -216,0 +326,4 @@
}
UNIT_TEST(UK_UseNocyclewayTertiary)
{
There are some tests with embedded map data, though maybe not routing tests.
I guess its just too time-consuming to set them up.
Right, @vng ?
Yeap my comment is not clear enough, so I've just removed it.
Actually I was quite surprised to find that service roads seems to be commonly used to map in countryside in Germany, see the Germany_UseServiceCountrysideRoads case.
I would have expected either unclassifieds or grade1 tracks...
Nope its not processed yet.
Also the direction (up/down) of stairs should be taken in account. ATM its not, right @vng ?
@ -56,2 +58,4 @@
{HighwayType::HighwayCycleway, InOutCitySpeedKMpH(SpeedKMpH(21.0, 18.0), SpeedKMpH(23.0, 20.0))},
{HighwayType::HighwayLivingStreet, InOutCitySpeedKMpH(SpeedKMpH(12.0, 10.0), SpeedKMpH(14.0, 12.0))},
// Steps have obvious inconvenience of a bike in hands.
{HighwayType::HighwaySteps, InOutCitySpeedKMpH(SpeedKMpH(1.0, 1.0))},
Yeap, exactly!
@ -56,2 +58,4 @@
{HighwayType::HighwayCycleway, InOutCitySpeedKMpH(SpeedKMpH(21.0, 18.0), SpeedKMpH(23.0, 20.0))},
{HighwayType::HighwayLivingStreet, InOutCitySpeedKMpH(SpeedKMpH(12.0, 10.0), SpeedKMpH(14.0, 12.0))},
// Steps have obvious inconvenience of a bike in hands.
{HighwayType::HighwaySteps, InOutCitySpeedKMpH(SpeedKMpH(1.0, 1.0))},
I created #9708 to avoid such confusion for others
hmm, I would say that going up and down with bicycle is nearly as obnoxious
Opened "for cyclists steps with ramps are much better than steps without ramps" #9709
I expect that many are grade1 tracks tagged for renderer
@ -216,0 +326,4 @@
}
UNIT_TEST(UK_UseNocyclewayTertiary)
{
if it is possible than scripting extraction from OSM data should be fairly easy
or maybe even save bunch of .osm files
(StreetComplete has small synthetic tests as when it was using live OSM data tests were getting broken all the time resulting in them being ignored, if someone points me to format/example code I can prepare some for bicycle routing)
do you want a replacement for "a bit longer cycleway is better than road"?
maybe it was assumed that "no cycleway here" will be more often tagged in places which were expected to have cycleway like busy road?
but it is fairly bad assumption IMHO
(or maybe reason was different? is there any cycleway that is not getting bonus but would be not hit by this penalty? like sharrows? but getting bonus to sharrows more likely to be on major busy roads would be also silly)
maybe it can be reduced further? primary road may be fairly small and calm, but if there is
primary_link
it indicates large intersection terrible for cyclistswe cannot easily extrapolate it on primary road itself but maybe penalising at least link section would be nice
why living street is so heavily penalised? more than
highway=primary
?maybe real speed will be fairly low (but still greater than 8, I bet) but I would definitely take slower driving on
highway=living_street
overhighway=primary
.And I am cyclist who on occasion uses overpasses on dual carriageway
highway=primary
(not anymore since proper cycleway exists now). And I sometimes cycle (legally) on roads with 5 lanes in each direction rather than on sidewalk (illegally).I bet that 99%+ of people will prefer
living_street
overprimary
, 90%+ over secondary, 80% over tertiary.some
highway=living_street
will be extremely busy with pedestrians, but most are great for cycling (and ones most crowded will often bebicycle=no
anyway)this matches
highway=secondary
in desirability and path/bridleway in speedthis matches highway=tertiary in desirability and path/bridleway in speed
or maybe give larger boost
I would say that after cycleway, good track, good service road, living street with asphalt surface is the next in order of preferred road types.
Yes please!
@ -216,0 +326,4 @@
}
UNIT_TEST(UK_UseNocyclewayTertiary)
{
There are many *.osm samples in
data/test_data/osm/
. Check their usage in the code.If we'll use such excerpts for routing then how would we visualize them and build routes and reason about?
Right now check the test in the desktop app - its more or less easy to reason which way is better, try to put intermediate points to check alternatives, check output of alternative routers on osm.org...
Maybe synt tests will be suitable for strict yes/no tests only like - a constructed road is a no go, cycleway=opposite should allow going in any direction, etc.
https://www.openstreetmap.org/directions?engine=fossgis_valhalla_bicycle&route=50.076924%2C19.917848%3B50.074458%2C19.910502#map=17/50.075451/19.914844&layers=N (this one misses even North-South shared sidewalk!)
https://www.openstreetmap.org/directions?engine=fossgis_osrm_bike&route=50.076924%2C19.917848%3B50.074480%2C19.910488#map=18/50.075936/19.914098&layers=N
more bordeline
https://www.openstreetmap.org/directions?engine=fossgis_valhalla_bicycle&route=50.043813%2C20.016456%3B50.047522%2C20.029986
https://www.openstreetmap.org/directions?engine=graphhopper_bicycle&route=50.043813%2C20.016456%3B50.047522%2C20.029986#map=17/50.046302/20.023109&layers=N
this one has contraflow on service road as cycleway substitute
https://www.openstreetmap.org/directions?engine=graphhopper_bicycle&route=50.036180%2C19.982480%3B50.040088%2C19.983348#map=17/50.038544/19.985375&layers=N
https://www.openstreetmap.org/directions?engine=fossgis_osrm_bike&route=50.036180%2C19.982480%3B50.040088%2C19.983348#map=17/50.038172/19.982790&layers=N
https://www.openstreetmap.org/directions?engine=fossgis_valhalla_bicycle&route=50.031478%2C19.948912%3B50.036289%2C19.941198#map=17/50.033927/19.945056&layers=N
https://www.openstreetmap.org/directions?engine=fossgis_osrm_bike&route=50.031478%2C19.948912%3B50.036289%2C19.941198#map=17/50.033927/19.945164&layers=N

should be enough, I think :)
I can give more examples of specific thing from Kraków
in all cases fixed routing is below.
I see that Valhalla really hates cycleways :)
@ -216,0 +326,4 @@
}
UNIT_TEST(UK_UseNocyclewayTertiary)
{
I thought about bunch of small obvious tests like "point A, point B, 100m long highway=living_street, 80m long highway=primary, living street should be selected" (can be done with 4 nodes and two ways in .osm format)
that in comment could link to issue/real A to B routing
There is some context in organicmaps/organicmaps#5192 and https://github.com/orgs/organicmaps/discussions/5158#discussioncomment-5938807
I found several cases where the 0.8 factor is contributing to weird detours.
I'm not 100% sure its better to remove the adjustment completely though. Maybe a small factor like 0.95 is beneficial.
Its like assuming that e.g. an explicit
smoothness=good surface=asphalt
footway is a better bet than a footway with no additional tags. WDYT?it sounds reasonable, it'd be great to have a test case 🙏
in my experience link roads (esp. on/off ramps) are also narrower and no shoulder
Is there any known case at all where this extra complexity helps? And this 0.8 is a massive penalty.
(61.5445696, 23.9394003) -> (61.6153965, 23.876755) was mentioned, I guess it is https://www.openstreetmap.org/directions?engine=fossgis_osrm_bike&route=61.54%2C23.94%3B61.62%2C23.88#map=13/61.57544/23.89835&layers=N
but it surely can be achieved by looking at
highway=secondary maxspeed=80
andhighway=tertiary maxspeed=50
, not at effectively random "where missing cycleway was mapped"Sounds reasonable, I'll try to adjust and see if the tests are good. Would be great also to add specific tests for living_street preference/avoidance cases.
IDK the reason it was penalized before, I can only guess it stems from experience of living_streets in ex-USSR countries used predominantly for inside-the-block small and winding access roads.
@vng might know more.
@ -216,0 +326,4 @@
}
UNIT_TEST(UK_UseNocyclewayTertiary)
{
yeap sounds good!
I have nothing obvious, on Poland for whatever reason
primary
is always used instead ofprimary_link
meandering roads should be solved by itself due to increased length...
bad: https://www.openstreetmap.org/directions?engine=fossgis_valhalla_bicycle&route=50.053595%2C19.948463%3B50.050640%2C19.950151#map=17/50.052076/19.949938&layers=N
good: https://www.openstreetmap.org/directions?engine=fossgis_osrm_bike&route=50.053595%2C19.948463%3B50.050640%2C19.950151#map=17/50.052062/19.949316&layers=N
(going together with trams, busses and heavy traffic is clearly inferior)
https://www.openstreetmap.org/directions?engine=fossgis_osrm_bike&route=50.006085%2C19.962158%3B50.006664%2C19.957639#map=18/50.006384/19.959900&layers=N
currently OM wants to do detour via south (warning: not checked this area in person, looks like a good test based on mapped data)
https://www.openstreetmap.org/directions?engine=fossgis_valhalla_bicycle&route=50.020758%2C20.049156%3B50.022031%2C20.048289 (OM wants illegally drive on sidewalk, GraphHopper wants to go on route that is of lower quality but balanced by being longer :) )
looks like good test case, never was there:
https://www.openstreetmap.org/directions?engine=graphhopper_bicycle&route=50.096027%2C19.904330%3B50.099875%2C19.889867
should be
https://www.openstreetmap.org/directions?engine=fossgis_osrm_bike&route=50.096008%2C19.904225%3B50.099847%2C19.889835
(let me know if screens are also needed)
@ -216,0 +326,4 @@
}
UNIT_TEST(UK_UseNocyclewayTertiary)
{
great! is there any such test already? Can you point me to one? (I can try to dig into
data/test_data/osm/
but I think that for tiny sythethic tests data would be defined it tests itself? unless it would not exercise OM code properly, and entire pipeline should be run starting from .osm file to test things well?)Actually this kind of
highway=service
use (rather long countryside connections which are not to e.g. a specific property) looks like mismapping according to https://wiki.openstreetmap.org/wiki/Tag:highway=serviceOr are there local (German, Poland, etc.) conventions which support this kind of usage?
yes, those are
highway=track
- no idea why Germans tagged it those way. If you point me to some I will open notes (or you can open notes yourself, I guess)(Poland has opposite problem, misuse of
highway=track
for unpaved driveways but there is ongoing cleanup)I can give examples of some
service
that are validly mapped and are useful shortcuts/bypasses if it would be useful.Please check the
Germany_UseServiceCountrysideRoads
case, ref organicmaps/organicmaps#6027Maybe we should remove/disable this case until the tagging is fixed.
Yeap it'd be helpful! Both shortcuts and detours via service.
cycleway interruptor, but as low traffic service it works OK:
https://www.openstreetmap.org/directions?engine=graphhopper_bicycle&route=50.067485%2C20.003859%3B50.068198%2C20.004041
shortcut unavailable to vehicles in general: https://www.openstreetmap.org/directions?engine=graphhopper_bicycle&route=50.067845%2C19.900210%3B50.068379%2C19.897437
avoids megatraffic, then continues as living street: https://www.openstreetmap.org/directions?engine=graphhopper_bicycle&route=50.098161%2C19.890951%3B50.101826%2C19.888762
should be enough, I guess? Can find more
For avoiding: I have no good examples, cases where it should not be used is happening when it is a dead end. Which seem not worth testing.
Many thanks! I've picked 2nd and 4th cases
@ -216,0 +326,4 @@
}
UNIT_TEST(UK_UseNocyclewayTertiary)
{
I don't know if there are such routing tests already. @vng?
There are some other tests which seem to setup mock mwms, e.g.
search/search_integration_tests/smoke_test.cpp
. But probably setting up for the routing to work will need to be more elaborate.All these tests seems way too obvious (only something horrific could break them).. All those service roads have some kind of bike infra (lanes...) or bicycle=yes which makes it very easy for OM to prefer them.
I've added a small penalty to all link roads.
Making the penalty higher breaks e.g. the RussiaMoscowKashirskoe16ToCapLongRoute test - to avoid a long secondary_link OM prefers a detour involving a secondary of a similar length :)
Have you pushed the new code? I see older in commits? (or maybe you selected it without turning it into code, sorry for noise then)
What is your opinion on position of highway=residential, unclassified, tertiary amongst those?
I didn't manage to finish adjustments yesterday, I'll push an update later today.
I've picked two, thanks!
I've raised weights for living streets and service. But not as much. Logically a living_street isn't more desirable than a service road and we can't raise service much at the moment as it leads to many small useless detours "to visit a gas station" :)
We need some special logic to filter such small and pointless deviations from the main route.
E.g. if the route has to go via a primary for several kms then there is no point to turn into gas stations driveways as 100m further one is back to the primary anyway.
Actually maybe introduction of turns/intersections penalties will help remedy this behavior.
even if living_street is not better than service it may be still possible to achieve better routing by giving it cost lower than service
in general these are routing weigths, not intended to be used to compare cycling quality in consistent, transitive etc. fashion
tertiary? definitely worse than residential and living_street, even for tertiary with bicycle lane due to higher traffic
though, tertiary with good asphalt may be better than service/residential/etc with terrible surface such as sand, mud, grass paver, true cobblestone and worse kinds of set
residential/unclassified is all over the place, but I would consider it (in my area) to be overall a tiny bit worse than living_street
Forgot to add that OM with latest changes passes 3 cases you've suggested.
OM goes via a sidewalk still because it has
bicycle=yes
. Actually it might be a good test case for #9593Interesting, I opened https://www.openstreetmap.org/changeset/151976870
congratulations!
For some reason residentials had quite little weight before, maybe because is some areas its usual to have a lot of parked cars along? IDK.
I've made it higher but lower than tertiary still.
We can review it later again, but first would be good to find some test cases.
(here I talk about roads of similar quality only; OM applies a factor depending on the quality, see e.g.
paved_bad
in the file with weights)static parked cars are little to no problem (just do not cycle within doorzone, glued to side of the road)
maybe it was a performance optimization to prefer compute inferior route but faster? or attempt to prefer simpler instructions over busy roads?
I will find some cases. I expect that no amount of weight tweaking will get match for all at once. That is OK.
prefer residential over tertiary (tertiary has high traffic and nasty curve with very poor visibility, and some local drivers taking shortcut over a wrong lane, I protested against using this hint too much but there is bicycle route going over residential. Residential has good surface and almost zero traffic.)
https://www.openstreetmap.org/directions?engine=graphhopper_bicycle&route=50.093257%2C19.814578%3B50.093415%2C19.807746#map=18/50.093343/19.811364&layers=N
preferred route: https://www.openstreetmap.org/directions?engine=graphhopper_bicycle&route=50.095435%2C19.980408%3B50.098643%2C19.994554#map=16/50.09866/19.98585&layers=N
worse route: https://www.openstreetmap.org/directions?engine=graphhopper_bicycle&route=50.09480%2C19.97874%3B50.09864%2C19.99455 (no osm.org router passes, Google routes cyclists there)
though you need to dismount on a tiny bridge and has gravel section
but this tertiary has really heavy traffic
bad https://www.openstreetmap.org/directions?engine=graphhopper_bicycle&route=50.078763%2C19.960291%3B50.078825%2C19.971396#map=17/50.077131/19.965656&layers=N
good http://brouter.de/brouter-web/#map=17/50.07864/19.96423/standard&lonlats=19.971321,50.078749;19.962094,50.079217;19.960356,50.0789
though literally no router wanted to go there on its own
but https://www.openstreetmap.org/way/237026822 is nasty enough (lanes=4, cycleway=no, I added shoulder=no now) that going up/down on steps without ramp is still better
https://www.google.pl/maps/@50.0766128,19.9688628,3a,42.5y,216.52h,85.61t/data=!3m7!1e1!3m5!1sI9LitafSvcq_vcxbd4k1FA!2e0!6shttps:%2F%2Fstreetviewpixels-pa.googleapis.com%2Fv1%2Fthumbnail%3Fcb_client%3Dmaps_sv.tactile%26w%3D900%26h%3D600%26pitch%3D4.391837655803542%26panoid%3DI9LitafSvcq_vcxbd4k1FA%26yaw%3D216.5195172870467!7i16384!8i8192?entry=ttu&g_ep=EgoyMDI0MTExOS4yIKXMDSoASAFQAw%3D%3D
have fun cycling here
especially that uphill part after going under railway bridge
this altitude change may be not seen in OM data :(
http://brouter.de/brouter-web/#map=16/50.0756/19.9222/standard&lonlats=19.926238,50.07722;19.917955,50.078223
cycle for longer to avoid busy tertiary - prefer to escape going slightly downhill (to East) than to go on it (to West)
again, this altitude may be not seen in OM data :(
prefers residential over tertiary + unsegregated footway allowing cyclists http://brouter.de/brouter-web/#map=16/50.0748/19.9204/standard&lonlats=19.921668,50.079108;19.916038,50.07401
http://brouter.de/brouter-web/#map=15/50.0381/19.9428/standard&lonlats=19.945207,50.045255;19.94033,50.036663
prefers minor streets over busy tertiaries
Can add more, what kind of characteristics are not satisfied by tests so far?
OM passes. The residential has yesbicycle (prob inherited from route relation), so OM prefers it.
Passed.
Not passed.
Not passed.
Not passed.
OM avoid the tertiary too, but in a different way
So let's leave for the next iteration.
this is not terrible and at this point it starts to get to "do you prefer to weave around pedestrians on crowded sidewalk or be on road with some cars" point, with preferred routes depending on person.
I would consider adding also some that pass now - this will protect against regressions
contacted the mapper in https://www.openstreetmap.org/changeset/151976870 - they commented that it was a mistake and removed it
looks great to me, though I have not run code myself
existing routing is really silly and I hope that it will get better with this changes
I don't mind moving forward here. Just don't delete some tests and leave (todo) comments if needed.
AFAIR (a long time ago), this test is based on a real case from the EMail of some bicycle rental app. There was a much bigger detour because of previous bugs in altitude calculations.
AFAIR, this test is from a user claim in EMail. Like "All cyclists in our town use this particular footway" :)
countries
Well, I don't mind with the update here if you checked and updated "Finland_Use_Tertiary_LowTraffic" test.
Why did you remove case with {"hwtag", "nobicycle"} ?
Ok, but do I understand right you want to keep this test? Why?
I understand the test was useful before, but now its not. If fixes to altitude calculations need to be tested then it should be some altitude calculations unit test, not an integration bicycle routing test, right?
Did this user tell whether the cyclists cycle through this footway or they dismount and push their bikes indeed?
Its a bit controversial.
The test is for
AllLimitsInstance
which means that cycling is allowed on footways.The speed calculation doesn't take the
hwtag-nobicycle
into account (I guess its processed elsewhere and just forbids bici routing there), hence anobicycle footway
would appear in this test with the same speed as a regularfootway
, which doesn't make sense.Though logically an explicit
bicycle=no
should result in a dismount speed:This PR doesn't change the current behavior, but it increased the footway speed for countries where its allowed.
I'll add a todo comment to the test.
I.e. if they (illegally) cycle through then we shouldn't adjust to route them there and it'd be better to treat this as an AvoidDismount case indeed (as per my changes in this PR).
But if they dismount indeed and prefer it over making a pedalling detour then its a legit UseDismount case and we can look into fulfilling it (e.g. increase dismount speed/weight).
So WDYT? Keep it or drop it?
I've checked this test. Yes, now it can be replaced with simple:
Before data or elevation fix the r2 route was completely different from r1 route (despite of equal start point and a small offset of the end point). That's why it was introduced.
Thanks! Updated.
For now I've just added a comment about this controversial situation..