Ronde van Nederland = kopie van bestaande relatie

Het valt me op dat stukken van de Ronde van Nederland kopieën zijn van bestaande relaties. NB: de Ronde van Nederland is een samenvoeging van al bestaande paden. Bijvoorbeeld het bestaande Grenslandpad is opgenomen in De Ronde van Nederland. Ik zou verwachten dat je dan een “parent relation” Ronde van Nederland maakt, en daar het bestaande Grenslandpad in plakt. Dan ben je ook in een wip klaar. Maar in plaats daarvan is er nu redundantie aangebracht door relaties te kopiëren. Voorbeeld:

  • Grenslandpad - 01 - Sluis-Smedekensbrugge id: 8457530 (bestaande relatie)
    = identiek aan:
  • RVN Grenslandpad - 01 - Sluis-Smedekensbrugge id: 9433000 (nieuwe relatie)

Enzovoorts voor alle deelrelaties.

Heeft iemand een idee of dit met een bepaalde reden is gebeurd? Waarom is de Ronde van Nederland niet opgebouwd uit al bestaande relaties zoals te doen gebruikelijk? Als ik verbeteringen wil aanbrengen, moet ik dat in beide relaties doen? Of wordt één van de relaties nog weggegooid?

Groeten van Henk

Eigenlijk een retorische vraag. Dus ik pak het zelf wel op. Tenzij iemand zich nog meldt, haal ik bovengenoemde redundantie vanavond uit OSM. :slight_smile:

Helaas zie ik dit nu pas…
De RvN is inderdaad een aantal paden aan elkaar geknoopt. Daarbij worden soms hele paden, soms delen van bestaande wandelroutes gebruikt. Het Grenslandpad wordt in de omgekeerde richting gebruikt, daarom zijn de etappes gekopieerd, omgekeerd gesorteerd en in de RVN gezet.

De volgorde en sortering maken voor rendering op bv waymarkedtrails niets uit, maar als je de route exporteert en in een ander systeem inleest wel. Dus het lijkt redundant, maar de relaties zijn wel degelijk verschillend.

Toevoeging: Het lijkt erop dat waymarkedtrails de sortering en etappevolgorde tijdens de export oplost. Bij eerdere tests zaten er hele rare sprongen in de gpx. Kan ook zijn dat afstandmeten.nl (waar ik gpx-en mee controleer op bruikbaarheid) het bij het importeren anders is gaan doen.
Of, en dat is nog het meest waarschijnlijk, de fouten die ik zag lagen niet aan de sortering en volgorde van de relaties, maar aan andere problemen in de deelrelaties, waardoor waymarkedtrails ze niet goed kon plakken en sorteren.

Als dat zo is, vereenvoudigt dat het werken met complexe routes wel, en Traildino, bedankt voor het ingrijpen!

(Ik had wel liever overleg vooraf gehad, dit ging wel erg snel! Ik had het dan gewoon zelf kunnen verbeteren.)

Intussen heb ik lonvia (van waymarkedtrails vh lonvia map) gemaild. Er zit inderdaad een sortering in, die volgordes gewoon oplost. Dus bv

  • Ways in verschillende richtingen, geen probleem.
  • Een setje ways omgekerd in de relatie, geen probleem.
  • Een deelrelatie heeft de ways andersom, geen probleem.
  • Deelrelaties staan in de verkeerde volgorde, geen probleem.
  • Een gap in de relatie, geen probleem (wordt gezien als een rechte streep)

Maar… als er teveel problemen zijn -zoals meerdere gaps; extra takken; tussenrondjes; verdubbelingen; rotondes en andere circular ways- dan faalt het sorteren en exporteert hij alles zoals het in OSM staat. En dan zijn alle bovengenoemde zaken ineens wél problematisch voor verder gebruik bij routeringen en dergelijke.
Het hoogteprofiel van waymarkedtrails voor die route is dan ook verstoord en verbrokkeld, daar kan je het goed aan zien.
Ondertussen kunnen de afzonderlijke deelrelaties wél goed zijn!

Dus bijvoorbeeld, het Marskramerpad is perfekt gemapt en samengesteld; maar de internationale E8-relatie waar hij inzit is ergens in duitsland vernaggeld; dan kan je geen fatsoenlijke gpx-export van de hele E8 maken.
Overigens moet ik nog even doortesten hoe het gaat met rondgesloten routes.

Nu terug naar de opmerkingen van Traildino. Voor internationale routes waar NL-routes onderdeel van uitmaken, maar ook (complexe) routes die niet door ons beheerd/beheerst worden, kun je er vrijwel zeker van zijn dat er multipele gaps, takken, verdubbelingen, extra rondjes, alternatieven etc. in de route zitten. Daardoor wordt de gehele route ongesorteerd, worden ook de omkeringen en sorteerfouten in het NL-deel weer zichtbaar, en zijn hoogteprofiel en gpx-export praktisch onbruikbaar.
Daarom denk ik dat het voor nu toch zinvol is om die stukken te verdubbelen en om te keren waar dat nodig is voor de volgorde. Dan kun je meteen de internationale tagging eraan hangen, want die verschilt van de nationale tagging.

De ronde van Nederland bestaat voor 100% uit delen van NL-LAWen en een SP, plus een verbindingspootje. Allemaal in NL-beheer dus. Ik denk dat we daarbij gewoon moeten zorgen dat hij goed is en blijft, door alle onderdelen goed te blijven onderhouden. Dus dan is verdubbeling niet nodig; maar als het een beetje versloft krijg je alle omkeringen en foutjes weer keihard terug!

Net weer een gevalletje gehad: de Via Degli Dei (Bologna naar Firenze), in principe goed gemapt in 1 relatie, maar iemand heeft 1 fout gemaakt. Resultaat: gpx met omkeringen en strepen, niet bruikbaar om aan een routeerapp te voeren. Ik kan de fout (1 simpel foutje) oplossen en heb dat ook gedaan, maar “normale mensen” kunnen dat niet en zouden dat ook niet moeten hoeven kunnen om de route te kunnen exporteren en gebruiken.

Als ditzelfde zou gebeuren (en als het kan, dan zal het ook gebeuren!) in een etappe van een langere route waarin ook andersomgesorteerde etappes zitten, dan wordt de export van de gehele langere route slecht. Hoe meer omkeringen erin zitten, hoe slechter de export.

Al bij al vind ik de moeite van het bijhouden van omgekeerd gesorteerde delen van een deelpad van een langere superroute toch de beste oplossing, ook al betekent het dat er meer relaties onderhouden moeten worden. Ik ben dan ook van plan de omgekeerde etappes opnieuw aan te maken. Niet alleen de omkering is het verschil, maar ook de tagging en soms de aansliuiting op een andere deel.

Waarschijnlijk is het wel handig als ik de naamgeving wat duidelijker laat verschillen.