Ik heb allebei aangepast (inclusief enkele kleine correcties zoals ontbrekende C9-geslotenveklaringen en stukjes maxspeed=100 die waren overgebleven):

* Provinciaal deel van trunk naar primary: changeset/178051719
* Gemeentelijk deel van primary naar trunk: changeset/178052286

Het provinciale deel van de N230 was tot kort geleden autoweg buiten de bebouwde kom maar is nu geen autoweg meer. Het gemeentelijke deel (vanaf Ghandiplein naar A27) is nog steeds autoweg binnen de bebouwde kom. Volgens osm.wiki/NL:Tagging_van_Nederlandse_wegen zou het nu dus half-primary-half-trunk moeten zijn, maar dan precies andersom.

Deze snelheidsverlaging moet ongeveer twee jaar gaan duren. Dat is voldoende langdurig om de maxspeed in OpenStreetMap aan te passen. Prima wijziging dus.

https://www.a27houtenhooipolder.nl/communities/common/images/04fb8cd8-c73f-40eb-a0a4-b00118eb0ca7/Overzichtkaart_gewijzigde_verkeerssituaties.png

Ah, I now see Valhalla treats every admin_level=3 as admin_level=2 by overwriting the admin_level. That explains the observed behaviour.

Okay, I've updated the tagging. The relation now uses the key prefixes reserved:, was:, and is_in: where appropriate.

Regardless, it may be worth debugging what happens in Valhalla because the code really looks like the override you describe should be technically impossible unless admin_level=2.

W.r.t. the former validity of FX: from https://en.wikipedia.org/wiki/ISO_3166-2:FR

> Metropolitan France (the part of France located in Europe) was previously officially assigned its own set of country codes in ISO 3166-1, with alpha-2 code FX, before it was deleted from ISO 3166-1. The code is now exceptionally reserved on the request of France.

This is how it ended up in ISO 3166-3 (mere exceptional reservations in ISO 3166-2 do not lead to codes in ISO 3166-3). The FX code was officially assigned from 1993 to 1997 according to https://en.wikipedia.org/wiki/ISO_3166-3

I'm not sure what you mean by saying FX was never valid. Before becoming an exceptional reservation, it was officially assigned, which is the highest possible degree of validity. As an exceptional reservation, it's only partially invalid.

The Valhalla code you mentioned only reads the value of ISO3166-1:alpha2=* in case of admin_level=2 (on line 194). This relation is admin_level=3, so it will never set the country code to FX, even if you remove the lines of code you referenced that manually set the code to FR.

I believe there are two sorts of practical applications for these country code tags:

1) Find the territory corresponding to a country code.
2) Find the country code(s) corresponding to a location.

Deleting all not-officially-assigned codes may benefit the second category of applications but harms the first. Besides reserved codes this would also affect user-assigned codes like XK.

Would you be okay with adding a reserved: prefix to the ISO3166-1 keys here? That should solve any problems of applications mistaking reserved codes for officially assigned codes, while still making it possible to opt-in to using the reserved codes.

See changeset/176984051

This relation for Metropolitan France should only contain ISO codes that identify Metropolitan France specifically. Data consumers trying to find France in OpenStreetMap by querying country code FR should not find this relation for Metropolitan France (or any other subdivision of France), but only the following relation for the entirety of France: relation/2202162 - that relation already has the FR/FRA/250 codes so these codes are in the correct place in OpenStreetMap already.

FX and FR are currently both valid codes here (with FX having a more specific meaning than FR). While the territory of FX has indeed been merged into the territory of FR, the FX code has not been fully deleted, but replaced by an exceptional reservation. This is why the iso.org website says "exceptionally reserved" as status for FX. If it was truly properly deleted, it would instead say "formerly used" there, like BQ for British Antarctica: https://www.iso.org/obp/ui/#iso:code:3166:BQAQ

Likewise, if you are in e.g. Martinique, both MQ and FR are valid codes (with MQ having a more specific meaning than FR).

There are also other codes like EU for European Union that have always been just an exceptional reservation: https://www.iso.org/obp/ui/#iso:code:3166:EU

In other words, "officially assigned FX" has been deleted and "exceptionally reserved FX" has been added at the same time.

All ISO 3166-3 codes are alpha-4 codes (i.e. codes consisting of four letters) and all alpha-4 codes are ISO 3166-3 codes.

ISO 3166-3 codes are normally created when ISO 3166-1 codes are retired (usually because the territory disappears in the real world). The FXFR code was created because the FX code was 'downgraded' from "officially assigned" to "exceptionally reserved", to offer an alternative for people who were already using FX but don't want to rely on the exceptional reservation (which could theoretically get deleted at some point in the future).

TL;DR: I've reverted this changeset because it incorrectly equates France and Metropolitan France and specifies a four-letter ISO 3166-3 code which is impossible. Also there is a misunderstanding about the nature of the "deletion" of the old codes for Metropolitan France.

Earlier comments: changeset/172975242

Aanvullende bron:

Omroep West (4 maart 2024). Dit is waarom trajectcontrole op A12 bij Den Haag verdwijnt. https://www.omroepwest.nl/nieuws/4812509/dit-is-waarom-trajectcontrole-op-a12-bij-den-haag-verdwijnt

Aanvullende bron:

