Broedseizoen en hond

Ik ben voor een wandelroute (Groene Hartpad) de varianten aan het mappen. Die gaan meestal over honden (met hond, zonder hond of hond aan de lijn) en vooral over broedseizoen (soms maar niet altijd met datums).
Ff tsjekken of ik het goed doe.

  1. De relatie
    De relatie ontleent zijn beperkingen/toelatingen aan de paden, dus in theorie zou je de beperkingen niet in de relatie hoeven taggen. Maar dat wordt erg lastig voor de huidige software, bijvoorbeeld omdat er alleen ergens onderweg een relatielid (wat zelf een relatie kan zijn…) is waar een beperking op zit.

Ik wil voor een hondenbeperking dog=no|leashed aan de relatie toevoegen. dog=yes lijkt me de verstekwaarde (ook wel bekend als default), dus dan hoef je die niet te zetten op de variant met hond. Maar die kan wel dog=leashed zijn.
Een exotisch bord als “Bij begrazing door schapen honden niet toegestaan” daar maak ik maar dog=no van. Als ik als wandelaar met hond geen schaap zie weet ik niet of ze achter een bosje staan of alleen die dag ergens een dijk aan het afgrazen zijn.

Voor een broedseizoenbeperking twijfel ik. Ik voel er weinig voor om daar komplete details in te zetten, maar ik wil wel aangeven dat er een broedseizoenbeperking is. Zal ik alleen seasonal=yes in de relatie taggen? De machineverwerkbare details kan je dan op de paden vinden. Voor de wandelaar is het dan misschien handig om in de description iets als gesloten 1 maart - 1 juli te zetten. Want die datums variëren per gebied.

  1. Het pad

Ik vind een voorbeeld van een pad

highway=path
access:conditional=no @ (Mar 01-Jun 30)
foot:conditional=permissive @ (Jul 01-Feb 29)
note=gesloten in het broedseizoen
seasonal=yes

Ik zie dat het klopt, maar…
? waarom seasonal=yes erbij, als de specifieke periodes van opening/sluiting er al instaan?
? Het is een path, dus moet er niet een betere accessrestrictie bij? Zoals het hier staat zou je er toch in februari of oktober met een mtb opmogen?
? note is de key voor een mededeling aan mappers. Deze informatie lijkt voor de wandelaars bedoeld, kan die dan niet beter als description=…?
? De toevoeging foot=permissive is nuttig, maar waarom twee periodes vermelden?

Ik zou denken: er is gewoon geen access, behalve foot:conditional=permissive @ (Jul 01-Feb 29).
Toevallig weet ik dat er bij deze een bord “wandelroute” en een voetbruggetje en een voetgangershekje staat, dus ik denk dat je er rustig een footway van kan maken. Dat geldt voor veel boerenlandpaden e.d., ook bv als je er alleen via een overstapje of kushekje opkan (en het is geen track) dan lijkt me dat al genoeg om er een highway=footway van te maken.

Kortom, ik vind dit heel erg lastige materie! Is hier consensus over of is het toch per geval bekijken?

Peter, hadden we ooit niet afgesproken dat slechts de met G 07 gemarkeerde paden footways werden en voor alle andere wegen volstaan met extra tags ? Want alleen path of track is ook niet bevredigend of voldoende, toch ?

In de praktijk zie ik veel getagde footways waar geen bordje bijstaat. Vaak onverharde paden die je met een gewone fiets of brommer nooit zou nemen, maar met bijvoorbeeld een atb prima toegankelijk en berijdbaar, of buiten de Randstad waar fietspaden en wegen gewoon onverhard kunnen zijn. In zo’n geval maak ik er wel een path van. Maar een als voetpad ingerichte way (meest duidelijke voorbeeld is een apart voetpad met stoeprand of speciale kleur of krijtwandelaars op de bestrating,) is volgens mij ook zonder bord een footway.

Bij nader inzien word ik met de relaties toch wat terughoudender. Als er in een dagetappe (1 relatie met pakweg 300 leden) van een LAW ergens een pad zit waar geen hond opmag (letterlijk he), dan ga ik niet de hele relatie dog=no maken. Als er een gemarkeerd “alternatief met hond” is kan ik die wel dog=yes maken, en bijgevolg is de dagetappe dan met hond te doen.
Omgekeerd, als de hoofdroute de route met hond is, en er is een leuk alternatief buiten broedseizoen en zonder hond, dan wordt het alternatief een relatie met rol “alternative”, dog=no en seasonal=yes.
De precieze openstelling zal op de paden en/of de toegang getagd zijn. Als er een bord staat met openstellingen van de route of het gebied, kan je denk ik de openstelling ook op de seasonal routerelatie taggen. In name en description kan je duidelijk maken waar het alternatief voor dient.

