-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Walking and Car routing failing except on Android 1.8.7 arm64 #35
Comments
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 :-) |
Thanks very much for the detailed and informative reply! 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: 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. |
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. |
Start: N 3(degrees)08.503' E 101(degrees)39.812' which is the location of a mobile mast |
I am trying to visualize routing graph algorithm by this command:
It seems to me that router refuse to go thru "barrier=lift_gate" https://www.openstreetmap.org/node/7240941899 When CMake is executed with
...have to look deeper... |
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. |
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. |
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: Framstag/libosmscout#1371 |
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. |
The initial idea of the handling of access was as follows:
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. |
I did some testing of Osmin on both Linux and Android using the Malaysia/Singapore map:
log shows:
Automatically closing FileScanner for file '/home/user/Maps/asia-malaysia-singapore-brunei-20221125-054244/types.dat'! )
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?
The text was updated successfully, but these errors were encountered: