In deze changeset worden de tagging aangepast waarschijnlijk om LiveNav te beïnvloeden. Wat doen we hiermee en waar ligt de grens.
Wat doet deze tagging met het reguliere verkeer?
Normaal is emergency=yes voldoende om bv een wegbreedte te overrulen. Nu maxspeed:advisory om 60km/u te overrulen.
maxspeed:advisory geldt voor alle verkeer, dus tenzij er een vierkant blauw bord met 80 staat naast een normaal (zone)bord met maximumsnelheid 60, lijkt me dit zeer ongewenst. Ik ben benieuwd welke verklaring hij hiervoor heeft.
Ik denk dat het een probleem voor LiveNav zou moeten zijn.
Bv negeer de maxspeed. Dat gebeurt in de praktijk ook.
We hebben… tenminste ik… geen inzicht in de scripts van LiveNav. Het is dan ook lastig iemand te adviseren.
Wat wordt genegeerd?
Het gebruik van OSM in de routering voor hulpdiensten neemt toe. Dat zegt ook wel iets over de betrouwbaarheid van OSM.
Het is ook wel heel vreemd om een adviessnelheid te hebben die hoger ligt dan de maximumsnelheid.
Als het om noodvoertuigen gaat die zich zowizo niet aan de normale max snelheid hoeven te houden, maar waarbij op dit stuk weg wel een (hogere) maximumsnelheid geldt, dan zullen ze dat zelfbepaalde (en niet publiek verifieerbare) gegeven zelf moeten opslaan en aan de navigatie toevoegen.
In voorgaande changesets is ook de max speed aangepast.
Mapper zou bij LiveOp navraag doen.
Dit soort aanpassingen lijken me niet gewenst.
Kennelijk maakt de app omwegen die gebruikers dan willen beïnvloeden.
Zo heeft LiveNav kennelijk een voorkeur via de busbaan. Zal de link hier zo plaatsen.
Edit Changeset: 158806749 | OpenStreetMap
De hulpdiensten worden kennelijk via het busstation gestuurd.
Het valt binnen een zone 60 gebied. NDW
Hoewel er A1-60 staan, i.p.v. zone herhalingsborden.
Dit is klinkklare onzin. Je kan niet een maxspeed:advisory hebben die hoger is dan de maximumsnelheid of die nergens aangegeven staat op borden. Hier zelfs beide gevallen!
Dit is dus absoluut ongewenst, want ook al zou het iets doen voor LiveNav, elke mapper die daar bezig gaat zal die tag weggooien omdat het qua tagginglogica immers nergens op slaat. Als ze daar afhankelijk van worden krijgen ze dus een probleem.
Volgens mij zou je dan maxspeed:practical:emergency moeten hebben (maxspeed:practical voor voertuigtype emergency). Deze sleutel wordt ook al op kleine schaal in België gebruikt.
Jeroen Dat snijdt in ieder geval wel hout.
LiveNav zou daar iets mee kunnen doen… Maarrrrrr… dat zou dan alleen getagd moeten worden als LiveNav een ongewenste omweg zou maken.
We zien ook ‘overrule’ tags bij bruggen met een max breedte… of max gewicht… maar waar er genoeg speling is voor een brandweervoertuig.
Edit… Even die wiki bekeken… Ook dan betreft die ‘snelheid in de praktijk’ denk ik een lagere snelheid dan de wettelijke snelheid.
Dat is in het onderhavige geval hoger.
Maar goed… het geeft wel mogelijkheden.
Het simpelst lijkt me gewoon dat LiveNav de max snelheid negeert.
Ik weet het niet… Die overrides op wettelijke beperkingen die betrekking hebben op de fysieke eigenschappen van de weg zijn nuttig omdat daarmee de daadwerkelijke fysieke limiet in kaart gebracht kan worden. Dus als een heel stuk weg een maxaxleload=2 heeft, dan is het vaak zo dat alleen de brug in dat stukje weg een fysieke beperking heeft, die ook nog eens flink ruimer is dan de wettelijk aangegeven beperking. Dat kan er op neer komen dat dan alleen het stukje brug een maxaxleload:emergency=3 krijgt en de omliggende stukken weg tussen de borden die de maxaxleload=2 aangeven een extra maxaxleload:emergency=none. Zolang de veiligheidsregio’s maar de bron zijn van die kennis is dat prima.
Bij maximumsnelheden valt dat helemaal niet eenduidig te doen. Een hulpvoertuigbestuurder zal altijd zelf ter plekke moeten inschatten of op een weg harder gereden kan worden. In principe mag het namelijk op elke weg. Dit voelt aan als tagging om specifieke knelpunten in de routering op te lossen, maar dat is enorm veranderlijk en lijkt niet op basis van de situatie op die weg zelf gedaan te worden.
Mee eens… dat pleit dan voor mijn stelling dat een maxspeed beter genegeerd kan worden in LiveNav… net als access=private.
Ik heb wel de indruk dat de VR mappers niet goed op de hoogte zijn van de routeringsscrips in LiveNav.
Ik weet zeker dat LiveNav/OP de normale beperkingen kan negeren voor de hulpdienstroutering. Daarom dacht ik dat het hier moest gaan over een maxspeed voor emergency voertuigen, dus ze mogen de max 60 negeren maar dan alsnog niet harder gaan dan 80.
Het beste zou zijn dat Live… het probleem aanneemt en oplost, zonodig mbv de OSM community waar het om tagging gaat. Creatief maar oneigenlijk gebruik van tags om iets in de routering te veranderen is ongewenst en onnodig. Jeroen heeft al een paar mogelijkheden/oplosrichtingen aangeduid, maar zolang we niet het precieze probleem weten kunnen we niks met zekerheid zeggen.
Wat Peter zegt zou natuurlijk goed kunnen.
Wellicht dat VR mapper Johan nog wil reageren.
Mijn ervaring is dat LiveOp hun scripts liever voor zich houden en dat bemoeilijkt dan wel enig overleg met de OSM Community.
Voorlopig haal ik de adviessnelheid hier weg, want die is niet consistent met de wettelijke max snelheid.
Ik sluit me aan bij het genoemde sentiment.
De bestaande maxspeed:advisory-tag hiervoor misbruiken is verwarrend, misplaatst en kan tot problemen leiden als ander (gewone) navigatie-apps daar (ook) iets mee doen.
Als er al speciale tagging nodig is op dit gebied voor hulpdiensten (waarvan je je overigens kunt afvragen of je dat publiek wil hebben?), dan zou ik dat ook graag in een gedocumenteerde eigen tag zien.
Eens… want nu is het vaak koffiedik kijken.
Kreeg nu wel een terugkoppeling via de VR Gelderland.
Het ‘verhaal’ was steeds dat een paaltje met de tag removable of flexible niet emergency=yes behoeft.
LiveNav geeft nu aan dat dit dus wel nodig is om het paaltje te passeren.
Vind ik op zich niet gek (dat dat nu wel zo is).
Neerklapbare paaltjes vallen uiteen in paaltjes met en zonder sleutel, de paaltjes met sleutels kunnen vervolgens algemene sleutels hebben (een driehoek of vierkant meestal), maar ook een echte cilinder. In dat laatste geval is het geen gegeven dat de brandweer daar (tijdig) over kan beschikken.
Nog even los van elektronisch bediende/bestuurde paaltjes, waar (net als bij SOS Toegang voor slagbomen) “iets” geregeld moet worden voordat de hulpdiensten hier “als vanzelfsprekend” doorheen kunnen.
Ik denk dat emergency=yes in de OSM-betekenis niets toevoegt aan bollard=removable|flexible|rising|foldable. Hulpdiensten mogen daar zowizo voorbij, als ze de juiste sleutels/codes/button hebben.
Ik denk dat men hier toch weer tagt: “wij hebben dit geïnspecteerd, en we kunnen erdoor en we hebben de sleutel”.
Dat zijn operationele gegevens die niet in OSM thuishoren, want het is geen eigenschap van het object, maar van een weggebruiker dat-ie een sleutel heeft.
In de andere draad over campings suggereerde ik om te taggen hoe de barriere geopend/gepasseerd kan worden. Dat kan je aan het object (slagboom, paaltje, hek) zien: ground truth.
Voegt emergency=yes dan niet juist toe dát ze dat ook kunnen? Voor een verwijderbaar paaltje op privéterrein (camping, jachthaven, etc.) zal dat niet per se zo zijn.
bollard=removable zegt voor zo ver ik kan zien niets over mogelijk gebruik door hulpdiensten.
Ik begrijp aan het antwoord van LiveOp dat een paaltje gewoon niet routeert in LiveNav zonder de tag emergency=yes. Overigens wordt ook wel. Emergency=no getagd.
Ik heb nu een vraag gesteld of emergency=yes noodzakelijk is op een fietspad.
Dat is geen objectgebonden gegeven, maar een gebruikergebonden gegeven. Of dienst xyz een sleutel heeft daar kan de paal niks aan doen. VZIW taggen we eigenschappen van het object, niet van de gebruiker.
Mijn voorstel was om te mappen iets als
emergency_unlock=SOS Toegang 2.0 (als het met SOS Toegang 2.0 open gaat)
voor een paaltje dat met zo’n standaardsleutel opengaat moet je dan een geschikte waarde verzinnen. Ik weet niet hoe die dingen heten.
Op zich is het trouwens niet erg als emergency=yes op barriers gaat betekenen dat de noodhulpdiensten ter plekke erdoor kunnen, maar dat is dan wel een afwijking van de definitie, die je als zodanig zou moeten documenteren.
