avoid unsecured junctions or turns / approach with a new pseudo-tag

[EssBee59]

Hello Brouter users!

multiple requests and ideas were posted in the last months to get a higher “safety” routing:
examples:

#817
“possibility to assign initial cost of an intersection”

#796
“dangerous_junction“

#792
“How to add initialcost for crossing a primary…”

Further requests were also addressed to navigation apps that support a routing with Brouter:

osmandapp/OsmAnd#23314
“and propose a safer traffic light crossing (instead of a highway crossing)”

With @afischerdev we worked in the last weeks on an approach to a solution!

1- The (first) use case we considered:

A biker is riding on a highway such as track, path, residential… and have to cross a primary or secondary highway with very high car-traffic and WITHOUT any securing equipment (such as traffic-signal, zebra...).

The main problem (or challenge):
Of course, all junctions are known in OSM as node, but the junctions without traffic-signal or zebra are generally WITHOUT any tag!
And without a tag, no check can be done on a node…
(on the contrary, when tags allready exist on a node, a check is possible in the node context:
Examples: barrier=block|bollard…, railway=crossing, crossing=traffic_signals, etc..)

2- The approach with a new Pseudo-tag:

2 years ago we introduced s.c. “pseudo-tags” to be able to consider noise, river, forest, town and traffic during the route calculation.
(using a Postgis database, “classes” are precalculated for each OSM segment. The OSM map is then enriched with these “new tags” and the resulting map is used during route calculation in Brouter)

With a similar processing we add now the new pseudo-tag “estimated_crossing_class” to the nodes that we do not consider “secured”:
For that we consider first the junctions (=nodes) where an highway of type tertiary, residential, cycleway, track, path,etc… is crossing a primary or secondary highway.

A filter then eliminates the junctions that are secured by traffic-signal, zebra, roundabout ... or when the traffic is estimated too low.
By “island” or “railway_crossing” the risk / class is only lowered.

Finally a “class” (value between 1 and 6) is estimated, it reflects the estimated risk at the node:
The calculation is based on 3 parameters of the crossed primary/secondary:

a- The pseudo-tag “estimated_traffic_class”
b- The maxspeed
c- The number of lanes

A first version of the pseudo-tag is available and can be visualized using this link:
https://brouter.de/brouter-web/PseudoTags.html

(select “crossing” in the class_type and enter a town name + submit)

Further, the new pseudo-tag is installed on the test-instance of the brouter (see below).

3- How to use the new pseudo-tag for routing / prerequisites ?

The new pseudo-tag is currently installed only on the test-instance:
The new RD5 map-files and a new lookups.dat were installed.
https://brouter.de/brouter-test/#map=13/49.9949/8.6407/osm-mapnik-german_style

Example of use in a profile / Define “node-cost” on unsecured nodes
See “example1.txt”

example1.txt

4- Unexpected detours & left-turns

When setting a high penalty (cost) on nodes, “unexpected” (crazy) detours can appear when the estimated_crossing_class evoluates on the road.
Example:
https://brouter.de/brouter-test/#map=17/49.98964/8.63914/osm-mapnik-german_style&lonlats=8.639291,49.989672;8.638175,49.989361&profile=MTB_NodeCost

An experimental solution to avoid such detours is to introduce a “left-turn” cost at the unsecured nodes!
(a version with “right-turn” cost by left drivers becomes then necessary)
The “left-turn” cost is added to the turn costs when the biker is on the primary/secondary and turns left into an highway with lowpriority classifier.

• A new Brouter version is prerequisite
• The turn-left costs are defined with new /special “global” parameters
  Configuration:
  Add the following variables in the context:global
  See “example2.txt”

example2.txt

Status:
Tests with a the experimental version are possible in the test-instance.
3 profiles were extended to use the new pseudo-tag:
https://brouter.de/brouter-test/#map=13/49.9949/8.6407/osm-mapnik-german_style&profile=racebike-verylowtraffic
https://brouter.de/brouter-test/#map=13/49.9949/8.6407/osm-mapnik-german_style&profile=MTB_light
https://brouter.de/brouter-test/#map=13/49.9949/8.6407/osm-mapnik-german_style&profile=trekking_SB

Remark:
We do not recommend to set the “crossing_penalty” to very high values:
Example:
https://brouter.de/brouter-test/#map=13/48.3097/8.7624/osm-mapnik-german_style&lonlats=8.724424,48.286721;8.727533,48.331476&profile=MTB_light