Als de renderer, router of trip-planner het belangrijk vindt kan die de informatie dus vinden in de relatietags of op de paden en toegangen, en weergeven of in de routing meewegen. Dat dat op dit moment niet of weinig gebeurt is een kwestie tussen de gebruiker en de toepassing. Ik zie wel de trend dat betaalde populaire platforms/apps steeds meer kunnen en bieden, en dat OSM naar de achtergrond verdwijnt. Letterlijk dus, dat OSM voor de achtergrondkaart gebruikt wordt en niet voor de routes en de reisplanning.

Blijft nog wel de vraag over hoe je de broedseizoen-openstelling/afsluiting precies tagt. Zie de vragen bij het voorbeeld in het startbericht. Of is dit een heikel punt waar niemand zijn vingers aan wil branden?

Stel datum in 9 april
https://www.openkaart.net/wandel/lvww/#map=16/52.1206/4.5796&overlays=lwn
Pad dat op de gekozen datum gesloten is vanwege broedende vogels.
(Path closed during breeding season.)

breeding in value
https://overpass-turbo.eu/s/1b1s
broedseizoen in value
https://overpass-turbo.eu/s/1b1u

twee broedseizoenen
https://www.openstreetmap.org/way/889959474
https://www.mapillary.com/app/?pKey=323997149233267

het permissive aspect en broedseizoen combinatie
https://www.openstreetmap.org/way/889959474

Basis broedseizoen
access:conditional=no @ (Mar 15-Jun 15)

Nuttige kaart! Maar volgens mij is dat pad juist altijd open, het is het broedseizoen-alternatief voor de hoofdroutes van de Limes en het Groene Hartpad.

TOEGEVOEGD: O nee, mijn fout, dat zit verder naar het westen.

Persoonlijk is een bord een mogelijkheid om als footway te taggen, maar ook als er geen verkeersbord, maar wel een stoeprand aanwezig is. Mits het niet direct aan een weg vastzit, want dan taggen we het voetpad niet.

Is dit (met dezelfde werking) te vervangen door:
access:conditional=no @ (Mar 01-Jun 30)
foot=permissive

Of gaat de foot=permissive boven de access=no?

https://wiki.openstreetmap.org/wiki/Conditional_restrictions#Evaluation_of_conflicting_restrictions

  1. Dat kan zowel een altijd durende als een conditional restriction zijn, wat wordt overruled door een meer specifieke transport modus.

  2. Er wordt alleen omschreven de werking binnen een transportation mode.

De werking, 1, dat foot=permissive de access:conditional overruled.
Dat je het broedseizoen apart moet aangeven als een conditional bij foot.

Ook als je dit voorbeeld bekijkt:

de except psv=yes overrules dus de conditional. In dit voorbeeld.

Nee.

Ja.

Ja.

Eigenlijk zou je access:conditional helemaal niet moeten aangeven, om het broedseizoen aan te geven.
Eerst de altijd durende verwerken en daarna zo nodig de tijdelijke per transportmodus.
Als je zet, want je moet in zulke gebieden al groepen uitsluiten en gebruik makend van de hiërarchie structuur.
access=no of vehicle=no horse=no
foot=permissive
foot:conditional=no @ (Mar 15-Jun 15)

Dan heb je het al goed geregeld betreffende access.

Er zijn er, die voor algemene info openingstijden, opening_hours, gebruiken.
Daar is ook wat voor te zeggen.
Misschien een verduidelijking.
Hoewel je de aangegeven datums/tijden, verbod datum/tijden op de borden dan wel moet omzetten van gesloten naar open. (mogelijk omzettingsfouten)

Dan heb je ook nog de combinatie met verboden toegang van zonsondergang tot zonsopgang en het broedseizoen in een permissive gebied.

Daar voldoet deze combinatie nog niet aan.
foot=permissive
foot:conditional=no @ (Mar 15-Jun 15)

