Mijn vraag was de volgende: Bij een weg wordt gesuggereerd (witte lijn niet meer zichtbaar, wel geel geblokte lijn) dat de weg niet meer fysiek aanwezig is. Dit geeft in andere software, die OSM als achtergrond gebruikt, een probleem. De weg bestaat wel maar is tijdelijk afgesloten door wegwerkzaamheden. In de tekentool van de wegbeheerder, welke OSM als ondergrond gebruikt, staat de weg nu niet meer op de kaart en kan er ook geen lijn meer overheen getrokken worden om een beperking aan te geven.
Het klopt dat de weg tijdelijk niet gebruikt kan worden door verkeer maar op de kaart mag deze niet verdwijnen.
Het betreft de volgende locatie: https://www.openstreetmap.org/#map=18/52.2174900/6.8903000
De tool die wij gebruiken is Melvin (meldin.ndw.nu) Daar staat nu wel een afsluitingslijn, maar de weg is daar niet zichtbaar.
Reactie hierop van Leo Slager:
De weg is voorzien van de tag highway=construction.
De weg is dus nog steeds aanwezig in de database van OSM.
Het is de standaard methode in OSM om aan te geven dat de weg voor langere tijd niet beschikbaar is voor het verkeer.
Daar is dus niets mis mee.
Een goede navigatie-app zal dus geen route plannen over deze weg en dat is dus precies de bedoeling.
Iemand suggestie hoe hier mee om te gaan?
Dit probleem doet zich overigens op meerdere locaties voor.
Is het mogelijk om highway=construction in de tekentool anders te renderen en dus wel zichtbaar te houden? Voor zover ik weet is het mogelijk om kaartelementen op verschillende manieren te renderen, maar daar heb ik zelf verder weinig verstand van. Is wellicht het uitzoeken waard.
Leo heeft in principe gelijk; dit is een probleem van de betreffende renderer (die de gegevens uit de OSM-database vertaalt naar een leesbare kaart) die wegen met highway=construction blijkbaar niet weergeeft. Ik weet niet welke renderer Melvin gebruikt; het lijkt wel wat op Wikimedia, maar er zijn verschillen. In ieder geval: het probleem dat u beschrijft is dus niet door ‘ons’ als mappers op te lossen.
Wel kiezen mappers er soms (te) snel voor om een weg op construction te zetten voor tijdelijke afsluitingen, terwijl dynamischer applicaties als Melvin daar juist veel geschikter voor zijn. Ik kan het niet duidelijker zeggen dan de wiki:
Hier kunnen we als mappers wél op letten. Hoewel wij OSM in principe in real-time kunnen aanpassen, werken onze data-afnemers hun data bij lange na niet zo vaak bij. Dat is hen ook niet echt aan te rekenen, zeker als het gaat om een ondergrond- in plaats van een navigatiekaart.
In pricipe zou je highway=construction alleen voor nieuwbouw moeten gebruiken.
Tijdelijke afsluitingen zouden dan altijd met conditional restrictions moeten worden aangegeven.
Het argument dat een navigatie-app daar niet mee om kan gaan is niet valide.
Als er een versperring is, is er ook een omleiding bewegwijzerd. Die kun je gewoon volgen tot je weer terug bent op de route van de navigatie-app. Voor die omleiding heb je de navigatie-app niet nodig !
Dank voor jullie reacties en het meedenken in deze!
Wij updaten onze achtergrondkaart maandelijks.
Ik zal eens navragen of het label highway=construction wordt meegenomen.
Een eerder antwoord dat ik kreeg van de beheerder van Melvin toen ik hem het probleem voorlegde is: Dat is helaas niet iets waar we invloed op kunnen uitoefenen. OSM heeft in dit geval kaart wijzigingen doorgekregen en gevalideerd en deze komen na verloop van tijd met een kaart update bij ons binnen.
Het enige wat je dan als gemeente kunt doen is vervolgens ook weer aanpassingen in OSM doorgeven (uiteindelijk niet heel veel anders qua proces dan wanneer het bijvoorbeeld een NWB kaart wijziging betreft behalve dat de groep die beslist groter is).
Maar het leek mij niet wenselijk dat een wegbeheerder die al intekent in Melvin, nu ook moet gaan aangeven in OSM dat een weg er wel ligt maar niet toegankelijk is. Eer dat dat is doorgevoerd en de update gedraaid heeft, is de situatie mogelijk alweer aangepast en kan een wegbeheerder het weer ongedaan maken.
Ik denk dat highway=construction ook prima kan als het wegdek verwijderd is.
Jij ben wel erg optimistisch over omleidingen. Maar ervaring is dat omleidingen een groot deel van de tijd volstrekt niet werken:
er staat op een bord welke straat of weg afgesloten is. Iemand die niet ergens bekend is heeft geen idee of de route van het navigatiesysteem daar langskomt of niet.
regelmatig staat een omleiding slecht aangegeven. Als je een bordje mist kan je goed zuur zijn.
Omledingen voor fietsers zijn vaak van slechte kwaliteit of ontbreken helemaal.
Dus als een weg lange tijd afgesloten is, dan is het zaak om te zorgen dat navigatiesystemen dat ook weten. Bijv. de sluizen bij IJmuiden die al jaren afgesloten zijn.
Als het gaat om een weg die vele maanden afgesloten is zonder duidelijk einddatum dan is een conditional restriction niet echt geschikt.
Tenslote, openstreetmap moet concurreren met kaarten die realtime bij gewerkt worden. Als mensen vast lopen omdat wij obscure tagging methodes gebruiken die niet ondersteund worden door navigatiesystemen, dan haken gebruikers af, en is het werk dat we doen voor niets.
Als je de gebruiker het gewoon maar uit laat zoeken, dan moet die eerst helemaal naar de versperring toe rijden om daar te zien dat er een omleiding is.
Als je een lange route hebt die via a of b maar 5 minuten verschil is, maar je via a een wegversperring tegenkomt die je 20 minuten extra kost, dan had je beter route b kunnen nemen. Maar de afsluiting staat alleen lokaal, in de buurt van a aangegeven.
Ik werk ook met construction voor afsluitingen van enkele maanden. Als ik een langere reis maak naar gebieden die ik niet ken dan update ik mijn OSMand altijd van te voren met de nieuwste kaarten (max 5 weken oud) en soms zelfs een live update (max 2 uur oud).
Zit ik toch wel met een probleem. Bij mij om de hoek gaat een brug uit het verkeer tot medio 2022 ivm sloop en herbouw. Voetgangers en fietsers kunnen er wel langs. Tzt wordt er een hulpbrug geplaatst voor deze categorie. Hoe geef je dat netjes aan? Juist door die verschillende categorieën. OV gestremd, taxi gestremd, auto gestremd, maar fiets en voetganger niet.
Er is geen enkele kaartenboer, op papier of online, die bij tijdelijke werkzaamheden zijn vaste kaarten aanpast. Dat doen alleen wij. Dat ziet er leuk uit op carto dat zichzelf iedere minuut bijwerkt maar voor de grote meerderheid van gebruikers van onze gegevens biedt het geen meerwaarde, of leidt het zelfs tot ergernis. Als je wilt beargumenteren dat we met andere kaartenmakers moeten concurreren, dan moeten we dit soort dingen juist niet fundamenteel anders doen.
Bij osmand kan het na het taggen van construction dus een maand duren voordat dit wordt doorgevoerd en als de weg weer open is kan het opnieuw een maand duren voordat de gebruiker erlangs kan routeren. En dan is osmand een afnemer die de kaarten maandelijks bijwerkt. Sommige diensten doen kwartaalupdates. Als die bijgewerkt worden op 30 juni terwijl de weg op 1 juli opent, is die 3 maanden onterecht onbruikbaar, en er is niets wat je daar als gebruiker aan kunt doen omdat het vaste in plaats van dynamische gegevens zijn. Talloze andere diensten kiezen er (terecht!) voor de kaarten nog minder vaak bij te werken (bijvoorbeeld omdat het puur als achtergrond dient) en dan zit er bijvoorbeeld drie jaar lang een gat in een straat. Conditional access restrictions geven deze problemen niet.
Tijdelijke(re) afsluitingen zijn veranderlijke gegevens en die moet je dynamisch afhandelen, niet in de kaartgegevens zelf. Dat kan prima met een open platform als Melvin, waar dit topic nota bene over gaat. Magic Earth maakt hier bijvoorbeeld gebruik van.
Kortom: dynamische afsluitingsdata is een zaak voor de gegevensafnemer, niet voor ons mappers. De opmerking op de wiki over zes tot negen maanden staat er niet voor niets; laten we ons minstens aan die termijn houden.
Ik ben het niet eens met je premisse, maar wel met (ongeveer) de rest van je opmerking.
Het concept “vaste kaarten” bestaat niet meer bij online. Onze database is “live” en toont in principe de situatie “on the ground”, zoals die nu is. Als je wil is semilive (met enkele uren vertraging) daar een download van te trekken.
Ik zou inderdaad wegen die voor een weekend dichtgaan voor nieuw asfalt niet op construction zetten.
Voor bijvoorbeeld de A9 Gaasperdammerweg is de Noord-Zuidverbinding in de S112 voor 2 maand gesloten. Omdat het niet alleen dicht is, maar ook complete herbouw, heb ik de oude ways verwijderd terwijl de nieuwe ways al een jaar of 3 als eerst highway=proposed en later construction in OSM stonden. Maar een weg die 6 maanden dicht is ga ik echt wel op construction zetten, en 3 maand ook al. Maar zulke lange werkzaamheden zijn in Nederland zeldzaam als het niet toch een totale reconstructie van een weg betreft.
En het voordeel van construction boven access=no is dat die eerste visueel veel duidelijker is op de mapnik-kaart, en ook de werkelijkheid reflecteert — De weg is immers dicht vanwege (ver)bouwing.
Er is op OSM vziw nog geen goede manier om werkzaamheden juist aan te geven (access restrictions werken niet met jaartallen, dus als niemand ze verwijdert dan komen ze het jaar erna terug). Ik heb dit ooit aangestipt op een tagging-mailinglijst (kan niet meer terugvinden waar en wanneer), maar in veel landen “verschijnen” werkzaamheden zomaar en “zijn ze klaar als ze klaar zijn”. In Nederland zijn we wel heel duidelijk met onze werkzaamheden die van vrijdag 25 september 20:00 tot maandag 28 november 05:00 duren, maar dat lijkt internationaal meer de uitzondering dan de regel te zijn.
Conditional access restrictions volgen de regels van de opening hours en daar kun je zonder meer een jaartal toevoegen.
access:conditional=no @ (2020 Oct 20 - 2020 Oct 30) zou gewoon moeten werken.
En let ook eens op de fijne nuances in de Engelse taal.
Een tijdelijk opgebroken weg wordt aangeduid met “road is closed” (for traffic).
Een nieuwe weg in aanleg wordt dan aangeduid met “road under construction”
Het ziet er dus naar uit dat in de loop der tijd de betekenis van “highway=construction” is verwaterd en nu ten onrechte wordt gebruikt voor een weg die tijdelijk niet bruikbaar is voor het verkeer.
We zouden dus principieel daarvoor altijd de access:conditional moeten gebruiken.
Conditionals hebben als nadeel dat de einddatum bekend moet zijn wil je er voordeel uit halen. Bij afsluitingen langer dan zes maanden is de einddatum bijna per definitie onbekend. Bij zulke langdurige afsluitingen is het ook niet zelden zo dat de wegsituatie aanzienlijk veranderd (een rotonde vervangt een kruispunt bijvoorbeeld), waardoor je lastig de oude route kan handhaven als die gesloten is en ook daadwerkelijk (deels) verdwijnt.
Wel is natuurlijk mogelijk om als een langdurige afsluiting ter plaatse omgeleid wordt langs of over het bouwvlak, dat je dan ook op de kaart altijd een open route houdt die dan steeds verlegd wordt naar mate de situatie naar de eindsituatie gaat. Volgens mij hadden we zoiets in Leeuwarden bij het verbouwen van een groot verkeersplein (Europaplein). Het maakt dan niet uit dat je kaartkopie achterloopt; hooguit loopt je lijntje wat scheef vergeleken met de werkelijkheid.
Toch was de tagging juist.
Er zijn navigaties-apps die daar (nog) niet mee om kunnen gaan.
Maar als wij dat correct en vaak genoeg gebruiken, zullen de bouwers van een navigatie-app dat ook gaan gebruiken.
Ik heb dit topic doorgelezen. Eerder deed ik aan soortgelijke discussies mee. Hier is nu nogmaals zo ongeveer alles weer gezegd. De conclusie is dat mappers highway=construction,construction=X alleen moeten gebruiken bij nieuwe wegen en daar waar wegen worden vervangen door iets wat cartografisch degelijk anders is. De navigatiesystemen gaan slecht met highway=construction om, omdat het weinig voorkomt, maar omdat het daar waar het voorkomt zeer cruciaal kan zijn, leidt het tot grote problemen en discussies op o.a. dit forum. N.a.v. topics als deze zouden eigenlijk bug-reports gemaakt moeten worden naar de makers van de navigatiesystemen.
Voor de kaartenmakers zouden volgens mij de regels preciezer moeten zijn:
Wanneer gebruik je highway=construction,construction=X? Bij nieuwe wegen wanneer met de aanleg begonnen is; bij wegen in ombouw wanneer met de sloop van de oude situatie is begonnen.
Wanneer ga je over naar highway=X? Nou … eigenlijk dus al wanneer de weg dusdanig berijdbaar is voor verkeer dat verkeer er overheen zou kunnen. Wanneer de weg daadwerkelijk weer / voor het eerst opengaat mogen navigatiesystemen van elders halen. En als navigatiesystem bij het weer / voor het eerst openstellen van de weg de aanpassingen er aan of het bestaan ervan nog niet hebben meegekregen met een update dan is dat toch echt een probleem voor het navigatiesysteem.
Beste Josbert,
Het probleem dat hier speelt is dat OSM Engels talig is en mogelijk daarom geen onderscheid kent tussen aanleg en onderhoud in welke vorm dan ook. Landuse=construction / highway = construction, reconstruction is onbekend terwijl dat in veel gevallen hier beter zou zijn.
Of een andere mogelijkheid is om te vertrouwen op de actueel aanwezige omleidingen die tegenwoordig bij iedere langdurige uitvoering verplicht worden geplaatst. Maar dan geen construction plaatsen voor een reconstructie in uitvoering, scheelt ook het monitoren van een construction werk (site)
Oh, er is al een issue van: https://github.com/Project-OSRM/osrm-backend/issues/5801
Maar hier is 0 reactie op gekomen, dus het lijkt erop dat dit niet erg hoge prioriteit heeft. Zoals ik zeg: ik vind OSRM maar een gekke router.