Ruiternetwerk Veluwe

Even tussendoor, gewoon omdat het kan, een impressie van mijn ruiterwerk:


Die paarse lijnen zijn van een gps-track uit een routeplanner. Die maakte er een behoorlijk zooitje van, maar je ziet wel de knooppunten en min of meer de wegen die erbij passen.

Dit is in de Ruiternetwerk-stijl, best duidelijk al zeg ik het zelf. Met de expected_rhn_route_relations erbij, en de knooppunten in de routes opgenomen, zie je in één oogopslag of het op dit punt af is.

Wat ik niet weet is hoe ik in JOSM kan zorgen dat de rhn_ref weergegeven wordt in het selectievenster en in het relatievenster. Nu staat er alleen de node-id, en die zegt mij weinig.

3 Likes

Weergeven van de rhn_ref in die vensters weet ik ook zo niet.
Wel kun je via de mouse_over de rhn_ref zien. Bijv. in het relatievenster, als ik de muis even op de node laat rusten, krijg je een mouse_over met alle tags+waardes van die node.
Dat werkt ook in het selectie venster.
Verder kun je voor de inhoud van het selectievenster een Advanced View oproepen Ctrl+i die in een apart venster nog extra info geeft

Er leek een advanced setting voor te zijn om die weergave te definiëren, maar het lukte mij niet om het gedaan te krijgen, ook niet na herstart. Nou ja, niet heel belangrijk, als ik er een foutje mee maak vindt Knooppuntnet Analyse het wel.

PS1 Om sneller op te schieten laat ik het vullen van de netwerkrelatie nu achterwege. Voor routeren en weergeven is die niet nodig, en KPN Analyse kan ook zonder. Mocht iemand willen kijken, gebruik dan de optie Analyse per gebied, Gelderland. Schrik niet van de vele “feiten”: bestaande stukken waren zonder network:type=node_network ingevoerd, en ik zet zelf overal de expected… value op wat het moet worden, zodat ik Knooppuntnet kan gebruiken om te vinden waar ik routes vergeten ben.

PS2 Ander dingetje: de nieuwe routes lopen geregeld over paden die in OSM als horse=no zijn aangemerkt. Dat is dan waarschijnlijk in het veld veranderd, maar in principe zou daar survey ter verificatie moeten plaatsvinden. Kan immers ook zijn dat de bebording niet klopt met de getekende routes; het is allemaal nog niet foutloos. Dus dat laat ik voor nu zo.

PS3 Nu ga ik een paar daagjes weg, dus wie vol ongeduld zit te wachten op content in de paardenplanner van Knooppuntnet of Waymarkedtrails die heeft even pech. Volgende week ben je de eerste!

Hieronder de reactie van Marcel van het routebureau die ik zojuist in mijn mailbox ontving.

Hier even in 't kort een reactie op de genoemde punten:

Over de tracécodes in het algemeen → na een korte analyse van onze zijde blijkt dat er in totaal 1128 lijnstukken van het ruiter- en mennetwerk in C-TIP staan, daarvan hebben er 475 geen of een foute tracécode. Van die 475 hebben er 243 de status definitief. Hieruit blijkt dus dat er veel fouten zijn/in de data zitten. Datatechnisch is het voor ons ook eigenlijk niet wenselijk om die tracécodes bij te houden. Wij gaan deze dus ook uit onze data halen en voortaan laten we dit dan ook weg!

21 → de routes hier zijn, in opdracht van de gemeente Nunspeet, aangepast (in april), zie bijgevoegd kaartje.
31 → tracécodes vervallen, de bewegwijzering buiten wordt aangepast
40 → tracécodes vervallen
42 → tracécodes vervallen
46 → 2x 64 vlak bij elkaar wil in ons systeem zeggen dat dit een “samengesteld knooppunt” is. De onderlinge afstand tussen deze 2 knooppunten is zo klein dat we er 1 knooppunt van maken (m.n. voor de vermelding op de -papieren- kaarten, dan overlappen ze elkaar niet).
47 → tracécodes vervallen

Ik wil graag even zeggen dat ik het met belangstelling volg. Mooi werk, mensen!

2 Likes

Gebruiksrecht:
Publiceert het routebureau al hun data onder een OSM-bruikbare licentie?
Anders zou Routebureau Utrecht voor deze source wel op de contributorspagina moeten staan.
Is er een mail met een duidelijke toestemming voor deze data voor dit doel? Dat zal wel want bestanden gestuurd. Of een toestemming voor alle routedata van het routebureau?

Mij lijkt een expliciete verklaring dat voor OSM alle routedata van het routebureau gebruikt mag worden, en dat dan op de contributorspage opnemen, het beste.

