Oh ja, ik heb het netwerk Reimerswaal aangemaakt en de knopen lid gemaakt van dit netwerk.

Hallo Wim,

Nog wat aanvullingen
Ik heb even geëxperimenteerd in ID.
In ID kun je een knooppunt lid maken van een relatie, dus bijv. een netwerk. Je moet dan wel er voor zorgen dat die relatie geladen is, dus voor een netwerk moet je eerst een knoop laden, die lid is van een netwerk.
Je kunt een route aanmaken in ID en die ook lid maken van een netwerk.
Wel moet je de route in de juiste volgorde invoeren. Een volgorde-fout herstellen lijkt nog steeds onmogelijk.
Verder zie je in ID niets van de route. In JOSM kan ik zien door een style waar de routes lopen en welk soort route het is. In ID lijkt alsof je zo blind bent als een mol
Dus met beperkingen is mogelijk om in ID een netwerk in te voeren.
Verder wordt bij de wandelknooppunten de tag expected_rwn_route_relations gebruikt. Die geeft aan hoeveel routes er bij dat knooppunt aankomen.
Dat is erg handig omdat knooppuntnet een lijst maakt van knooppunten waar deze tag niet overeenkomt met het aantal routes en zo kun opsporen waar nog werk te doen is.

Vriendelijke groeten,
Dick van den Hoven

Wim,

Vind je dat nu echt een goed idee om met ID een wandelnetwerk te gaan inleggen?
Je zadelt mij gelijk al met werk op waar ik helemaal niet op zit te wachten.
Een lijst van 13 knooppuntwezen in knooppuntnet
Die moeten lid gemaakt worden van een netwerk, dat ook nog niet bestaat.
En hoe nu verder?
Kan ik voortdurend knooppunten en routes lid gaan maken van een netwerk omdat dat niet met ID kan?
Wil je alsjeblieft hier mee stoppen?
Ik zit echt niet op extra klussen te wachten.
Ik vind dat als je als mapper een klus oppakt, je die klus ook geheel zelfstandig moet kunnen doen zonder dat andere mappers daar onverwacht ook nog eens werk door krijgen.
Het is nu eenmaal zoals het is, er zijn maar weinig mappers, die netwerken inleggen en dat betekent dat er dingen blijven liggen. Ik heb die note ook gezien, maar op dit moment geen draad zin om dat netwerk in te leggen en nu wordt ik door een andere mapper gedwongen me daar alsnog mee bezig te houden of ik moet lijsten fouten in knooppuntnet gaan accepteren, wat het erg lastig maakt om nog werkelijke fouten te vinden.

Vriendelijke groeten,
Dick van den Hoven

Wim,

Ik heb deze changeset reverted.
Er liggen daar een hele bult bus- en fietsroutes, die allemaal stuk zijn door deze changeset.
Die fietsroutes kan ik nog repareren, maar die busroutes niet, er zit daar een start- en eindhalte en daar kom ik niet uit.
Verder had je de eenrichting op zijn Engels gezet.
Je kunt het beste een note op de kaart zetten en vragen of een busspecialist de boel hier wil aanpassen of je stuurt een berichtje aan Leo
En verder moet je zo'n klus nooit met ID aanpakken, dat moet je echt met JOSM doen.

Vriendelijke groeten,
Dick van den Hoven

Ik zie dat je op meerdere plekken traffic_calming neer zet.
Als je in ID een traffic_calming op een knooppunt van het fietsnetwerk of wandelnetwerk neerzet, dan poetst ID een essentiële tag van dat knooppunt, nl network:type=node_network
Is het mogelijk dat je na plaatsen van de traffic_calming die tag terug zet? Het zo erg fijn zijn want nu moet ik regelmatig weer een tag terug gaan zetten.
Alvast bedankt.

Vriendelijke groeten,
Dick van den Hoven

Sorry, ik was op dat moment me niet bewust dat er al een 2025 foto was en omdat de BGT nog de oude situatie weergeeft, werd ik ook niet getriggerd dat er zaken veranderd waren.
Ik heb eea aangepast.
Vriendelijke groeten,
Dick van den Hoven

