Tijdelijke wegafsluitingen en nieuwe wegen: highway=construction

Hoi,
Ik zag op openstreetmap.org niets van de werkzaamheden aan de Ring Zuid van Groningen, de ringweg die de komende 4 maand (van begin mei t/m 2 september) gesloten is, stond er in alsof deze “af” was, met highway=trunk en dan een aantal access:conditional=no@(begindatum-einddatum) erop.

Ik heb dat in changeset 151275524 gewijzigd, zodat alle wegen die volgens Wat is dicht? - Website Aanpakringzuid dicht zijn op highway=construction staan. De access:conditional=no heb ik laten staan, al zag ik wel dat daar een boel fouten in zaten: de ringweg-zuid ri Julianaplein had al 8 verschillende waarden van begin- en einddatum (Terwijl ze allen dezelfde einddatum hebben)

Ook heb ik het tijdelijke Meeuwerderbaan->Herewegboogje de access=no + access:conditional=yes @ (tijdvak) verwijderd: deze weg is nog open tot deze dicht gaat en dan permanent verwijderd wordt en van Openstreetmap mag.

Maar wat vinden jullie nou de juiste manier van taggen? Werken met access:conditional is beter voor de router die weet wat 'ie er mee aan moet en niet vaak bijgewerkt wordt, maar rendert totaal niet op openstreetmap. Highway=construction werkt wel voor routers nu, maar geeft problemen voor routers die niet vaak bijgewerkt worden. Mijn persoonlijke ervaring met andere projecten (zoals bijv de A9 Gaasperdammerweg, die ik zelf bijgewerkt heb, of A9 Amstelveen, waar ik nauwelijk iets mee doe) is dat highway=construction binnen enkele uren na opening goed bijgwerkt is. Routers die niet vaak bijgewerkt worden zullen altijd dingen missen, en routers zoals OSMand kunnen tegenwoordig elk uur met delta updates bijgwerkt worden.

hi @IIVQ
Ik vind zelf eigenlijk dat highway=construction de betere oplossing is.

De access:conditional is een workaround voor die twee problemen:

  1. binnen OSM is er geen goede methode is om dergelijk constructions actief bij te houden. Het is erg afhankelijk van hoe actief de mapping community lokaal is.
  2. Routers worden niet allemaal frequent genoeg bijgewerkt.

Die tweede vind ik eigenlijk een probleem van de router. Zoals je zelf zegt: OSMAnd kan zelfs per uur worden bijgewerkt.

Voor die eerste spelen een paar dingen:

  1. Er is geen goed systeem om bij te houden welke werkzaamheden zijn afgerond
  2. Het kost relatief veel tijd om wegwerkzaamheden op een weg te zetten én er vervolgens weer af te halen.
  3. Zeker bij werkzaamheden die in fasen uitgevoerd worden is het tijdrovend. De informatie moet je dan van een website halen en goed doorgronden en niet elke gemeente is hier even duidelijk in.

Eigenlijk zou je een soort automatische revert willen als de constructie eind-datum voorbij is. Met het nadeel dat die eind-datum nogal eens wil verschuiven.

1 Like

Een quasi redelijk systeem is het toevoegen van check_date als de construction ingekaart wordt en een beoogde open_date, als het aangegeven is. Zeker StreetComplete zal surveyende mappers vragen hoe de stand van zaken is… ‘is deze constructie al klaar?’ Diverse afgelopen week hiermee gesloten… natuurlijk moeten de tags wel goed staan bijv highway=construction + construction=residential.

1 Like

Ik zou zelf zeggen:

  • nieuwe wegen en wegen waarvan het alignement grootschalig gaat wijzigen (wat voor mij een nieuwe weg is): highway=construction
  • wegen die langdurig (mijn gevoel: >3 maand, of voor snel- en autowegen >1 maand) gesloten zijn: highway=construction
  • wegen die tussen 9 dagen en 1/3 maand gesloten zijn en grotendeels het alignement houden: access:no=conditional @ (begindatum-einddatum)
  • wegen die tussen 0 en 9 dagen (= 1 week met 2 weekenden) gesloten zijn: niets aan doen.

