Mappen van wegwerkzaamheden

Als we kijken naar de Ripperdastraat in Enschede waar momenteel onderhoud verricht wordt heeft een mapper deze compleet van het wegennet afgesloten en omringd door een hek. Het lijkt mij dat OSM voornamelijk bedoeld is voor het intekenen van permanente entiteiten in plaats van tijdelijke zaken als het afsluiten van wegen van het (routeerbare) wegennet. Is het niet voldoende om de weg te laten zoals deze was, inclusief de verbindingen met aansluitende wegen, en alleen ‘construction=secondary’ toe te voegen, of desnoods ‘highway=construction’? Wat is de policy voor wegwerkzaamheden?

Hoi , wij ondervinden hier momenteel hinder van. Wegen die voor onderhoud niet toegangelijk zijn worden verwijderd in OSM. Als hulpdiensten kunnen wij soms nog wel langs deze wegopbrekingen. Echter doordat de weg verwijderd is in OSM gaat de navigatie niet langs deze weg terwijl die voor ons als hulpdienst wel beschikbaar en sneller is. Daarbij ook genoemd te hebben is dat wij de data van het NDW verwerken voor wegopbrekingen zodat de de route calculatie hier rekening meehoud. We mappen de NDW data op de OSM wegen maar als de weg er niet meer is dan gaat het mappen ook niet goed en wordt bijvoorbeeld een naast gelegen weg gemarkeerd als blokkade wat dus niet juist is.

Kortom het is voor ons niet wenselijk om wegen die nog bestaan en blijven bestaan te verwijderen uit OSM omdat er onderhoud wordt gepleegd. Is hier niet een betere en slimmere oplossing voor te vinden/af te spreken.

Die frustratie is begrijpelijk en ook gegrond. Zo hoort het namelijk niet. Afspraken maken is niet nodig; die zijn er al:

Aan de Ripperdastraat wordt geen onderhoud gepleegd. Het zijn werkzaamheden die langer dan ‘closed over a weekend’ zijn. Wat er over maanden komt te liggen, ligt weliswaar over dezelfde route, maar zal cartografisch toch anders zijn dan wat er al lag. Er staat daadwerkelijk een hek rond de werkzaamheden.

De plekken die ik in Enschede evenzo heb behandeld zijn allemaal niet meer toegankelijk voor hulpdiensten. Wellicht dat men met een brandweerwagen nog ver komt als men het hek open kan krijgen of omver rijdt en bouwmaterialen gaat verplaatsen. C.q. het is niet toegankelijker dan door een park heen rijden bijvoorbeeld.

Van de regels was ik op de hoogte van de regels; allerlei andere plaatsen in en rond het centrum van Enschede heb ik nooit aangepast voor tijdelijke werkzaamheden die er plaatsvonden.

Als er een weg in aanbouw ligt, worden de werkzaamheden dan daarop gemapt? Zo niet: Dan zit daar de fout. In feite is een weg in aanbouw immers ook een vorm van een geblokkeerde weg.

Trouwens, ook het verleggen van een weg begint met een blokkade van de oude weg, maar die oude weg zal toch een keer verdwijnen van de kaart. Het is geen triviale zaak.

De kaartgegevens zouden te allen tijde een representatie / model moeten zijn van wat er daar buiten ligt. Gegevens afwijkend invoeren t.b.v. een gebruik ervan is onwenselijk. Zo worden de gegevens ook gebruikt om de kaart op openstreetmap.org te renderen, maar daar mag ook niet expliciet rekening mee gehouden worden. Zie ook:
https://wiki.openstreetmap.org/wiki/Tagging_for_the_renderer

Er is slechts een vage grens tussen “onderhoud” en een weg compleet vervangen door een andere weg die ongeveer op dezelfde plek ligt. Dus afspraken erover zullen altijd vaag blijven.

Hier is men in feite begonnen aan het langlopende project “Kop Boulevard”. Zie ook:
https://www.enschede.nl/sites/default/files/Presentatie%20Jacky%20Scherens%20-%20Project%20Kop%20Boulevard%20Enschede-inloopspreekuur.pdf
De Ripperdastraat wordt vervangen door een weg zonder baanscheiding en een deel 30-km/h zone. De riolering wordt, zoals Enschede dat altijd doet wanneer een weg “open” gaat, geheel vervangen. Het asfalt was daarentegen bijvoorbeeld helemaal niet aan vervanging toe.

Straks gaat ook de rotonde er uit en dat wordt een kruising met een VRI. Weer later idem dito voor de rotonde verderop in de Haaksbergerstraat. De mogelijkheid om langs ingang-west van de van Heekgarage te rijden zal permanent verdwijnen.

