Errors in GraphHopper profiles and menu control?

[Boomer4722]

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.

[devemux86]

@Boomer4722 thanks for the report.

GraphHopper Offline Data

There was an problem in the latest GraphHopper data and they only contain the car.
We will update them and they will work properly again with all profiles.

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.

• "Extended settings" option displays more options in all app settings (not menu).
• "Extended menu" option displays more options in the map menu.

Can you post some screenshots to understand what you mean?

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?

Offline POI are used in offline search and nearby POI in navigation.
What do you mean with offline POI in the maps menu?

[Boomer4722]

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

[Boomer4722]

Thank you for the information. I had already loaded the brouter data and experimented with the parameters. I never get the route that local drivers would use. GraphHopper does it this way. But it might be a coincidence...

[devemux86]

@Boomer4722 what profile, car, motorcycle, bike, walking?

It really depends on the selected routing options.

[Boomer4722]

bike

[Boomer4722]

I found the error. OSM recently allowed a bridge for pedestrians only, but that is not true. Because of this error, you have to take a big detour. I edited it.

Wouldn't it be an option to restore the old GraphHopper files until the new ones are created?

[devemux86]

Wouldn't it be an option to restore the old GraphHopper files until the new ones are created?

@Boomer4722 unfortunately this is not possible.

[devemux86]

@Boomer4722

GraphHopper (offline) routing data have all been recreated.

[Boomer4722]

thx

[Boomer4722]

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

[Boomer4722]

pictures delete

[Boomer4722]

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".

[Boomer4722]

The route by car is OK!

Compare picture 2 with the one in the attachment!

There is a fundamental error somewhere!

pictures delete

[devemux86]

It is recommended to switch to BRouter (offline).
Its routing data are updated daily and we can check more easily the routing. 🙂

GraphHopper offline vs online use different engines, so the results may be different.
GraphHopper offline isn't supported anymore, so I don't know if it's worth keeping it in Cruiser.

[Boomer4722]

OK i try BRouter (offline) again.

[Boomer4722]

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.

[0709wiwiwi]

This is already available, we can freely create copies of app profiles
for testing with app interface.

That's how it is in theory, but in practice no such thing happens and you
fall into the trap all too quickly anyway.

[devemux86]

This how Android settings work: make changes, Android saves them.
If want to make tests, create a copy of any profile and use it for tests.

See the main Android settings, it certainly does not ask anywhere to save the changes!

[devemux86]

@0709wiwiwi you already suggested elsewhere this idea.
I answered that it is difficult to rewrite how Android works.

We have many important features that are needed by all users.

Very advanced features, especially if Android does not allows them,
are suitable for winter nights when our todo list is empty. 🙂

[MotoUKRider]

The behaviour that @0709wiwiwi suggests is expected (if not mildly frustrating). Like anything with a "profile", you make changes within it and that's what you're left with. If you open your house door with your key and re-arrange the furniture - the neighbour's house is unaffected.

I agree to some level that the process has become "messy", and it could perhaps be offered in a more tidy style to the user, but what's being suggested is a caveat that "if you change a setting, a setting will be changed" - that should be obvious, no?!

[devemux86]

It is not necessary to use profiles: open app, select vehicle, change settings and use it.

Most apps do not have profiles, they just have global settings.
We change the app settings, they are saved and used immediately.

This is how Android and all Android apps work from the beginning.

[Boomer4722]

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.

[devemux86]

@Boomer4722

Routing is the same if we use the same options. And options do not change unless we change them.

You can also easily check it without the need to open any files.
Compare the options in app settings: same options calculate the same route.

Similarly in BRouter website: if we see different results in 2 same routes,
then we have used different routing options in the website.

[devemux86]

@Boomer4722

Or have I completely misunderstood the problem?

If you want to transfer something, never copy the files,
but use the app interface and export / import functions.

[Boomer4722]

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?

[devemux86]

What errors?

Do you use internal BRouter in Cruiser or external BRouter app?
(default is internal BRouter)

Same profile type and same routing options produce same routes.
This simply cannot be different.

Perhaps you can provide a route example?
And screenshots of the routing options in the 2 different devices.

[Boomer4722]

delete

[devemux86]

Calculation result is stable uniform.

Route calculation depends on routing options. One of them in all routers is start direction.

Start direction is mandatory in navigation rerouting. Question is if we also want it in route planning.

Press navigation arrow > Cruiser asks where to ?

This is already available:

• Navigation button without route #64

[0709wiwiwi]

Wow, I hadn't even noticed that. I had already become so used to the previous Cruiser versions method that I not even tested it again later ;-)

[MotoUKRider]

@devemux86

Start direction of route is required in rerouting in navigation.
We could disable it in normal route planning if you like.

It may be an essential consideration if you have (or place) the start point on a particular side of a dual-carriageway where a U-turn is not possible, but any other road, I think, should plot the most direct route (within the rules) unless/until the direction of travel reaches the threshold for a re-route.

Of course, oneway tags are obeyed so dual-carriageways and complex town networks may cause you to take a longer route, but unless the road properties say otherwise, I think a U-turn is allowed here.

Disclaimer: Sat-nav is no substitute for looking at road-signs and using common-sense in these scenarios!

[Boomer4722]

The OSM data does contain one-way streets, so these are taken into account. If this were not the case, the calculation based on the orientation would lead the route in the opposite direction to a one-way street. In my opinion, the general direction of the destination should only be used for quick recalculations and not for planning.

[devemux86]

If this were not the case, the calculation based on the orientation would lead the route in the opposite direction to a one-way street.

Naturally this does not happen, oneways are always considered.

[Boomer4722]

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.

[devemux86]

Τhere are no unexplained things in all software, only maybe in the 3D graphics! 🙂

@Boomer4722 see my answer above.

[Boomer4722]

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.

[devemux86]

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?

Please check my comment:

When user location is at or near start waypoint, then the location heading is used as start direction for the route.

If you are planning a route in Spain from Germany, then the route start is in Spain and GPS location in Germany.

[devemux86]

We can disable routing direction in route planning to avoid confusion.

[Boomer4722]

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.

[devemux86]

@Boomer4722 you are right, the location heading will no longer be involved in route planning.

It will remain in navigation as it works now.

[Boomer4722]

thx