Mijn ervaring is dat de geplande einddatum van wegafsluitingen in Nederland over het algemeen redelijk tot op het uur gevolgd wordt*, dus dat dat met de conditional tag redelijk te doen is. Klopt mijn interpretatie dat met de conditional-tag geen eindtijd aangegeven kan worden bij een meerdaags evenement (dus bijv: van vrijdagavond 23:00 tot maandagochtend 5:00, wat wordt omgezet in van vrijdag tot maandag, elke nacht van 23:00 tot 5:00)?

*niettegenzeggende dat ik op mijn werk (in het OV) eens de grootste problemen heb gehad met grootschalige werkzaamheden waar pendellijnen voor in dienst waren gekomen; die 2 weken eerder klaar waren dan gepland; dáár hadden we geen rekening mee gehouden, we hebben dus nog 2 weken de omleidingsroute gereden met 2 extra overstappen, terwijl de gewone weg al klaar was; lopen was bijkans sneller.

3 Likes

Je kunt sowieso altijd voor zo’n soort gedrocht gaan:
2024 Apr 04: 08:00-24:00; 2024 Apr 05-2024 May 12; 2024 May 13: 00:00-14:00
Maar eerlijk is eerlijk, ik sluit zulke situaties meestal af op basis van de datum, niet het uur :see_no_evil:

Het probleem is eigenlijk dat er voor verschillende toepassingen verschillende drempels zijn tussen korte en lange termijn. Voor een verkeersmodel voor een kalenderjaar is dat anders dan voor een navigatiesysteem waarop een consument eens per kwartaal een nieuwe netwerkversie installeert of voor een online routeplanner die dagelijks een nieuw netwerk binnenhaalt.

Voor middellange afsluitingen is het wellicht een oplossing om highway=construction conditioneel routeerbaar te maken:

highway=construction + access=yes + access:conditional=no @ (periode van afsluiting)

Een voorstel doen en een discussie starten staat je natuurlijk vrij, maar de gang van zaken m.b.t. de wijzigingen in Groningen staat me niet aan.

Het gebruik van access:conditional staat uitgebreid gedocumenteerd op de wiki en is momenteel de geldende praktijk voor tijdelijke afsluitingen. highway=construction is hier volgens de huidige richtlijnen niet voor bedoeld. Er is op dit forum overleg geweest over het taggen van de werkzaamheden aan de Groningse ringweg en de conclusie was van access:conditional gebruik te maken en van OSM geen faseringskaart te maken. Meerdere mappers hebben vervolgens hun best gedaan om de restricties zo goed en precies mogelijk in tekenen.

Deze precisie compleet van de kaart vegen en vervolgens de boel naar eigen inzicht “op gevoel” taggen en daarna pas een forumtopic openen om de manier van taggen te bespreken lijkt me niet de juiste volgorde. Ik heb je wijziging daarom voor nu teruggedraaid. Mocht de consensus daadwerkelijk veranderen dan is dat uiteraard reden om dat ook naar de kaart te vertalen.

Dan over het voorstel zelf:

Je lijkt te veel uit te gaan van je eigen usecase (een router die zich elk uur bijwerkt), terwijl er, zoals Jeroen opmerkt, veel meer afnemers van OSM zijn die hun materiaal (volkomen terecht) niet constant bijwerken. Dan wil je niet maandenlang een gat in de A7 hebben.

Ook dit impliceert dat routers de enige data-afnemers van OSM zijn. Afgezien daarvan vind ik de opmerking te stellig. Er zijn genoeg legitiieme redenen om als router(-gebruiker) geen extreem bijgewerkt kaartmateriaal te hebben. Het is ook niet toevallig dat dit bij OSMAnd een betaalde functie is.

Iedereen mag natuurlijk zo veel tijd aan OSM besteden als hij/zij wil. Als iemand tijd wil besteden aan een gedetailleerde weergave van begin- en einddata lijkt me dat altijd te verkiezen boven het simpelweg verwijderen van een weg (vandaar ook mijn ongenoegen dat IIVQ deze gedetailleerde informatie klakkeloos verwijderd heeft).

Bij access:conditional is dit in principe optioneel als er een einddatum is aangegeven. Als iemand op een gegeven moment een verouderde conditional tegenkomt kan deze verwijderd worden, maar het laten staan heeft geen gevolgen. Dit in tegenstelling tot highway=construction, dat op het juiste moment moet worden omgezet en niet vergeten moet worden.