Ik weet niet of het helpt, maar dit ruiternetwerk staat ook op routedatabank.
Volgens mij mag routedatabank gebruikt worden.
routedatabank is vernieuwd en bevat nu meer dan fiets- en wandelknooppuntnetwerk

Aangepast.

1 Like

De standaardlicenties van de routedatabank zijn onvoldoende voor OSM. We hebben toestemming gevraagd en gekregen voor de fietsroutes en de wandelroutes incl de netwerken, voor gebruik tbv OSM.
Die toestemming hebben we van de routedatabank, voor zover ze zelf toestemming hebben gekregen van de data-eigenaar. Dat is niet altijd duidelijk!
Dus in dit geval is MI nog aanvullende toestemming voor de ruiternetwerken nodig, ongeacht of we de data via de routedatabank halen of niet.

PS Het toesturen van bestanden kan je zien als een eenmalige toestemming voor die data. Daar zitten updates dus niet bij. Dat moet dan elke keer opnieuw gevraagd en gegeven worden. Nou lijkt die toestemming vanzelf te spreken, maar het is toch beter om een globalere expliciete toestemming op de contributorspage op te nemen. Dat geldt dan dacht ik gelijk als naamsvermelding.

Momenteel gebruik ik de ruiterrouteplanner van routemaker, omdat het routebureau daar zelf naar verwees, en soms ook de planner van ruiterenenmennen die volgens het routebureau ook dezelfde data gebruikt.
Al zie ik toch stevige verschillen tussen beide planners… zo is de wijziging bij Nunspeet op ruiterenenmennen al te vinden, terwijl routemaker nog de oude toestand geeft.

Ik neem aan dat je routebureau Veluwe bedoelt. In mijn eerste mail aan hen heb ik toestemming gevraagd om de data over te nemen in OSM. Daarop kreeg ik prompt de data aangeleverd zonder uitgebreide toelichting. Vervolgens heb ik meteen een mail gestuurd dat ik er zonder tegenbericht vanuit ga dat het OK is deze data te gebruiken. Ik heb daarin ook verwezen naar het belang dat OSM hecht aan licenties en compatibiliteit. Op dit onderwerp is men ook in latere mails niet meer terug gekomen. Ik ga er dan van uit dat het OK is. Of zich dit dan leent om op de contributer pagina opgenomen te worden weet ik niet maar lijkt mij geen probleem.

Lijkt me voor het invoeren afdoende, maar heel formeel gezien heb je geen algemene toestemming voor toekomstig gebruik en bijwerken.

Helemaal netjes wordt het als je een paragraaf voor de contributors page maakt waarin je zegt dat OSM toestemming heeft om deze bron te gebruiken voor invoeren en bijhouden, met verwijzing naar deze draad. Dan leg je die tekst nog 1x voor aan het routebureau, voor goedkeuring van de vastlegging. Dan weten ze gelijk hoe dat bij ons werkt. En dan het (ongetwijfeld positieve) antwoord in deze draad opnemen.

Klinkt omslachtg maar dan is het wel helemaal netjes afgehecht, zoals dat heet.

PS Veel al ingevoerde routerelaties hebben de rollen ref voor de knooppunten en main voor de paden. Voor ways is geen rol gebruikelijker, dat staat sinds het invoeren van de recreatieve rollen gelijk aan main. Voor ref is geen rol afgesproken, en MI hoeft dat ook niet want deze knopen zijn eenduidig gekenmerkt met rhn_ref. Ik ken geen software die deze rollen gebruikt.
Tegelijk zijn er ook routes met backward en forward vanwege de verschillende rijrichtingen; ook op de routeplanner staan die ingetekend.
Mijn voorstel is daarom om alleen backward en forward te gebruiken in de ruiterenenmennenknooppuntnetwerkverbindingsrouterelaties, en alle andere rollen te verwijderen!

1 Like

Voortgang
Het hele netwerk zit erin. Alles met expected aantal en met de knooppunten erbij in de routes.

Met Knooppuntnet Analyse heb ik alle foutjes die ik gemaakt had opgelost, behalve de paden die als horse=no in OSM staan maar waar volgens de data een horse-route over loopt. Ik zie niet hoe ik dat zonder survey kan oplossen.

Ongenummerde 'knooppunten
De data bevat veel knooppunten met een streepje ipv een nummer. Sommige daarvan zijn helemaal geen knooppunten (geen keuze, geen bestemming) maar staan bv op een gemeentegrens. Die heb ik gewoon weggelaten.
Maar sommige zijn ongelabelde eindpunten van aanlooptakken. Die heb ik de speciale value o gegeven.

