Isochrone Differences between self hosted ors and official ors

zacki41 · June 5, 2023, 7:14am

Dear ORS Team,

thanks for your valuable work. I am using a docker instance to allow isochrone for 3,8,12 mins driving distance car of 100 - 300 points (that come from openstreetmaps using overpass api), sometimes repeatedly in QGIS using the ORS tools plugin. I use a austria pbf file.

As shown in my web example (this qgis web client qgis 1:1 as the desktop version) when calculating the isochrones the two instances differ in some cases.
Examples:

in Kirchschlag bei Linz no isochrone is calculated at all from my self hosted instance. Transparenzlandkarte Rettungsdienst
in Linz Mengerstraße only a versy small polygon shape is created.
Transparenzlandkarte Rettungsdienst

Also, where do I have to put which file from the GHSL to also get the estimated coverage of population of the isochrones like in the official instance?

I would really appreciate help to solve this.
Greetings Florian

jschnell · June 5, 2023, 7:59am

Hey,

the two links you sent are a bit unclear, as there is a lot of information displayed on the map.

Could you provide the exact requests that you’re having trouble with, probably as a curl-command?

What version of the openrouterservice are you running self-hosted? Did you docker pull an image lately, or are you building the image yourself?

What version of the austria.osm.pbf-file are you using?

Best regards

zacki41 · June 5, 2023, 8:55am

Hey Joe,
wow you are fast - thanks. Here’s the screenshot. My docker container runs at http://rdtransparenz.zahorka.at:8080/ors/v2/status

This is the response when I create a isochrone from point and use the exact coordinates of Kirchschlag bei Linz

I am using the latest versions of both ors and austria

Sorry I don’t know how to create a curl command - even when reading examples here Dashboard | ORS - maybe you can help me out

Greetings Florian

jschnell · June 7, 2023, 6:53am

Hey,

the issue here is in the way that version 7 (available via the latest docker images) handles snapping and road barriers.

In both your cases, there’s a barrier=lift_gate on the road that your point would snap to.
Thus, from there on, no isochrone can be found.

If the gate allows vehicles to pass through, then that should be tagged accordingly.
If not, then the “outside” roads are not accessible to vehicles, so it correctly cannot route from there - although it still snaps to the road, since driving “inside” of the gate is still possible.

Best regards

zacki41 · June 7, 2023, 9:02am

Hey Jakob,