Wat is de meerwaarde van dat onderscheid? De N7 door Groningen volgt al decennia hetzelfde tracé en behalve het bouwniveau (boven- → ondergronds) verandert daar weinig aan. Wat mij betreft is dit geen reden om de weg te verwijderen (want highway=construction is geen functionerende weg) en later weer in te tekenen. Mijns inziens is highway=construction voorbehouden aan daadwerkelijk nieuwe wegen in aanbouw zoals in een nieuwbouwwijk, een nieuwe rondweg rondom een dorp of, om in het Groningse te blijven, de Máximaweg en de verbinding Drachten → Groningen-centrum. En verder wegen die serieus langdurig in aan-/verbouw zijn (als in: het merendeel van een jaar of meer). Nogmaals: OSM is geen faseringskaart.

Ook dit komt nogal arbitrair op mij over en ook hier ontgaat me de meerwaarde van het onderscheid. Er staat al een richtlijn op de wikipagina voor highway=construction; al met al mis ik een duidelijk overtuigend argument om hiervan af te stappen.

Ik zal later op meer punten reageren maar even een eerste reactie:

•Ik heb niets verwijderd. Alle access:conditionals staan er nog, als je alle construction=trunk(-link) de key in highway verandert ben je weer terug bij de oude situatie. Dat kan ik met JOSM binnen 2 minuten als het moet.
•De tunnelbak/verdiepte ligging en het knooppunt Julianaplein is echt een nieuwe weg (t.o.v. de oude verhoogde weg en het oude Julianaplein). Die hoort. m.i. echt op highway=construction tot die in gebruik genomen wordt.
•Bas85’s manier van taggen met access:conditional werkt wellicht voor /routeerders/ maar laat visueel op dr kaart geen afsluitingen zien. Ik dacht echt dat ik de Ring Zuid kon volgen. Dat blijkt de komende 3½ maand niet te kunnen.
•Ik heb de praktijk van highway=construction toegepast zoals ik gedaan heb bij het (door mij 5 jaar lang bijna tot op het uur bijgewerkte project) Gaasperdammertunnel (A9) en die ik anderen ook zien doen bij andere vergelijkbare snelwegombouwprojecten, zoals o.a. de A9 Amstelveen en A1 Muiden. Daar lukt het mensen ook goed om werkzaamheden bij te houden. Bij grotere werkzaamheden is vaak al maaanden van te voren een planning tot op uurniveau van afsluitingen bekend.
Ik had vaak ook agendameldingen van wanneer ik wijzigingen in OSM moest doen.
•Niet-vaak updatende routers bedienen is een zogeheten /wicked problem/. Als je naar de toekomst werkt bedien je altijd mensen die op de nieuwe weg afkomen, terwijl er altijd mensen zijn die met een oude kaart rijden. Dan kan je maar beter zo actueel mogelijk zijn, zodat je weet dat een recente kaart actueel is.

Laten we de discussie zuiver en vriendelijk houden. Het kan zijn dat je het niet eens bent met de volgordelijkheid die iemand hanteert (bijv. handelen voor de beraadslaging), maar laten we uitgaan van elkanders goede bedoelingen.

2 Likes

Als ik het goed lees, is dit eigenlijk een verzoek aan Carto (om maar een renderaar te noemen) om wegen met access:conditional anders weer te geven, waardoor het voor de visueel ingestelde kaartlezer óók duidelijk wordt dat er iets gaande is op het getoonde tracé.
Dat is zoals allicht bekend problematisch omdat de vormgeving van Carto’s kaartlaag buiten onze invloedssfeer ligt… Misschien dat het team achter Tracestack topo iets makkelijker te bewegen is…?

1 Like

Misschien is deze discussie van internationaal belang, en zou er een draad in het Engels gestart moeten worden?

De wiki beschrijft dat “Already existing features may be closed for a short time for a temporary construction (e.g. old, damaged roads getting rebuilt). Don’t use construction=* to tag such short-term closures (e.g. a road closed over a weekend to replace a sewer pipe); consider using conditional restrictions instead. As OSM data is often used offline (and therefore may be several months old), only tag construction sites if they are planned to be closed for at least six to nine months.” Misschien is verduidelijking van deze tekst noodzakelijk (o.a. voor- en nadelen van het gebruik van construction=* vs. conditional restrictions voor routers en visuele kaartgebruikers)?

