Strange behavior when custom weighting

Hi!

I’m trying to building a route
https://graphhopper.com/maps/?point=51.549751%2C128.309326&point=48.210032%2C135.087891&locale=en-US&elevation=true&profile=car&use_miles=false&selected_detail=Elevation&layer=Omniscale

  1. Looks good here:

778km will take 8h 46min

  1. But if enable custom weighting even empty, then it’s not logical to routing:

1466km will take 1d 8h

What could be the problem?

This looks very wrong. Will investigate.

1 Like

I was not able to reproduce this locally with a more recent version and so I updated the currently used older version for this cluster. This new version also contains some unrelated bug fixes to the custom weighting.

If you observe something similar with this more recent version - please let me know and we will immediately investigate as this looked very suspicious and should never happen. (time and distance of the preferred route was longer and on this route there were no destination access roads so priority did also not influence the choice - weird)

Thanks for your answer! Unfortunately nothing has changed for me:

@karussell i think this might be related to landmarks.

Our splitting:

The routing with a few intermediates:

Note the huge detour from intermediate point 2 to the destination.

Executed using a completely empty custom weighting: {}

2 Likes

@IldarKhayrutdinov yes, I did something wrong yesterday. It is still the same problem. Also I can now reproduce this locally.

@otbutz thanks! Indeed, if I disable LM everything is fine.

1 Like

Isn’t this by design? According to our docs:

Currently we limit routing requests using the landmark algorithm, then it is not possible to cross the borders between EU, Africa, and Asia. All other algorithms are not affected by this limitation.

With our splitting the route would need to leave and reenter Russia again.

@otbutz thanks for investigation!
@karussell I can prepare PR with boundaries correction

@otbutz Yes, indeed this is kind of expected. But it looks very wrong and worrisome :slight_smile:

Maybe we should use a higher precision for our split-boundaries in general, so that it works properly inside every country. Or we think again how to improve performance or memory usage for LM.

Agreed. Maybe we should take our countries.geojson as a basis and simplify it. That way we would also get rid of those nasty overlapping borders:

@karussell @otbutz
Definitely, the boundaries can be clarified, I would like to do it.
Should be considered, too precise boundaries (many points in polygon) are likely to slow down the map importing.

I think the easiest way would be to import our countries.gejson into something like QGIS and delete everything except for Russia, Turkey and Iran. Europe, Africa and the region around Indonesia/Papua New Guinea can be drawn by hand.

Such drastic measures would be very helpful!

Also, I want to add about the borders, in fact, quite a lot of traveling from Russia to EU (in terminology map.geo.json), this is problems when routing

It seems the problem is still reproducible. I can prepare a PR for border correction, do that?

Sure if you think the country borders can be improved send a PR. Also see this: https://github.com/graphhopper/graphhopper/issues/2394

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.