New case of RouteNotFound Exception

[alecava58]

Hi Ben,

I have another case:

        var lat = new double[] { 46.055325100000, 46.460682300000 };
        var lon = new double[] { 11.234153100000, 11.705468600000 };

I think the problem is the second coordinates

TryResolveConnect with default parameter fails TryResolveConnect with radiusInMeter: 2000, maxSearchDistance: 1000 is Ok

but router.Calculate fails with RouteNotFound Exception

[alecava58]

More details.

the TryResolveConnect with radiusInMeter: 2000, maxSearchDistance: 1000 resolves the coordinates lat=46.460682300000 and lng=11.705468600000 to lat=46.46298 and lng=11.7050238 those coordinates are far from the route.

[sergn-n]

Many RouteNotFoundException when TryCalculate on contracted db. It runs OK on non-contracted db. See gist https://gist.github.com/sergn-n/ebe8a15a1fc61af2de64501e7a6d1f57

[alecava58]

I saw this behavior too. But for the moment my focus is on not contracted.

[xivk]

I recently fixed an issue releated to this, you need to re-contract and should see improvement.

[alecava58]

I still have this error. I'm not using contracted db.

[xivk]

Probably also due to https://github.com/itinero/routing/issues/96

[xivk]

This is special case, I finally managed to figure it out but the fix is not so simple. Anyway, the problem is that the routerpoint is snapping to this way:

http://www.openstreetmap.org/way/176540565

And then it start searching for connectivity to the rest of the network and it can find a prettly long and big part of the network that is accessible but still not connected to the rest of the network. The search stops too soon and Itinero things it's connected and routable. This give you an idea of the island Itinero finds:

http://geojson.io/#id=gist:anonymous/1162fa5f3b0e940342782f30a11749cb&map=15/46.4672/11.7114

When you set the search parameter very high it will give this route, so that works:

http://geojson.io/#id=gist:anonymous/8ce88eb7b1fe13548c48864f58ea9ec7&map=11/46.2399/11.4234

I have implemented a solution in the past to remove islands from the network at the preprocessing stage, still supported but not enabled by default:

https://github.com/itinero/routing/blob/develop/src/Itinero/Algorithms/Networks/Islands/IslandDetector.cs

But that's not the whole solution because it won't be able to remove everything when the routerdb contains more profiles. Something else needs to be figured out here, probably marking ways that are part of a routing island per profile to make things really rock solid. I'm going to open a new issue for this.

A solution could be for now to remove "track" from the car profile, most of the time it's not supposed to be there anyway or you could, when a route fails, try and resolve again with an every increasing search radius.

[alecava58]

Thanks for the detailed answer. I'll remove track from the profile, I don't need track. If this solution doesn't work I'll try with increasing radius.

2017-06-13 20:05 GMT+02:00 Ben Abelshausen notifications@github.com:

This is special case, I finally managed to figure it out but the fix is not so simple. Anyway, the problem is that the routerpoint is snapping to this way:

http://www.openstreetmap.org/way/176540565

And then it start searching for connectivity to the rest of the network and it can find a prettly long and big part of the network that is accessible but still not connected to the rest of the network. The search stops too soon and Itinero things it's connected and routable. This give you an idea of the island Itinero finds:

http://geojson.io/#id=gist:anonymous/1162fa5f3b0e940342782f30a11749 cb&map=15/46.4672/11.7114

When you set the search parameter very high it will give this route, so that works:

http://geojson.io/#id=gist:anonymous/8ce88eb7b1fe13548c48864f58ea9e c7&map=11/46.2399/11.4234

I have implemented a solution in the past to remove islands from the network at the preprocessing stage, still supported but not enabled by default:

https://github.com/itinero/routing/blob/develop/src/ Itinero/Algorithms/Networks/Islands/IslandDetector.cs

But that's not the whole solution because it won't be able to remove everything when the routerdb contains more profiles. Something else needs to be figured out here, probably marking ways that are part of a routing island per profile to make things really rock solid. I'm going to open a new issue for this.