If no secured crossing exists far away at this place, do not try to set the penalty higher and higher…
Too high penalties can lead to unexpected results by the routing (send the biker on the secondary in the example).

But, whenever possible, compared with the old routing (just set for that “consider_crossing=false) the new routing will avoid unsecured junctions:

https://brouter.de/brouter-test/#map=12/49.9845/8.6618/osm-mapnik-german_style&lonlats=8.64212,49.95365;8.743744,50.062561&profile=MTB_light

https://brouter.de/brouter-test/#map=16/58.3642/26.7406/osm-mapnik-german_style&lonlats=26.734334,58.364444;26.746381,58.365174&profile=trekking_SB

In the last example two options are now interesting for a safety routing:
Consider_traffic
Consider_crossing

If you plan as example a route with childrens, very low traffic should be selected using the default option “consider_traffic = as cyclist alone in the week”, but the resulting routing on the preferred residentials crossed the primary 100 meters away from the securing traffic-signal :
Using now at the same time the option “consider_crossing = true”, the route crossed the primary at the traffic-signal.

Thank for any test results, remarks or further ideas

Afischerdev / Essbee

[polyscias]

Good to have this!

Finally a “class” (value between 1 and 6) is estimated, it reflects the estimated risk at the node:
The calculation is based on 3 parameters of the crossed primary/secondary:

a- The pseudo-tag “estimated_traffic_class”
b- The maxspeed
c- The number of lanes

• Would be good to see the exact code/logic and how this value is calculated
• Would it not be better to provide the a/b/c values and have the profile combine them instead of doing that (fixed) in the code, just like is done for way attributes.

When setting a high penalty (cost) on nodes, “unexpected” (crazy) detours can appear when the estimated_crossing_class evoluates on the road.
Example:
https://brouter.de/brouter-test/#map=17/49.98964/8.63914/osm-mapnik-german_style&lonlats=8.639291,49.989672;8.638175,49.989361&profile=MTB_NodeCost

Somehow https://brouter.de/brouter-web/PseudoTags.html?class_type=7&town=Langen is not working for me, I see only the text at the top, no map.

Interesting crossing:

I am pretty sure the 100 km/h is incorrect here and although the costs are indeed way too high I see also a more systematic error in the sense that the costs ratio between the two relevant crossing nodes is wrong:

So I can not even force the route over the logical route even tough the 5.6 meter piece of road even has cycleway=lane.

5.6m is also about the width of the Forstring side road and, other problem, ideally brouter should ignore this piece of road just like normal cyclist do.

[EssBee59]

• Would be good to see the exact code/logic and how this value is calculated

Thank for your tests and comments !
As we make changes every day, we delayed to put the sources in GitHub (ea example we introduced the number of lanes in the calculation yesterday):
So I just enclosed to "daily" version of the SQL´s

all.sql.txt

crossing_tags.sql.txt

[EssBee59]

• Would it not be better to provide the a/b/c values and have the profile combine them instead of doing that (fixed) in the code, just like is done for way attributes.

many challenges for this alternative solution:
-more data in RD5
-more work / effort to implement 2 new pseudo-tags
(only 2 because the third parameter (estimated_traffic_class) allready exists
-and the real value of the estimated traffic is used, not the approximation with a class
(by the tags in Brouter, only low cardinality is supported, that for classes are used)
-more complexity in the profiles
-further tags on nodes and way differ, as result they cannot be easilly exchange between the way and node sections:
maxspeed / traffic / lanes depend on the ways, but the node is generally the intersection of many ways?

(as we started with this change, we could not answer the question: is it worth to create a new pseudo-tag for that?)

So, I prefered not to introduce more pseudo-tags as necessary...

[EssBee59]

Somehow https://brouter.de/brouter-web/PseudoTags.html?class_type=7&town=Langen is not working for me, I see only the text at the top, no map.

Yes, I encountered the same problem now; possibly weakness in the tool that I had to restart
(in further observation)

[EssBee59]

I am pretty sure the 100 km/h is incorrect here and although the costs are indeed way too high I see also a more systematic error in the sense that the costs ratio between the two relevant crossing nodes is wrong:

I agree, the maxspeed tags in OSM looks very strange....
It explains the different classes of the nodes:

The relevant maxspeed at the 2 "red" nodes is 100 (=max of the maxspeed of the crossed segments!)
At the yellow node maxspeed is 70!

The resulting classes are 6 at the red nodes) and 4 at the yellow node.
(the "calculated" traffic may also differ a bit, even if the class is the same for the 3 nodes)