Zouden hulpdiensten er bij gebaat zijn wanneer wegen in aanleg vastgemaakt worden aan bestaande wegen? Zo ja, dan is daar rekening mee houden wel een mooie middenweg tussen het bruikbaar houden van de gegevens en het correct invoeren ervan. M.a.w. dan is een feitelijk incorrecte / niet bestaande koppeling tussen in-aanleg en bestaand hier en daar best een leuke.

Ik heb de reacties gelezen al begrijp ik de laatste niet geheel.
Wij hebben met de gemeenten bepaalde afspraken over wanneer wel en wanneer niet wij langs werkzaamheden kunnen. Het kan goed zijn dat we eerste weken er niet langs kunnen maar later wel (terwijl de weg nog weken dicht is). Dergelijke afspraken worden bij onze chauffeurs kenbaar gemaakt.

De gemeenten registeren in Melvin (NDW) de werkzaamheden, wij importeren die en waar wij met gemeente afspraken hebben passen wij de data aan (dus lokale verwerking) dat wij bij die specifieke werkzaamheden wel langs kunnen. Soms moeten we een hek weghalen of gaan rijden over een fietspad/stoep (waar we dus niet over heen navigeren). Ons navigatie systeem ziet dan de weg werkzaamheden als hinder en niet als blokkade.

Wanneer een rontonde een kruizing wordt met stoplichten dan moet dit ook natuurlijk in OSM worden aangepast ook als de weg structuur veranderd natuurlijk. Ook wij willen begrijpen hoe het zou moeten zodat iedereen mee kan werken.

Als op de kaart een weg-in-aanleg vast zit aan een andere weg, gaat jullie navigatiesysteem dan die weg-in-aanleg als optie aangeven? (Ook al zijn daar wegwerkzaamheden geregistreerd in Melvin (NDW)?)

Het lijkt mij geen probleem om afgesloten wegen aan het wegennet te knopen. Als er een barier verschenen is kan die erop, en als er access restrictions gelden kunnen die er ook op. Het is aan het navigatiesysteem wat het met die gegevens doet.

Als de situatie van dag tot dag verandert en de gegevens precies goed moeten blijven omdat de navigatie tijdens het projekt erop rekent, dan hoort het bij het projekt om het in OSM bijgewerkt te houden. Dat kan je niet van willekeurige mappers verwachten, dan heb je echt een mappende medewerker of kontaktpersoon nodig die dit volgens strakke afspraken doet.

De toekomstige situatie zou ik niet mappen. We maken een kaart, geen ontwerp- of planningssysteem. Als iets af is maar nog niet opengesteld kan je het gaan invoeren, en dan precies bij de openstelling de access restrictions erafhalen, dat lijkt mij de beste regel.

Even afgezien van de discussie over of een weg als nieuw-in-aanbouw toegevoegd moet worden of moet blijven liggen, stel dat er besloten is de oude weg te vervangen door een weg-in-aanleg. Dan stellen de regels dat wegen die ooit ergens in de historie gelegen hebben niet op de kaart mogen blijven bestaan. Wegen die in aanleg zijn mogen ingevoerd worden wanneer er daar buiten meer dan “little or no evidence” is dat die weg daar aangelegd wordt.
Zie: https://wiki.openstreetmap.org/wiki/Tag:highway%3Dconstruction
Daar waar ooit de oude Ripperdastraat lag is daar genoeg bewijs voor: Alle asfalt is verwijderd, evenals de helft van de stoepen, er staat een hek omheen en het staat vol met bouwmaterialen.

Hoe deze tag zetten?

access:conditional=no @ (2019 Sep 16-2019 Nov 10)

Waar wordt deze tagcombinatie toegevoegd.

Zoeken naar jaartal 2019 in de value.
[“access:conditional”~“2019”]

Kijk je in hetzelfde gebied zoekend op jaartal 2018 dan lijkt het dat mogelijk geplaatste tags verwijdert zijn.
[“access:conditional”~“2018”]

Een voorbeeld van Noordfiets die een fietspad voor langer tijd dicht zet.

OSRM Fiets routeert er nog over heen

Zou het te maken kunnen hebben met hoofdletter gevoeligheid of het niet aanwezig zijn van de 0 voor de 1.

no @ (2018 jan 1-2023 dec 31)
no @ (2018 Jan 01-2023 Dec 31)

EDIT: Situatie aangepast met nieuwe code.
Kijken of het over een paar dagen niet routeert.

Na aanpassing code en een tijdje wachten (data update) Routeert Fiets OSRM er niet meer overheen.

Fiets Graphopper nog wel. (De vraag is of daar al een data update is geweest.)

Edit: HELAAS, een mapper na mij heeft er access=no op gezet. Naast de access:conditional. En tevens verandert naar path
Dus de TEST of het niet routeert is mislukt.

(Verandering, misschien is dat gebeurd na melding hier.)

https://pewu.github.io/osm-history/#/way/237646420