foot:conditional=no @ (Mar 15-Jun 15;sunset-sunrise)

Eerder in het forum waren we het over eens dat het belangrijker is de sunset-sunrise verboden te verwerken in access mode conditional.
Niet alleen in opening_hours, voor een goede werking.

Topic post:

Hiermee sluit je bepaalde transportation modes niet uit.
bicycle mag er op bepaalde datums langs.

Als ik het dus goed begrepen heb zou dit:

highway=path
access=no
foot:conditional=permissive @ (Jul 01-Feb 29)
note=gesloten in het broedseizoen
seasonal=yes

beter zijn. Geen toegang voor al het verkeer, maar permissive voor voetgangers gedurende 01-jul - 29-feb

Hoi, datumgebonden sluitingen van wegen (in de zin dat ze op bepaalde dagen geheel gesloten zijn) is een van mijn aandachtsgebieden bij mappen.Ik struin ze af met surveys en doe jaarlijks een check hierop op OSM-data in NL (zoals syntax, sluitingsdata in [name] etc)
Het blijft ingewikkelde materie, een foutje is zo gemaakt en heb al een paar keer mijn beeld van wat goed / het handigste is bij moeten stellen.
Vooralsnog ben ik hier op uitgekomen:

**1. **Opening-hours zou eigenlijk makkelijker zijn geweest als een pad voor alle vervoerswijzen dicht is, maar access:conditional is ingestemd met een proposal en daardoor ook beter ondersteund door dataverwerkers (die om die reden weigeren opening_hours op highways te verwerken)

2. Datagebruikers die access:conditional ondersteunen geven foot=permissive (algemeen in tijd, specifiek in vervoerswijze) inderdaad prioriteit boven acces:conditional-no @… (specifiek in tijd, algemeen in vervoerswijze) gaan, conform wiki

3. Het door Allroads in een ander draadje https://forum.openstreetmap.org/viewtopic.php?pid=840775#p840775 aangehaalde advies uit de wiki https://wiki.openstreetmap.org/wiki/Conditional_restrictions#Default_restrictions " when using conditional tag, it is recommended to mark the default value in overt form in all cases." blijkt in de praktijk nuttig, ook om eenvoudige diensten mogelijk te maken die in algemene zin aangeven of in OSM is vastgesteld dat op een pad mag lopen / fietsen etc

4. Het eerst op slot zetten van een weg (bijvoorbeeld met access=no) en vervolgens deels ontgrendelen met conditional-waarden levert bij veruit de meeste dataverwerkers onjuiste resultaten op, dit is een extra reden om zulke tegenstrijdigheden in tagging zoveel mogelijk te voorkomen

5. Het toevoegen van seasonal=yes maakt het makkelijk om overzichten te geven van wegen met seizoenssluitingen, als je dat met een query wilt doen is het heel erg lastig om vals positieven te vermijden, zoals wegen die wel elke dag geopend zijn, maar waar de openingstijden afhankelijk zijn van de datum (ipv zonsondergang)

Er zijn bij tagging verschillende mogelijkheden, maar achterliggende doelen zouden naar mijn idee moeten zijn:
-De verwerking van data door meer algemene dataverwerkers -die geen rekening (kunnen)houden met datumgebonden beperkingen- moet niet ernstig worden gehinderd door deze specifieke en complexe toepassing, met name: paden die voor de meeste gebruikers geopend zijn moeten niet onterecht worden afgelsoten

-Voor dataverwerkers die wel rekening houden met datumgebonden beperkingen zoveel mogelijk taggen conform brede afspraken in wiki / proposals, want het is al ingewikkeld genoeg als je dat scherp hebt
Voor het pad uit het voorbeeld in de startpost van Peter met de tags

highway=path
access:conditional=no @ (Mar 01-Jun 30)
foot:conditional=permissive @ (Jul 01-Feb 29)
seasonal=yes

kom je dan uit op

access:conditional=no @ (Mar 01-Jun 30)
foot=permissive
foot:conditional=no @ (Mar 01-Feb 29)
seasonal=yes

