New Option for Preferred Side

[Trietes]

Currently the preferred_sie parameter has the options same, opposite and either to specifiy the preferred side of the street to route to. In reality the preferred side also depends on the road(-class). For higher road classes the side for e.g. a delivery driver becomes more important, since he doesn't want to cross the street by foot. On the other hand e.g. a residential road can be crossed by foot more easily, so the side of the street doesn't matter that much.

I'm currently realising this behaviour by having a /locate request first to determine for each location if arriving on the same side of the street is important, dependent on the road class. Would it be intersting for you guys to have another configuration parameter for the preferred_side option (maybe something like automatic or road_specific)? Or is this too specific for certain use-cases? Of course the threshold for which road classes the preferred side does matter is debatable.

[nilsnolde]

Yeah, it's logical to me what you're describing, but I'd personally refrain from making the (already very complex) API more complex, to accommodate for this. As you mention a workaround exists for a client.

[kevinkreiser]

it might not be all that complicated and it is a pretty useful feature. we would just need another parameter preferred_side_cutoff which says to adhere to the preferred_side parameter so long as the road class is above the value provided in preferred_side_cutoff and if the road class is not then we treat it as either. i agree that it complicates the api but the workaround the client is doing is no good, once you include a radius you will have more than one road candidate per location, also doing two api calls is pretty crappy.

an alternative design would be to keep the single parameter but allow more complicated values like:

preferred_side=same,tertiary

so that the parser has to first split on , and parse the second string as a road class. of course omitting the extra stuff would still be allowed. eg. :

preferred_side=same

would be equivalent to:

preferred_side=same,service_other

at any rate, seems like a well scoped, easy to implement feature if you want to take a crack @Trietes

[kevinkreiser]

oh i should also say, that if you are using a geocoder, it would be fantastic if the geocoder told you the road class because then you'd know what you want apriori without having to do the /locate preflight checks (since geocoding would fill that niche)

[Trietes]

In my case I'm working without geocoder, so I've to do the /locate request first. Although I would agree that would be a nice workflow to do it like that.

Regarding the API design, I guess I would prefer the additional preferred_side_cutoff parameter. It looks a little cleaner to me.

[Trietes]

So now we have two opinions here :D I can understand the argument with making the API more complex. On the other hand I like Valhalla because of exactly this powerfull and complex API. Most other routing engines might have a simpler API, but are far less configurable. In my opinion it would break down to if it is a usefull feature which other people also would like to use. I've I'm the only one who thinks it is a good thing to have and nobody else would use it, its not worth implementing.

Regarding the implementation I agree to @kevinkreiser. I already checked the code which handlese the preferred side and it should be pretty straight forward to a new configuration to it.

[nilsnolde]

Yeah, never mind me here :D Depending on the stress of the day I might look at things darker than necessary. I agree with @kevinkreiser and also with you regarding a new preferred_side_cutoff (or preferred_side_maxclass?).

[nilsnolde]

A contribution there would be highly appreciated:)

[Trietes]

Okay, so I guess we have an agreement here :D
I'll see when I get some time and give it a try.