feat(fr): extend French signal icons and refine parsing#814
Merged
hiddewie merged 18 commits intohiddewie:masterfrom Feb 27, 2026
Merged
feat(fr): extend French signal icons and refine parsing#814hiddewie merged 18 commits intohiddewie:masterfrom
hiddewie merged 18 commits intohiddewie:masterfrom
Conversation
noeldev
commented
Feb 13, 2026
noeldev
commented
- Added icons for primary signal states: C (Carré), Cv (Carré violet), S (Sémaphore), D (Disque), A (Avertissement), and ID (Indicateurs de directions)
- Updated French parsing in signals_railway_signals.yaml to always display the most restrictive primary state for each signal
- Ensures the rendered icon always represents the signal's primary state, independent of the target type
Add new icons representing various aspect states and targets for French signals. Enhance parsing logic in signals_railway_signals.yaml for more accurate support of French signal definitions.
Refines YAML parsing logic for French light signals and adds new icons to support additional signal configurations.
hiddewie
reviewed
Feb 16, 2026
hiddewie
reviewed
Feb 16, 2026
| - { any: [ 'FR:RR', 'FR:RRc' ], value: 'fr/C-RR' } | ||
| - { any: [ 'FR:R', 'FR:Rc' ], value: 'fr/C-R' } | ||
| - { any: [ 'FR:A', 'FR:Ac' ], value: 'fr/C-A' } | ||
| - { any: [ 'FR:VL', 'FR:VLc' ], value: 'fr/C-VL' } |
Owner
There was a problem hiding this comment.
Is it intended that there is no more matching on the possible states of the signal, in case of A/C/F/H/K shape?
Author
There was a problem hiding this comment.
Yes, this is intentional. Based on the latest information I have, the updated open dataset would provide the available lights for each signal head, but not an exhaustive list of all aspects the head may display. The icon therefore renders the most restrictive possible aspect. This makes the signal type immediately identifiable (C, CV, S, A or D) which is not possible with aspects like A, R, RR or VL.
hiddewie
requested changes
Feb 16, 2026
Owner
hiddewie
left a comment
hiddewie
left a comment
There was a problem hiding this comment.
Thank you for the work on the icons for the signals with the different shapes. This is valuable.
I left some comments about the matching that will not work in its current form (nested matching).
I think it would be useful to split the signals into separate features: one for dwarf and then one per signal shape. And within each feature, match on the states to show the most restrictive signal icon for that shape.
hiddewie
reviewed
Feb 16, 2026
hiddewie
reviewed
Feb 16, 2026
hiddewie
reviewed
Feb 16, 2026
| country: FR | ||
| icon: | ||
| # Check ground installation first | ||
| - match: 'railway:signal:location' |
Owner
There was a problem hiding this comment.
Is this not normally tagged as either railway:signal:position = in_track (see https://taginfo.openstreetmap.org/keys/railway%3Asignal%3Aposition#values).
Or railway:signal:main:height = dwarf
Author
There was a problem hiding this comment.
This type of signal is installed between the tracks, not in-track like a buffer stop light.
I’ve seen railway:signal:position=ground used occasionally. It could work if we assume it implies the usual side of the track (the left side in most of France), but this remains implicit and lacks precision.
Using railway:signal:main:height=dwarf might also be misleading:
- For
FR:CARRE,dwarfrefers to an actual dwarf-format head mounted high (typically indoors or under a platform roof). - In contrast, an
FR:CVinstalled at ground level typically uses a standard K-type head.
Furthermore, this doesn't describe the light arrangement, which can be horizontal or vertical at ground level, whereas it is always vertical on a mast. Any ideas on how to tag this distinction?
Owner
There was a problem hiding this comment.
Yes railway:signal:position=ground seems to be used a few times in the US (https://overpass-turbo.eu/s/2kXw):
And railway:signal:location=ground seems only used twice at the moment (https://overpass-turbo.eu/s/2kXx):
So railway:signal:position=ground makes more sense to me.
Furthermore, this doesn't describe the light arrangement, which can be horizontal or vertical at ground level, whereas it is always vertical on a mast. Any ideas on how to tag this distinction?
This could be tagged with railway:signal:*:shape, but that tag is also used for the other kind of signal shapes already.
Author
There was a problem hiding this comment.
I’ll switch to railway:signal:position=ground, as it is a logical complement to railway:signal:position=bridge and the other defined positions.
…ev/OpenRailwayMap-vector into feature/fr-signals-support
Author
|
I’ve updated the code to remove the nested matching. Please let me know if this approach works. There could be some issues with this tagging scheme if SNCF Réseau wants to maintain a unique ID per signal, sign, or board. This approach would also not work in cases where a TIV-D of the ordinary type is mixed with either a B-type or C-type TIV-D at the same position. I’ll try to get more information from the company. |
Owner
|
I had to make 3 changes to make the pull request build and run:
I still think it might still be useful to match the main signals on their states for the signals that have their shape tagged, and show the most restrictive non-Carré state if it is tagged. With a fallback to the current Carré if no state is tagged on the signal, like you already have in this pull request. Because even if SNCF does not expose the possible aspects of the signals in their dataset, the OSM mappers can still map it (or it could already be mapped). For your information, current distribution of main OSM signals in France: select "railway:signal:main", "railway:signal:main:shape", count(*) c
from signals
where "railway:signal:main" is not null
group by "railway:signal:main", "railway:signal:main:shape"
order by c descresults
And with signal states select "railway:signal:main", "railway:signal:main:shape", "railway:signal:main:states", count(*) c
from signals
where "railway:signal:main" is not null
group by "railway:signal:main", "railway:signal:main:shape", "railway:signal:main:states"
order by c descresults
|
Owner
- add variants for C-, F- and H-type signal heads - fix missing clearing light
…ev/OpenRailwayMap-vector into feature/fr-signals-support
…to feature/fr-signals-support
Owner
|
Great, thank you! Some more testing after some small adjustments. (http://localhost:8000/#view=18.93/48.8989388/2.3549344&style=signals): (http://localhost:8000/#view=16.32/48.897786/2.391659&style=signals): |
hiddewie
approved these changes
Feb 27, 2026
Author
|
Thank you for the review and the fixes. The rendering gets interesting. |
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.