Nadeel van deze tagging is natuurlijk de overlap tussen de identieke values in de keys access:conditional en foot:conditional , die je normaal probeert te vermijden. Dit is echter het gevolg van de hierboven genoemde punten, waar je geen last van zou hebben als opening_hours als breed gedragen key voor dergelijke sluitingen op highways zou gelden (die dan niet wordt overschreven door een in de tijd algemene foot=permissive). Maar die dubbeling schaadt niemand en biedt wel voordelen. Als je de algemene access:conditional zou weglaten, dan is het weer lastig om te achterhalen of het pad gesloten is voor alle vervoerswijzen (en daarbij: wie vergeet er nou niet eens om horse=no te taggen na een vehicle=no…?)

Voordeel hiervan is ook dat diensten die expliciete toegangs-tags renderen voor vervoerswijzen (Osmand, Locus / Orux met OpenAndro en Opencyclemaps) de waarde die voor veruit de meeste gebruikers relevant is goed kunnen verwerken en vooral voor fietsen op paths en tracks kan goede verwerking van positieve toegangs-tags verschil maken voor de routering.

Het toevoegen van de positieve waarde in opening_hours is wel nuttig voor validatie: de negatieve waarde in access:conditional en de positieve in opening_hours moeten als twee puzzelstukjes in elkaar passen, geen overlap, geen gaten. Hopelijk draagt gebruik van opening_hours er ook toe dat iemand eens de moed verzamelt om voor te stellen om access:conditional de deprecaten voor situaties waarin een weg in een periode voor alle vervoerswijzen is gesloten ten faveure van opening_hours, het is immers vaak een kip-ei verhaal in OSM waarbij “weinig gebruikt” ook vaak een reden is om iets helemaal niet op zijn eigen merites te beoordelen.

Deze site werkt goed om de data/tijden die je in OSM wilt zetten vooraf te toetsen: https://openingh.openstreetmap.de/evaluation_tool/

**Praktische voorbeelden **
**-Osmand **leidt je in de Kroondomeinen vanaf de openbare gravelpaden (foot=yes ipv permissive en ook geen seizoenssluiting) nu om het afgesloten gebied heen:
Osmand met instelling “Houd rekening met tijdelijke beperkingen” UITgeschakeld

Osmand met instelling “Houd rekening met tijdelijke beperkingen” INgeschakeld

Als je de access:conditional verwijdert en vervangt door alleen opening_hours dan werkt het niet meer, zie https://www.openstreetmap.org/changeset/72420330

**Brouter **verwerkt access:conditional nog niet in route-advies, maar met onderstaande overpass-laag in Broutrer kan je wegen met een maand in de access:conditional wel zichtbaar maken en de waarden handmatig bezien en indien nodig om die wegen heenrouteren

way["highway"]["access:conditional"~"jan|feb|mar|apr|may|jun|jul|aug|sep|oct|nov|dec",i]["access:conditional"!~"202"]

(de ~202 is bedoeld om sluitingen door werkzaamheden -waarin een jaartal is benoemd- uit te sluiten en echt de wegen met een jaarlijks terugkerende sluiting in beeld te krijgen, zoals gezegd wel kans op vals positieven)

Hier de **Overpass-versie van de kaart waar Allroads naar verwees op mijn website **(meer heel veel hulp gemaakt door een programmeur) die voor de genoemde datum met kleur aangeeft of het pad dan geopend/gesloten is
https://openkaart.net/wandel/#map=16/52.2747/5.8266&overlays=lwnDeze overpass-kaart werkt op alle locaties met actuele data (de kaart waar Allroads naar verwees is een oude lokale versie), maar is traag.

Ik wil voor komend broedseizoen een versie maken waarin alle paden in NL op mijn server zijn opgeslagen, zou leuk zijn om samen met andere mappers de nog missende data verder aan te vullen. Afgelopen week al een heel setje paden met seizoenssluitingen op Texel afgelopen, moeten nog worden verwerkt in OSM. Groet!

Dat is nieuw voor mij, het gaat zover ik zie tegen de Wiki in, zie de quote van @Allroads eerder in dit topic. Ik ben ook wel benieuwd wie die dataverwerkers zijn.

Het is een tijd terug hier ook wel voorbijgekomen, toen met een voorbeeld op het strand in Voornes Duin en daarna ook nog een keer aan de oostkant van de Veluwe.

Allereerst is een algemene access=no al niet echt de bedoeling op wegen die wel doorgaans openstaan voor het publiek (ook als dat beperkt is tot bepaalde tijden en vervoerswijzen), zie bijvoorbeeld

https://wiki.openstreetmap.org/wiki/Tag:access%3Dno

