Identical custom weighting profile - different results for CH vs flex

[ozzik]

Hi,
Using GraphHoper for a custom sea mesh and really like it. Ran into a strange problem though, since the introduction of custom weighting started playing with this feature using flex box to block certain areas ie. Panama Canal.

When in flexible mode and using the custom model to block Panama Canal, everything is perfect, getting route around South America.
However when using exactly same custom weighting model under a CH profile, result is totally different (route over Pacific that is 2-3 times longer).

Any idea why it would happen.

Screenshots below:

Model:

priority:
  area_canal: 0

areas:
  canal: 
     { "type": "Feature", "properties": {},
       "geometry": { 
         "type": "Polygon", 
         "coordinates":  
          [[
            [
              -79.89395141601562,
              8.970540802815867
            ],
            [
              -79.51766967773438,
              8.970540802815867
            ],
            [
              -79.51766967773438,
              9.355577767181513
            ],
            [
              -79.89395141601562,
              9.355577767181513
            ],
            [
              -79.89395141601562,
              8.970540802815867
            ]
          ]]        
       }
    }

[easbar]

Well now imagine you are in this situation and cannot use the Panama Canal
Actually I am more surprised that you do not get an error than the fact that you get another route, because the flex box is not supported/should not work with CH

[ozzik]

Maybe was not precise, used the flex box only for experiments with a CH-disabled profile, once satisfied with the results, moved it to custom_model_file under CH-enabled profile.

New profile (without flex box as indeed it gives an error) returns a different route.

[easbar]

Ah ok. Hm yes this should of course work. Could you share your config.yml, GH version and used OSM file?

[ozzik]

Sure, many thanks.

GH version: 1.0

https://ozzik-folder.s3.eu-central-1.amazonaws.com/Archive.zip

[easbar]

I am afraid you are breaking into new territory here with this kind of application (sea routing).
First there are quite a few errors like this:

2020-09-17 20:03:19.357 [main] WARN  com.graphhopper.reader.osm.OSMReader - Bug in OSM or GraphHopper. Too big tower node distance 3204972.1735441475 reset to large value, osm way -1816

To get rid of this you should consider splitting long route segments into multiple smaller ones.

Maybe it also helps to visualize the (sea)route network created by graphhopper (using the ‘LocalMVT’ checkbox in the map’s layer menu), but for this we would have to enable it at low zoom levels: https://github.com/graphhopper/graphhopper/issues/2129

With CH you will probably also run into the problem that ‘shortcuts’ (these are helper edges that combine multiple segments of a route into one) get too long. There is a 30bit limit currently, but maybe you can workaround this by using larger distance unit (default is meters). https://github.com/graphhopper/graphhopper/issues/1544, https://github.com/graphhopper/graphhopper/issues/1688, https://github.com/graphhopper/graphhopper/issues/1663

[ozzik]

This is a great help, will come back once have some findings.