Why the routing choice is strange?

[ichsan2895]

Hello,
First of all, thanks for creating conveyal r5. I use r5r with R to do routing from a point to a point.

Here is my concern

Why r5 doesn't have "trunk" street class?

r5/src/main/java/com/conveyal/r5/labeling/StreetClass.java

Lines 6 to 7 in 995635a

	public enum StreetClass {
	MOTORWAY(0), PRIMARY(1), SECONDARY(2), TERTIARY(3), OTHER(4);

The absence of trunk highway is my hypothesis for strange routing result when I use car as the mode for intercity way.

Here is an example of a point to point routing result. I use r5r to do it..

Magenta line is the route from A to B
Yellow line is the route from B to A

A = 0.3610082 N, 101.9085 E
B = 0.4994880 N, 101.4547 E

The yellow line exits the trunk highway then enter rural residential before it turns back to trunk highway), but the magenta line still in trunk way.

Could somebody fix it?

Another similar case
#ipeaGIT/r5r#317

[abyrd]

Hi @ichsan2895. First, about StreetClass. This categorization is currently used only for display purposes when creating vector map tiles via com.conveyal.analysis.controllers.NetworkTileController#getClippedAndProjectedEdgeGeometries. It shouldn't affect routing in any way. The categories we define and assign to the streets are only the categories we've differentiated visually in our map display. This vector map display is new, currently serving as a preview of the uploaded data and will likely be changed a few times before these street categories are visible throughout our web UI. Note that Conveyal maintains the R5 library but we don't work on r5r ourselves, so I'm not sure if these street categories are somehow used in that package, but they should not be considered part of a public API.

Second, before getting into the route details, I want to point out that R5 is made specifically for computing travel times and urban planning metrics derived from travel time, such as cumulative access to opportunities. As long as the routes found are representative of the minimum travel time a person would experience between two points, we are not very concerned with the exact details of the route. So if multiple alternatives exist with very similar travel times, we are not concerned with always selecting or highlighting the one that's easiest for a traveler, as long as this has a negligible effect on the travel time statistics that are our true output.

That said, if there's a problem with our routing we do want to find and fix it. The problem you describe could be a problem with input data (OSM) or with how we interpret it, including things like turn restrictions. The yellow path does look significantly longer, and if it takes more time it should not be preferred. We'd usually need additional information to diagnose that, such as the source OSM data you used, and ideally the request parameters that were sent to R5.

I have identified the area east of Pekanbaru on Sumatra and made an OSM extract, so will check it out.

[abyrd]

Looking at the street data as imported in R5, I can see that the speed on the circuitous yellow route is about 40 kph and the speed on the trunk road is 88 kph. I would not expect the router to prefer the slower circuitous route. Performing searches from the northwest and southeast sides, isochrones appear as expected:

The isochrone proceeds more quickly along the trunk road but also proceeds along the circuitous route more slowly. So I am unable to reproduce the problem with freshly downloaded OSM data.

[ichsan2895]

Hi @ichsan2895. As long as the routes found are representative of the minimum travel time a person would experience between two points, we are not very concerned with the exact details of the route. So if multiple alternatives exist with very similar travel times, we are not concerned with always selecting or highlighting the one that's easiest for a traveler, as long as this has a negligible effect on the travel time statistics that are our true output.

Thanks for your clarification

@abyrd I'm sorry you can not replicate my issues.
My issues is happen when do point to point routing using car. In this case, the circuitous
yellow line is the route from B to A

B = 0.4994880 N, 101.4547 E
A = 0.3610082 N, 101.9085 E

Surprissingly, If I route from A to B, the result it different (it doesn't choose circuitous way).

Here is it the pbf data:
Highway_Riau_20230123.osm.pbf.zip

[abyrd]

Hi again @ichsan2895 and sorry for the delayed response. We haven't used the point-to-point routing server for many years and it is not actively maintained. This dates from a time when we were exploring use of R5 as a replacement for OpenTripPlanner, but there has since been a clearer division of roles between the two projects with OpenTripPlanner 2 handling passenger-facing and point-to-point routing, while R5 is specialized in many-to-many urban analytics use cases. The point-to-point routing code paths do work somewhat differently than the one-to-many routing we use heavily for travel time mapping and accessibility calculations. We have not (yet) removed the point-to-point functionality in case anyone finds it useful, but realistically we probably won't spend time exploring issues with this part of the codebase.