Closed 0709wiwiwi closed 3 months ago
The link works fine, but I don't know what the issue is:
Both times the start marker is on the same OSM way: https://www.openstreetmap.org/way/31462380
Another case discussed here: https://github.com/devemux86/cruiser/discussions/205
In this case @poutnikl CarProfiles seem to work.
In this case @poutnikl CarProfiles seem to work.
That is funny, as I consider them obsolete, not updating them for years, because of the internal kinematic model, developed by @abrensch for his car profiles. OTOH, they can be used as a fallback in case something goes wrong in recent development.
We have two problems around this discussion - all depend on the large distances in this area.
based on the sample above: car-eco not work
: route link
The routing process doesn't complete.. It is trying to find a route again and again. At the end a runout of points. So you have the message 'from-position not mapped ...'
if (inRadius && (isFinalLink || bestPath.cost + bestPath.airdistance <= maxTotalCost + 100)) {
at RoutingEngine line is the breaker. The constant of 100 is to small in this case.
There is an other maxTotalCost + 100
in line
I would like to set this constant to waypointCatchingRange
(default 250)
The second is base on this sample . A really 'from-position not mapped' problem, the point is not found.
The area shows the searching area for this from
point and the way segments around. Bouter also have a look in the eight areas around. But as you can see the top left point is not in that range. So there is no way segment for this point.
This is a general problem with ares like this that was planned with a ruler.
I thought there might be a way to generate pseudo points. But for the tile generation process, this means checking all distances of all points. Might be a bit time consuming.
I would like to set this constant to
waypointCatchingRange
(default 250)
:+1:
I thought there might be a way to generate pseudo points. But for the tile generation process, this means checking all distances of all points. Might be a bit time consuming.
At this Stage in preprocessing there's already douglas-peuker Elimination for Points that are too dense, so doing the opposite Here should be similar in Processing cost
Another BRouter example reported here: https://github.com/devemux86/cruiser/discussions/227#discussioncomment-6328482 (we see several failed routes even with waypoints exactly on road network)
I can reproduce the report with a small BRouter route:
assign waypointCatchingRange = 2000
@abrensch douglas-peuker routine was a great idea. I got it runnung to add some points. But still not finding the 'from' point. I will go on deeper.
Ja Not so easy. It does not Help to add it as a "Transfer node". It need to become a Network node, located in the Micro tile that does Not have one yet.
@abrensch
Yes, I think so. At the moment I'm back to standard rd5. Not all options done here.
The points showing the area BRouter is searching for. I doesn't enter a square North of from position.
I make tests with fallback to get all the 8 blue areas around.
Did only two of the ideas for a merge. The samples above will work with this but I'm sure we will find more/other samples.
But I'm pausing here to add this to the necessary new APK.
What is wrong ?
https://youtu.be/G82JGCHp6NE
https://bikerouter.de/#map=13/24.3099/43.5004/standard&lonlats=43.501697,24.327877;43.508218,24.321775 or https://t.ly/eVEy
brouter_beeline.gpx.txt
Compare:
Cruiser_GH_routing.gpx.txt