routing result has problems with roundabouts and some right turns?

[koenvanhollebeke]

Had a look at the output result imported into OsmAnd for a route which is not implemented in OSM - spin-off topic, but it gives an assessment of the proposed routing for public transport from GTFS only:

General view: I encircled 3 strange routing points - resulting in failures on the proposed routing.

The routes from the operator are as follows:

Analysis:
To be expected, as this is a route which is not in OSM, and therefore the specific ways on the problematic points are not adjusted in OSM.

Conclusion: nice experiment but it is not possible to do a nice perfect routing on the map with the data only coming from GTFS. For the public transport routes which are not in OSM the offline map through OsmAnd will do give the stops but the visual routing will be limited. But still impressed what is possible.

[koenvanhollebeke]

Issue can be closed as it is more informative than a non-expected result.
Thanks a lot for your support for this weird request :)

[Gabriele]

To be expected, as this is a route which is not in OSM, and therefore the specific ways on the problematic points are not adjusted in OSM.

Exactly. The ways need to be adjusted/split according to the GTFS route manually (in JOSM, for example). Maybe doing this automatically with GraphHopper directly in the tool can be possible, I need more time to understand if this is really possible.

Issue can be closed as it is more informative than a non-expected result.

I'll keep this open as this is a nice idea that can be implemented sometime in the future.

Thanks a lot for your support for this weird request :)

No problem :)) If you have other issues/suggestions you can always open a new issue :)

[koenvanhollebeke]

OK, I think I can fix it for the routes which are not in OSM - see the screenshot of the route which fails before.

It is done as follows:'

• take the shape_ID from the trips.txt GTFS file (route 3 with shape_ID 3_26040_3_0_1 in this case)
• use pfaedle script: pfaedle -x sibiu.osm -i tursib.gtfs_2023-06-v1.zip -T 3_26040_3_0_1 - this will output the route in json format (path.json)
• convert the path.json to osm: ogr2osm --id 10000 path.json (the --id 10000 makes the osm id numbers start from 10000 and it goes down) which gives a path.osm file
• these are the node and ways for the particular trip, and this can be merged to the stops.osm file from your tool.
• the only thing what is missing is the relation way members. These do not come from the above path.osm, but can be created using the same order as the ways come out in the path.osm file, eg. for this route (3_26040_3_0_1)

<member type="way" ref="9985" role=""/>
<member type="way" ref="9977" role=""/>
<member type="way" ref="9967" role=""/>
<member type="way" ref="9931" role=""/>
<member type="way" ref="9924" role=""/>
<member type="way" ref="9917" role=""/>
<member type="way" ref="9904" role=""/>
<member type="way" ref="9891" role=""/>
<member type="way" ref="9882" role=""/>
<member type="way" ref="9873" role=""/>
<member type="way" ref="9862" role=""/>
<member type="way" ref="9847" role=""/>
<member type="way" ref="9834" role=""/>
<member type="way" ref="9818" role=""/>
<member type="way" ref="9805" role=""/>

• merge the resulting file to the map.osm file of the area, and give it to osmandmapcreator.

Actually works for all routes in the GTFS file, but this is diverging from the original idea of fixing OSM :) The advantage of the pdaefle tool over graphhopper is that it also (claims to) support train, ferry, metros, ... which as far as I know will not work with graphhopper (only car, foot and bicycle, not?).

[Gabriele]

the only thing what is missing is the relation way members. These do not come from the above path.osm, but can be created using the same order as the ways come out in the path.osm file, eg. for this route (3_26040_3_0_1)

Sorry, could you explain me how Pfaedle works? Does it create new ways that do not exist in OSM, or does it reuse and split/edit the already-existing OSM ways? Unfortunately I won't have time to try that tool for the next few days.

Maybe could you also post there an example of the path.json and path.osm files so that I can understand? Thanks :))

The advantage of the pdaefle tool over graphhopper is that it also (claims to) support train, ferry, metros, ... which as far as I know will not work with graphhopper (only car, foot and bicycle, not

With the correct configuration, Graphhopper can be used for subway, train, etc. trips also.

[koenvanhollebeke]

Maybe could you also post there an example of the path.json and path.osm files so that I can understand?

added the path.json and path.osm of my trial yesterday. the relation way members need to be added in the path osm file.
path.osm.txt
path.json.txt

Sorry, could you explain me how Pfaedle works? Does it create new ways that do not exist in OSM, or does it reuse and split/edit the already-existing OSM ways? Unfortunately I won't have time to try that tool for the next few days.

I did had a bit of a look to Pfaedle before finding your tool - it is all C++ (and I am not good at it, java/python is fine). From my understanding it uses the OSM information to build map matched paths. I can only get json files out of it, but i might not have explored all CLI options.
The json will be made independently of the public transport implementation in OSM (ptv1, ptv2, non existent). With a json output only it is less good than your Graphhopper solution, as it does NOT reuse and split/edit the already-existing OSM ways. The latter would be impossible for transport routes which aren't available in OSM - see the example of yesterday.

So I would see pfaedle a potential solution for the non-existing OSM PT routes in a future solution which converts GTFS using OSM to a OSM file which can be added on top of an existing OSM file for import in Osmand. But maybe graphhopper has a similar solution of dumping a json file with the proposed route (which does not exist in OSM)?

With the correct configuration, Graphhopper can be used for subway, train, etc. trips also.

That's good to here, as at least subways and trains are needed in many countries. Ferries would be a nice add on (for Indonesia for example).

I will be traveling from tomorrow for a while - still with the old public transport android tools :) (Organic maps+google and a bit of osmand)