Je kunt prima een table op een knooppunt zetten. Daar zijn tich voorbeelden van.
Wat er aan de hand is, is dat in ID een bug zit, die als je een table toevoegt, de tag network:type=node_network poetst.
Dus na het toevoegen van een table in ID aan een knooppunt moet je handmatig de tag network:type=node_network weer toevoegen.
Iets wat ik regelmatig doe, want er zijn diverse ID gebruikers, die table's plaatsen en ik wil ze niet aanspreken op een bug van ID waar ze niks aan kunnen doen.

Vriendelijke groeten,
Dick van den Hoven

Ik heb de route 33-37 op de juiste manier gesorteerd, de rotonde bij de Einsteinstraat geknipt, die kun je niet intact laten omdat delen ervan niet in de route passen.
De role backward heb ik omgezet naar forward. De rollen forward en backward slaan op de tekenrichting van de weg, niet op de heen- of terugrichting van de route.
Met deze role geef je dus aan hoe je moet rijden tov de tekenrichting van de weg. De role backward wordt weinig gebruikt en altijd op tweerichtingwegen, nooit op eenrichting wegen.
Sortering:
Eerst de heenrichting, dan de terugrichting, startend bij het begin van de heenrichting tegen de rijrichting in met wel de juiste rollen.
Het blijft altijd een beetje tricky.

Vriendelijke groeten,
Dick van den Hoven

Nog even in StreetView gekeken. in september 2022 was daar nog een oversteek.

Nou routedatabank heeft hem nog steeds als oversteek. Volgens routedatabank steekt daar de rcn route 30-80 over.
Het lijkt me veel veiliger om bij de kruising over te steken en 30-80 steekt nu bij de kruising over, voor 1 richting deed hij dat al.
Ook in FB is de oversteek bij de kruising.
Ik heb die oversteek gelijk maar verwijderd. Er is niks te zien daar

Vriendelijke groeten,
Dick van den Hoven

Wat je ook doet, je lost het hoofdprobleem niet op.
Het hoofdprobleem is dat een elementroute (=route opgebouwd uit netwerkelementen) onzichtbaar is.
Kijk als je routes hebt, die gewoon uit wegen bestaan, ik noem ze maar wegroutes, dan kun je in JOSM even op een weg klikken en je krijgt een lijstje van alle routes, die over die weg lopen. Echter elementroutes staan daar niet bij.
Die kun je alleen opsporen, door een netwerkelement te selecteren en dan te kijken waar hij member van is. Dat is omslachtig en niet werkbaar.
Ik doe veel onderhoud aan netwerken en juist daar gaat het mis.
Bijv. er komt een knooppunt bij tussen 2 andere knooppunten, dan wordt de route gesplitst. Als die route lid is van een memberroute, dan blijft er 1 helft in de memberroute, de andere helft is weg.
En om die erin te krijgen moet je alert, eerst de ene helft selecteren en constateren dat de route lid is van een memberroute en dan de 2e helft weer invaren op de goede plek.
Ook hergebruik ik netwerkroutes als dat zo uitkomt, bijv. 21-22 wordt 24-36 en dan moet je niet hebben dat die route lid is van een memberroute, is dat wel het geval, dan gaat het mis en dat zie in Twente waar ook een paar memberroutes liggen, die gewoon stuk zijn.
Daarnaast heb ik nog tich andere bezwaren tegen memberroutes en dat in het forum uiteen gezet.
Belangrijkste is, dat zeker bij fietsroutes, je nooit een goede aansluiting krijgt. Netwerkroutes sluiten vaak niet netjes op elkaar aan en hoeven dat ook niet. Ze kunnen gewoon overlappen.
En als je elementroutes gaat maken, dan krijg je dus overlappen, die je nooit meer weg krijgt.
Er zijn inmiddels honderden routes met gewoon wegen als member, die het netwerk volgen. Denk maar aan de gekleurde routes bij keuzepuntnetwerken.
Routes opgebouwd uit netwerkelementen zijn een niche in OSM, die asap moet verdwijnen.
Ik heb overigens het rondje Salland gisteren omgezet naar wegen. Nu is het een keurig gesloten route geworden. En ik ben nu bezig om in Twente ook 2 van die elementroutes om te zetten naar wegen, die routes zijn ook stuk als gevolg van netwerkwijzigingen.

Op de Voorweg lag nog de wandelroute Koninklijke Weg
Die heb ik naar het fietspad omgelegd