Mennen
Het paard-met-karretje vs paard-zonder-karretje verhaal laat ik voor nu wat het is, want de tagging is niet duidelijk afgesproken en er is geen landelijk eenduidige aanpak en markering.

Ontbrekende paden
Er ontbreken nog veel ruiterpaden. Ik heb een paar paden ingeschat als ik delen ervan kon zien op de luchtbeelden, en een paar die absoluut noodzakelijk waren om de verbinding te maken (dus op gezag van het routebureau). Soms was er wel een getekend pad volgens de BGT, maar zonder enige andere bevestiging ga ik daar in een natuurgebied niet op af.

Bridleway of designated
Ik heb de indruk dat veel paden echt wel ingericht zijn als ruiterpaden, maar zonder survey is dat niet met zekerheid te zeggen. Er zijn ook veel paden highway=path waar wsch ook lopers en mtb’s op mogen. Die kunnen dan wel de aangewezen route zijn voor paarden, dus dan zou horse=designated passen, of toegelaten voor paarden, horse=yes. Of is dat default voor highway=path?
Is het feit dat een pad gemarkeerd is voor ruiteren/mennen genoeg om horse=designated toe te kennen? Het is geen wettelijk bord, maar het is wel officieel aangewezen.

@PeeWee32 Ik heb nog wat vragen en opmerkingen voor het routebureau. Wil jij die als OSM-contactpersoon aan het routebureau stellen, of zeg je, doe maar zelf?

PS Ik heb alle knooppunten en routes in de netwerkrelatie gemikt. Heeft verder geen nut, want je kan in Knooppuntnet Analyse selecteren op gebied, Gelderland, dan krijg je precies hetzelfde. Om toch wat toe te voegen heb ik de operator op de networkrelatie getagd.

2 Likes

Ik ben het met je eens Peter. Ik zal er nog een mailtje aan wagen.

Hoewel ik het wel logisch vind dat ieder onderdeel van een relatie een rol heeft binnen de relatie heb je wel een punt. Binnen dit type netwerk zie ik niet snel andere rollen ontstaan en als die er wel komen dan kunnen we die alsnog toevoegen. Ik heb in het verleden wel eens andere rollen
toegevoegd als er informatieborden over de route in het veld zichtbaar waren.

Klasse Peter. Ik zal ook nog eens een kritische blik werpen op het geheel. In augustus ben ik weer in Hoenderloo en kan ik wat veldwerk doen. Als je nog punten weet waar dat nodig is mag je wat mij betreft wel notes aanmaken dan kijk ik daar t.z.t. wel naar in het veld. Ik zal nog een analyse maken van wat vreemde zaken zoals de horse=no op zo’n routerelatie. Ik zag ook al een aantal cattlegrids in de relatie wat erg onwaarschijnlijk is omdat je daar met een paard niet overheen wil. Veelal zal daar een klein stukje way liggen er net omheen. Ik snap je punt over yes/designated. Ik denk dat ik meestal designated toevoeg maar als anderen daar yes van willen maken is dat wat mij betreft ook goed. Er zullen wellicht anderen nog reageren die hier een uitgesprokener mening over hebben .

Daar hoef ik niet tussen te zitten hoor. Je had toch al contact met Marcel en die reageert tot nu toe erg snel dus stel ze maar aan hem.

Ik bedacht me net dat ik daar al eens eerder een overpass kaartje van had gemaakt. Een mens kan niet alles onhouden :grinning:

Ja, prima, want knooppuntroutes zijn gewoon routes, zij het meestal vrij kort en ingekaderd in een netwerk. Qua rollen zijn voor (recreatieve) routerelaties backward en forward, guidepost, en main/alternative/excursion/approach/connection goedgekeurd en gebruikelijk, maar er is geen lijst van toegestane rollen en soorten punten.
Terzijde 1: Persoonlijk ben ik erg terughoudend met het opnemen van allerlei puntobjecten in routerelaties, omdat die vaak niet bijdragen aan de routeplanning en rendering. Voor planning heb je in de relatie alleen de route (de ways) nodig, en ook voor rendering hoeven de interessante objecten niet in de relatie te zitten; die kunnen op zichzelf al gerenderd worden. Maar dat is mijn voorkeur; anderen willen graag alle objecten die bij de route horen ook in de relatie opnemen, in Italië is dat heel gebruikelijk.

