Add crossing:signals field to crossing/*traffic_signals presets
#1203
+475
−133
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Terms are not used for unsearchable preset so we can remove them.
This streamlines the presets and makes it easer to review and use them.
This streamlines the crossings presets
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.
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 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 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.
I added this in openstreetmap@3e5e99f an I think that was a mistake so lets remove it again.
The convention is, to tag this on the node _and_/_or_ on the separate `barrier=kerb+kerb=*` node when the path is mapped separately. It should be part of all crossing vertex presets.
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.
…tion 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 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.
…nd `@templates/crossing/defaults` 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.
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…
…g `segregated` 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 openstreetmap#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.
…ng notes 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.
…ossings 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.
Usually prettier can switch automatically to check Markdown and format it. However, this prettier config forces the JSON formatter for all files.
`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
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
…template/geometry_way_more` The "lit" value was present on some of the presets before and is common to be applied to all kind of ways.
|
🍱 You can preview the tagging presets of this pull request here. |
TestingLooks good. For a crossing node with just Follow up
Open question…
|
Next steps
|
tordans
commented
Apr 29, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is based on top of #1201 and should only be merged after that was merged. For that reason it is marked as a draft for now.
I will rebase here in case #1201 changes.
This PR adds the
fieldand add theaddTagspart.This follows the conversation during the iD Community Meetup to consider adding the tag due to the usage in StreetComplete, Routers and the general impression that the
crossing:signals=yestag is widely "in use" and accepted.Closes #1118
Makes parts of https://github.com/openstreetmap/id-tagging-schema/pull/1044/files#diff-b8505be38bbc0be40512bf63c04d79f36f8826808ba4f0c06f186527eddcc7b4 obsolete.