Eerlijk gezegd vind ik dat data users waarvoor actualiteit van de gegevens belangrijk is, zelf verantwoordelijk zijn voor de verversing. Ons probleem is alleen om de gegevens actueel te houden. Aantekeningen over verwachte ontwikkelingen bij projecten zijn voor mappers, niet voor data-users.

Of en hoe een renderer conditional access verwerkt en weergeeft is een ander onderwerp.

1 Like

ik vermoed dat dit er zo staat vanwege het probleem van hoe vaak er ververst wordt; dezelfde reden die @85Bas aangeeft om conditional te gebruiken.

20 jaar geleden werd mijn kaartenboek nooit ververst. Ja; door een nieuwe te kopen. 10-5 jaar geleden was mobiele data vrij duur; dus dan had je het kaartmateriaal offline op je mobiel staan en werkte je die eens in de zoveel tijd bij. Zelfs TomTom ververstte de kaarten slechts 1x per jaar. Toen elk half jaar, toen elke drie maanden en inmiddels elke maand; waarbij wegwerkzaamheden, blokkades en files elek 2 minuten worden ingeladen.

Je ziet dat diezelfde evolutie bij OMS. Meer en meer apps en webpagina’s gebruiken OSM en steeds vaker om te navigeren. Daarbij is het fijn als een router de conditionals inleest en een andere route aanbied; maar als ik op de fiets zit en ik krijg een route die ik niet snap, volg ik die niet. Dan is het prettig om hiervan ook een visuele indicatie te hebben dat er een weg opgebroken is.

@Lachgast (a.k.a. Luciën) geeft wel een goede omschrjiving dat ‘access:conditional’ voor de visueel ingestelde kaartlezer niet lekker werkt. Zou fijn zijn als de renderers hier iets mee deden. Maar helaas zijn die niet dynamisch genoeg en Carto is toch nog steeds de default.

Maar het zorgt wel voor vervuiling van de tags, ik weet niet wat ik liever heb; her en der allemaal verlopen conditionals of een visuele indicatie op de kaart die heel duidelijk maakt dat de weg niet toegankelijk is vanwege werkzaamheden? En dus voor veel meer mensen zichtbaar is en weg te halen.

En een conditional die verlopen is; mag je daar zomaar vanuit gaan dat deze verwijderd mag worden? Moet je dat nog controleren of mag je een verlopen tag rücksiglos weggooien?

Over verlopen “conditionals” (tijdelijke afsluitingen) en hoe dat potentieel vervuilend werkt in de database van OSM omdat het op het oog niet zichtbaar is:

Dit zou je kunnen ondervangen met een regelmatig uitgevoerde SQL-bevraging op alle wegen met “access:conditional=no”. Mocht de aangegeven periode zijn verlopen, dan kan, na raadpleging van Melvin (om na te gaan of een afsluiting (nog) actueel is) de “access:conditional”-riedel verwijderd worden.

Over het algemeen is Melvin voor Nederland een betrouwbare bron voor afsluitingen (en hun duur).

1 Like

Er staat nergens dat voor wijzigingen een concensus op het forum nodig is. Ik heb inderdaad gewijzigd en daarna daar een melding gemaakt ter lering en discussie.

Door mijn wijziging integraal terug te draaien en daarna pas te reageren doe je hetzelfde. (Dat staat mij niet aan!) Bovendien heb je zelfs onjuistheden ge(her)introduceerd. Deze weg: Way: ‪Weg der Verenigde Naties‬ (‪142492406‬) | OpenStreetMap is nu toegankelijk en zal hierna afgebroken worden. De access:no op deze weg is dus fout.

“uitgebreid gedocumenteerd” vind ik wat overdreven. Er staat één casus op bij de voorbeelden Conditional restrictions - OpenStreetMap Wiki en ook bij highway=construction staat het niet als duidelijk alternatief. Of ik mis iets op de wiki.

Dat eerste zie ik niet zo, maar wellicht ben ik ouderwets.
Dat tweede lijkt mij zeker wel de bedoeling voor de ring-zuid. Dat is namelijk een nieuwe weg en way, die nooit eerder berijdbaar is geweest.

