Errors in GraphHopper profiles and menu control? #591
-
I noticed two things: If you select a profile other than "car", e.g. "bike", with the current GraphHopper Offline Data (which is smaller than the old ones, by the way), this leads to an error and it says that the profile does not exist. Are the parameters in the app incorrect or does the GraphHopper Offline Date no longer support other profiles then "car"? If you activate "advanced settings", the selection for "Map" is larger (e.g. Offline POI) but the selection for "Route" is smaller and vice versa. With other devices nothing happens and e.g. offline POI are not displayed in the maps menu even though the POI Data (Openandromaps) are on the memory card in the POI directory and the menu is unchanged. Is there something wrong with the menu control? So, enough complaining... great app... it was worth a subscription to me. |
Beta Was this translation helpful? Give feedback.
Replies: 16 comments 33 replies
-
@Boomer4722 thanks for the report.
There was an problem in the latest GraphHopper data and they only contain the car.
Can you post some screenshots to understand what you mean?
Offline POI are used in offline search and nearby POI in navigation. |
Beta Was this translation helpful? Give feedback.
-
Thanks for your quick reply. The problem with the menu has been resolved. I overlooked the fact that there exist two advanced options. :-( When will the new Graphhopper data be available? thx |
Beta Was this translation helpful? Give feedback.
-
GraphHopper (offline) routing data have all been recreated. |
Beta Was this translation helpful? Give feedback.
-
There is still an error somewhere. GraphHopper (online) and GrapHopper (offline) come to different results: At both ends of the street shown you can see a traffic island where one-way traffic applies to the left and right - but not in the long stretch in between. In the offline version, however, it appears that the entire street is a one-way street (but only for bicycles and motorcycles, not for cars). The online version comes to the correct result. Now you could say, OK, it's just not right at that point. What's the point? But the OSM data is correct! So either the offline maps have errors (but then not only at that point) or the route calculation itself makes an error (but then not only at that point). I believe that the one-way street attribute is only taken into account at the beginning of the street. It seems that it is no longer taken into account that the property can change along the street. But as I said, only for bicycles and motorcycles, not for cars. I'll upload some pictures soon |
Beta Was this translation helpful? Give feedback.
-
pictures delete |
Beta Was this translation helpful? Give feedback.
-
In the first picture you can see the "wrong" route. In the following picture you can see why: The street is probably considered a one-way street (bicycles and motorcycles only). In pictures 3-5 you can see the direction arrows. In picture 6 (online) it is "correct". |
Beta Was this translation helpful? Give feedback.
-
The route by car is OK! Compare picture 2 with the one in the attachment! There is a fundamental error somewhere! pictures delete |
Beta Was this translation helpful? Give feedback.
-
It is recommended to switch to BRouter (offline). GraphHopper offline vs online use different engines, so the results may be different. |
Beta Was this translation helpful? Give feedback.
-
I have now tested various options and various devices. Each test was carried out with a new installation of 4.0.2 (before uninstalling I deleted the data and cache). The data used was always the currently available (mapsforge, brouter, graphhopper ...) Here are my results: I noticed that different routes were calculated with the same data and the same settings. These were always reproducible. It couldn't be the maps, nor the engine. I was completely desperate! At some point I had the idea of looking at the profile files. Without me having changed anything, they were different sizes and had different content. So I copied the files from the installations that had calculated the "correct" route into the installation with the "wrong" routes. Suddenly it worked there too. Somehow, with the same software version and the same data versions and identical settings, different profile files appear to be created, which then lead to different results, as they apparently provide the parameters for the route to be calculated. My impression is that there is some kind of error here. I can't explain it any other way. |
Beta Was this translation helpful? Give feedback.
-
OK, I can see that Android is problematic in many places. But if I want to go out of the front door to the neighbor on the right and a routing app directs me around the entire block to the left because something has been changed in the profile, then that is a problem. It gets even more absurd if the second device does it completely differently... navigation becomes a bit of a random game of chance. You'll get there, no question about it, but it's not ideal. It doesn't make much sense to allow profile settings if Android then takes on a life of its own. Control via parameters is one of brouter's strengths. Perhaps the standard profiles should be permanently integrated into the software and only user-controlled deviations should be saved, which are then read in again when the device is started. Or have I completely misunderstood the problem? In any case, my observation is that after installation on different devices, the 7 profiles [X].json have different content (e.g. bike 3.json) and lead to different results. If I then copy the file from a device that routes "correctly" to a device that routes "incorrectly", it suddenly works. But I haven't changed anything myself and can't control it at all. Just take a look at the 7 profiles [X].json after a new installation on different devices. Pedestrians and cars should be fairly unproblematic, but with "mixed" requirements such as with a bicycle, it quickly becomes problematic. Just test bicycle navigation in an environment that you are familiar with (whether GH or BR). Maybe you can then understand the problem. Maybe I'm just too stupid to use the app properly. |
Beta Was this translation helpful? Give feedback.
-
Out of 5 devices, it works perfectly on 3. 2 devices produce meaningless routes with offline data for Graphhopper and brouter. Of course, I first compared the settings in the app, because identical settings should lead to identical results. But there was no difference. I then reset the profile, deleted the cache, then deleted the data, then uninstalled the app and reinstalled it completely and tested at each stepp. Two devices (Honor Magic 5 Pro / Android 14 and Samsung Tab S5e / Android 9) are causing errors, with Graphhopper offline and brouter offline, for which I simply have no explanation. Does anyone have an idea? Could it be the Android? Could it be that there are still remnants of old installations in directories that you don't have access to, which are now causing problems? |
Beta Was this translation helpful? Give feedback.
-
You can clearly see that other routes are being chosen. To get 10m further, the app drives around the entire block. As if it were a one-way street. The results are reproducible. It always uses Graphhopper / brouter (both offline). Maps and data from the same day. Settings identical. Even if I change the settings in brouter, it stays the same. Profile reset, cache deleted, data deleted, app deleted... everything new... it stays the same. Somehow the app passes parameters to the engine that I have no influence over, the engine is acting up... no idea. I don't understand it at all. Hence my idea that with certain Android versions, there might not be files/data from old installation files/data lying around in the hidden installation directories that affect the process. |
Beta Was this translation helpful? Give feedback.
-
OK, I'll test whether that was the problem. But I don't think the rule really makes sense. If, for example, I'm planning a holiday route to Spain from home in Germany, why should the direction of the location or the orientation on the display matter? But there may be situations where this is helpful. Perhaps it should be optional and switched off. Basically, you determine a route between two points. I would also like to be able to specify other parameters: shortest route, fastest route, etc. ... if the engine supports this. |
Beta Was this translation helpful? Give feedback.
-
We can disable routing direction in route planning to avoid confusion. |
Beta Was this translation helpful? Give feedback.
-
OK, I think I have it. I changed the location once and voila, everything is fine. As soon as the starting point is near the GPS location, there are problems. The difference in the devices may be due to the compass or satellite modules. I think the location consideration is a mistake: Navigation ALWAYS starts at the GPS location. Otherwise it is planning! The compass is far too inaccurate and the orientation of the map and the device is random. In my opinion, taking this into account only makes sense if you have lost your way and the route has to be recalculated. Even then the compass is unreliable and the orientation is random, because even if I am heading south I could be heading east, west or north at the moment (curves, connecting routes, etc.). Only the rough direction from the starting point or viewpoint to the destination could be used to avoid calculating all possible routes. Basically, you can only use the GPS position for this, everything else (compass, orientation of the map ...) is not useful. |
Beta Was this translation helpful? Give feedback.
@Boomer4722
GraphHopper (offline) routing data have all been recreated.