The detour through the yellow node is due to the class difference!

So mapping issue?
But to avoid "unexpected" routing, I prefered to consider the left-turn costs?

[polyscias]

crossing_tags.sql.txt

Thanks, that has the code I see. Would still be good to have a more basic description as not everybody is used to read code meaning that not many people will react.

(only 2 because the third parameter (estimated_traffic_class) already exists

The estimated_traffic_class is available only in way context and not for the node of the crossing way.

I see the code is only calculating for crossings between a highway=primary/secondary and ways primary and lower. I doubt if that is what is wanted. If maxspeed is present that is I think way more important, there are enough highway=unclassified's with maxspeed=80 that are no pleasant crossings for a cyclist.

The code for traffic signals is I think not good, for sure in NL almost all highway=traffic_signals nodes are mapped on the place where you are supposed to stop and not the crossing node. Likely what is needed is to check for highway=traffic_signals in the surroundings of the crossing node. The code should also consider crossing=traffic_signals.

I wonder also how good these calculations are for what for example @fgregg and @ProBackup-nl want to archive and I think what is wanted could also be different per consumer.

For ways we have now 6 penalty classes and in that light I find the arguments on larger RD5 files, more profile code not strong. There will be less nodes than ways also. The flexibility of handling different cost factors different per profile is a good thing.

[EssBee59]

I see the code is only calculating for crossings between a highway=primary/secondary and ways primary and lower. I doubt if that is what is wanted. If maxspeed is present that is I think way more important, there are enough highway=unclassified's with maxspeed=80 that are no pleasant crossings for a cyclist.

The code for traffic signals is I think not good, for sure in NL almost all highway=traffic_signals nodes are mapped on the place where you are supposed to stop and not the crossing node. Likely what is needed is to check for highway=traffic_signals in the surroundings of the crossing node. The code should also consider crossing=traffic_signals.

Ok, not every one is able to understand the code for Postgis!
And in the current state, as changes are probable a full documentation of the code is not really our dream:

But tests are possible when considering the Brouter as a black-box?
(for whihte-box tests, knowledge of the programming language ie prerequisited)

In other words, "unexpected" results are also of interest

[polyscias]

I still think having the current estimated_crossing_class is wrong. What that means I that I think that the current magic sauce might work but sub-optimal.

Customers will far easier understand keys that they can relate to real concepts:

• number of lanes
• maxspeed
• (maximum) crossing highway class

You seems to be not convinced what I understand as you already coded the solution. So let me ask you, what can convince you that separate keys are better? If there is nothing, then we better conclude this discussion and go with what I think is a sub-optimal design.

Note that I do not buy the argument that we can change things later, if the design is limiting the only thing that works is completely replacing the design and that will probably never be done.

[polyscias]

Somehow https://brouter.de/brouter-web/PseudoTags.html?class_type=7&town=Langen is not working for me, I see only the text at the top, no map.

Yes, I encountered the same problem now; possibly weakness in the tool that I had to restart
(in further observation)

Same problem now. Is there a way to run this server myself?

[afischerdev]

@polyscias
Ok, lets bring sub-optimal to optimal. We are at the beginning.

Customers will far easier understand keys that they can relate to real concepts:

• number of lanes
• maxspeed
• (maximum) crossing highway class

I would agree that this keys easier to understand. You will find them on a T-crossing situation in way section. But what is on X-crossing?

May be there is a way to find the node:crossing tags when they are not at the X-crossing node. We don't need a penalty when crossing is save at traffic signal, zebra or so.
And to find all X-crossings with maxspeed=80 or so should be easy. But what is with ways outside town with untagged maxspeed but with national max speed.

Have you ever tried to define a node profile rule with way variables?
May be something like
if way:is_multi_lane then crossing_penalty 10 0

[EssBee59]

Same problem now. Is there a way to run this server myself?

For me it is running...
Not sure, but the leaflet client is running there with html-POST, not GET !
So, the URL https://brouter.de/brouter-web/PseudoTags.html?class_type=7&town=Langen is NOT usable there!

Do you have the same problem when you start the client witt https://brouter.de/brouter-web/PseudoTags.html and entrer manually the class_type, tow name + XMIT ?

As you have many questions, I will tray to provide qualified answers asap.
Thank for your help and interest for a more safety routing
Essbee

[EssBee59]

@ Polyscias,
About your remark above

The code for traffic signals is I think not good, for sure in NL almost all highway=traffic_signals nodes are mapped on the place where you are supposed to stop and not the crossing node. Likely what is needed is to check for highway=traffic_signals in the surroundings of the crossing node. The code should also consider crossing=traffic_signals.

Indeed, the traffic-signals are not allways mapped exactly on the junction:
An this is a real challenge for us to estimate whether the node is secured or not!

If the code, you can see many comments outside the SQL code, example:

-- unfortunatly, traffic_signals are not allways on the intersection itself...
-- example 1 / node 645255230 (not 282220 in underground!) : the node is safety !!! (no detour possible) ==> node should not get a penalty!!!
-- example 2 / node 60740728: node is NOT safety, and a detour is possible ==> node should get a penalty!!!
-- example 3 / 1097988193 (with traffic_signal on 1097988200 ) the signal is not on the "lowprio Highway" but should not get a penalty

-- ==> complex and very different situations
-- ==> current solution:
-- delete the intersec-node when a safety crossing is less than 25 meters away and is ON the "lowprio" Highway" of my current position
-- delete the intersec-node when a safety crossing is less than 25 meters away of my current position

-- create index intersec_6_idx on intersec_6 using gist (node_way) WITH (fillfactor='100');

delete from intersec_6
where node_way in
(select node_way
from intersec_6 a
inner join nodes b on ST_DWithin(a.node_way, b.geom, 25 * (st_length(l_way) / st_length(ST_Transform(l_way,4326)::geography)))
where
st_intersects(a.l_way, b.geom)
and
(b.tags->>'crossing' = 'zebra'
or b.tags->>'crossing' = 'traffic_signals'
-- or b.tags->>'crossing' = 'island'
or b.tags->>'crossing' = 'pedestrian_signals'
or b.tags->>'crossing_ref' is not null
-- island alone is not completly safe ==> reduce the class instead!
-- or b.tags->>'crossing:island' = 'yes'
or b.tags->>'crossing:signals' = 'yes'
or b.tags->>'highway' = 'traffic_signals'));

With high priority I liked as first step to validate / unvalidate / enhance the logic used in this first version.
(without a stabile solution I would prefer to stop further devloppement in that direction)

That for, I liked to get test reports:
Could every one check with the "visualize tool" the nodes in his area?
(are unsecured nodes not in the picture / are secured nodes in the picture?)

[polyscias]

@afischerdev

I would agree that this keys easier to understand. You will find them on a T-crossing situation in way section. But what is on X-crossing?

On a X-crossing or five way intersection the (pseudo) keys should give the maximum value, so the maximum number of lanes of all roads, the maximum maxspeed of all roads and the maximum highway class.

May be there is a way to find the node:crossing tags when they are not at the X-crossing node. We don't need a penalty when crossing is save at traffic signal, zebra or so.

For traffic lights I think searching in the ~25 meter is enough, it looks to me that is what @EssBee59 did implement.

For zebra's I know two ways of tagging, one on the crossing node via crossing=zebra or crossing:markings=zebra and by tagging the footway part of the crossing with crossing:markings=zebra, for this it is I think not necessary to search around in the area.

I am not sure we need to filter out zebra crossings as I think there are other way characteristics are way more important. For NL I am reasonably sure that I would call zebra crossing safe but at the same time they are not with 70/80 km/h or secondary or larger roads (let me try to check this). So instead you could filter out all crossings with a "max maxspeed" of 50 km/h or lower.

As I understand for the US the situation is quite different, pedestrians can not expect priority on zebra crossings but at the same time the number of lanes is way higher.

So a schema like this?

• Only crossings with a least one footway/pedestrian/path/cycleway
• Each crossing way will have a highway classification.
  • Within urban areas assume crossings with roads up till and including tertiary are safe
  • Outside urban areas assume crossings with roads up till and including unclassified are safe
• If the only the maxspeed is (additionally) mapped:
  • Assume maxspeed <=60 km/h safe
• If the maxspeed and number of lanes is mapped:
  • Assume <= 60 km/h and 1/2 lanes or 1 one-way lane safe

[polyscias]

@EssBee59

For me the pseudo tags website is now also running, seems that I have to give it some time.

I had a look in Rotterdam but I am surprised to see:

estimated_crossing_class on a crossing without footway/pedestrian/path/cycleway but not on a crossing with a cycleway:

Very many red dots:

Almost all crossings are 50 km/h and 2 lanes, that resulting in the one but highest estimated_crossing_class. Looks to me most if not all should be filtered out.

I think roundabouts should be de-weighted: