bollard naast het pad en de te gebruike breedte.

Naar aanleiding VRT topic, breedte hoogte.

Dit is een aparte discussie, waarbij anders tegen gebruik wordt aangekeken.

Bollard op de weg, je wilt weten of die er ook echt staat, midden op het pad of hij fixed is of movable.

Vaak staan naast het pad ook paaltjes (bollards).
Of zelfs alleen maar. “Ground truth” zou dan eigenlijk inhouden dat op het midden, de routelijn, geen bollard getagt mag worden. Je wilt daar wel weten wat de maximaal te gebruiken breedte is.

https://wiki.openstreetmap.org/wiki/Key:maxwidth:physical op de waynode.
maxwidth:physical=*
en eigenlijk wil je weten waar tussen de afstand geldt, de objecten, de paaltjes, daar is geen goede tag voor.

https://wiki.openstreetmap.org/wiki/Tag:barrier%3Dcycle_barrier
Nu heeft barrier=cycle_barrier een cycle_barrier=single.
Daar kan men het wel op de way node zetten. Er is een doorgang, altijd in het midden is het open, bollard niet.
cycle_barrier kenmerkt zich door twee of meer hekjes.

Nu zijn het twee hekjes, die je op zich apart zou kunnen mappen.
Die wayline node moet wel die route tag hebben.

Maar bij een bollard weet je niet of er paaltjes staan naast de weg en/of op het midden van de weg. Dat is wel belangrijk.
Die hinderlijke paaltjes in het midden. VRT zal het verschil willen weten.
Twee vormen, wat in Openstreetmap vaak op dezelfde manier word getagt.
Wat dus niet correct is tenzij je het aan geeft. En daar ligt de problematiek.

Bij naast de weg, apart de bollards op locatie taggen en op de wayline node maxwidth:physical=* ?

Er is geen bollard=* schema, die duidelijk maakt dat de bollard niet op de weg staat.

Twee fences die tot de rijbaan aangebracht zijn, daar geldt hetzelfde voor. Wat overeenkomt met barrier=entrance.
https://wiki.openstreetmap.org/wiki/Tag:barrier%3Dentrance
Eigenlijk wil je alleen tekenen tot aan het pad en op de node maxwidth:physical en dan voor VRT dat het tussen “passthrough (by)” een fence, bollard, wall is.
:passthrough=* wall, fence, block, etc.

https://wiki.openstreetmap.org/wiki/Key:cycle_barrier:installation
is te vergelijken met bollard=* raar dat hier een andere opzet wordt gebruikt.
Je zou namelijk dan ook bollard:installation verwachten.
https://wiki.openstreetmap.org/wiki/Key:cycle_barrier met maar 392 node tags.

Een omgekeerde werkwijze binnen het barrier concept, key opbouw.

Een voor VRT belangrijke tag.

Nog kort geleden is dit voorstel goedgekeurd om fietsbarrières in meer detail te mappen. Dit staat nu goed gedocumenteerd op Tag:barrier=cycle_barrier.

Ik heb nu nog niet zo goed begrepen wat er nu ontbreekt of problematisch is aan de combinatie van barrier=bollard + bollard=* + maxwidth:physical=*, want naar mijn idee geeft dit wel goed genoeg weer waarlangs of waartussen men zich moet/kan manoeuvreren.

Tja, wie van de huidige mappers surveyed locally en heeft dan ook een rolmaatje op zak ? De laatste kan slecht tegen nattigheid, roest gegarandeerd. Iedere bollard=movable is versleuteld.

Ik tag wel eens maxwidth:physical aan barriers. Rolmaat neem ik niet mee, maar mijn fietsschoenen zijn bijna precies 30cm lang. De wielbasis van mijn fiets is 1,20m. Daarmee kan je wat.

Verder vind ik het niet belangrijk of een paaltje op het pad staat of ernaast. Als er maxwidth:physical=1.8 erbij staat, hoef ik niet te remmen; wel bij maxwidth:physical=1.

