Simplify handling of safety values

[miklcct]

Summary

This simplifies the OSM mappers by using mixins to add permissions and multiply safety values. It removes a large number of matches just to override the safety numbers and to add bicycle mode.

This will be a follow up for #6764.

Issue

None yet

Unit tests

Existing tests are updated. In particular, tests which plan journeys need to have their expectation changed as the routing results are changed due to the simplified safety values, which approximate but not exactly equal the old values.

Documentation

Updated

Changelog

Needed

Bumping the serialization version id

[codecov]

Codecov Report

❌ Patch coverage is 95.94595% with 3 lines in your changes missing coverage. Please review.
✅ Project coverage is 72.11%. Comparing base (ca8971f) to head (b05290f).

Files with missing lines	Patch %	Lines
...lanner/osm/wayproperty/MixinPropertiesBuilder.java	80.00%	2 Missing and 1 partial ⚠️

Additional details and impacted files

@@              Coverage Diff              @@
##             dev-2.x    #6767      +/-   ##
=============================================
- Coverage      72.20%   72.11%   -0.09%     
- Complexity     20134    20142       +8     
=============================================
  Files           2183     2183              
  Lines          81108    80868     -240     
  Branches        8144     8146       +2     
=============================================
- Hits           58561    58316     -245     
- Misses         19666    19672       +6     
+ Partials        2881     2880       -1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[miklcct]

Wip

[miklcct]

I think this is ready now but a thorough discussion is needed among stakeholders for the desired values. It also has implication on #6782 as well.

[optionsome]

Could the addition of walk safety be split into a separate pr so this would be simpler to review?

[miklcct]

Could the addition of walk safety be split into a separate pr so this would be simpler to review?

I have removed walk safety here and drafted #6944

[optionsome]

I tested this a bit with HSL data and FinlandMapper. I noticed that on ways ways like https://www.openstreetmap.org/way/23571016 the bicycle safety value changed quite a bit (it was 5.95 before, now it is 2.38). Is this expected change? I think the key thing here is the highway=footway and bicycle=yes combo, but I think the surface also affects the values a bit but I'm not sure if in the same proportion as before. I'll have to talk to our OSM guy what sort of safety values we would actually expect from these ways. The original 5.95 feels a bit high and there were some like https://www.openstreetmap.org/way/229825375 which had 7.02 bicycle safety, which is starting to approach the safety values on some car streets which we don't people to cycle on.

[optionsome]

I like these changes in general. The configuration and documentation seem cleaner now. However, there are some changes to safety values which seem more than just minor changes.

[optionsome]

You don't need to use the elses when you always have a return in the condition.

[optionsome]

I discussed the changes to the highway=footway + bicycle=yes ways with our OSM editor and he also throught that previously they had slightly too high safety values. However, we noticed that https://www.openstreetmap.org/way/235220367 has now a higher bicycle safety value than the road that its crossing which might be slightly problematic as it could lead to avoidance of the cycleway in some cases.

[miklcct]

I tested this a bit with HSL data and FinlandMapper. I noticed that on ways ways like https://www.openstreetmap.org/way/23571016 the bicycle safety value changed quite a bit (it was 5.95 before, now it is 2.38). Is this expected change? I think the key thing here is the highway=footway and bicycle=yes combo, but I think the surface also affects the values a bit but I'm not sure if in the same proportion as before. I'll have to talk to our OSM guy what sort of safety values we would actually expect from these ways. The original 5.95 feels a bit high and there were some like https://www.openstreetmap.org/way/229825375 which had 7.02 bicycle safety, which is starting to approach the safety values on some car streets which we don't people to cycle on.

I discussed the changes to the highway=footway + bicycle=yes ways with our OSM editor and he also throught that previously they had slightly too high safety values. However, we noticed that https://www.openstreetmap.org/way/235220367 has now a higher bicycle safety value than the road that its crossing which might be slightly problematic as it could lead to avoidance of the cycleway in some cases.

The current version is so complicated that it is hard to set the appropriate value when tags interact each others in a way which we didn't expect. If the simplification results in more sensible values for more sensible tags combination that is my intention.

And thanks for finding out the crossing value is problematic, in the current version it also has a high safety value to deter using them (when it is a footway crossing which you are allowed to cycle through) but you have now mentioned that you don't want this, so I will adjust it to be much lower.

[optionsome]

This pr looks ok to me, but we need a second reviewer.

[habrahamsson-skanetrafiken]

This looks like a nice simplification. It's impossible to foresee all the consequences of this, but if any specific issues show up they shouldn't be very difficult to address.