en https://wiki.openstreetmap.org/wiki/Key:access

Daarom is het ook de gewoonte ook in ons land om op een path waar het publiek wel (bij gedogen) mag lopen, maar niet met voertuigen/paarden mag komen gebruiken geen access=no / foot=permissive te gebruiken, maar wel *foot=permissive / vehicle=no / horse=no *

Uit de wiki-quote die Allroads citeert volgt dat als je foot:conditinal=no @ … tagt, dat je ook tagt wat de situatie is als die conditional niet geldt, namelijk: foot=permissive.

Met de algemene access= *key is dat dan weer lastig, want access=permisive betekent niet alleen dat *de weg *bij gedogen openstaat voor het publiek, maar dat dat tegelijk ook geldt voor alle vervoerswijzen. Dat is een nadeel van de opbouw van de access-key en het gebruik van access:conditional voor tijdgebonden situaties waarin de weg geheel voor het publiek gesloten is.

Heb je even :wink:
Als je een voorbeeld neemt zoals https://www.openstreetmap.org/way/414723368/history met

highway=track
access=no
foot:conditional=permissive @ (sunrise-sunset)

en probeert te routeren te voet, dan zie dat het misgaat op bijvoorbeeld:

De twee routing engines die de OSMF standaard aanbiedt op osm.org:
-Graphhopper: https://www.openstreetmap.org/directions?engine=graphhopper_foot&route=52.27220%2C6.90131%3B52.27540%2C6.90218#map=17/52.27414/6.90332
-OSRM: https://www.openstreetmap.org/directions?engine=fossgis_osrm_foot&route=52.27220%2C6.90131%3B52.27540%2C6.90218

Daarnaast ook bijvoorbeeld:
-Openroute service: https://maps.openrouteservice.org/#/directions/Boordwapenschietbaan,Lonneker,OV,Nederland/Grefteberghoekweg,Lonneker,OV,Nederland/data/55,130,32,198,15,97,4,224,38,9,96,59,2,24,5,192,166,6,113,0,184,64,54,0,232,4,224,1,128,70,98,1,103,212,252,7,96,3,156,211,72,21,152,182,1,163,96,38,67,123,211,102,197,128,102,81,249,27,230,47,66,64,110,34,101,201,181,24,212,125,94,165,68,206,47,135,191,65,229,25,75,232,216,185,94,226,65,113,1,0,3,170,120,17,19,97,202,0,23,148,0,182,185,201,233,7,109,1,0,6,111,0,3,110,139,130,12,21,10,128,11,64,14,236,134,16,13,100,128,14,109,96,29,14,140,30,131,152,134,9,23,131,153,5,229,238,136,139,14,139,2,0,11,231,84,0
-Brouter: http://brouter.de/brouter-web/#map=16/52.2738/6.8966/standard&lonlats=6.901472,52.271859;6.901868,52.275504

(Op moment van schrijven is natuurlijk de zon onder, maar ik durf het op basis van eerdere ervaring overdag wel aan dit nu te posten, ervan uitgaand dat die tags vannacht niet gewijzigd worden…)

En er is daarnaast nog een hele trits dataverwerkers die acces:conditional niet verwerkt (en dus bijvoorbeeld routeert over over paden met negatieve access:conditional tags zoals in Kroondomein het Loo), naast bovenstaande oa:
-Garmin Connect
-Bryton Active
-Hammerhead routes
-Komoot (geeft alleen een waarschuwing dat er een tijdelijke beperking is, maar zegt niet wat die is en past de route er niet op aan verwerkt het niet in de route)
-Strava (in ieder geval toen hun Routebuilder nog met een gratis account te gebruiken was…)

[edit: opmaak]

Dank voor het uitgebreide antwoord, het verhaal wat betreft access=no is duidelijk.

Ook bedankt voor het benoemen van de dataverwerkers, ik ben zelf goed thuis in brouter en de reden dat brouter niet over deze weg wil is inderdaad dat er access=no op staat en brouter ondersteunt geen conditionele restricties, dus dat volgt het verhaal dat access=no is geen goed idee voor een pad dat “vaak” wel toegankelijk is.

Zouden ook Graphhopper, OSRM en -Openroute service gewoon deze conditionele restricties niet ondersteunen? Ik vindt die “oplossing” van Komoot nog niet zo slecht.