Walking and Car routing failing except on Android 1.8.7 arm64

[emulti]

I did some testing of Osmin on both Linux and Android using the Malaysia/Singapore map:

1. v1.8.7 Android osmin-arm64-v8a-release-signed.apk on LineageOS 18.1 (MicroG): Walking/Cycling/Car routing all working correctly.
2. v1.8.7 Android osmin-armeabi-v7a-release-signed.apk on LineageOS 18.1 (no MicroG): Cycling works, but Walking and Car gives "There was an error while routing!"
3. Build from source (Master branch) on Arch Linux x86_64 following "build for Desktop" instruction in the Readme.md: Cycling works, but Walking and Car gives "There was an error while routing!". There were some warnings during the build:

• Could NOT find LIBAGG (missing: LIBAGG_INCLUDE_DIRS LIBAGG_LIBRARIES (resolved by installing agg from AUR).
• System marisa was not installed so Cmake built the included tarball.

log shows:

qml: mapView.state: routing
qml: Deactivate map preview
qml: Search state changed: dialog
~PlaneMapRenderer
~MapRenderer
No route found!
Route computation failed: There was an error while routing!

4. v1.8.7 on Arch Linux x86_64 from Manjaro PKGBUILD (https://gitlab.manjaro.org/manjaro-arm/packages/community/osmin/-/raw/master/). This requires the map to be re-downloaded ( File '/home/user/Maps/asia-malaysia-singapore-brunei-20221125-054244/types.dat' does not have the expected format version! Actual 24, expected: 23 Automatically closing FileScanner for file '/home/user/Maps/asia-malaysia-singapore-brunei-20221125-054244/types.dat'! )

• When attempting to route for 'Car' the error "There was an error while routing!" is shown.
• When attempting to route for 'Cycle':

  /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/12.2.0/../../../../include/c++/12.2.0/bits/stl_vector.h:1123: std::vector::reference std::vector<osmscout::RouteNode::ObjectData>::operator[](std::vector::size_type) [_Tp = osmscout::RouteNode::ObjectData, _Alloc = std::allocator<osmscout::RouteNode::ObjectData>]: Assertion '__n < this->size()' failed.
  Aborted (core dumped)

• When attempting to route for 'Walking' the error "There was an error while routing!" is shown.

Unfortunately the error message is not informative enough to me to allow debugging, but I am happy to try if you can give some advice on how to proceed. Is it possible that there have been recent changes to the libosmscout API that mean that some routing calls are failing?

[Framstag]

Hi, I'm one of the authors of libosmscout. Some background:

The warning regarding libagg and marisa should be ignorable, since osmin uses the Qt backend. marisa is AFAIK not used by osmin, too, and would further full text searches.

The warning regarding format version comes from libosmscout. Changes in the file format lead to "+1" for the version. Current version is 24, see https://github.com/Framstag/libosmscout/blob/master/libosmscout/include/osmscout/TypeConfig.h#L1043. It was increments 10 month ago...I assume that osmin is still on an older version of libosmscout and expects an older version of map data.

"No route found" is a log output from the router itself, in case where the routing did not succeed because it was not able to reach the destination. It does not necessarily show an error in the router itself. It is possible that the cause is that there simply does not exist a route under the given constraints. This had be analyzed manually. The core dump though, may show a problem in libosmscout itself.

For libosmscout to reproduce the problem, we would need the input to the router together with the map data. The best way would be to have a call to one of the (command line) routing demo application, but we might get that working internally as long as we have geo coordinates or OSM node ids for the start and the end of the requested route. For map data we would generate the current map data based on the geofabrik exports of the region.

If you are a software developer and are interested in doing the analysis yourself, we can give you help on this, too :-) Depending on the result of this analysis, we can at least rule out a bug in the current version of libosmscout itself.

[emulti]

Thanks very much for the detailed and informative reply! It seems the older 'release' builds of Osmin do indeed require an older map version. The fork of libosmscout has been updated since so the new version 24 is needed.

I have done some more investigation including tracking down the error message to the precision of the start point used, for which I was using only 'My Position'. The armv8 Android device was getting an accurate GPS fix that is on a known road. The two Armv7 devices (older Samsung mobiles with LineageOS) have notoriously poor wifi and GPS antennas due to the mechanical construction, so the reported position was actually being taken from the MLS backend, defaulting to a mobile tower in a car park about 100m away from true location. Libosmscout doesn't seem to be able to route from that off-street start point, even though the map shows a link road to a named street. Changing the start point to somewhere on a named street makes the routing work again for Car and Walking. It's odd that Cycling was able to route, however.

So I think it's a minor error in the OSM map database that's maybe causing this.

For the Osmin versions 1.8.7 and 1.9.3 built on x86_64 with the PKGBUILD, the crash on routing persists: /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/12.2.0/../../../../include/c++/12.2.0/bits/stl_vector.h:1123: std::vector::reference std::vector::operator [_Tp = osmscout::RouteNode::ObjectData, _Alloc = std::allocator]: Assertion '__n < this->size()' failed. Aborted (core dumped)

However, building directly from source with the git Master branch of Osmin produces an executable that doesn't crash on routing, so someting is amiss with the PKGBUILD. Maybe it is connected to Osmin statically linking against an older version of iconv, where on Arch it is part of libc? I'll have to figure out how the CMakelists.txt files work to prevent that, and investigate further, including how to get the Demos to build with the Osmin fork of libosmscout.

[Karry]

Can you provide the start and target locations where routing is failing? Qt routing module should lookup routable node up to one kilometer from location. So it is weird that it is failing in park.

[emulti]

Start: N 3(degrees)08.503' E 101(degrees)39.812' which is the location of a mobile mast End: N 3(degrees)06.952' E 101(degrees).42.667' (but it fails for any destination)

[Karry]

I am trying to visualize routing graph algorithm by this command:

./Demos/RoutingAnimation \
  --dpi 300 --width 3840 --height 2160 \
  --style ../stylesheets/standard.oss \
  --output animation \
   --debug \
  ~/Maps/asia-malaysia-singapore-brunei-20221124-224244 \
  3.14172 101.66353 \
  3.11587 101.71112

It seems to me that router refuse to go thru "barrier=lift_gate" https://www.openstreetmap.org/node/7240941899

When CMake is executed with -DOSMSCOUT_DEBUG_ROUTING=ON, routing debug output is:

StartForwardNode:   Way 96146145 2748113587211585537 0.00388668 0.0557055 0.0595922
TargetForwardNode:  Way 94146892 2748113257711535105
TargetBackwardNode: Way 94146892 2748113261997726465
Analysing follower of node 0 / 2748113587211585537 (Way 96146145[2748113587211585537]) 0.00388668 0.0557055 0.0595922
  Inserting route to 2748113582930052865 (Way 95431890) 0.00414034 0.0556752 0.0598156 2748113587211585537
  Inserting route to 2748113587211711745 (Way 96146145) 0.00407568 0.0557521 0.0598278 2748113587211585537
Closing DBId(0,2748113587211585537) (previous DBId(0,0))
Analysing follower of node 0 / 2748113582930052865 (Way 95431890[2748113582930052865]) 0.00414034 0.0556752 0.0598156
  Skipping route to 2748113582922712065 (Way 95431830) => moving from non-accessible way back to accessible way
  Skipping route to 2748113587211585537 (Way 95431890) => back to the last node visited
Closing DBId(0,2748113582930052865) (previous DBId(0,2748113587211585537))
Analysing follower of node 0 / 2748113587211711745 (Way 96146145[2748113587211711745]) 0.00407568 0.0557521 0.0598278
  Skipping route to 2748113582922838529 (Way 95431869) => Cannot be used
  Skipping route to 2748113587211585537 (Way 96146145) => back to the last node visited
  Inserting route to 2748113587211839745 (Way 96146145) 0.00419534 0.055782 0.0599774 2748113587211711745
Closing DBId(0,2748113587211711745) (previous DBId(0,2748113587211585537))
Analysing follower of node 0 / 2748113587211839745 (Way 96146145[2748113587211839745]) 0.00419534 0.055782 0.0599774
  Skipping route to 2748113582922966529 (Way 95431848) => Cannot be used
  Skipping route to 2748113587211711745 (Way 96146145) => back to the last node visited
  Inserting route to 2748113587185770497 (Way 96146145) 0.00882168 0.0569471 0.0657688 2748113587211839745
Closing DBId(0,2748113587211839745) (previous DBId(0,2748113587211711745))
Analysing follower of node 0 / 2748113587185770497 (Way 96146145[2748113587185770497]) 0.00882168 0.0569471 0.0657688
  Skipping route to 2748113587211839745 (Way 96146145) => back to the last node visited
Closing DBId(0,2748113587185770497) (previous DBId(0,2748113587211839745))
No more alternatives, stopping

...have to look deeper...

[janbar]

I will release osmin with a recent libosmscout soon. Before I have to complete all checks. Also I wait feedback from Karry about this issue.

[emulti]

I confirmed on site that there is a lift barrier at the problem location, at the gatehouse of a condo complex. What's odd is that 'cycle' routing works, but 'walking' and 'car' fail. Other than that ,I find Osmin works well, with a good balance of UI complexity and performance for resource-constrained devices. Thank you for your work developing this application!

[Karry]

So, the problem is in access=private tag on starting way. For simplicity, we are handling access values "delivery", "destination" and "private" the same way. Vehicle may access these ways, but it cannot leave it back to unrestricted way. It is correct for access=destination, but not really correct for access=private. Anyway, routing fails when such "private" way is start of the routing, because router cannot leave...

Not sure if this explanation is clear enough :-) We should fix the case when routing is starting on restricted ways...