“De conclusie” haal ik niet uit de twee forumposts die je aanhaalt, daar wordt in de 2 forumposts samen één keer over conditional tagging gesproken door iemand anders dan jij. Dat noem ik geen conclusie. Maar het kan zijn dat ik wat mis, ik volg het forum niet altijd even actief en gebruiken kunnen wijzigen.

Hier komen we op de diepere discussie:
Personen die op openstreetmap.org kijken of een app gebruiken die de data gebruikt van openstreetmap.org gebruiken altijd een snapshot van data, die uit verschillende momenten kan komen. Jij lijkt te redeneren vanuit de gebruiker die eventueel op 1 juni (middenin de werkzaamheden) een download doet, en dan daarna op 1 oktober (als alles weer open is) een route gaat plannen.

Maar omgekeerd geldt hetzelfde probleem voor de gebruiker die op 1 januari een download heeft gedaan (oude route nog open) en op 1 juni (in de werkzaamheden) een route plant. Die denkt dat de weg nog open is maar dat is die niet. Zeker in dit geval kom je er dan te laat achter: je eerste mogelijkheid om (vanuit Drachten) af te buigen is afrit Groningen-Zuid, maar daar kom je de snelweg niet meer op. Je had al veel eerder de borden moeten volgen en de ring west-noord-oost moeten volgen.

Plant diezelfde gebruiker op 1 oktober zijn route (bijv van Hoogezand naar Assen), komt die wéér bedrogen uit: die denkt op het Julianaplein links te moeten slaan, maar in werkelijkheid moet hij al ervoor rechts voor te sorteren om deze boog te nemen. Kortom: in dit geval (een grootschalige wijziging, het nieuwe wegalignement is echt anders dan het oude) ben ik het niet mee eens dat de weg “open moet blijven”.

Een gebruiker die nu naar de kaart openstreetmap.org kijkt, heeft geen enkele reden om aan te nemen dat de N7 niet bruikbaar is. Er staan geen “construction-strepen” op, en géén “access=no”-strepen. Dat komt omdat access:conditional eigenlijk meer bedoeld is voor zaken als “elke marktdag gesloten”, iets dat de renderer nooit bij kan houden. Ik verwacht dan ook niet dat renderers snel access:conditional zullen gaan renderen, omdat bepaalde wegen dan enkele keren per dag herrenderd moeten worden.

Zoals eerder gezegd: ik heb niets verwijderd, de access:conditionals die er waren heb ik volledig intact gelaten (met uitzondering van dit stukje weg).

Zoals hierboven aangehaald: Het gaat hier niet om een stukje snelweg dat nieuw asfalt krijgt.
De route is volledig anders, je rijdt zo veel zuidelijker dat sommige niet-bijgewerkte navigatiesoftware zal denken dat je op een andere weg rijdt. Bovendien zijn routebeslispunten op geheel andere plekken en in andere richtingen (rechtsaf een afrit ipv linksaf op een VRI-kruispunt).

In dit geval is deze weg dus nooit eerder bereden, dus is m.i. highway=construction de juiste tag. Wellicht i.c.m. iets voor 2 september (als alles weer open gaat) de highway=construction er af en access:conditional er op.
Die access:condtional mag er altijd al op staan, maar tijdens highway=construction doet deze niets anders dan als note voor evt taggers gelden.

Waar baseer je op dat OSM geen faseringskaart zou moeten zijn? Bij meerdere andere grote snelwegprojecten wordt de fasering — met highway=construction — vrijwel realtime bijgehouden. Door mij én door andere gebruikers. Dat is dus niet het probleem.
Vaak zijn we daardoor als OSM véél preciezer dan Google, die soms maanden na een snelweg open is nog niet bruikbaar is voor navigatie.

En ik deel niet jouw visie over highway=construction (en dat is punt voor discussie), noch dat de N7 geen nieuwe weg zou zijn (zie hierboven)

Klopt, maar ik en anderen hebben het al vaker over deze 3 maand gehad. Waar kan ik zo snel niet vinden, dat moet op het oude forum geweest zijn. De 9 maand is meer op de amerikaanse leest geschoeid waar werkzaamheden vaak “zomaar verschijnen” en klaar zijn “als het klaar is”. Niet op de Nederlandse situatie waar soms al maanden van te voren een planning op uurbasis beschikbaar is.

