No results for certain areas - issue with snapping?

[majki00]

Description of the problem:

Hi, I am analysis accessibility via public transportation to hospitals across Warsaw and run into some issue. My origins are centroids of hexagonal cells that I created using H3 (resolution 9). The travel_time_matrix function does not return the results for some of my origins - i.e. it seems the travel time exceeds max trip duration (90min) to all destinations. It is expected that the travel time to the nearest hospital indeed exceeds 90min for certain outskirt areas, but it also happens in few central areas and I do not see what is the issue. As you can see in the example below there is no output for almost all centroids that are within cemetery boundaries, yet all areas around it are well below the cut-off time so it seems that there is some issue with snapping. Can you specify how the origins and destinations are snapped to the R5 network and is there a way to specify different snapping method (for example to larger nodes or so?)

This particular example does not greatly affect my analysis since I am interested in inhabited places, but the next two are more worrying and I cannot see why the function would not give output for these origins. Is it possible that some centroids (i.e. origins) are snapped to some inaccessible nodes which "stop" them from reaching rest of the network; thus, reaching 90 min time limit? I would be grateful for any info on what might be an issue and how to resolve it. I am worried that similar issue might also inflate the results of other hexagons for which r5r eventually found an under 90min route but the results are longer then the realistic one.

If it makes a difference I am using pbf file for Mazovian Voivodeship (https://download.geofabrik.de/europe/poland/mazowieckie.html) and gtfs file from here https://mkuran.pl/gtfs/.

I had the same issue 2 years ago when I worked on similar project so it seems that the newer r5r versions does not resolve it. I would be grateful for your help!

[rafapereirabr]

Hi @majki00 . Thanks for opening this issue.

Sometimes, R5 might not return any result for a given location for different reasons. This can happen when, for example:

1. The travel time from that place to all other places exceed the maximum travel time allowed.
2. The location of origin is trapped in a part of the transport network that is disconnected from everything else. It looks like this is the problem you have with the centroids located inside the cemetery.
3. R5 cannot snap the origin point to a road segment that is traversable by the selected transport mode.

It is possible that case 3 could be the explanation for the problem you have in the other areas. To make sure, I suggest you use the r5r::find_snap() function to find the snapped location of the centroids you are passing to r5r.

ps. Perhaps we shoud address this issue in our FAQ.

[majki00]

Hi @rafapereirabr , thank you very much for a quick answer and appologies for my late reply

When I used find_snap I found out that in certain cases (e.g. the second screenshot above) origins are snapped to smaller paths that are not connected to the outside network according to pbf file so this is what you described in Point 2. I am attaching the photo of how it looks.

As the fault lies with pbf file rather then r5r is there anything you recommend doing in such case? Do you thing modifying pbf file in any way might help (e.g. removing paths under certain size). I don't know if that's possible; It's just a random thought as I want to further explore minimising such issues. I would be grateful for your insight

[rafapereirabr]

Hi @majki00. I'm glad to hear my response was helpful, but I'm sad to hear about the network connectivity issue in your .pbf file. I believe that fixing these connectivity issue would solve the problem. Ideally, this should be fixed on OSM so that the fixes are available to the wider public.

What is the best to determine which routes are disconnected, though, is a really good question. Howerver, this is currently beyond my experience, although there are various packages in R for network analysis that could be helpful with this task. See for example dodgr, stplanr and sfnetworks

[rafapereirabr]

closing this issue as the problem seems to be a problem in the OSM network data