thanks for your reply. So if I understand correctly, I could use an older version of ors or change access priviledges in OSM (what would imply I need to modify set barrier=lift_gate (which now is called boom_barrier key: motor_vehicles to value yes or in the case of Kirchschlag I already created a driveway from the mainstreet to the building)
Is there a way I can extend the snapping radius to more meters or publicly accessible streets?
Since I am mapping ambulance isochrones that have all priviledges, would it be possible to grant access to all streets? What file or profile settings do I need for that?
Lastly as far as I understand ORS needs a pbf file , correct? Would it be possible or does it even make sense to use the Austrian GraphenIntegrationsPlattform File for Road Network which is a gpkg file https://www.data.gv.at/katalog/dataset/3fefc838-791d-4dde-975b-a4131a54e7c5?

Greetings Florian

zacki41 · June 19, 2023, 12:10pm

Hi again,

I managed to solve some of the cases as described by you @jschnell .
I found you already implemented a profile called emergency - is it usable with ORS Qgis Plugin or how and where can I change settings for the driving car profile to be able to access all roads in both directions ?

Greets Florian

amandus · June 20, 2023, 7:40am

Hi @zacki41,

You can couple the plugin with a self hosted instance, but if you managed to enable the emergency profile (i remember some other post here that does that) you would have to add the profile name to the list in the QGIS plugin locally as well, as we don’t include that in our official API.
That’s the place where you would have to add it in your local Plugin files.

github.com

GIScience/orstools-qgis-plugin/blob/main/ORStools/common/init.py

# -*- coding: utf-8 -*-
"""
/***************************************************************************
 ORStools
                                 A QGIS plugin
 QGIS client to query openrouteservice
                              -------------------
        begin                : 2017-02-01
        git sha              : $Format:%H$
        copyright            : (C) 2021 by HeiGIT gGmbH
        email                : support@openrouteservice.heigit.org
 ***************************************************************************/

 This plugin provides access to openrouteservice API functionalities
 (https://openrouteservice.org), developed and
 maintained by the openrouteservice team of HeiGIT gGmbH, Germany. By using
 this plugin you agree to the ORS terms of service
 (https://openrouteservice.org/terms-of-service/).

/***************************************************************************

This file has been truncated. show original

Afterwards you can add a provider for your local instance and choose the profile for your requests in the Plugin.

zacki41 · June 20, 2023, 6:26pm

Hey @amdandus,
thank you - your instructions to add the profile in ORS Qgis Plugin worked just fine.

For the other part:
As far as I understand I have to add a new profile in the ors-config.json called emergency. But from there on I receive errors.

 "profile-emergency": {
            "profiles": "driving-emergency",
            "parameters": {
              "encoder_flags_size": 8,
              "encoder_options": "turn_costs=true|block_fords=false|use_acceleration=true",
              "maximum_distance": 100000,
              "elevation": true,
              "maximum_snapping_radius":1000,
              "preparation": {
                "min_network_size": 2000,
                "min_one_way_network_size": 2000,
                "methods": {
                  "ch": {
                    "enabled": true,
                    "threads": 1,
                    "weightings": "fastest"
                  },
                  "lm": {
                    "enabled": false,
                    "threads": 1,
                    "weightings": "fastest,shortest",
                    "landmarks": 16
                  },
                  "core": {
                    "enabled": true,
                    "threads": 1,
                    "weightings": "fastest,shortest",
                    "landmarks": 64,
                    "lmsets": "highways;allow_all"
                  }
                }
              },
              "execution": {
                "methods": {
                  "lm": {
                    "active_landmarks": 6
                  },
                  "core": {
                    "disabling_allowed": true,
                    "active_landmarks": 6
                  }
                }
              },
              "ext_storages": {
                "WayCategory": {},
                "HeavyVehicle": {},
                "WaySurfaceType": {},
                "RoadAccessRestrictions": {
                  "use_for_warnings": true
                }
              }
            }
          },

[quote="amandus, post:7, topic:4931"]
n your
[/quote]

Here’s what I get back in the docker log

error: emergency$average_speed: value for reverse direction would overwrite forward direction. Enable storeTwoDirections for this EncodedValue or don’t use setReverse

Is there a sample emergency profile that I can add instead of copy paste the driving car one ?

Greetings Florian

amandus · June 22, 2023, 9:11am

The profile needs to exist in the code as well. Otherwise the config value won’t take any effect.
Take a look at:

zacki41 · June 22, 2023, 11:13am

Sorry again,
where and how exactly ?
In the EmergencyFlagEncoder.java ?

Sorry for my annoying question - I feel like I am very close but then again getting away from the solution again.
As far as I understand the EmergencyFlagEncoder.java is THE file to set all the parameters that are used for ischochrone calculations - correct? (so if I measure different average speeds I can change them in there and rebuild graphs in Docker)

Your help is very much appreciated.
Greetings Florian

Update: If I am not mistaken I need to follow these instructions, correct?

zacki41 · August 5, 2023, 7:15am

Hey @amandus,

I’m still stuck with adding the emergency profile.
What works? Adding any of the pre-existing profiles in the ors-config.json under routing - > profiles → active (eg. hgv, car etc.)
Next added only emergency & created a new profile driving-emergency based on hgv (see screenshot)

Afterwards docker-compose up returns this error:

5 Aug 07:13:09 ERROR [routing.RoutingProfileManager] - java.util.concurrent.ExecutionException: java.lang.RuntimeException: Couldn’t process file /home/ors/ors-core/data/osm_file.pbf, error: emergency$average_speed: value for reverse direction would overwrite forward direction. Enable storeTwoDirections for this EncodedValue or don’t use setReverse

What am I missing to add the emergency profile ?
Help is greatly appreciated!

amandus · August 7, 2023, 9:15am

Hi, check the Error lines at 07:13:09. There seems to be an issue with setting the average_speed for the emergency profile when building the graph.
There might have been some changes to the Flagencoder files in general, but not to the Emergency Flagencoder (as it is not actively used) which you might need to replicate.

Best compare it to the car or hgv Flagencoder, or look at the git history of those to see what changed.

Best regards

zacki41 · September 13, 2023, 6:55pm

Hey Amandus,

not getting anywhere near a solution. Compared the files at github Updated hgv and emergency vehicle profiles to gh 0.12 · GIScience/openrouteservice@eaf23ea · GitHub & had a friend who helped me look at changes.

I notice that the last change was around 4yrs ago, but do not find any hints that deal with the average_speed - could you once more help me get a little closer. thx

sascha · September 14, 2023, 7:56am

Hi @zacki41 ,

I noticed there are several unanswered questions in this thread, so I try to answer them one by one:

Lastly as far as I understand ORS needs a pbf file , correct? Would it be possible or does it even make sense to use the Austrian GraphenIntegrationsPlattform File for Road Network which is a gpkg file Intermodales Verkehrsreferenzsystem Österreich (GIP.at) Österreich - Datensatz - data.gv.at?

This is correct. If you want to use the file from GraphenIntegrationsPlattform, the easiest way is probably to transform it into a pbf file.

As far as I understand the EmergencyFlagEncoder.java is THE file to set all the parameters that are used for ischochrone calculations - correct? (so if I measure different average speeds I can change them in there and rebuild graphs in Docker)

Yes, this is the right file to look at. The flag encoder is responsible for interpreting the data in the pbf file and storing them in the ORS graph. Here you should be able to adjust the speeds. However, as the emergency profile has not been maintained for quite some time, it is not properly tested. Hence, there may be issues to be solved.

5 Aug 07:13:09 ERROR [routing.RoutingProfileManager] - java.util.concurrent.ExecutionException: java.lang.RuntimeException: Couldn’t process file /home/ors/ors-core/data/osm_file.pbf, error: emergency$average_speed: value for reverse direction would overwrite forward direction. Enable storeTwoDirections for this EncodedValue or don’t use setReverse

Here, I guess this is related to trying to set a backwards speed for a one-way street. In order to permit driving through a one-way street in the wrong direction you would need to store it as a two way street. Maybe you have also to look at the VehicleFlagEncoder, from which EmergencyFlagEncoder inherits.

However, I believe, there would be more adaptation necessary. Technically, roundabouts or highways are also one-way streets, and you probably wouldn’t like to drive them in the wrong direction, even in case of emergency.

Best regards

zacki41 · September 20, 2023, 8:28am

Hi Sascha,

thanks for the reply. I haven’t really found a tool that can convert gpkg files like the GIP to pbf files - Osmium can not as far as I have tried & failed.

I have now given up the emergency profile and went to the solution suggested by amandus - I make adaptions in the car profile (using it as a template and specifying the paramaters there)

My main problem is, whenever there is a lift_gate barrier (or other features I don’t know of like oneway or so ) the ischrones end there - this can be seen here:
http://rdtransparenz.zahorka.at/?k=b8f1d3352&hc=1&c=1464536%2C5994652
or here
http://rdtransparenz.zahorka.at/?k=e44318c08&hc=1&c=1518063%2C6107394
or here several times
http://rdtransparenz.zahorka.at/?k=b00406e1d&hc=1&c=1595826%2C6151982
or here (where no isochrone is calculated at all)
http://rdtransparenz.zahorka.at/?k=3aa3af74a&hc=1&c=1803916%2C6171272

What I did was to comment the following in the vehicleflagencoder

and comment the following in the carflagencoder

Did docker-compose down and rebuilt the graphs after commenting the lines but did not see the expected changes - what am I missing ?

@jschnell has already told me what the error is a few posts earlier -

Blockquote
the issue here is in the way that version 7 (available via the latest docker images) handles snapping and road barriers.
In both your cases, there’s a barrier=lift_gate on the road that your point would snap to.
Thus, from there on, no isochrone can be found.
If the gate allows vehicles to pass through, then that should be tagged accordingly.
If not, then the “outside” roads are not accessible to vehicles, so it correctly cannot route from there - although it still snaps to the road, since driving “inside” of the gate is still possible.

But changing the tags had no effect - like I did in Vöcklabruck (already several attempts made). OpenStreetMap

Help is greatly appreciated and thanks for every thought you are helping me with
Florian

sascha · October 17, 2023, 10:09am

Your issue might have been fixed in the following bug fix (available at the current main branch):

github.com/GIScience/openrouteservice

fix(isochrones): use correct edge filter for snapping

GIScience:master ← GIScience:fix/isochrones_snapping

opened 11:00PM - 13 Oct 23 UTC

aoles

+10 -63

### Pull Request Checklist  - [x] 1. I have [**rebased**][rebase] the latest version of the master branch into my feature branch and all conflicts have been resolved. - [x] 2. I have added information about the change/addition to functionality to the CHANGELOG.md file under the [Unreleased] heading. - [ ] 3. I have documented my code using JDocs tags. - [ ] 4. I have removed unnecessary commented out code, imports and System.out.println statements. - [ ] 5. I have written JUnit tests for any new methods/classes and ensured that they pass. - [ ] 6. I have created API tests for any new functionality exposed to the API. - [ ] 7. If changes/additions are made to the ors-config.json file, I have added these to the [ors config documentation][config] along with a short description of what it is for, and documented this in the Pull Request (below). - [x] 8. I have built graphs with my code of the Heidelberg.osm.gz file and run the api-tests with all test passing - [x] 9. I have referenced the Issue Number in the Pull Request (if the changes were from an issue). - [x] 10. For new features or changes involving building of graphs, I have tested on a larger dataset (at least Germany), and the graphs build without problems (i.e. no out-of-memory errors). - [ ] 11. For new features or changes involving the graphbuilding process (i.e. changing encoders, updating the importer etc.), I have generated longer distance routes for the affected profiles with different options (avoid features, max weight etc.) and compared these with the routes of the same parameters and start/end points generated from the current live ORS. If there are differences then the reasoning for these **MUST** be documented in the pull request. - [x] 12. I have written in the Pull Request information about the changes made including their intended usage and why the change was needed. - [ ] 13. For changes touching the API documentation, I have tested that the API playground [renders correctly][api]. Fixes #1491, #1533, and #1560 🌈 ### Information about the changes Fixes the phenomenon where isochrones could not be computed or the computed isochrone was confined to a small subnetwork inaccessible from the rest of the routing network. [config]: https://GIScience.github.io/openrouteservice/installation/Configuration.html [api]: https://gitlab.gistools.geog.uni-heidelberg.de/giscience/openrouteservice-infrastructure/ors-docs-api#test-new-ors-documentation [rebase]: https://github.com/GIScience/openrouteservice/blob/master/CONTRIBUTE.md#pull-request-guidelines

zacki41 · October 26, 2023, 8:29am

hi @sascha - indeed the latest nightly build seems to have that error fixed.

is there a timeline when version 8 will be released ?

greetings florian

sascha · October 30, 2023, 8:56am

There is no fixed release date yet. We are planning to start the release process in November. If no serious issues appear, version 8 will be released during November.

zacki41 · December 15, 2023, 4:51pm

Dear @sascha - any news on the update. Version 7.2. is almost there - but still has some snapping issues. Version 8 show the best results for me so far.
Have a great x-mas Holiday to you and the team

sascha · December 18, 2023, 8:40am

Dear @zacki41 ,

unfortunately version 8 is still not ready. We believe that the isochrone snapping fix has been released with version 7.2 and therefore decided to make version 8 even better. Can you provide more information about the differences you observe between version 7.2 and 8?

Best regards