RWN Node 30, after edit, shown as 11, which is the RCN value

[FrankOverman]

Just committed a changeset with a number of route updates, both RWN and RCN: https://overpass-api.de/achavi/?changeset=113771489

Now the RWN30 node is shown with value 11, which is its RCN value. https://www.openstreetmap.org/?mlat=51.69189&mlon=4.98382#map=18/51.69189/4.98382 https://knooppuntnet.nl/nl/map/hiking

I am digging in my head, as I seem to remember somewhere we ran into similar issue before ... ? Ah, found it: https://github.com/vmarc/knooppuntnet/issues/187

[vmarc]

@FrankOverman thanks for this additional example!

I do see the problem now.

I suspect that the problem will not be visible anymore tomorrow morning after the overnight complete recalculation of all tiles (scheduled to run 03:00h). If this is the case, it means that the problem is in changeset triggered recalculation of the tiles.

To be further investigated.

[vmarc]

Confirmed: problem gone after recalculation of all tiles. Still to be further investigated.

[FrankOverman]

Ook wel interessant: zie dat de punten niet als groen cirkeltje getoond worden: https://www.openstreetmap.org/?mlat=51.69532&mlon=5.23162#map=17/51.69532/5.23162

Dit komt uit een survey gisteren waarin ik in Vlijmen gefietst heb: https://www.openstreetmap.org/changeset/113960593 Ik heb alvast de punten toegevoegd, de routes nog niet, komt nog natuurlijk.

Als dit een ander issue is, vorken we wel af. Ik zal even wachten met routes toevoegen hier, tot reply.

EDIT: Wat me trouwens opvalt is dat de kaart eronder nog niet is bijgetrokken, misschien ligt daar de oorzaak. Ik heb extra paden ingevoerd rond dit water, waar die 3 punten op leunen.

[vmarc]

Zelfde probleem.

Maar bijkomende complicatie: gisteren is de knooppuntnet overpass database corrupt geraakt, en is het nodig geweest om deze helemaal opnieuw aan te maken. Hierdoor heeft de verwerking van de veranderingen in OpenStreetMap een hele tijd stilgelegen, en is nadien een inhaalbeweging nodig geweest. De wijzigingenset 113960593 004/807/396 met veranderingen van 18-11-2021 21:04 werd pas deze morgen om 19-11-2021 04:26:01 verwerkt. Dit was na de volledige herbereking van de kaarttegels om 03:00u.

Na het manueel starten van een volledige herberekening van de kaarttegels zijn de nieuwe knooppunten nu wel zichtbaar op de kaart.

[FrankOverman]

Ik las het prompte antwoord: zeer gewaardeerd; alsook al deze moeite die erin gestoken wordt; Ik heb inderdaad de vertraging opgemerkt want ik zag mijn changesets op Vlijmen niet tevoorschijn komen. Ondertussen ziet het er allemaal uitstekend uit. Met Groet!

[jdhoek]

Zie ik hier hetzelfde probleem bij deze node? 58 is de rcn ref, 82 de rwn. 34 en 92 iets naar het oosten net zo.

[vmarc]

Inderdaad, dit is hetzelfde probleem. Na een totale herberekening van alle kaarttegels worden de knooppunten nu wel juist weergegeven geloof ik. De logica voor de onmiddelijke herbereking van kaarttegels die geimpacteerd zijn door node of route veranderingen, werkt momenteel niet juist. Dit mechanisme wordt veranderd in knooppuntnet release 4 (komt hopelijk over een maand of zo). Dan zou het probleem opgelost moeten zijn.

[jdhoek]

Het lijkt nu inderdaad weer goed. Bedankt!

[FrankOverman]

For example in Gilze here: https://knooppuntnet.nl/nl/map/hiking?mode=surface&position=51.54182804,4.94103923,17 https://www.openstreetmap.org/?mlat=51.54224&mlon=4.94075#map=19/51.54224/4.94075 The right RWN point shows as walking number 13 while the actual number in OSM is 51: network:type=node_network rcn_ref=13 rwn_ref=51

Seems like regression of this older bug: https://github.com/vmarc/knooppuntnet/issues/187 https://github.com/vmarc/knooppuntnet/issues/237

[vmarc]

Fixed in server version 4.2.14.

Finally figured out what the problem was. It was a caching issue that lead to mixing up cycling and hiking node information.