Ware het niet dat er een access:conditional=yes op staat voor de periode waarin deze wel toegankelijk is, aangezien dit stuk weg maar zeer tijdelijk geopend is.

Ook deze eerdere opmerking met betrekking tot onjuistheden herken ik trouwens niet. Na mijn eerdere reactie heb ik de ringweg nagelopen en alle einddata stonden (waar toepasselijk) netjes op 1 september.

“Verwijderd” was een verkeerde en te sterke woordkeuze van mijn kant, al is het maar omdat OSM de geschiedenis bijhoudt en er dus nooit écht gegevens verdwijnen. Hier de nadruk op leggen had ik dus achterwege moeten laten. Zoals eerder benoemd in dit topic hebben we allemaal de beste bedoelingen.

Echter, door een wegstuk te veranderen in highway=construction verliest access:conditional=no zijn functie en is het feitelijke gevolg voor de kaart hetzelfde als de access:conditionals weghalen. Je benoemt zelf ook dat het dan niets meer is dan een notitie voor andere mappers en verlaagt op die manier het detailniveau van de kaartgegevens.

Ik heb zelf geen forumposts aangehaald; de persoon die op je changeset heeft gereageerd is iemand anders. Dat het overleg summier was met een beperkte respons ben ik met je eens maar dat is nu eenmaal zo. Er is in ieder geval vooraf overleg geweest en daarnaast volgt de uiteindelijke tagging de richtlijnen op de wiki. Dit “hetzelfde” noemen als de gang van zaken bij jouw wijziging lijkt me niet helemaal terecht.

Voor een groot deel redeneer ik überhaupt niet vanuit de gebruiker van een router, wat in dit topic wel steeds gedaan wordt. Een route plannen is slechts een van de vele toepassingen van OSM-data (en een van de weinige waarbij constant nieuwe data downloaden echte meerwaarde zou bieden). Er zijn vele andere toepassingen voor OSM-data zoals verkeersmodellen of achtergrondkaarten voor software. Iemand die, ik noem maar iets, een poster van de kaart van Groningen wil printen, zou kunnen ontdekken dat de belangrijkste weg van de stad, die er al heel lang ligt en er nog heel lang zal liggen, op zijn kaart ontbreekt. (Klein bier natuurlijk, maar je snapt het voorbeeld.) Ik heb ook fysieke plattegronden gezien op basis van OSM. Daar moeten alle wegen gewoon op staan, ook wegen die jaren geleden toevallig een paar maanden gesloten zijn geweest.

Een route plannen die niet blijkt te kloppen vanwege tijdelijke werkzaamheden is vanuit het oogpunt van de gebruiker beter te begrijpen dan een route die niet werkt omdat er ten tijde van de download toevallig tijdelijke werkzaamheden bezig waren.

Als de conditional trouwens tijdig is ingevoerd zal er überhaupt niet langs worden gerouteerd, in tegenstelling tot de situatie waarbij er gewacht wordt met de aanpassing naar highway=construction tot de eerste dag van de werkzaamheden.

Klopt. De precieze instructies zullen inderdaad afwijken, wat ook prima te verklaren is door het verouderde kaartmateriaal, maar de globale route A7 → A28 is wel gewoon te volgen. Bij een highway=construction zou de gebruiker (waarschijnlijk) door woonwijken geleid worden, of over een tijdelijk viaduct dat niet meer bestaat.

De N7 door Groningen is al decennia de N7 en zal dat ook nog decennia blijven. Dat die route een paar maanden niet beschikbaar is betekent niet dat deze van de kaart moet worden verwijderd (wat omzetten naar highway=construction feitelijk inhoudt). Dat is de kern van mijn argumentatie. Als ik nu een wegenkaart koop of een plattegrond van Groningen opzoek (online of op straat) dan staat de N7 er ook gewoon op. Volkomen terecht natuurlijk.