And the fact that bicycle routing is working - it is the bug, access flags are not setup properly: https://github.com/Framstag/libosmscout/pull/1371

[emulti]

That seems a logical explanation of the error. Workaround is to pick start point on map instead of the slightly incorrect 'My Position' where accurate GPS fix is not available. Perhaps the libsmscout error message when routing fails could be made more informative? Or an 'allow private roads' flag in the application when requesting the route. I saw Osmand+ prompt for this on the same route, though the reason is not specified.

[Framstag]

The initial idea of the handling of access was as follows:

1. I must not come from a public route, enter an access restriction region, ways and then leave the restricted area again - as this would violate the generalized idea of restricted access.
2. It should be possible to start in a restricted area and leave it to a public area
3. It should be possible to start in a public area and stop in a restricted area (since then I have a direct intention to drive to the target and I'm not only passing through).
4. It should be possible to start in one restricted area and target a location in another restricted area
5. And routing within a restricted area should of course also not be a problem

I did not look at the code (yet) but it seems that option 2 at least was broken?

Restricted area == A way or a continuous string of multiple ways which all have restricted access (in real life IMHO an area is restricted by placing a corresponding sign on all ways entering or leaving the area)

The handling is implemented in the route calculation, so during routing - especially rerouting - the situation can occur all the time. So from a usability point, an interactive dialog can be a problem if popping up during driving. At least a hit on the inital calculation makes sense (it looks like you start in or target a restricted area, what should we do? option 1, 2, 3....)

It should however be not a problem to make the handling optional, since it is just a simple internal state handling.