Omroep Brabant (26 februari 2024). Trajectcontroles op A58 bij Roosendaal plotseling beëindigd: dit is waarom.
https://www.omroepbrabant.nl/nieuws/4426436/trajectcontroles-op-a58-bij-roosendaal-plotseling-beeindigd-dit-is-waarom

Het onderscheid tussen ref A13 en official_ref A4 is hier gemaakt, omdat dit stuk weg formeel-administratief gezien een verbindingsboog van de A4 is, terwijl het functioneel gewoon de hoofdrijbaan van de A13 is (waar het vanaf de onderdoorgang Prins van Oranje ook formeel in overgaat).

De tag official_ref in combinatie met carriageway_ref klopt met wat er op de hectometerbordjes staat (A4 x). Dat je de tags zo moet lezen, staat ook uitgelegd op de wiki: carriageway_ref=*#Netherlands

Prima!

Een vergelijkbaar bord staat overigens ook al nabij de bushalte: https://www.mapillary.com/app/?lat=52.10819130300001&lng=4.322853069749954&z=19.48384982394855&pKey=515210499514257&focus=photo&x=0.7178830342306364&y=0.523068520060813&zoom=1.3182779490727579

Deze borden zijn zogenaamde aanduidingsborden conform artikel 21 van de Verkeersregeling Defensie: https://wetten.overheid.nl/jci1.3:c:BWBR0043001&paragraaf=4&artikel=21&z=2021-03-10&g=2021-03-10

Uit de bebording van de militaire basis blijkt dat dit eigen wegen zijn, vandaar access=permissive.

Op dit specifieke stuk weg staat bovendien een verkeersbord C1 met een uitzondering voor militair verkeer, vandaar vehicle=private en horse=private (bord C1 geldt ook voor ruiters).

Onder het bord C1 staat ook een uitzondering voor fietsers vermeldt, dus moet er weer bicycle=permissive bij om vehicle=private te overschrijven.

De algemene tag access=permissive wordt nu dus overschreven voor vehicle en horse, en nog een keer voor bicycle, maar blijft nodig voor voetgangers die niet onder vehicle/horse/bicycle vallen.

Different systems may use different codes from ISO 3166 to refer to this object, hence I included them all. Codes from ISO 3166-3 are unusual but in the case of Metropolitan France, FXFR refers to a territory that still exists present-day rather than a historic territory.

Beste Jan,

Ik heb deze straatnaam niet ingevoerd. In 2014 heeft iemand de naam hier gewijzigd van Sint Jansdijk naar Sint Jansstraat op grond van wat er kennelijk toen in de Basisregistratie Adressen en Gebouwen (BAG) stond: changeset/21646155

Ik zie dat het Nationaal Wegenbestand wel "St. Jansstraat" als straatnaam van dit stukje weg vermeld, maar daar lijkt de naam foutief gekoppeld aan de BAG-registratie van de gelijknamige straat in de woonplaats Sluis.

De weg/brug is in OpenStreetMap toch ook open?

OpenStreetMap heeft wel een vrachtwagenverbod tussen het kruispunt met de Rijksweg (N317) en de rotonde met Eldrikseweg/Barlhammerweg.

Er staat een bord met de naam Lievenspleintje, met daaronder verboden toegang voor onbevoegden. Ik vermoed dat Lievenspleintje een eigen naam is van de privé-eigenaren van het plein. Alle adressen zijn Axelsestraat 79 met diverse toevoegingen. Ik zal official_name=Axelsestraat toevoegen.

Zie https://community.openstreetmap.org/t/direction-tags-op-verkeersborden/124634/4

Omdat het bord C2 inderdaad na het fietspad staat, is het stuk daarvoor geen eenrichtingsverkeer voor fietsers; zij kunnen het kruispunt verlaten via het fietspad. Echter auto's zouden zichzelf klemrijden op het kruispunt, waardoor dit voor hen wel eenrichtingsverkeer is in plaats van een doodlopende tweerichtingsweg tot aan het C2-bord. Er is hier voor auto's geen toegestane manoeuvre mogelijk in de andere rijrichting. Dit wordt ook ondersteund door de haaientanden over de volledige rijbaanbreedte (en voor twee van de drie aankomstrichtingen ook door borden D6).

Ik heb dit stuk nu oneway gemaakt met uitzonderingen voor bicycle en mofa (die mogen het fietspad op) en er een note met uitleg bij gezet. Zo klopt de routering voor alle vervoerwijzen.

Hoi Eggie,

Er staat hier wel degelijk een bord dat ook het stuk tussen de rijbaan en het fietspad effectief eenrichtingsverkeer maakt:

https://wegkenmerken.ndw.nu/verkeersborden/e3f79314-717d-40df-b311-ef3e42d0c7b3

Maar ook zonder dat bord zou je tegen de haaientanden in moeten rijden, is de binnenbocht ontworpen om rechtsafslaan moeilijk te maken, en als je het toch zou doen, mag je het kruispunt daarna niet verlaten. Dus het is effectief alsnog eenrichtingsverkeer op basis van Artikel 5 Wegenverkeerswet.

Snel kijkend zie ik dat het op de andere locaties met name gaat om de fietsroutering, die moet natuurlijk wel blijven kloppen, dus dan is het inderdaad noodzaak om goed op te letten of er oneway:bicycle=no nodig is.