Routers zouden de tijdelijke afsluitingen waarover we hier discussiëren eigenlijk uit Melvin moeten halen; op de basislaag van OSM hebben ze wat mij betreft niets te zoeken. access:conditional is dan een redelijk, niet-destructief compromis. highway=construction tot op het uur nauwkeurig bijhouden is wél destructief en werkt alleen maar voor een zeer beperkte groep gebruikers van OSM-data, waar jij (en ik trouwens ook) toevallig onderdeel van uitmaakt.

Als in dat geval de routering op de basislaag wordt aangetast voor een tijdelijke afsluiting dan is dat naar mijn mening dus wél een probleem; over dat meningsverschil gaat dit hele topic volgens mij.

Gebruikmaken van access:conditional is toch nóg preciezer en gedetailleerder, of zie ik dat verkeerd? En daar heeft ook de 99.9% van de OSM-gebruikers die niet betaalt voor OSMAnd Live iets aan. En gebruikers die een snapshot voor langdurig gebruik nodig hebben zitten niet met een gat in de kaart (visueel danwel qua routering).

Blijft (volgens mij) de kern van het probleem over: de visuele rendering. Dat lijkt me zoals eerder genoemd iets om aan te kaarten bij de betreffende renderers. Al deel ik je visie op de kans van slagen daarvan, gezien de complexiteit en vele verschillende manieren om conditionals te gebruiken. Toch is dat naar mijn mening geen reden om “op gevoel” van de huidige manier van taggen af te wijken.

In dit geval vind ik de visuele rendering toch wel van belang. De site over de werkzaamheden aan de ring (aanpakringzuid.nl) bevat regelmatig nieuwsberichten, waarin kaartjes van OSM gebruikt worden (netjes met bronvermelding).

1 Like

Zou het kunnen werken als we het verschil aanduiden met betrekking tot de staat van de weg. Bij volledige reconstructies zoals deze is er een fase waar een weg in aanbouw is. Dan bestaat de weg nog niet dus dan zou highway=construction van toepassing zijn.

Maar dat als de weg klaar is maar nog niet open, bijvoorbeeld omdat een aansluiting nog niet af is of omdat de strepen nog moeten dan zou een access:conditional meer van toepassing zijn.

Ik weet niet wat de huidige staat is van de weg, maar is dit iets waar jullie je in kunnen vinden?

Nee, want dan krijg je een discussie over wat “af” is. Hier in de Gaasperdammertunnel ligt een wisselstrook die al 5 jaar er compleet af uit ziet. Maar er heeft jog geen auto over gereden, in knooppunt Holendrecht komt het asfalt op niets uit. Die is dus nog gewoon under construction om aan te geven dat het geen deel is van het huidige openbaar toegankelijke wegennet.

2 Likes

Hierbij een algemene reactie over dit onderwerp. Ik woon ver van Groningen vandaan, dus ik ken de specifieke weg niet.

Ik begrijp niet waarom we bij (langdurige, bijvoorbeeld meer dan één maand) afsluitingen de highway niet gewoon op access=no zetten (als de weg in kwestie nog bestaat) of highway=construction (als de weg compleet opgebroken is).

Zoals al eerder opgemerkt in deze thread, conditional access tags lijken me niet echt voor dit soort zaken bedoeld (hoewel het wel een mooie hack is) want het rendert in het algemeen niet. Je kunt niet van renderers verwachten dat ze conditional tags gaan parsen om erachter te komen hoe een weg momenteel gerenderd moet worden, en dan ook nog tiles automatisch in de renderqueue gooien als de conditional access verandert.

Als een weg niet berijdbaar is, lijkt een “gat in de routering” me geen probleem, maar juist wenselijk!

Dat bepaalde datagebruikers hun kaartmateriaal niet vaak genoeg bijwerken, is hun eigen probleem; wat mij betreft is dit geen reden om wijzigingen dan maar niet te doen. En als je een papieren kaart maakt, dan kun je highway=construction gewoon als een normale highway renderen als de construction binnen x maanden klaar is (gebaseerd op opening_date o.i.d.). Je kunt deze zelfs in de routering meenemen, mocht je dat willen.

(Je moet dit natuurlijk als mapper alleen doen, als je ook de toewijding hebt om zodra de weg weer open gaat, de boel weer netjes terug te zetten. Maar aan toewijding is er naar mijn ervaring bij de meeste OSM’ers geen gebrek :smiley:)

4 Likes