Dat is het huidige probleem met het ontbreken van bicycle tag op path. Op een groot deel van de path staat geen bicycle tag maar toch is het verboden er te fietsen. Denk dan m.n. aan de natuur terreinen met veel paden. Uiteraard komt dat doordat we in NL nog lang niet compleet zijn met bicycle=no etc. tags op paths. En dat heeft momenteel best wat vervelende consequenties.
Even een voorbeeld. Momenteel is gravelbiking erg populair maar er is nog geen goede router (AFAIK) o.b.v. OSM die dat ondersteunt. Dat komt omdat een router te weinig informatie heeft over access op paths. Als de router fietsers zou sturen over een path zonder bicycle tags (want de default is bicycle=yes) dan zullen veel gravelbikers gaan klagen omdat ze over path gestuurd worden waar je niet mag fietsen. Dus⊠dan zal de router in het vervolg alleen maar routeren over path waar fietsen expliciet is toegestaan. Dat is bv te herkennen aan bicycle=yes of permissive. Dan helpt het als we deze expliciete tags toevoegen ook al zou het volgens het schema een default zijn. Dat taggen is dan niet alleen voor de mapper maar ook voor de data consumer.
En zoals Eggie aangaf ⊠hier is inderdaad al eindeloos over gediscussieerd maar ik kan dat draadje niet zo snel vinden.
In Osm Nederland gebruiken we highway=path ook voor doorsteken in wijken waar geen G7 bord staat. Het zijn dus niet alleen die bospaden. Die zullen dus voor fietsers routeren. Ze worden wel als onverhard gezien⊠daarom is het wel handig om een surfacetag mee te geven.
Het âgesteggelâ sloeg op de tagging van g11 g12a en g13 fietspaden. Designated of yes.
âdoorsteekâ zegt op zich ook niet of je er mag/kan fietsen of niet - dus valt gewoon onder de defaults, en als het anders is dan moet het getagd worden! Of het onverhard is maakt MI weinig uit. Als fietsen wel mag maar het is diep zand of zo, dan is het aangewezen om surface te taggen, maar dat geldt dan onafhankelijk van vervoermiddel. Als het echt alleen te voet mag of kan, en je kan dat afleiden uit zichtbare kenmerken (een kuil of zo) kan je denk ik beter highway=footway gebruiken, ook als er geen voetgangersbord bij staat.
Het punt is dat zowel footway (routeert niet voor fietsers) als path (die dus wel) in bv de Openfietsmap worden gezien als onverhard. Hoe het met andere routers zit weet ik eigenlijk niet.
Ik heb in mân garmin etrex dan ook meestal âonverhard vermijdenâ uitstaan. Het is dan toch van belang voor een juiste routering als onverhard en/of verhard zijn toegevoegd.
Dan kan de Garmin een beter keuze maken.
Dat geldt eigenlijk ook voor fietspaden. Die ziet de OFM als verhard. Wanneer dan is toegevoegd surface=sand dan kan mân garmin de juiste keuze maken in de routering als ik onverhard vermijden heb aanstaan.
Dit geldt ook voor tracks⊠Die worden als onverhard afgehandeld totdat je het juiste tracktype toevoegt.
In Frankrijk bv zet ik onverhard vermijden altijd uit. Daar noemen ze alles gravel terwijl het eigenlijk fine_gravel is. Nog genoeg te doen voor ons als mapper.
Maar ieder heeft een eigen insteek in OSM. Dat moge duidelijk zijn.
Nergens in dat defaultverhaal [ wiki met die tabellen] is bepaald dat je alleen uitzonderingen op een default zou moeten taggen. Dat is een hardnekkig misverstand dat steeds terugkomt omdat mensen een deze voorgestelde defaults voor routers (wat neemt een router aan als er geen access is getagd? ) verwarren met een richtlijn voor wat je wel en niet moet taggen als mapper.
Dat het 1-op-1 leidend verklaren van die tabellen voor wat je wel en niet mapt onzinnig is, merk je ook als je bedenkt wat er gebeurt als je de waarde in zoân tabel gaat wijzigen (wat regelmatig is gebeurd):
wat doe je dan met alle ways waar geen waarde is ingevuld?
Ga je er dan vanuit dat die daadwerkelijk in het veld voldoen aan de oude default en ga je dat dan op die ways zetten (dus bicycle=yes toevoegen op alle highway=path waar dat niet was ingevuld) ?
Dan ga je een heleboel onjuiste data toevoegen omdat daar ook wegen bij zitten die nog niet door een mapper zijn beoordeeld op toegang voor bicycle, en waar je in werkelijkheid niet mag fietsen.
Nee, wat PeeWee beschrijft heeft niets te maken met taggen voor de router in de zin dat je iets oneigenlijke data toevoegt voor een gewenst resultaat, het is gewoon na een constatering als mapper iets expliciet maken dat eerder feitelijk nog onbepaald was (en waar je alleen kon gokken met een default naar keuze).
En dat het toevoegen van correcte data ook concrete positieve effecten het werk van datagebruikers heeft mag best als illustratie worden benoemd.
En het heeft ook niet te maken met van de standaard afwijkende routers, dat is nog zoân misverstand.
Op de wiki-pagina met die tabbellen staat bijvoorbeeld al:
As per 2022, no mainstream routing engine is known to use this page directly to influence routing behavior. Routers are known however to use other default values than the values below and to treat ways without explicit access-tags (that are assumed to be default in this wiki) different than ways with such explicit tags. See the section below.
Examples of routers that use other defaults then the tables in this wiki
[âŠ]For reference, here are some links to mainstream routing enginesâ default profiles that use other default values then the country-specific tables in this wiki:
[vervolgens worden 8 voorbeelden van routers gegeven die andere defaultwaarden gebruiken dan die tabellen waar al die misverstanden over zijn, waaronder alledrie de routers die worden aangeboden op openstreetmap.org]
Het weglaten van tags omdat ze in die default tabellen zijn, dat zou wel een vorm van âtagging for the routerâ zijn :in de zin van oneigenlijke datamanipulatie:
dan laat je een tag weg (of erger: je verwijdert iets) omdat je ervan uitgaat dat de router waarvoor je tagt toch wel hetzelfde routeerresultaat geeft, met of zonder die tag.
Het bijzondere aan deze variant van datamanipulatie (tags weglaten of zelfs verwijderen âomdat ze default zijnâ), is dat het ook nog eens taggen voor een niet bestaande router isâŠ
Als ik dit zo lees, dat er routeerders zijn die niet (volledig) met de default access kunnen omgaan, dan concludeer ik dat we op alle highways moeten aangeven welke categorieën een no dan wel een yes benodigen. Dat zal toch niet de bedoeling zijn?
En het wijzigen van betreffende wiki-pagina terwijl deze discussie loopt lijkt me op zijn best opportuun.
Default is per definitie datgene wat geldt als een expliciete waarde ontbreekt. Een tabel met afgesproken defaults is handig want dan hoeven data users niet te gokken, maar kunnen gewoon de tabel implementeren. Afgesproken defaults=niet hoeven gokken.
De tabel is voor routers: ja, want daarin staat hoe het ontbreken van waarden geinterpreteerd moet worden.
Dat werkt, mits de mappers zich er ook precies zo aan houden.
Als de default niet handig is om het in de praktijk meestal anders is, moet je de default veranderen, voor mappers en routers tegelijk.
In die situatie voegt het niets toe om de default expliciet te taggen. Als in sommige gevallen de default niet het gewenste resultaat oplevert, moet je in die gevallen de uitzondering taggen.
Het heeft voor de data geen meerwaarde om de defaultwaarde expliciet erbij te taggen.
Dit lijkt me op vragen naar de bekende weg,
hier een link naar het eerdere waarnaar verschillende bijdragers verwezen maar dat ze zo snel niet konden vinden, waarin je ook had toegezegd data die overeenkwam met default-tabellen niet meer te verwijderen : link discussie 2018
Een toezegging waar je je niet aan hebt gehouden, zoals ook hier geconstateerdâŠ
Voor de mensen die destijds die die discussie uit 2018 niet hebben meegekregen:
mappers verwarren vaak by default met by definition
PeeWee vatte het hierboven al mooi samen met het voorbeeld van de foot op highway=motorway:
er is een 1-op-1 relatie tussen het bord G1 autosnelweg en de tag highway=motorway : alle autosnelwegen buiten zijn motorways in OSM en alle motorways zijn autosnelwegen
het verbod om op een autosnelweg te lopen geldt overal: onderborden âvoetgangers toegestaanâ worden niet geplaatst en mogen volgens het BABW ook niet geplaatst worden
daarom kan je uit de tag highway=motorway met zekerheid afleiden dat foot=no ; het heeft weinig zin om dat toe te voegen
Op andere wegtypes dan motorway zijn die onderlinge relaties veel minder sterk en geven acces-tags meer duidelijkheid, de mate waarin die extra informatie geven hangt af van het wegtype, de vervoerswijze en het gebied. Het is aan mappers om te bepalen wat zij de moeite waard vinden om toe te voegen.
Wat in ieder geval niet de bedoeling is, is om naar eigen inzicht en zonder overleg correcte access-data van anderen te verwijderen uit de gemeenschappelijke database omdat je ze persoonlijk niet âtaggingswaardigâ vindt
Geldt dit dan alleen voor een motorway? Hoe om te gaan met een residential, unclassified? Hier vormen de default acces rights toch een prima leidraad?
Voor een cycleway zijn tags voor mofaâs en mopeds duidelijk van meerwaarde, mee eens.
Voor een path voor foot alleen als er conditionele waarden zijn als sunset/sunrise etc. anders kan je ervan uitgaan dat foot=yes impliciet dan wel default is.
Ik denk niet dat alleen een motorway âsterkâ in defaults is.
Die wijziging betreft zoals je kan zien het deels herstellen van een wijziging van een andere mapper van vandaag, en die wijziging ziet op de opmaak, niet op de inhoudâŠ
Een voorbeeld van oneigenlijke wiki-edits zou ik eerder jouw edits vinden, waarbij je inhoudelijke wijzigingen maakt die raken aan een bediscussieerd onderwerp en die steeds ten onrechte het kenmerk âkleine wijzigingâ meegeeft (wat je normaal doet bij correctie van typoâs etc.) , waardoor andere mappers niet op deze wijzigingen worden geattendeerd en deze wijzigingen voor hen verborgen blijven en je pas jaren later ziet wat er allemaal is gewijzigdâŠ
(zie alle k 's in deze lijst) NL:Cycleway: Revision history - OpenStreetMap Wiki
Je zegt: âDie wijziging betreft zoals je kan zien het deels herstellen van een wijziging van een andere mapper van vandaag, en die wijziging ziet op de opmaak, niet op de inhoudâŠâ
De wijziging van vandaag door user Envee was, in zijn woorden: âMoved the table to the top; no other changes apart from changing above/below)â en dus geen inhoudelijke wijziging, Jij hebt inhoudelijk zaken toegevoegd:
Possible fallback values for data users, based on a particular simplified interpretation of regulations. These values are NOT the legal default access restrictions when a road in the real world is not signposted; these values are also NOT a guide for tagging or a replacement for explicit access tagging on ways in OSM. See further caveats below.
Zoals aangegeven in de change-comment alleen een deel van de reeds opgenomen inhoud samengevat op de oude plek:
Restored a short version of the old text above the table, some introduction is needed before reading the table to avoid misinterpretation ( I do however support moving the table up in the text, thx @Emvee for that)
Ik heb het voor nu wel weer gezien hier als het hier zo gaat, kan mijn vrije tijd en energie wel beter benuttenâŠ
Er moet wel Ăets zichtbaar zijn, anders heb je geen wegsoort. Als er daarnaast niet expliciet toegang is aangegeven, gelden er bij verstek regels, en het lijkt mij dat de tabel met verstekwaarden daar wel op gebaseerd is. Maar dan vertaald naar OSM-termen.
Maar ze kijken er wel degelijk naar, het is niet dat ze maar willekeurig wat doen, muntje opgooien of zo.
Als ik de hele tabellen-per-landlijst doorwerkt, snap ik dat algemene routers dat willen vereenvoudigen, keuzes maken. En dat sommige gevallen dan buiten de boot vallen omdat ze bv alleen in een bepaald klein landje voorkomen. Als daardoor duidelijke fouten ontstaan, moet het op routerniveau worden aangepast. Ik heb een paar keer in een zoân router xml mogen grasduinen, best lastig uitvogelen en soms veel code, maar het is geen raketwetenschap.
Misschien moet er dan een landspecifieke router.xml gemaakt worden. Of misschien moeten de verstekwaarden in een voorbewerking worden toegepast. Bij OsmAnd kan je zulke dingen opnemen in de conversiespecificatie die de âvertalingâ van OSM naar de OsmAnd database doet. Dan belast het de routing engine niet, maar als je iets wijzigt moet je het wel opnieuw laden of wachten op de volgende update.
De hele bundel verstekwaarden expliciet in alle objecten opnemen vind ik persoonlijk de slechtste oplossing. Dan kan je als er een nieuw voertuig verschijnt of kwa regels aangepast wordt, alle wegen in de database gaan aanpassen, in plaats van het centraal aan te passen in de defaults-tabel (en de router xml of vergelijkbare spec).
Om Marc maar eens te quoten: ââŠmaar je mag ook niet tennissen op een snelweg. Dat wil toch niet zeggen dat ik dan maar sport:tennis=no op alle snelwegen moet plakken?â
