Add `alt_name`, `loc_name`, `nat_name`, `official_name`, `reg_name`, `short_name` as global fields (which makes them `moreFields` for every preset) with the `prerequisiteTag` of `name` being present.
This fixes "crossing: New approach with …`@templates/crossing/defaults`".
We need the "crossing" field on vertex/node fields as well to allow to quickly change the preset.
SQ
`npm run build` still works, so I don't think this is an issue.
This also removes the second run of very similar code in the prettier workflow which I think is probably a legacy redundancy that can just be deleted.
x
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 field `flashing_light` was used on some of those presets. It is now more systematic.
I also kept them on the `traffic_signals` presets because those can have additional `flashing_lights` as well.
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.
All fields are unsearchable (for now) so we can learn how to name properly.
The names are adapted from `presets/highway/cycleway/crossing/bicycle_foot.json`.
The terms are removed because the presets are unsearchable.
Using the preset I find the markings field to be the most important to change. The `@templates/crossing/defaults` is less important for all situation except for `data/presets/highway/crossing.json`. The main reasons for this is, that only on the base `highway/crossing` the field `crossing` is actually visible. For the more precise presets this field is hidden by some automatic part of the system.
All those fields used a different order of properties, which made it hard to compare them.
This commit does not change anything on the fields, it just streamlines the same order of properties across files.