Een gerelateerde vraag: als ik paaltjes naast het pad zie, gaat het meestal om krappe beton/schelpenpaden met een brede berm. Dan staat het paaltje op de berm om trekkerverkeer te weren. Vaak (maar niet altijd) removable voor die éne boer die er wel langs mag. Die bollard zet ik gewoon op het paadje, niks mis mee. Maar hoe taggen wij de informatie dat er een begaanbare grasberm zit naast het pad? Belangrijk voor veiligheidsdiensten, vermoed ik. Maar ook voor wandelaars of ruiters.

Mijn twee centen in het zakje:
Wat is het nut van deze verregaande vorm van µ-tagging? Een bollard of andere barrier is als node aan de highway gekoppeld. Deze barriers hebben default access (bicycle, foot etc.) die desgewenst uitgebreid kunnen worden.

Dat een bollard pas fysiek dit default access mogelijk maakt doordat in de berm varkensruggetjes geplaatst staan dient toch niet gemapt te worden. De access tags zijn voldoende.

Maxwidth kan je taggen natuurlijk, maar een ligfiets die < maxwidth is kan soms toch niet door een cycle barrier
En als smoothefiets al navigerend kan zien of ie, afhankelijk van zijn snelheid, met zijn fiets moet afremmen of niet: knappe jongen.

En een voor de VRT belangrijke tag: daar twijfel ik zeer aan. Indien echt noodzakelijk drukken de brandweerwagens wel eens iets opzij, daar hebben ze OSM niet voor nodig. Net zo min als strooi- en sneeuwschuifdiensten.

Ieder zijn hobby, maar het nut van dergelijke tagging, los van de volledigheid en onderhoudbaarheid waag ik te betwijfelen.

Maar ja, alles kan je taggen: de kleur van een bankje, of er een rugleuning is, een armrest, of er drie of vier mensen op kunnen zitten (maxwidth?), of ie van hout (welk?) of plastic of metaal is, in welke kleur (rood, groen, zwart, regenboog), of ie droog of nat is.

Vreselijk belangrijk allemaal.

Het gaat hier ook om de bruikbaarheid voor nooddiensten (zie VRT diskussie). Die navigeren zeg maar met een brandweerwagenprofiel, en dat hoeft zich niet aan de normale access en verkeersregels te houden. Maar de router moet wel rekening houden met fysieke mogelijkheden/beperkingen: max doorgangshoogte, max doorgangsbeedte, surface en smoothness.

Je hebt dan twee mogelijkheden: ofwel je tagt precies de fysieke kenmerken die voor hulpdiensten van belang zijn, ofwel je tagt expliciet emergency=yes met de betekenis dat de node of de way toegankelijk én geschikt is voor emergency voertuigen.

Ik zou zeggen, waar je ondubbelzinnig de fysieke kenmerken kan taggen heeft dat de voorkeur. Mocht dat niet goed genoeg kunnen of lukken, tag je emergency=yes bij, of als het specifiek alleen voor brandweerwagens geldt, fire_path=yes.

In dit geval zijn er (daadwerkelijk in gebruik) belangrijke toepassingen, het gaat niet alleen om dat iemand zo graag mooie paaltjes mapt.

Zelf plaats ik alleen een barrier=bollard als het paaltje op/in de weg (of fietspad) staat.

Een situatie zoals hier (links en rechts een paaltje langs het fietspad:
https://www.google.com/maps/@51.4562227,6.1229435,3a,15.2y,159.72h,82.49t/data=!3m6!1e1!3m4!1saCI7mUcLv-yw73kRDh2Orw!2e0!7i13312!8i6656
tag ik nooit.
Ik zie die paaltjes niet als onderdeel van een fietspad, ze beperken niet de breedte van het (asfalt)pad.

Als een fietspad bruikbaar moet zijn voor een nooddienst, is het misschien handiger daar juist een access tag voor te maken.
Er zijn waarschijnlijk veel fietspaden die te smal zijn voor 4 brandweerauto’s, zonder dat er paaltjes gebruikt worden.

Voor de hulpdiensten is (naast doorgangsbreedte, doorgangshoogte en berijdbaarheid) van belang of er paaltjes verwijderd/ingezonken/ingeklapt moeten worden om erdoor te kunnen. Voor middenpaaltjes zal dat meestal gelden, en voor 1 van de poortpaaltjes, dus die zullen ze willen mappen. Het zijn zichtbare elementen met verifieerbare kenmerken. Dus is daar een tagging spec op zijn plaats!