Dag OttoR,

In de Nederlandse community is er consensus dat zulke kort durende werkzaamheden niet op de kaart worden opgenomen. De voornaamste reden is dat routers niet elke dag de nieuwste kaartgegevens van OSM overnemen. Soms gebeurt dat maar 1x per week of 1x per maand.
Dat betekent dan dat navigatie apparatuur gedurende een volle maand de weg als niet bruikbaar beschouwd terwijl de werkzaamheden al lang gereed zijn.
Als je die werkzaamheden op de kaart wil zetten dan kan dat met een conditional.
Voor de H. Cleyndertweg zou dat bijv zijn:
access:conditional=no@(2022 Nov 21 - 2022 Dec 9).
Zie:
osm.wiki/Conditional_restrictions
Tenslotte zijn dat soort afsluitingen absoluut terwijl het vaak zo is dat fietsers en voetgangers gewoon kunnen passeren langs de werkzaamheden.
Alleen als de werkzaamheden langer duren (bijv meer dan 6-8 weken) is een highway=construction gepast.
Maar al te vaak gebeurd het dan dat de aconstruction niet tijdig verwijderd wordt met als gevolg dat gebruikers gaan melden dat de kaart niet klopt.
Bij een conditional gaat dat dus automatisch goed.

De routerelaties zijn weer gerepareerd.

Dag Rocket Racoon,

Helaas gaat dat met de editor iD altijd fout.
De editor iD kan niet met routerelaties omgaan en plaatst een nieuwe halte of wegen altijd achteraan in de relatie.
Dat levert dan een foutmelding op omdat de wegen en haltes niet in de juiste volgorde staan.
Als je serieus met routerelaties wilt werken dan adviseer ik je om over te stappen naar de editor JOSM.
Daarmee kun je de haltes en wegen wel in de juiste volgorde opnemen in de routerelatie.
.
https://forum.openstreetmap.org/viewtopic.php?id=53710

Dag Ferina365,

Helaas kun je met de editor iD de routerelaties van het OV niet correct bewerken. De nieuwe wegen en haltes worden door iD altijd achterin de relatie toegevoegd en dan staan ze dus niet in de juiste volgorde.
Dat leidt dan weer tot foutmelding in OSM Inspector.
Verder is de role in OV-relaties altijd blanco. Dit in tegenstelling tot fiets en wandelroutes war de heenweg over andere ways gaat dan de terugweg. Daarbij moet de role wel worden ingevuld.
De routerelaties zijn nu weer gerepareerd.
Als je serieus met routerelaties aan de gang wilt gaan, dan adviseer ik je om over te stappen naar de editor JOSM. Met die editor kun je de routerelaties correct bewerken.
https://forum.openstreetmap.org/viewtopic.php?id=53710

Sorry emvee, je was weliswaar de laatste die de routerelaties wijzigde, maar de fouten zijn waarschijnlijk door de voorgaande mapper gemaakt.

Door alleen de wegen te downloaden worden de routerelaties niet op de correcte wijze gewijzigd.

Daarbij zijn de routerelaties van bus 716 zwaar beschadigd.
Het kostte me ruim 20 minuten om de zaak weer in de juiste volgorde te zetten.

Bij het splitsen van de Pleiadenlaan werden de routerelaties beschadigd.
Nu kan JOSM daar prima mee omgaan, maar dan moet je de relaties wel downloaden.
De routerelaties zijn weer gerepareerd.

Toch maar even afwachten wat de rendering doet. Het lijkt erop dat er veel zichtbaar wordt.

Hi Dick, dat heeft geen gevolgen voor de rendering. Volgens mij is er veel meer aan de hand. Dubbele ways als inner waar die niet nodig zijn. Een inner die ontbreekt rond twee aaneengesloten landuse-delen.
Een inner die als outer in de mp staat.
Als je geen bezwaar hebt, wil ik er wel mee aan de slag gaan.

Dat zou geweldig goed nieuws zijn.
Sorry voor de overlast.

Dag Sander,
Na de BAG update (in 5 changesets) staat Edam vol met ca 100 self-intersecting ways.
Dat kun je hier zien:
https://tools.geofabrik.de/osmi/?view=geometry&lon=5.06384&lat=52.50725&zoom=15&baselayer=Geofabrik%20Standard&opacity=0.80&overlays=long_ways%2Cways_with_long_segments%2Clong_segments%2Cself_intersection_ways%2Cself_intersection_points%2Csingle_node_in_way%2Cduplicate_node_in_way%2Clong_ways%2Cways_with_long_segments%2Clong_segments%2Cself_intersection_ways%2Cself_intersection_points%2Csingle_node_in_way%2Cduplicate_node_in_way

Als gevolg daarvan kunnen de gebouwen niet meer op de kaart getoond worden.
Ik heb geen idee van de oorzaak van deze fout.
De beste oplossing lijkt mij deze 5 changesets te reverten.
Graag een reactie.

Helaas is dit een grote wirwar van self-intersecting ways geworden.
Ik zie geen kans om dat te ontwarren.
Wellicht is het slimmer om deze changeset te reverten en opnieuw te beginnen, maar dan niet met zo een ongeschikte editor als Go Map.
https://tools.geofabrik.de/osmi/?view=geometry&lon=5.03875&lat=52.13323&zoom=19&baselayer=Geofabrik%20Standard&opacity=0.90&overlays=long_ways%2Cways_with_long_segments%2Clong_segments%2Cself_intersection_ways%2Cself_intersection_points%2Csingle_node_in_way%2Cduplicate_node_in_way%2Clong_ways%2Cways_with_long_segments%2Clong_segments%2Cself_intersection_ways%2Cself_intersection_points%2Csingle_node_in_way%2Cduplicate_node_in_way

De way linksaf vanaf het verkeerslicht naar de Prins Bernhardlaan maakte nog deel uit van de routerelatie.

En de beschadigde routerelaties zijn ook weer gerepareerd.

Is er nu éénrichtingsverkeer op de Punterweg ?

Dat moet zijn: april 2023 !
:-)

Ter hoogte van de Lissevenlaan zijn de drie rijbanen fysiek van elkaar gescheiden. Daar zijn dus ook 3 highways getekend.
Op elke way kan dus de van toepassing zijnde hoogtebeperking worden weergegeven.

Jazeker, die eigenschap kan per lane en per richting worden aangegeven:
maxheight:lanes:backward=3.1
maxheight:lanes:forward=3.1|
Zie ook wat beschreven is in de wiki:
osm.wiki/Lanes

Dag tvdbroek,
Ongetwijfeld zijn je bedoelingen goed.
Helaas is dat niet de manier waarop die wijziging moet worden doorgevoerd.
Er zijn geen 3 fysiek van elkaar gescheiden wegen.
Er is daar maar 1 highway met 3 rijstroken (lanes=3)
Daarna kun je gaan verbijzonderen:
lanes:forward=2
bus:lanes:forward= |designated
acces:lanes:forward= |no
Ik heb de wijziging gecorrigeerd.
Je kunt dat ook allemaal opzoeken in de wiki.
Laat dit je niet ontmoedigen en ga vrolijk verder met mappen.