Bug Web App: veer wordt niet goed meegenomen in gpx
-
I created a 355km route on OSM which was enhanced to 199 soft/shaping points.
Checking the route against HERE and TomTom did not reveal any issues in difference of routing.
I exported the route as a gpx1.1 (Track, POI), which contains about 7000 gpx points (20 points/km, a point every 50m).The route contains a ferry over the Rine river at Bad Breisig. I deliberately added two points at both banks of the river and mark No. 192 (see picture) as Skip (Overslaan), the "old" way of telling to ingnore the map and draw a straightline from point.
Now I send the gpx to the participants, which he import as a Route-Track..
User can use the gpx to export to his GPS device, leaving the claculation to the GPS (and its map, setup, OS version etc).Opening the gpx in MRA for editing, and using the HERE MAP creates a different route! It ignores the ferry and heads for a bridge further down the Rhine.
And there are more differences.First thought is that RMA does not import all the gpx track points.
The reason I imported the exported gpx in RMA again is to see if there are any unpaved roads in it. This cannot be done at the OSM map as soon as Segments are used.
Can you tell me what is best practice?
- Create route at OSM incl Segments.
- Compare to TT and HERE.
- Export to GPX for participants.
- How to check for Unpaved roads?
@Gerard-Wullink The isn't with MRA itself, but with the HERE map, which doesn't like to route over ferry's for some reason. The work-around is to set a routepoint on both sides of the crossing and then set the one on the "far" side to "Skip".
-
@Gerard-Wullink The isn't with MRA itself, but with the HERE map, which doesn't like to route over ferry's for some reason. The work-around is to set a routepoint on both sides of the crossing and then set the one on the "far" side to "Skip".
@Herko-ter-Horst said in Bug Web App: veer wordt niet goed meegenomen in gpx:
the HERE map, which doesn't like to route over ferry's for some reason
The speed of a ferry is unknown (and often relatively slow) . I guess that for the route calculaiton, making a detour is always faster than taking the ferry?
It is not difficult, it is easy, it's a hobby
-
@Herko-ter-Horst said in Bug Web App: veer wordt niet goed meegenomen in gpx:
the HERE map, which doesn't like to route over ferry's for some reason
The speed of a ferry is unknown (and often relatively slow) . I guess that for the route calculaiton, making a detour is always faster than taking the ferry?
@Drabslab spot on
Within the very near future we will support "shortest" routing too which is perfect for these situations. Then HERE will prefer the shorter distance (and thus the ferry). For small ferries, no scheduling information is available, causing the travel time to become infinite - then a detour will by definition be faster, no matter how long the detour is
-
@Herko-ter-Horst said in Bug Web App: veer wordt niet goed meegenomen in gpx:
the HERE map, which doesn't like to route over ferry's for some reason
The speed of a ferry is unknown (and often relatively slow) . I guess that for the route calculaiton, making a detour is always faster than taking the ferry?
@Drabslab Except of course it really isn't, at least not for the river crossing ferries in the Netherlands and Germany. In my experience, a crossing (+wait) rarely takes more than 10-15 minutes . Yes, you could be unlucky and see the ferry depart just as you arrive, which means a 15-20 minute wait + a 5-10 minute crossing. But even then it's hardly worth doing a potential 20 km(or more) round trip to use a bridge. Also, if this was the really the case, why do none of the other navigation options in MRA or Google do the same? Do they have information HERE doesn't? To me, this is one of the most annoying aspects of HERE.
-
@Drabslab spot on
Within the very near future we will support "shortest" routing too which is perfect for these situations. Then HERE will prefer the shorter distance (and thus the ferry). For small ferries, no scheduling information is available, causing the travel time to become infinite - then a detour will by definition be faster, no matter how long the detour is
@Corjan-Meijerink "Shortest" routing may work fine in this specific situation, but in most other situation it can be very annoying. For example, on motorways it may take you off and back on the motorway at an exit just to save 10 meters. And in towns it will send you through 30 km zones with dozens of speed bumps instead of around on the main road to save 500m, but adding 5-10 minutes of annoying driving in the process.
I can't see many situations (other than this specific one to work around a defect in HERE's algorithm) in which "shortest" routing is useful.
-
@Corjan-Meijerink "Shortest" routing may work fine in this specific situation, but in most other situation it can be very annoying. For example, on motorways it may take you off and back on the motorway at an exit just to save 10 meters. And in towns it will send you through 30 km zones with dozens of speed bumps instead of around on the main road to save 500m, but adding 5-10 minutes of annoying driving in the process.
I can't see many situations (other than this specific one to work around a defect in HERE's algorithm) in which "shortest" routing is useful.
@Herko-ter-Horst "shortest" routing is more intelligent than just that
It does make certain tradeoffs.Route calculation from start to destination disregarding any speed information. In this mode, the distance of the route is minimized, while keeping the route sensible. This includes, for example, penalizing turns. Because of that, the resulting route will not necessarily be the one with minimal distance.
Meaning that
@Herko-ter-Horst said in Bug Web App: veer wordt niet goed meegenomen in gpx:
on motorways it may take you off and back on the motorway at an exit just to save 10 meters
should not occur
-
@Herko-ter-Horst "shortest" routing is more intelligent than just that
It does make certain tradeoffs.Route calculation from start to destination disregarding any speed information. In this mode, the distance of the route is minimized, while keeping the route sensible. This includes, for example, penalizing turns. Because of that, the resulting route will not necessarily be the one with minimal distance.
Meaning that
@Herko-ter-Horst said in Bug Web App: veer wordt niet goed meegenomen in gpx:
on motorways it may take you off and back on the motorway at an exit just to save 10 meters
should not occur
@Corjan-Meijerink said in Bug Web App: veer wordt niet goed meegenomen in gpx:
should not occur
I should be able to find back a practical example where this did occur (but before Next).
A river with a road on both sides, and regular bridges crossing it. Depending on the meandering of the river, the navigation sent me over each bridge
but there will always be exceptions where the automated calcualtions don't work. That is why the human effort preparing and planning the route remains important (thank the gods for that
). -
@Drabslab agree. Do not that MRA has not ever yet supported "shortest" mode - so all MRA related examples will be fastest by default.
@Herko-ter-Horst Fun thing to now, TomTom actually has another mode: "short". So their "shortest" mode is just as HERE - tries to keep a sensible.
Their "short" mode however enforces shortest distances over sensible roads.shortest: Route calculation is optimized by travel distance, while keeping the routes sensible. For example, straight routes are preferred over those incurring turns.
short: Route calculation is optimized such that a good compromise between small travel time and short travel distance is achieved.
-
undefined Hans van de Ven MR.MRA moved this topic from General Discussion on
-
@Drabslab agree. Do not that MRA has not ever yet supported "shortest" mode - so all MRA related examples will be fastest by default.
@Herko-ter-Horst Fun thing to now, TomTom actually has another mode: "short". So their "shortest" mode is just as HERE - tries to keep a sensible.
Their "short" mode however enforces shortest distances over sensible roads.shortest: Route calculation is optimized by travel distance, while keeping the routes sensible. For example, straight routes are preferred over those incurring turns.
short: Route calculation is optimized such that a good compromise between small travel time and short travel distance is achieved.
@Corjan-Meijerink Suggestion: it would be cool if we could mix the different preferences (fastest, shortest (, offroad)) in 1 route. That is also possible in Basecamp
Then we only have to set it to “shortest” at the crossing and we can leave the rest of the route on “fastest”. -
@Gerard-Wullink The isn't with MRA itself, but with the HERE map, which doesn't like to route over ferry's for some reason. The work-around is to set a routepoint on both sides of the crossing and then set the one on the "far" side to "Skip".
@Herko-ter-Horst "I deliberately added two points at both banks of the river and mark No. 192 (see picture) as Skip (Overslaan)". That what youn mean or am I wrong?
-
@Herko-ter-Horst "I deliberately added two points at both banks of the river and mark No. 192 (see picture) as Skip (Overslaan)". That what youn mean or am I wrong?
@Gerard-Wullink said in Bug Web App: veer wordt niet goed meegenomen in gpx:
@Herko-ter-Horst "I deliberately added two points at both banks of the river and mark No. 192 (see picture) as Skip (Overslaan)". That what youn mean or am I wrong?
Still the routing goes over the bridge....
-
@Gerard-Wullink
That's correct unfortunately.
The "Skip" is only functional in the planner not in Navigation.
