Dat heb ik in de diskussie ingebracht, maar het is niet opgepakt. Ik wil way members niet uitsluiten, maar zou (mocht het zover komen) in mijn basisvoorstel kunnen stellen dat het niet gekombineerd kan worden met forward en backward zoals dat bij fietsrelaties wordt toegepast, en dat als dat toch zou moeten, aparte variant-relaties gemaakt kunnen worden.
Mijn pilotvoorstel in NL gaat alleen over relation members in wandelroutes, die toch al netjes onderverdeeld zijn. Ik ben wel goed maar niet gek!
Praktisch: ik heb met https://www.longdistancepaths.eu/laws/en/index.php de afspraak dat als zij hun routes weer eens willen verversen, dat ik dan de hele mikmak op onderbrekingen, volgorde etc. kontroleer en zonodig repareer. Kost me 5 a 15 minuten per LAW (tenzij er echt idiote dingen inzitten, maar dat komt eigenlijk niet voor). De volgende keer dat ik dat doe kan ik de members van een paar overkoepelende routerelaties makkelijk even een rol geven, dat kost me hooguit enkele minuten extra.
Voor zover het over een relatie met relaties als leden gaat, zie ik geen problemen. Dit zijn vaak goed gestructureerde relaties, waarbij deze rollen kunnen helpen om duidelijk te maken wat die subrelaties in de route doen. Ik ken meerdere wandelrondjes die aanvoerroutes hebben en dat is toch altijd vervelend om goed te taggen.*
Je spreekt bij forward- en backward-rollen alleen over fietsroutes, maar ik ben ze ook wel eens op wandelroutes tegengekomen. Bijvoorbeeld op een knooppuntenroute waar de stickers op de lantaarnpalen aan de rechterkant van de weg zijn geplakt en dus heen- en terugweg aan verschillende kanten de rotonde oversteken.
Ze zijn soms ook slecht te volgen. Zo ken ik een route met rode paaltjes, waarbij de aanvoerroutes ook rode paaltjes hebben. Dan kom je op een kruising en gaat de route ineens twee kanten op.
Inderdaad, zelfde advies: zet die variant-roles niet op de losse wegen maar maak er een deelrelatie van.
Het viel me wel op dat veel mensen uit andere landen nog niet goed raad weten met hierarchisch opgebouwde routerelaties. Ze zijn er nu wel aan gewend dat het bestaat, maar zelf eraan beginnen, huuuu! Ik heb trouwens geen overzicht in hoeverre de meeste renderers/routers/data-users de hierarchie goed oplossen. OsmAnd in ieder geval niet, en die kan ook niet routeren langs onze perfekt getagde langeafstandsroutes. Garmin, ook niet.
The Floris V trail https://hiking.waymarkedtrails.org/#route?id=9769895&map=9!51.9349!4.6883
This national trail has three short alternatives and I added one section connecting this trail to the Dutch part of the GR5 (=E2).
The connecting section has the “approach” role within the parent relation. The connection is signposted on both larger trails and waymarked with the same symbol as the parent trails.
Brabantse Vennenpad https://hiking.waymarkedtrails.org/#route?id=9500318
This is a regional roundtrip trail, it is sectioned for daily stages and includes a number of waymarked approaches to/from train stations.
Dit kostte heel weinig tijd omdat de routes goed ingedeeld en gedokumenteerd zijn. Ik kan alle LAWen en SPen in een uur doen, mocht dit voorstel aanslaan. Andere routes zouden meer tijd kunnen vergen, vooral om ze goed in te delen. Het rollen toekennen gebeurt dan tussen neus en lippen door.
Rollen toekennen aan wegen in routerelaties zou veel tijdrovender en lastiger zijn. Vooral omdat de relatie-editor van JOSM moeilijk kan omgaan met niet-aaneensluitende ketens van wegen. Je zou functies moeten hebben zoals “group the members according to role and sort within the group” en/of “detect and sort chains of ways”. Ik zou eerst de indeling in losse deelrelaties aanpassen en dan rollen toekennen aan de deelrelaties binnen de overkoepelende relatie.
De rollen zoals hier toegekend beïnvloeden de bestaande rendering niet. Ze kunnen rustig blijven staan voor mensen die er mee willlen experimenteren, qua data-use of rendering.
Zelf zou ik al tevreden zijn als deelrelaties met een willekeurige rol (niet-main) ietsjes anders weergegeven worden. Een streepjeslijn voor alternatieven/extra’s is tamelijk gebruikelijk, maar als je een kaart maakt met alle routes dan lopen er soms rustig 8 verschilende routes (regionaal, lokaal, knooppunt, internationaal, landelijk) over 1 weg, en voor elk daarvan kan het de hoofroute of een alternatief zijn… ik zou het niet kunnen oplossen.
Een voortgangsbericht.
Het originele voorstel ligt helemaal stil, de voorsteller reageert niet eens meer. Ik heb nu een basisvoorstel als Feature Proposal op de wiki gezet en de RFC op de tagging mailing list geopend. Punten uit de diskussie hier zijn verwerkt. Punten kunnen natuurlijk hier besproken worden, maar de talkpagina bij het voorstel is de plek voor verbetersuggesties, op- en aanmerkingen.
NB Voor de Nederlandse situatie komt het erop neer dat deze rollen niet aan wegen worden toegekend maar aan relaties (deelroutes). In andere landen zullen ze wel geregeld aan wegen worden toegekend, al denk ik dat de mappers dat snel zat zijn als het om flinke alternatieven gaat.
De RFC is geopend tot 4 juni, daarna ga ik proberen om het in stemming te brengen!
De stemming is geopend, onderstaand bericht is op de tagging-lijst geplaatst.
Hopelijk mag ik ook in dit forum op voldoende steun rekenen!
De toepassing die waarschijnlijk als eerste verbeteringen hierop gaat baseren is waymarkedtrails. Dit voorstel maakt verbeteringen mogelijk voor rendering van alle soorten recreatieve routes, plus een betere hoogtegrafiek en verbeterde gpx-uitvoer.
The proposal will not change during voting. I will answer clarifying questions. Comments, even if it’s just about wording or examples and doesn’t change the proposed roles, will be considered after the voting.
Thanks everyone for useful comments and suggestions so far. I am confident we will get this improvement done.
I know some people had expected more. And I agree! Even then, please vote yes to this basic proposal, it lays the groundwork for things to come.
Die bevat een node 56, een stukje weg, en weer een node 56.
Zou die weg dan op role=connection horen? Route 56-56 is immers niets anders dan een uitgespreid knooppunt die ‘echte’ routes verbindt.
Een alternatief is om alle aansluitende routes alle punten van zo’n opgeknipt knooppunt te laten bereiken met een stukje connection, maar dat lijkt afgeraden te worden vanwege de complexiteit en onderhoudbaarheid van die aanpak.
Hm… hier is niets over afgesproken, dit voorstel gaat niet over knooppuntnetwerken.
Gedachte 1. De rol connection in knooppuntnetwerken wordt alleen in de netwerkrelatie gebruikt voor members die twee netwerken verbinden. Dus in de netwerkrelatie zou ik het niet voor nodeX-nodeX verbindingen binnen 1 netwerk gebruiken.
Gedachte 2. In een node netwerk zijn alle node2node-relaties verbindingen tussen twee nodes. In dit geval hebben de nodes hetzelfde nummer, maar voor de netwerktopologie maakt dat niet uit. Dus waar zou het toevoegen van de rol connection voor dienen?
Gedachte 3. Als je niet de nodeX-nodeX-relatie de rol connection geeft, dan kan je alleen het stukje weg de rol connection geven. Doe je dat dan binnen de nodeX-nodeX-relatie, of neem je het stukje weg op in alle relaties die eroverheen gaan? Maar wat is dan het hoofdknooppunt en welke zijn de bijknooppunten? Het kan aan mij liggen, maar dan wordt het toch best wel ingewikkeld, en wat levert het op?
Nee, ik zou gewoon die gesplitste knooppunten houden met kleine verbindinkjes ertussen om de aansluitingen (in de knooppuntplanner) mogelijk te maken. Het gebeurt trouwens vooral bij fietsen, omdat die ook werkelijk vaak een andere route met andere junctions gebruiken en daarbij ook meestal op meerdere plekken een bordje hebben staan.
Maar, ik moet eerlijk bekennen dat ik wb fietsknooppunten geen expert ben, om het zacht uit te drukken.
Na het vorige bericht heb ik https://wiki.openstreetmap.org/w/index.php?title=Cycle_Node_Network_Tagging nog eens bekeken. Het zag er best wel oud uit, ik snap nog steeds niks van het tentakelgebeuren, en volgens mij is de toestand in de wereld wel wat veranderd sinds dit geschreven werd!
Sommige stukjes zijn nog steeds duidelijk en aktueel genoeg, maar:
Klopt het stuk over een “collection relation”?
Klopt het dat op de nummerbordjes meestal de netwerknaam staat?
Is het kopje “Examples of already existing network relations” niet een beetje achterhaald?
Het klopt wat betreft België, maar niet wat betreft Nederland. Er lijkt nogal een aversie tegen collectie-relaties te bestaan, waardoor dit nooit is uitgevoerd.
edit: Het lijkt alsof de Belgische collectie-relatie is verwijderd en het dus helemaal niet meer klopt.
Ik zou meestal naar vaak veranderen. Het lijkt wel steeds vaker niet voor te komen. In Brabant staat op veel nieuwe bordjes ‘www.visitbrabant.nl’ i.p.v. het netwerk. Volgens mij staat in Rotterdam de netwerknaam ook niet meer op de bordjes, maar nog wel op de kaarten bij de knooppunten.
De voorbeelden zelf zijn best goed, alleen de tekst voor Belgisch Limburg klopt niet meer.
En dat het punt van de gesplitste knooppunten… is het niet gewoon zo dat je een paartje, een driehoekje of een vierkantje maakt van onderling verbonden punten met precies hetzelfde nummer, en dan je knooppuntroutes laat landen op het eerste punt wat ze tegenkomen?
Voor wandelroutes is dat meestal zeer eenvoudig, omdat de richtingen hetzelfde zijn.
Voor de tweezijdige fietsroutes betekent het dan vaak dat de heenrichting op het ene punt xx landt, en de terugrichting begint op een ander punt xx, en ergens komt het dan samen.
O, dát zijn dan de “tentakels”! Ik begin het geloof ik in principe te snappen.
Visueel zie ik dat op sommige plekken de onderlinge xx-xx verbindingsstukjes ook in sommige knooppuntroutes zijn opgenomen. Soms zie ik de heenweg zelfs weer terugverbonden met de terugweg. Het veiligheidsspeldmodel? Dat klopt dan weer niet met wat ik dacht te begrijpen.
Dat hele wiki stuk is verouderd.
Ik heb wel een tijdje terug wat over de ref tag erin gezet.
Het tentakelstuk is ook onbegrijpelijk.
De tentakelgedachte is nog wel te volgen, alleen moeilijk in de praktijk toe te passen.
Grootste probleem is dat de validatie van knooppuntnet.nl wel is opgebouwd op het tentakelmodel, dus moeten we het erin laten staan.
Het voorbeeld dat daar gegeven wordt, in Bemmel, bestaat inmiddels niet meer in die vorm en heeft ook geen tentakels meer.
We kunnen toch zonder tentakels taggen, bijvoorbeeld door een relatie 20-20 te maken bij meerdere knooppunten 20, waarbij dit geen fouten oplevert in Knooppuntnet.nl?
Dan kan er worden gezegd in de wiki dat deze methode afgeraden wordt, maar kan het nog steeds gevalideerd worden in Knooppuntnet voor routes die wel zo zijn getagd.
In Almelo liggen er een paar van die routes met meerdere afslagen.
Als je dat met de tentakelmethode moet oplossen, krijg je echt onwerkbare zaken met routes die over 750m als forward/backward lopen en als iemand ergens de tekenrichting van de weg verandert, ben je het haas. Hier loopt 51-51 van Wierdensestraat naar Schouwburgplein met totaal 3 afslagen.
Echter als je met forward/backward moet gaan werken, dan wordt het vreselijk uitkijken.
Dan gaat knooppuntnet.nl denken dat het tentakels zijn en loop je kans op meldingen van overbodige segmenten.
Dat kun je soms oplossen, door de richting van de route om te draaien of de knopen anders te zetten.
Routes brei ik over kruisingen en rotondes rond, met als standaardregel, dat bij eerste knoop van de rotonde/kruising, de heenroute stopt en de terugroute dan de rest over de kruising doet.
knooppunten zet ik op die punten, waar je moet beslissen welke vervolgroute je moet nemen.
Dat wijkt af van de tentakelregel, die ervan uitgaat dat de eerste splitsing, die je tegen komt een knooppunt is.
Maar dat vind ik niet logisch.
Stel je komt bij een eenrichtingrotonde. Dan kun je bij de eerste splitsing alleen maar rechtsaf.
Ik vind het dan niet logisch, dat je daar een knooppunt legt.
Als je de tentakelregels volgt, krijg je routelijnen, die niet rond lopen en dat is verwarrend in de route editor, je ziet dan niet goed of het een echt gat is of een opzettelijk gat.
Ik denk dat de tagging zo simpel mogelijk moet zijn, en als dat meldingen in knooppuntnet oplevert kunnen we aan vmarc vragen de check aan te passen. Een enkele keer taggen voor de checker is niet erg, vind ik, maar een vereenvoudiging niet doorvoeren omdat de checker dan een melding geeft, dat lijkt mij niet goed.
