[OSM-talk-nl] FRN Stadsregio Arnhem - Nijmegen

[Jo]

>> Overigens mooi dat je eens goed naar het netwerk gaat kijken.
>> Bij het schrijven van dit mailtje kwam ik dit tegen:
>> http://www.openstreetmap.org/browse/relation/1084675/history
>> Ik weet niet hoe dat misgegaan is, maar dat is duidelijk niet
>> in orde. Zal ik dit nog even niet corrigeren om te controleren
>> of jouw script dit probleem ook ontdekt?
>>
>> Groeten,
>> Wim

Wat het script doet, is het volgende:

Trachten om de route te volgen, beginnend met de eerste way, dan de volgende.

Mislukt dit, trachten om de route te sorteren (met mijn algoritme lukt
dit enkel voor de simpelste gevallen, die die geen roles hebben)
Mislukt dit, opgeven en rappporteren.

Opnieuw trachten om de route te volgen, way na way. Als ze geen roles
hebben, worden ze toegevoegd aan 2 lijsten.

Als je een way met een role tegenkomt, het knooppunt onthouden waar de
splitsing gebeurde en alle volgende ways die verbonden zijn met elkaar
enkel toevoegen aan de lijst van ways die van laag KP-nummer naar hoog
KP-nummer gaan.

De wegen met roles die volgen na de onderbreking enkel toevoegen aan
de andere lijst. Terwijl ik dit aan het doen ben, kijk ik, voor zover
ik weet niet na of die wel starten op dat knooppunt.

Vanaf het moment dat er geen roles meer zijn, worden alle ways weer
toegevoegd aan beide lijsten.

Ik onthoud hierbij steeds de eindnode van de vorige way en bij
roundabouts alle nodes van het ronde punt. Daarom is het dus
belangrijk dat junction=roundabout erop staat en dat deze geen role
hebben, anders loopt het fout.

Dan geef ik om beurten deze twee lijsten door aan een functie die
nagaat of het een continue sequentie van way vormt. De lijst van hoog
naar laag KP-nummer wordt echter vooraf 'reversed', omgekeerd dus.

Om gesplitste KP'en en de tentakels daartussen te kunnen verwerken was
veel denkwerk en nogal ingrijpende aanpassingen aan de logica nodig en
daar ga ik nu niet over uitwijden. Het zou te ver leiden. Het komt er
op neer, dat elk tentakel(gedeelte) apart in een gegevensstructuur
wordt opgeslagen.

Voordat ik daarmee begon, waren routes die met een vork begonnen ook
al een uitdaging.

Wat het script ook doet, is routes met network=rcn die het vindt in de
wegen die verbonden zijn met een knooppunt, toevoegen aan de
networkrelatie. Ik heb dus ondertussen de gewoonte om gewoon, nadat ik
een network en alles wat er omheen hangt, heb afgehaald van de server,
om alle routes uit de relatie te gooien, dan (voorlopig handmatig)
alle knooppunten te sorteren a.d.h.v. van hun rcn_ref en er dan mijn
script op los te laten. Dat bouwt de networkrelatie dan weer op en
voegt de routerelaties tussen de knooppunten toe.

Verder kijk ik na of de routes name= of ref= tags hebben die
overeenkomen met xx-yy (met een slimme regular expression). Al zou ik
nu, in Nederland eigenlijk gewoon alle name=-tags kunnen verwijderen,
zonder meer.

Ik zou de code moeten nakijken om te weten, of ik niets over het hoofd
heb gezien, maar dat is het in een notendop.

Oh ja, er wordt ook gekeken of er wel 2 knooppunten met verschillende
rcn_refs met elkaar worden verbonden. Als zo'n knooppunt dus op de
verkeerde plaats staat, of de route schiet er voorbij, dan kom ik dat
ook te weten.

Wat misschien niet zo veilig is, is dat het script ook de note=-tag
bepaalt, als het dat kan (2 verschillende rcn_refs gevonden) en
desgevallend aanpast en normaliseert naar 0x-0y of xx-yy.

Ik heb daar nog niet echt vodden mee gehad.

Nu betekent dat dus wel, dat al de rest ambachtelijk handwerk is. Als
er een probleem wordt gedetecteerd, zelf gaan nazoeken wat de oorzaak
is, data bij afhalen van de server, wegen splitsen bij overshoots,
steenwegen 2x splitsen om dat kleine benodigde stukje aan de relatie
toe te voegen, soms een weg die op zichzelf terugdraait repareren,
soms twee knooppunten samenvoegen, wegen hersorteren in de relatie,
enz. Je kan het zo gek niet bedenken of ik ben het al tegengekomen,
denk ik.

Je kan je dus al voorstellen dat ik bij mijn eerste 'run' in
Vlaanderen niet stond te springen om de volledige complexiteit van
gesplitste knooppunten in hun volle glorie te gaan ondersteunen, maar
nu dat ik het (eindelijk) helemaal begrepen heb, zie ik de zin en het
nut en de deugdelijkheid van de gebruikte oplossing er wel van in.

Als ik bij het uploaden conflicten heb, dan selecteer ik de betrokken
relatie (hopelijk is dat dan niet de networkrelatie, want dan heb ik
een probleem) en dan pas ik de aanpassingen van die andere toe, om
daarna weer zelf naar de relatie te gaan kijken en te zien of het
allemaal nog wel klopt in de samenhang die ik aan het doorsturen ben
naar de server.

mvg,

Jo