A solution could be for now to remove "track" from the car profile, most of the time it's not supposed to be there anyway or you could, when a route fails, try and resolve again with an every increasing search radius.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/itinero/routing/issues/85#issuecomment-308200489, or mute the thread https://github.com/notifications/unsubscribe-auth/ABtMQZEj4Gdrn0gN756Rslzaz_c7-iqGks5sDs-EgaJpZM4MXvGc .

-- Alessandro Cavalieri

[alecava58]

I tried to remove track from car profile this way: -- default access values access_values = { ["private"] = true, ["track"] = false, ["yes"] = true, ["no"] = false, ["permissive"] = true, ["destination"] = true, ["customers"] = false, ["designated"] = true, ["public"] = true, ["delivery"] = true, ["use_sidepath"] = false }

But without success.

Note: I didn't rebuild the routing db, I only change the profile e make new calculation, should I rebuild?

2017-06-13 21:46 GMT+02:00 Alessandro Cavalieri < alessandro@cavalieriinformatica.it>:

Thanks for the detailed answer. I'll remove track from the profile, I don't need track. If this solution doesn't work I'll try with increasing radius.

2017-06-13 20:05 GMT+02:00 Ben Abelshausen notifications@github.com:

This is special case, I finally managed to figure it out but the fix is not so simple. Anyway, the problem is that the routerpoint is snapping to this way:

http://www.openstreetmap.org/way/176540565

And then it start searching for connectivity to the rest of the network and it can find a prettly long and big part of the network that is accessible but still not connected to the rest of the network. The search stops too soon and Itinero things it's connected and routable. This give you an idea of the island Itinero finds:

http://geojson.io/#id=gist:anonymous/1162fa5f3b0e940342782f3 0a11749cb&map=15/46.4672/11.7114

When you set the search parameter very high it will give this route, so that works:

http://geojson.io/#id=gist:anonymous/8ce88eb7b1fe13548c48864 f58ea9ec7&map=11/46.2399/11.4234

I have implemented a solution in the past to remove islands from the network at the preprocessing stage, still supported but not enabled by default:

https://github.com/itinero/routing/blob/develop/src/Itinero/ Algorithms/Networks/Islands/IslandDetector.cs

But that's not the whole solution because it won't be able to remove everything when the routerdb contains more profiles. Something else needs to be figured out here, probably marking ways that are part of a routing island per profile to make things really rock solid. I'm going to open a new issue for this.

A solution could be for now to remove "track" from the car profile, most of the time it's not supposed to be there anyway or you could, when a route fails, try and resolve again with an every increasing search radius.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/itinero/routing/issues/85#issuecomment-308200489, or mute the thread https://github.com/notifications/unsubscribe-auth/ABtMQZEj4Gdrn0gN756Rslzaz_c7-iqGks5sDs-EgaJpZM4MXvGc .

-- Alessandro Cavalieri

-- Alessandro Cavalieri

[xivk]

Yes, you should probably rebuild... how are using the profile?

[alecava58]

I'm rebuilding the routing db.

I'm not using the router db embedded profile, I'm loading the profile from car lua file

                var vehicleFile = new FileInfo(args[1]);
                using (var stream = vehicleFile.OpenRead())
                {
                    localVehicle =

DynamicVehicle.LoadFromStream(stream); localVehicle.Register(); }

is this ok?

2017-06-29 11:26 GMT+02:00 Ben Abelshausen notifications@github.com:

Yes, you should probably rebuild... how are using the profile?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/itinero/routing/issues/85#issuecomment-311912614, or mute the thread https://github.com/notifications/unsubscribe-auth/ABtMQVHT6SYzYsiUXsmzGYVVLS8kvhgfks5sI226gaJpZM4MXvGc .

-- Alessandro Cavalieri

[alecava58]

Confirm solved rebuildeing not contracted router db. I'll try with contracted one.