Profiles and contracts

[kevin-work]

• What does passing in profiles to LoadOsmData() do?
• Can adding a contract cause resolving to fail that could otherwise be normally resolved if there wasn't a contract?

I had some points that could not be resolved and I checked on Google Maps but they didn't appear to be too far from a road. What options would I need to get the least amount of non resolvable points? Not passing in any profiles and contracts?

Are there any options to absolutely force a resolve?

[xivk]

Resolving points is independant of contracted graphs so should not have any effect. Passing the profiles makes sure that only ways for those profiles are loaded, so make sure to load the data with at least the profiles you plan on using later.

You can add an extra parameter to the resolve call to increase the distance it will search for nearby roads.

[kevin-work]

• So what is the point of a contracted graph?
• When you resolve, you pass in profile(s). What does this do? I didn't think resolving needs to know about that.

[xivk]

The point of a contracted graph is routing optimization, resolving is just the process of converting a lat/lon to the closest edge. Routing will calculate an actual route.

When there is a cyclepath you would want to start there or when you have a pedestrian you should not start on a motorway. When you load only data for one profile then you are right, but when there are multiple profiles in one router db you need to resolve using a predefined profile. You can also pass in multiple profiles for example to change vehicles at a given location.

[xivk]

I appreciate your curiosity but we have thought this through you know... :-)

[kevin-work]

Oh I'm not questioning your decisions. I'm just trying to get my head around the code as the Wiki is quite limited so that I know that I am writing the correct code for what I need.

I think I understand profiles now...

Since contracted graphs are for calculating a route, if I add a specific contract e.g. Car.Fastest, will calculation for Car.Shortest fail?

[xivk]

Routing for Car.Shortest will not fail, it will just be slower...

[kevin-work]

Thanks very much. I appreciate your clarification. I think that's all I have for now.

[xivk]

Sure, also, suggestions to improve the docs are also welcome!

[kevin-work]

I have come up with a few more questions. You listed a few routing algorithms in the Wiki. Can you override this? If so what is the default?

Also what is the difference between the edge-based and non edge-based algorithms?

[xivk]

The router will use the best algorithm per request depending on profiles and what's there in the router db. This means using contraction hierarchies when they are there for a profile.

By including a contracted version for a profile the router will find it and use it, or you can leave it out and it will use regular dykstra based routing... you can also have a look at the internal code of the router and use the specific implementations for your usecase but that means getting to know the internals and reasons behind the algorithms.

Edge based routing is needed to properly support turn restrictions and, in the future, turning weights. Vertex based routing can't handle turn restrictions properly but is a bit faster and can still be used for bicycle/pedetrian routing.

[kevin-work]

I see okay. I think the information on why use and what effects the contracts have would be a good addition to the Wiki.

[alecava58]

I experienced the same behaviour: if I use a not contracted db the routing is ok, if I use a contracted db I often receive a message like this "Cannot build vertex path, edge 1146398 -> 1146356 not found". In this case if I move slightly one of the two points the routing will be ok. In your first answer you said "You can add an extra parameter to the resolve call to increase the distance it will search for nearby roads.". This "extra parameter" is already there? if yes, how could I use on routing?

[xivk]

I managed to reproduce the 'edge () not found' issue, see #21 also. Working on tracking down the problem and a fix.

The extra parameter is there already:

https://github.com/itinero/routing/blob/develop/src/Itinero/RouterBaseExtensions.cs#L180

Use the search distance in meter parameter.

[xivk]

21 is fixed now... can you confirm this also fixed the issue you are having here?

[alecava58]

Hi Ben,

must I rebuild the routerDB?

2016-10-26 12:11 GMT+02:00 Ben Abelshausen notifications@github.com:

21 https://github.com/itinero/routing/issues/21 is fixed now... can

you confirm this also fixed the issue you are having here?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/itinero/routing/issues/25#issuecomment-256305271, or mute the thread https://github.com/notifications/unsubscribe-auth/ABtMQYo16bfOVpZgXncK__K-4sWKCye6ks5q3yc3gaJpZM4KQ3r0 .

Alessandro Cavalieri

[xivk]

No should be fine without...

[alecava58]

Did you update the nuget or do I rebuild the project on my pc?

2016-10-27 10:13 GMT+02:00 Ben Abelshausen notifications@github.com:

No should be fine without...

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

Alessandro Cavalieri

[xivk]

Nuget should be updated.

[alecava58]

This issue is fixed for me. Thanks.