The common practice is to tag this in the `highway=crossing` nodes and on separate `barrier=kerb` nodes but not on the crossing ways. Same as the `kerb` field.
The fields `oneway` and `access` are important for `highway=cycleway|path` crossings but not essential. They are more of a advanced user setup which should be visible when prev filled in but only added by users that read more about it before. They are moved to the `moreFields` for that reason.
The `segregated` is added here for the same reasons and because of it's importance for highway types that likely have bike traffic.
Ping https://github.com/openstreetmap/id-tagging-schema/issues/317
The `surface` and `smoothness` is extracted from the `@template` because it makes more sense to split them up in `fields` and `moreFields`. A templates adds too much abstraction in this case.
The markings templates are not touched by this PR and it does seem to work without this. However, the fields are used on line and point geometries so either the `geometry` field is ignored during build or something else is happening…
The field "crossing" is removed from the `/defaults` fields.
- it is only relevant for the geometry line because it is hidden on geometry vertex.
- but on geometry line, we want it to be on the first position of fields
- the `/defaults` fields however should be positioned below the `markings` which are more relevant for specifying the kind of crossing
- the `/defaults` fields now includes `crossing_raised` which was removed from the previous and discontinued `/geomery_line` fields template.
The new `@templates/crossing/bicycle_relevance`
- is used on all highways that have bicycle relevance which are `highway=path|cycleway` and not on `highway=footway`
For all traffic_signal presets, the order of fields is different to give the `/traffic_signal` more prominence.
This extract the three moreFields to be reused in all traffic_signals presets.
- "traffic_signals/arrow"
- "traffic_signals/countdown"
- "traffic_signals/minimap"
For unclear reasons the cycleway/crossing/traffic_signals did not have those more fields which are now added to streamline the presets.
This extract the three fields to be reused in all traffic_signals presets.
- "button_operated"
- "traffic_signals/sound"
- "traffic_signals/vibration"
Nothing else is changed, this is just an extraction into a template.
This streamlines the fields on all line geometry crossings.
- "oneway"
- "surface"
- "smoothness"
- "crossing_raised"
- "access"
Those fields are always the last in the list. For traffic signal those specific fields are put above. Which is also the only change for one vertex preset in this commit, to have the "crossing_raised" come after the traffic signal specific fields and so the order is the same across presets.
This will roll out the smoothness field for all crossings; it was previously only present in some. But given the importance of smoothness for accessibility I think that is OK. This commit also moves the surface (and smoothness where present) fields further down the list which reduces the priority a bit.
The biggest change in priority is the oneway-field which had the first position before and now is below the defaults- and markings-field.
This way we have the same fields in all crossing presets:
- "crossing"
- "tactile_paving"
- "crossing/island"
This change the order of things slightly for some footway, cycleway crossing where `surface` is now a bit lower, but that should not be a problem.
