Naar aanleiding van changeset: Changeset: 133886605 | OpenStreetMap Vraag ik mij af of er een actualiteitsveld in OSM aangemaakt kan worden. In bovenstaand voorbeeld zou je kunnen bedenken dat er automatisch een !-teken geplaatst kan worden op het object, bij voorkeur gekoppeld aan een begin- & eind-datum. Het nut hiervan: Diegene die OSM gebruiken als route planner zien dan in bovenstaand voorbeeld dat deze parkeergarage voorlopig NIET gebruikt kan worden, waardoor een gebruiker VÓÓR het daadwerkelijke ritje niet op plaats van bestemming voor onaangename verrassingen komt te staan, zoals niet je auto kwijt kunnen … Andere voorbeelden zijn te bedenken m.b.t. wegwerkzaamheden, tijdelijk gesloten andere gebouwen enz.
Omdat ik een te nieuwe ‘mapper’, zelf vindt mij meer een ‘verkenner’ hier heb ik deze vraag eerst bij A67-A67 via mail neergelegd:
Met zijn geniale response: “ De correcte tagging voor tijdelijke verboden werkt met access:conditional. Helaas ondersteunen de eenvoudigere navigatiesystemen conditionele tagging niet of niet goed.
In dit geval zou de correcte tag iets zijn als access:conditional = private @ (2023 Mar-2023 Oct).”
Ik ben benieuwd hoe anderen reageren op bovenstaand voorstel.
Mijn motto: “Alleen kom je ergens snel, met een groep kom je echter CORRECT verder !”
Voor tijdelijke afsluitingen wordt inderdaad meestal de tag access:conditional gebruikt, zie ook de wiki-pagina’s Conditional restrictions en access.
Het is correcte tagging, maar wij hebben er geen invloed op hoe renderers en navigatiesystemen met onze data omgaan. We kunnen dus geen !-teken taggen, maar slechts een restrictie. De renderer bepaald hoe dat eruit zit. De goede OSM-navigatiesystemen ondersteunen access:conditional en weigeren toegang binnen die tijden. De slechtere OSM-navigatiesystemen begrijpen die tag dan weer niet.
Helaas gaat er niks automatisch!
Iemand zal moeten aangeven wat er aan de hand is, wanneer dat begint en wanneer het eindigt.
En dan moeten de toepassers het op hun kaarten weergeven en in hun navigatie gaan gebruiken.
Vervolgens moet iemand ook in de gaten houden of de werkelijkheid wel klopt met de aankondigingen, en zo niet, eea aanpassen.
Hoe het gaat is dat getagd wordt hoe het NU is, als iemand zich daartoe geroepen voelt. Daarna blijft dat zo tot iemand zegt: hoho, dat klopt niet (meer). En dan tagt die de toestand op dat moment.
Je kan er een note op zetten, maar dat is vrije tekst en wordt niet voor gebruikerstoepassingen gebruikt.
Er zijn vrijwel geen planningsmogelijkheden in OSM.
Zoals in mijn changeset als voorbeeld gegeven zou het een extra stimulans zijn voor gebruikers om OSM als navigatiesysteem te gebruiken boven bijv. Google maps die deze functionaliteit niet heeft, als deze actualiseringsfunctionaliteit er WEL in zou zitten.
Voor de goede orde: OSM is in de eerste plaats een database met geografische gegevens. Daar kun je kaarten van maken zoals je onder andere op osm.org kunt zien (maar er zijn er meer), en je kunt er een routing/navigatie applicatie op bouwen (OSRM, GraphHopper, Valhalla, BRouter/OSMAnd etc )
Zo’n signalering van geslotenheid is op zich een goed idee. Maar om dat gerealiseerd te krijgen zul je mijns inziens de makers van de navigatie app(s) moeten benaderen met een aanpassingsverzoek.
Heeft iemand binnen dit forum rechtstreekse contacten met navigatie app bouwers toevallig ?
Hoe meer gebruikersgemak binnen deze apps hoe meer vraag er zal zijn naar OSM data hoe meer kwaliteit wij als OSM-mappers kunnen leveren. Dit komt OSM NL en wellicht verder in de OSM boom, bij succes, ten goede. Ik wil wel een poging wagen hoor !
Of hun navigatie app gebruik maakt van: access:conditional = private @ ([begindate]/[begintime]-[enddate]/[endtime]) statements en zo ja of er een mogelijkheid is op true waarden een doorzichtige !-teken te plaatsen op die items voor de in het statement aangegeven periode…
Dit dan met de eerdere uitleg van mijn gestartte post.
Dat is dus voor de rendering. En dat dan alleen voor parkeergarages, of alle gebouwen, of alle objecten, ook barriers?
En voor de routering: wordt een parkeergarage uberhaupt in de routering meegenomen? Ik dacht dat routering vooral over de wegen ging.
Is access:conditional = private @ ([begindate]/[begintime]-[enddate]/[endtime]) specifiek genoeg voor de bedoelde gevallen, of vallen er ook niet-bedoelde gevallen onder? Want dan zou de kaart allemaal uitroeptekens gaan tonen waar je ze niet bedoeld had.
Alle objecten zodat iemand VÓÓRAF ziet dat er op bijvoorbeeld plaats van bestemming dingen gaande zijn die zijn of haar plannen in de war kunnen gaan schoppen, waardoor je je plannen of routering daarop kan aanpassen…
Of onderweg… dan krijgt dus alles waarop een conditie staat een uitroepteken op de kaart. Vergeet niet dat de renderer niet weet wie welke bestemming op welk moment gaat hebben, dus alles is een bestemming.
Of moet het uitroepteken alleen verschijnen als de toepassing een route aan het plannen is, en dan alleen op relevante objecten voor die route?
Ik gebruik zelf OsmAnd, ik heb bij hun ook wel eens een verzoek neergelegd, ik weet niet meer precies hoe. Dat is ff uitzoeken dus. Brouter hoor ik vaak noemen, en OSRM, maar daar heb ik geen ervaring mee.
Suk6 ermee!
Bedankt Peter !
Even uitzoeken bij wie ik precies moet zijn maar vooral ook eerst zorgen dat er velden gevuld worden met precies de eerder besproken waarden…
Heeft OSM een soort “Fantasia” test map faciliteit ?
Ik bedoel daarmee een alleen digitaal & in werkelijkheid niet bestaand stuk land voor test- & voor newbie’s zelflerende doeleinden…
Die parkeergarage heeft nu toch een geldige access:conditional=* tag? Dan kan daarmee getest worden. Aangezien een routeerapp de data niet wijzigt, kan de ontwikkelaar daarmee testen. Ik zou geen testdata verzinnen als er ook echte data is.
Daar mee eens maar: ik wil ook weten of t op andere objecten ook mag en/of dat er kwa definitie het wel mag maar toch ergens fout geïnterpreteerd wordt… Ik heb zelf al aangegeven ik heb nog niet veel mapping ervaring & eerlijk gezegd me op dit moment meer thuis voel in een soort verkennersrol dan mapping rol juist bij gebrek aan mapping-ervaring
Conditional access is niet het gemakkelijkste onderwerp om mee te beginnen, maar deze pagina gaat erover.
Let wel, het gaat meestal niet over gebouwen, maar over wegen en barriers.
Andere objecten die baat zouden hebben bij [access:conditional] zijn OV-liften… Ik heb zelf uitjes in het water zien vallen als mantelzorger omdat op een station een OV-lift defect was… sta je daar op een station met iemand in een rolstoel samen niet de volgende verbindende overstap kunnen maken… Daarbij weet ik inmiddels ook uit ervaring dat OV-liften die vervangen worden door Pro-rail een gemiddelde 3 MAANDEN vervangingstijd vergen…
Andere op toepasbare voorbeelden:
openbare zwemwater plekken:
die door test-instanties afgekeurd worden voor een bepaalde tijd
Veiligheidsdriehoek instanties:
“de bekende houd ramen en deuren dicht”-meldingen