Router confusion due to area sharing border with highway

[sjakobi]

See https://bikerouter.de/#map=19/51.21989/12.52168/osm-mapnik-german_style,Waymarked_Trails-Cycling&lonlats=12.522542,51.219508;12.521635,51.219685&profile=shortest

I was surprised that BRouter reports this short bit of road as a highway=service with unknown surface and smoothness. The reason seems to be that there is an area=yes tagged as a highway=service using the highway=tertiary as its southern border:

IMHO BRouter should try to ignore this area and keep the route on the continuous highway=tertiary.

[sjakobi]

BTW I also noted that the "Road surface/quality" highlighting somewhat misreports the extent of the problematic area:

The short grey stretch above is actually known to have surface=asphalt and smoothness=good.

[sjakobi]

Hmm, apparently the routing via this "area" is profile-dependent. With the fastbike profile the weird highway=service stretch is shorter: https://bikerouter.de/#map=19/51.21973/12.52201/osm-mapnik-german_style,Waymarked_Trails-Cycling&lonlats=12.522542,51.219508;12.521635,51.219685&profile=fastbike

[sjakobi]

Hmm, apparently the routing via this "area" is profile-dependent.

The randonneur profile manages to avoid the weird highway=service entirely:

[abrensch]

Ja, known problem that BRouter cannot handle "2-node-loops"

I don't remember the exact reason for this technical constraints.

But I remember that I spent some effort to mostly mitigate this, if I can resolve 2-node-loops by "promoting" a transfer-node to a network-node. See the method "checkDuplicateTargets" in https://github.com/abrensch/brouter/blob/master/brouter-map-creator/src/main/java/btools/mapcreator/OsmNodeP.java

But in this case the 2-node loops do not have any transfer-nodes to promote.

So just bad luck here...