Terzijde 2: JOSM heeft ingebouwde presets voor routerelaties, waarop ook de validatieregels gebaseerd zijn. Daarbij hebben ze een veel te strak idee aangehouden over welke soort punten en rollen er mogen zijn. Bovendien hebben ze het idee dat knooppuntroutes heel anders zijn dan andere routes. Vandaar dat er allerlei waarschuwingen komen, bijvoorbeeld als je n informatiebord opneemt of als je start- en eindknopen opneemt.
Ik heb daar een issue over geopend, maar afgaande op de reacties denk ik niet dat het aangepast gaat worden. Ik heb zelf die validatie-kategorie nu permanent geblokkeerd, zodat ik er niet voortdurend mee lastiggevallen word. Want dan heb ik de neiging om alle waarschuwingen te gaan negeren.

1 Like

Kwam vandaag in de duinen dit niet-zo-carriage-geschikte ruiterpad tegen :wink:

1 Like

OK toegegeven … het is wat uitdagend met een aanspanning maar waar een wil is … :wink:

2 Likes

30 gr camber moet genoeg zijn…

1 Like

Ik heb een mail gestuurd met de vraag of we toestemming krijgen nu en in de toekomst om hun data te gebruiken voor OSM. Mijn voorstel aan hen voor de contributer page was :

Routebureau Veluwe gave permission (2024-05) to use their data of the horse-, hike-, bike- and MTB network of Veluwe, Gelderland, Nederland. Further info can be found in this thread on the OSM forum.

De reactie daarop was :

Prima om dat zo te vermelden, geen probleem! Al onze data (van alle routenetwerken) is openbaar omdat wij voor en namens overheidsinstanties werken. Wij geven al onze data dus bijvoorbeeld ook door aan de Routedatabank.

Dit maakt de weg ook vrij om hun wandel, mtb en fiets data te gebruiken voor OSM. Ik heb nog ff geen idee of dit veel toevoegt aan wat er al beschikbaar is maar kwaad kan het nooit.

@Peter_Elderson Zou jij de contributer page willen bijwerken? Alvast dank.

1 Like

Ik heb de bijdragerspagina bijgewerkt.

En ik had nog wat dingetjes nagevraagd:

  1. Alle routes in het ruiterknooppuntennetwerk zijn tweerichtingen
  2. Nepknooppunten met een streepje die op de gemeentegrenzen liggen, horen niet als knooppunten in de data te zitten.
  3. Eindstandige knooppunten met een streepje, zijn wel knooppunten, maar ze krijgen alleen een nummer als het officiële opstappunten zijn. Dus zij willen ze in de officiële planner niet als startpunt hebben staan. Op de weg staat er gewoon een paaltje zonder nummer maar wel met het ruiternetwerkschildje en een pijl. Ik geef die het speciale knooppuntlabel o wat we ooit voor dit doel in het leven hebben geroepen. De Knooppuntnet Planner kan er dan mee plannen maar we geven ze geen knooppuntnummer. Ze denken erover na hoe ze dat in hun routemaker planner moeten verwerken.
  4. Nepknooppunten bij secties waar heen andere wegdelen heeft dan terug: Wij kunnen die met backward/forward verwerken. De routemaker planner gaan ze laten aanpassen zodat dit geen planbare knooppunten meer zijn, en misschien ook rekening houden met de rijrichting.
  5. Idem bij plekken waar zij zelf niet gesplitst hadden maar die op de weg verschillen voor heen en terug. Zelf heb ik ook die in OSM al met backward en forward geregeld.
  6. Er zijn een paar dubbelroutes, dwz twee routes tussen dezelfde twee knooppunten. Dat blijft zo. In OSM maak ik ook twee relaties, de een noem ik bv 10-20 en de andere dan 20-10.
  7. Alle routes zijn horse=yes of horse=designated. Dus horse=no kan overal af.
  8. Alle routes van het ruiter- en mennetwerk Veluwe zijn ook menbaar tenzij ter plekke (door de landeigenaar) anders aangegeven. Op de routemaker planner staat dat niet; vooralsnog heb ik dat dus niet gemapt.
  9. Zij hebben geen precieze informatie over alle paden of ze ruiterpad, horse=designated, horse=yes of horse=no zijn. Ze zouden het wel willen hebben. Dat is misschien een punt waarop een samenwerkingsproject gedaan kan worden? Tegelijk met surface bijvoorbeeld, en intekenen van nu ongemapte aparte ruiterpaden naast de paden waar de route nu op loopt.

PS ad 7: gedaan: horse=yes toegevoegd behalve op bridleways daar heb ik horse=yes juist weggehaald. Horse=designated zou soms van toepassing kunnen zijn, soms ook niet; zonder nadere gegevens of survey kan ik dat niet taggen.

1 Like