Changeset reverted.
Er zijn allerlei fouten door knooppunt.nl geconstateerd en ik heb al aangegeven dat het rcn netwerk leading is en niet tbv routes moet worden gewijzigd

Changeset reverted.
Geen rcn wijzigingen voor route toepassen.

Als je een route 30-30 invoert, moet die lid worden gemaakt van het netwerk.
Alle routes, die hier al liggen, moeten worden aangepast. Die mogen geen tentakel meer hebben, zo heet dat stukje met een role erbij.
Van de bestaande knooppunten 30 moet de tag expected_rcn_route_relations worden aangepast van 4 naar 3
Verdiep je aub eerst in de ins en outs van het rcn netwerk, voor je zomaar aan het rommelen gaat.
En als je de wegen in het Rondje Salland had laten zitten en alleen had aangepast, had je het netwerk totaal niet hoeven te wijzigen

Ik heb deze changeset reverted.
Je hebt hier de rcn routes vernield, terwijl er geen enkele reden voor is.
Het lag geheel goed
Je hebt eerst al het Rondje Salland, dat ik had ingevoerd vernield, door alle wegen eruit te halen en op een onzalige manier te vervangen door netwerk elementen en nu probeer je het netwerk om te buigen naar die foute invoer.
Nee, nee, nee en nog eens nee, het netwerk is leading, de routes zijn volgend. Als je het Rondje Salland had in gevoerd met wegen, had je geen enkel probleem gehad.
En grote delen van het Rondje Salland zijn hetzelfde gebleven, dus er was geen enkele reden om de wegen eruit te halen, je had gewoon de wijzigingen kunnen aanbrengen.
De situatie hier illustreert heel goed waarom je routes niet moet opbouwen uit netwerk elementen.
Dat lijkt leuk, maar is het niet.
Netwerk elementen bevatten nu eenmaal overlappen met andere netwerk elementen, dat is onvermijdelijk en daarom krijgt een route, die opgebouwd is uit netwerk elementen, die overlappen kado. Dat los je niet op door de netwerkelementen aan te passen en daarmee foutsituaties te creëren in het netwerk, maar door routes in te voeren met wegen. En dat kan prima door die wegen over te nemen uit de netwerkroutes. Gisteren heb ik het Rondje Deventer ook op manier ingevoerd.
In maart heb ik dezelfde ellende gehad met de Limes route, die ook is opgebouwd uit netwerk elementen ipv wegen.
In hef forum heb ik maart uiteen gezet waarom het een uitermate slecht idee is om met netwerk elementen routes op te bouwen.
Peter Elderson was het daar volledig mee eens.

Ik heb network:type=node_network verwijderd uit de route.
Die tag is uitsluitend voorbehouden aan routes en knooppunten van het knooppuntennetwerk.
Het Boswachterspad is geen knooppuntnetwerk route en mag die tag niet hebben.
Het probleem is dat knooppuntnet.nl het Boswachterspad gaat zien als een netwerkroute en produceert een aantal foutmeldingen.
Met een beetje pech zijn dat meldingen, die niet meer verdwijnen omdat knooppuntnet veel zaken in een cache opneemt
Alsjeblieft geen network;type in "gewone" routes.

Vriendelijke groeten,
Dick van den Hoven

Lijkt me een prima oplossing.

Groet,
Dick

Die routerelaties zijn wandelroutes, dus die kunnen zo op de track gelegd worden. Ik teken veel wandelroutes op de track ook als er een fietspad ligt

Met ID kun je geen routes bewerken.
Dat wordt een chaos. En zeker in dit geval met de rollen forward en backward, ID gaat daar verkeerd mee om en vernielt de volgorde. Dat luistert bij rollen heel nauw.
En ID stopt nieuw toevoegde wegen altijd onderaan in de route. Meestal niet de plek waar je ze wilt hebben.

Ik heb alle schade hersteld, dat kwam neer op het geheel opnieuw maken van route 29-71 en bij het rondje Eindhoven een greep in de truukendoos om die wegen van onderen naar de goede plek te krijgen en enig herstelwerk aan de wandelroutes
Het vriendelijke doch dringende verzoek om met ID geen routes te bewerken.
Als je dat wilt, moet je overstappen op JOSM

Vriendelijke groeten,
Dick van den Hoven