Hallo, ik kom de brug niet meer over en zie niet waar dat aan ligt. Jullie wel?
Ik kijk evenā¦
editā¦
Het komt omdat een mapper barrier=lift_gate heeft aangebracht met dit als gevolg.
Ik denk niet dat we lift_gates op bruggen moeten zetten. Het zal niet alleen hier nu zijn.
Mapper is hier al op aangesproken enige tijd geleden.
Sommige routeplanners hebben er moeite mee ā¦ andere weer niet. Zal eens checken met generic routable.
Je zou nog eens een bericht kunnen sturen.
Ik ga in ieder geval iets aanpassen hier.
edit2ā¦ Ik heb access=yes aangebracht op alle lift_gatesā¦ Geef geen garantie. De routeringsmogelijkheden lopen altijd even achter dus over een tijdje weer proberen. In de generic routable in mapsource routeerde het wel. Ook met OSRM routeerde het zonder access= yes. Kennelijk heeft graphHopper er moeite mee.
Edit3ā¦ Zal mapper nogmaals inseinen
edit4ā¦ Zijn er meer bruggen waar dit speelt?
edit 5 ā¦ Met access=yes erbij routeert het op andere plaatsen wel met GraphHopper
Een barriernode heeft altijd expliciete access-tags nodig, omdat ze access=no impliceren. De wiki noemt niets over bruggen (waar zoān slagboom bijna altijd open staat), maar fout is het allicht ook niet. Is dit ooit besproken op de tagging-ML?
Bedankt voor het uitzoeken. De lift_gate had ik niet eens opgemerkt. Weer wat geleerd.
Besprokenā¦ geen idee Jeroen. waar we wel achter zijn gekomen dat de verschillende routers er ook verschillend mee omgaan.
Ik wil niet zomaar iets verwijderen. 'k Heb voorgaande mapper op het draadje in het forum gewezen middels PB.
Wie weet ontbreekt de tag access=yes op nog meer bruggen?
https://forum.openstreetmap.org/viewtopic.php?id=59693
Komt overeen met dit verhaal.
https://wiki.openstreetmap.org/wiki/Key:barrier#Access_control_on_highways
Jammer dat hier geen verhaal bij staat dat het zeer gewenst is dat access op de barrier wordt gezet.
Bij de afsluitdijk staan ze ook:
Overpass lift_gate op node van een brug
[āaccessā]
Hier kun je dus problemen verwachten.
Hangt af van de routeerder, hoe verder de zoekpunten uit elkaar staan, dan zal een tijdsvertraging gate eerder doorwerken.
Zie voorstellen Sander H
Maar dan kan het nog zijn dat de lift_gate voor de brug op de highway staat.
omgeving 25 meter van af brug
Nu alleen even in de omgeving van de bridge gekeken.
Je zou dus ook kunnen zoeken op een node van een highway. Wat is een lift_gate. Andere methodiek.
Ik heb nu omgeving van gezocht als eerste indicatie.
Around search had ik gebruikt om te kijken of streetlamps dubbel op de plek stonden of net naast elkaar wat fout zou kunnen zijn.
Zo ook bij bomen.
Bij Den Oever staat in iedergeval access=yes er al bij zag ik.
edit Kornwerderzand ook
Let echter op: de slagbomen bij een spoorwegovergang worden heel anders aangeduid.
Zie https://wiki.openstreetmap.org/wiki/Tag:railway%3Dlevel_crossing.
Dan zijn er dus ook geen problemen met routing apps.
De meeste spoorwegovergangen in Nederland zijn Ahobs en die tag ik zo:
crossing:activation=automatic
crossing:barrier=half
crossing:bell=yes
crossing:light=yes
crossing:saltire=yes
railway=level_crossing
supervised=no
Let op, bij fiets en voetpaden worden tegenwoordig weer vaker hele bomen gebruikt, dus dan wordt het crossing:barrier=full
Bijvoorbeeld alle stationsoverpaden hebben weer hele bomen met hekwerk eronder gekregen. Dit om te voorkomen dat mensen nog even snel onder de bomen door glippen om een trein te halen met soms zeer tragische gevolgen.
En mocht iemand nog belangstelling hebben voor de preset voor een Ahob, dan hier de code:
<?xml version="1.0" encoding="UTF-8"?>
<presets xmlns="http://josm.openstreetmap.de/tagging-preset-1.0"
author="Dick van den Hoven"
version="1.0"
shortdescription="Presets voor Nederlandse ahobs"
description="vaste waarden voor Nederlandse Ahobs">
<item name="Ahob" nl.name="Ahob" type="node">
<key key="railway" value="level_crossing" />
<key key="crossing:barrier" value="half" />
<key key="crossing:light" value="yes" />
<key key="crossing:saltire" value="yes" />
<key key="crossing:bell" value="yes" />
<key key="supervised" value="no" />
<key key="crossing:activation" value="automatic" />
</item>
</presets>
Hoe gebruik ik zoān preset-code?
Je kunt de preset van mijn site downloaden http://www.dvdhoven.nl/JOSM/Ahob.zip
Uitpakken en een leuke locatie kiezen voor het xml bestand
In JOSM ga je naar preferences en kies je voor het 3e knopje van boven, Map settings
3e tab Tagging presets
Uiterst rechts op het plusje drukken en dan bij URL/File het open knopje rechts drukken en naar de bestandslocatie gaan.
Als alles gelukt is, verschijnt het in het menu Presets als Ahob
Het is een one-click preset, je selecteert een node en klik dan bij Presets op Ahob en de tags worden automatisch gezet.
Evt kun je zoān preset in de toolbar zetten. Rechts klikken op de Toolbar en dan Configure Toolbar kiezen en vervolgens via de menu boom naar de Preset gaan
Aha, dank je. Ik konstateer dat ik al zover ben dat ik je beschrijving begrijp!
Toevoeg: En uitgevoerd, werkt als een zonnetje. Die xml lijkt niet erg moeilijk aan te passen voor andere voorkeuzen.
Ik kreeg van de VRGroningen het volgende probleem voorgelegd.
Wanneer er bij een brug een barrier=lift_gate /access=yes is ingetekend levert dat een vertraging op in de routering van 20 sec.
LiveOp! berekent dan de snelste route op grond van de strafpunten. Zoān slagboom staat natuurlijk bijna altijd open, maar in de routering blijf je strafpunten houden. In de praktijk heb je dus geen vertraging en bij werkelijke opening van de brug is de vertraging uiteraard langer.
Die strafpunten kun je via LiveOp! kennelijk omzeilen door de maxspeed te verhogen, maar het moet uiteraard wel als vlag de lading dekken.
Los van het feit of een barrier=lift_gate wel of niet op een brug hoortā¦ wie weet een manier om te vertraging er uit te halen?
De situatie in Groningen Node: 7476059298 | OpenStreetMap
Voor oorspronkelijke mapper was de access=yes tag āvergetenā. In deze changeset is dat gecorrigeerd.
Wellicht kan de VRG ook nog even aanhaken?
editā¦ Bij de Volkeraksluizen zag ik dat de slagbomen vastzaten aan de brugomtrek. Dan heb je uiteraard helemaal geen routeringshik.
1 Like
De routering kan rekening houden met het type weg waar de slagboom aan vast zit:
snelweg t/m residential: normaliter altijd omhoog dus geen impact of ~kwartier wachten als de brug idd omhoog is
service of busway: dan lijkt 20 sec wel OK, want vrijwel altijd bij terrein van bedrijven/appartementen of zoiets en vrijwel altijd nabij bestemming of vertrekpunt en toch onvermijdbaar
Sinds een tijdje zit in de standaard preset van bijv. een gate, de mogelijk om aan te geven of de gate normaal gesloten is. Dat is een vinkvakje. Als je dat aanvinkt, krijg je locked=yes.
Zo zou je bij lift_gate met locked=no kunnen aangeven, dat de boom normaal omhoog staat en met locked=yes normaal naar beneden, bijv. bij parkeerplaatsen.
Wel vereist dat een aanpassing bij de routers
2 Likes
Ahhā¦ dat locked=no klinkt plausibel.
Dan is het in ieder geval eenduidig.
Tjaā¦ en dan zal LiveOp dat kunnen verwerken.
Maar dan zal de VR dat in hun contacten met de app bouwer moeten kortsluiten.
Dat zegt locked=no niet, het zegt dat je geen sleutel of toegangsbewijs, anderszins nodig hebt om door te rijden.
Als hij dicht staat, dan zou je hem dus zelf kunnen openen en dat is niet waar.
Top, inmiddels verwerkt in de router waar we gebruik van maken.
Op deze manier kunnen we nog beter gebruik maken van de snelste route.
Rienkā¦ hoe is het aangepastā¦ met locked=no?
Dat is dan volgens Allroads verkeerd gebruikt. Het zou dan om het sleutelgebruik gaan. Volgens mij zijn we er nog niet uit.
Goedemorgen,
Sorry voor de late reactie ik was op vakantie:-)
Helaas was het in de router al aangepast naar aanleiding van het bericht D van den Hoven. Voor ons werkt de routering nu wel goedā¦ Verwacht je dat we tegen problemen aan gaan lopen als we dit in de router zo laten?
Gr Rienk