Niet helemaal mee eens. Het is in OSM erg belangrijk om een goede foutdetectie en kwaliteitsborging te hebben. Liefst ook een automatische verouderingsdetectie. Anders holt het achteruit. Dus knooppuntnet vind ik heel belangrijk. Dat je dan wat afspraken maakt en kenmerken gebruikt om dat te laten werken is prima, zolang het óók een daadwerkelijke functie heeft.
Misschien zouden we eens op een rijtje moeten zetten welke kontroles echt zo’n nuttige funktie hebben. MI kan het eenvoudiger en daardoor effektiever.
Bijvoorbeeld de kontrole op verwacht aantal relaties. Dat moet je zelf taggen, en als het niet klopt volgt een “feit”. In de praktijk doen sommigen het wel en sommigen niet, en wie het wel doet zet de waarde vaak gewoon op het aantal relaties wat er op dat moment is. Mij lijkt het voldoende als het punt in de checker opvalt als er twee of minder relaties aan vast zitten, en dat je dan bij 1 of 2 kan aangeven als het echt zo hoort.
Daar heb ik het toch totaal niet over gehad?
En ik heb toch aangegeven dat routes compleet en goed moeten zijn?
Natuurlijlk moeten er foutcontroles zijn. Ik heb nergens gezegd dat die weg moeten.
In ieder geval moeten gaten in routes gedetecteerd worden. En eigenlijk niet alleen in knooppuntroutes, maar ook andere routes.
Ik ben de laatste tijd in Duitsland aan het werk geweest en als daar de diverse routes ziet, is het om te huilen. Heel veel gaten en repareren is een bijna onbegonnen klus.
Ook blijft de volgorde belangrijk, zeker bij forward/backward, dus ook dat controleren.
Maar of een route van hoog naar laag of van laag naar hoog loopt, is niet spannend.
Om de routes niet onhandelbaar te maken, kun je het beste routes van knoop naar knoop maken, dus ook controle op overbodige segmenten, dus of je over de knoop heen gaat, of dat ergens onderweg een weg niet doorgeknipt is
Of een route tot aan zijn knopen loopt is ook belangrijk, er wordt nog wel eens een stukje vergeten
Ook de controle op toegankelijkheid is belangrijk. Er wordt nu gecontroleerd of er geen bicycle=no of use_sidepath in de route voorkomt en bij rwn op foot=no
Ook de controle of alle routedelen een highway= tag hebben, is nuttig
Maar vooral dat checken volgens het tentakelmodel moet er naar mijn idee uit.
helemaal eens dus! Ik heb de duitse E8 onderhanden gehad, dat was nog niet eens zo heel slecht (redelijk kompleet) maar het totaal had toch flink wat onderhoud nodig. Nu waarschijnlijk weer, ik zal eens kijken.
De controles in knooppuntnet zijn oorspronkelijk gebaseerd op de suggesties in de OSM wiki over hoe knooppuntnetwerken gemapped kunnen worden. Als hier zaken bij zijn die niet meer relevant blijken, of die eerder tegenwerken dan helpen, dan wil ik daar zeker aanpassingen voor doen.
Het laten vallen van het concept “netwerk” in knooppuntnet zou een grote verandering zijn, maar zeker ook een flinke vereenvoudiging van de analyse logica. Route wezen zouden niet meer bestaan. Er hoeft niet meer gekeken te worden naar verbindingen tussen netwerken. De logica rond expected_rcn_route_relations zal dan wel vereenvoudigd moeten worden ten opzichte van de beschrijving in de wiki (niet langer geweten of knooppunten binnen hetzelfde netwerk liggen).
Maar: zonder netwerk informatie worden wijzigingen niet meer gerapporteerd met vermelding van het netwerk waar de wijzigingen binnen vallen, ook niet in de detail pagina van een wijzigingenset. Dit maakt het denk ik wel moeilijker om te zien waar een bepaalde wijziging gebeurd is.
Is er iemand die het concept “netwerk” in knooppuntnet zou missen?
Er is een knooppuntnet route planner in opbouw, gebaseerd op de knooppuntdata in OpenStreetMap.
Je kan hier al eens een blik werpen op het “work-in-progress”.
Deze is in voorbereiding voor versie 3.0.0 (gebaseerd op survey:date).
Ok, als hier een vereenvoudiging mogelijk is, wil ik dit graag doen. Het lijkt me misschien wel nodig dat “tentakels” geinterpreteerd kunnen worden zolang ze er zijn in de OSM data?
Dick, kun je een link geven naar een route waar ik dit probeem kan zien?
Het betreft Bornerbroek https://www.openstreetmap.org/note/1888999#map=19/52.30846/6.65649&layers=N Bij de schapendrift ligt ook nog een knooppunt 67. Echter dat krijg ik er niet in zonder meldingen over overbodige segmenten. Meestal maak ik in zo’n situatie een route van hetzelfde knooppunt naar het zelfde knooppunt, dus 67-67 in dit geval. Zoals altijd wil ik dan de route “rond breien” op de rotonde, maar dat levert overbodige segmenten op. Alleen op te lossen door een deel er tussen uit te halen, maar dat wil ik niet. Ik wil complete en hele routes. Ook geprobeerd bij de Schapendrift een knooppunt 67 neer te leggen en het met de routes 67-68, 67-92 op te lossen, maar niets.
Veel tentakels heb ik al opgeruimd in de afgelopen jaren.
Wat er nog veel over is, zijn mini tentakels. Vaak heb je 2 eenrichting fietspaden en een knooppunt bij een wegkruising. Dan leg ik op beide fietspaden een knooppunt en de routes die op de kruisende weg lopen, krijgen een mini tentakel over de oversteek heen. Dat ziet er ook keurig uit in de route editor.
Bij rotondes en kruisingen hanteer meestal de methode van “rond breien” Ik ga de rotonde of kruising rond met forward/backward zodat de route mooi afgerond wordt in de route editor. De logica ziet dit als tentakels, maar dat zijn het niet echt.
Bij de rotonde of kruising zet ik knooppunten op elke splitsing waar je kunt afslaan. Dat is ook anders dan het oorspronkelijke tentakel model aan geeft. Als ik op zo’n rotonde of kruising aankom, stop ik de route meestal bij het eerste knooppunt en maak de rest als een terugrichting.
Wat een groot probleem is, zijn knooppunten, die samengesteld zijn uit een kruising of rotonde en dan nog een stuk tweerichting met het volgende splitsing(en) van hetzelfde knooppunt. Zie bijv. 67 in Bornerbroek.
Verdeelde knooppunten, met een of meer gewone wegen ertussen geef ik meestal een knoop-knoop route, waarbij beide knopen hetzelfde nummer hebben.
Dit heeft het voordeel dat er dan geen dikke bundel routes met forward/backward meer over een aantal wegen loopt. Je hoeft dan nog maar één route te herstellen en geen 4 of soms 5.
Bovendien is vaak zeer moeilijk vast te stellen of het forward of backward moet zijn omdat de tekenrichting van de weg niet altijd zichtbaar is als je stijlen gebruikt, bijv. voor snelheid.
Verder is het tentakelmodel ook er lastig als de samengestelde knoop uit 3 of meer splitspunten bestaat. Dan moet je dus routes van/naar dat splitspunt maken en dat ziet er niet uit in de route editor en is ook nauwelijks te onderhouden.
Ik heb laatst in Losser knooppunt 13 dat ik ooit nog exact volgens het handboek tentakels had gemaakt vervangen door een 13-13 route
Verder strekken sommige van deze verdeelde knooppunten zich uit over grotere lengtes.
Voorbeelden zijn bijv. knooppunt 51 in Almelo over 750 meter met 3 splitspunten en 82 in Almelo met 3 splitspunten en in Enschede 60. Dat los je elegant op met een route 51-51 en 82-82 en 60-60. De bewegwijzering binnen deze knooppunten is ook met knooppuntbordjes.
Mooi! Dit was een groot gemis, want waarom zouden anders al die knooppuntroutes invoeren?
Wat wordt in vergelijking met bestaande knooppuntplanners het unieke voordeel van deze?
Eén grote lange lijst wordt wel een beetje veel… Is het mogelijk om een indeling naar provincie / gemeente te doen? Of alleen wat binnen het gekozen kaartdeel valt? In ieder geval iets wat je gewoon uit de knooppunten/knooppuntverbinden kan afleiden, zonder expliciet een kenmerk toe te moeten voegen?
Nou het gaat eigenlijk over alle knooppuntsoorten, dus ook wandelroutes.
Maar zeker bij wandelroutes is een knoop-knoop route veel simpeler en robuuster
Het idee is niet zo moeilijk, alleen de praktische uitwerking is lastig.
Het idee is, dat als je op het eerste splitspunt van het verdeelde knooppunt aan komt, jouw route ophoudt en de route naar het volgende knooppunt begint. Je wordt dan over het verdeelde knooppunt geleid met een route in forward/backward, die pas na het laatste splitspunt van het verdeelde knooppunt “normaal” wordt. En zo hebben alle routes dus een enkelvoudige uitloper over het knooppunt heen.
Lastig wordt het vooral als je 3 of meer splitspunten hebt, de route vanaf een splitspunt er tussenin krijgt dan 2 forward/backward takken. Iets wat de route editor in JOSM niet aan kan.
Verder krijg je dus bundels forward/backward routes wat lastig te onderhouden is.
Over netwerken moeten we nog wat langer nadenken wat voor en tegen is.
Ik heb ook al zitten denken aan een tag network:name in routes en knopen. Dan kun je nog steeds groeperen.
Maar nu heb je relaties met soms een paar duizend members, waar je eigenlijk niet veel mee kunt.
Verder zijn ook diverse netwerken er eigenlijk niet meer. Bijv in Limburg heb je Zuid Limburg en Noord- en Midden Limburg.
Als je in OSM kijkt, zie je veel meer netwerken.
Ok dat is spaghetti voor mij! Het ligt ongetwijfeld aan mij, maar ik kan er in mijn hoofd geen model of stappenlijstje van maken. Ik ga er dan maar vanuit dat slimmere mensen het kunnen begrijpen en in de tools verwerken!
In dit draadje https://forum.openstreetmap.org/viewtopic.php?id=54379&p=2 post #29 heb ik een uitleg gegeven met een plaatje voor het rwn netwerk.
Maar jouw reactie bevestigt mijn mening. Zo’n model moet je niet willen. Als je een enorme lap tekst nodig hebt om de basissituatie uit te leggen, dan is er iets mis.
In de wiki staat nog een uitleg van een tentakelmodel bij Bemmel en dat heb ik nog nooit kunnen volgen.
Voor wandelen is het zelden moeilijk. Het zou moeilijker worden als de wandelknooppunten in osm preciezer waren wb voetpad, fietspad, rijweg, weghelft. Nu is dat niet het geval, je neemt de eigenlijk de knoop die het dichtstbij is en de aansluitingen van de nodige ways heeft. Als er op een kruispunt voor het gemak van de wandelaar nog meer paaltjes met hetzelfde nummer staan, laat je die gewoon weg, want je mapt de aansluitingen, niet de paaltjes zelf.
Het enige wat ik soms niet kan vermijden is dat twee aansluitingen een klein stukje hetzelfde pad volgen. Dat stukje staat dan in twee relaties. Ik weet niet of dat een “feit” oplevert, maar ik zie er in de praktijk geen probleem in. Wat mij betreft mag het wel gedetekteert worden als “mogelijk een probleem” maar geen rode vlag.
Over dat soort feiten had ik het idee dat je misschien in knooppuntnet een vinkje zou kunnen zetten dat het in dit geval klopt?
Die overlappen zijn niet te vermijden en worden in knooppuntnet niet gemeld, gelukkig maar.
Bij het rcn heb je ze ook, in sommige netwerken over kilometers, bijv. in Limburg en Brabant.
En bij de oosterburen is het zeer gebruikelijk. Daar staan lang niet overal knooppunten, er zijn ook veel punten waar het knooppuntnetwerk splitst, maar geen knooppunt staat. Dat is daar geen probleem door de andere manier van bewegwijzeren. Bij een knooppunt wordt dan naar 2 knooppunten verwezen en ergens onderweg splitsen de routes.
Inmiddels heb ik op verzoek van een Brabander het wandelknooppuntnetwerk rond Veghel (Meierijstad) ingevoerd. Ik zag dat er ook alweer kleine verbeteringen aangebracht zijn, foutjes van mij verbeterd, bedankt daarvoor! Daarna heb ik gezorgd dat knooppuntnet.nl geen fouten/feiten meer geeft. Top-tool!
Dus ik heb netjes alle netwerkrelaties en connecties bijgewerkt, de volgorde aangehouden en zo.
Knooppunten in de relatie opnemen en expected zetten heb ik vrijwel nergens gedaan, de meeste omringende netwerken hadden dat ook niet (alleen Uden wel, dacht ik).
Ik heb ingevoerd tot en met de connections, dus ik heb niet alle aangrenzende netwerkjes aangevuld. In totaal is Brabant nog lang niet klaar!
Het tijdrovendste en foutgevoeligste deel van het werk is het gedoe met verschillende netwerken en met connections. Sorteren/omdraaien van losse knoop-knoopverbindingen is in JOSM geen enkel probleem.
