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

Dat je OSM notes wilt oplossen, prima. Maar blijf van de routes af. Met ID kun je geen routes bewerken. Dat lijkt zo, maar is niet zo.
Bij de aanpassing van 89-90 en de Cor Schipperspadroute heb je een voetpad tussengevoegd.
ID stopt dat voetpad vervolgens onderin de route en dat is niet de plek waar het thuis hoort, het moet ongeveer midden in de routes.
ID haalt overigens nog meer gemene dingen uit met routes, maar dat is hier niet aan de orde.
Het beste is asap overstappen op JOSM, maar als je met ID wilt blijven werken, laat dan de routes met rust en laat zulke notes openstaan of PM mij, ik pas het dan aan.

Vriendelijke groeten,
Dick van den Hoven

Die oneway ontbreekt niet. Die is er terecht niet. De oneway begint altijd pas na de fietspaden. Daar staat het C01 bord.
Hier een oneway plaatsen is fout en verstoort de fietsroutering.
En fiets uitzondering erop zetten kan ook niet.
Ik heb de oneway=yes verwijderd.

bij de Watermolenval heb ik het verwijderde fietspad weer terug gelegd als construction. Dan kan ik 2 fietsroutes en een wandelroute heel houden. Er zaten gaten in de routes
Vriendelijke groeten,
Dick van den Hoven

Als het een overstapje is, geef dat dan aub ook aan: stile=stepover
Er zijn meerdere types stile, dus stile alleen is niet voldoende.