[Knooppuntnetwerken] 2020-11-01 Release Knooppuntnet 3.0 + Planner!

Ik gebruik hiervoor twee plugins: de track recording plugin en de Audio/Video notes.
Als ik een audio note maak terwijl er een track opgenomen wordt, dan komt er in die track een waypoint.

Als ik vervolgens thuis ben dan haal ik de audio notes en tracks van mijn telefoon en zet ze in dezelfde directory op mijn computer.
In mijn geval (Linux/KDE/verbinding via USB-kabel) staan de audio notes op de telefoon in mtp:/Moto G (5) Plus/SD card/Android/data/net.osmand.plus/files/avnotes/ en de tracks in mtp:/Moto G (5) Plus/SD card/Android/data/net.osmand.plus/files/tracks/rec/.
Ik kopieer deze naar mijn computer naar een map, bijvoorbeeld /home/tijmen/Hobby/OSM/script/AVnotesTodo/ - dus de audio notes (.3gp-bestanden) en de tracks (.gpx-bestanden) naar dezelfde directory - in mijn geval /home/tijmen/Hobby/OSM/script/AVnotesTodo/

Als je nu een GPX-track opent in JOSM (kan met sleur&pleur) dan zie je alle opgenomen audio nodes in de laag “markers for ”. Als je op zo’n marker klikt dan wordt het audiobestandje afgespeeld.

Als je naar de audiobestandjes kijkt, deze heten allemaal iets als 0E6UELlA–.1.3gp. De “naam” (het 0E6UELlA) is een codering van de locatie, shortcode. Ik heb een script geschreven dat van deze audiobestandjes een gpx-track maakt, zonder daadwerkelijke track maar met alleen deze markers erin, die je dan ook in JOSM kan zetten.

Hoe dat te doen heb ik bescrheven in deze post, ik zal binnenkort, als ik tijd heb, daar een deugdelijker blogpost van maken en proberen het geheel in één perl-bestand te frutten, zodat het ook voor windows-gebruikers werkbaar is. Ik ben daar echter geen held in, dus als iemand daar goed in is hou ik me aanbevolen!

Ik gebruik een Columbus V-990 voor verkenningen, die kan ik terwijl ik fiets inspreken en zo in JOSM laden. Je hebt wel een apart apparaat nodig en de audio-kwaliteit is niet geweldig.

Wandelend is die werkwijze van IIVQ ook prima lijkt me.

Wat betreft het script om die audio notes en de track te combineren, misschien is het wel beter om het in een “Columbus” formaat weg te schrijven, dat wordt door JOSM ondersteund en laat zowel de track als afspeelbare audio waypoints zien.

Klinkt allemaal goed voor een mapper met passie, maar ik ga dat een Willekeurige Wandelaar die wel wat wil helpen, niet vragen. En daar is het mij om begonnen: hoe kan je uit die duizenden wandelaars informatie krijgen over de routes en de andere interessantre objecten, in dit geval knooppuntpaaltjes.

Wandeling tracken met een simpele aan/uit tracker, ja, dat lukt met bijna iedereen die bereid is met een mobieltje te wandelen. In 5 jaar dat is dat omgeslagen van bijna niemand naar bijna iedereen.
Van elk paaltje een foto nemen, ja, maar dan moet-ie het met lokatieinformatie aanleveren, en dat blijkt lastig. Maar het helpt mij meer als-ie de node gelijk al in OSM zet met behulp van een simpel zet-pin kaartje. Dan hoef ik niks te koppelen, de track hoeft niks te bevatten, ik loop gewoon de track na in josm en kom vanzelf langs de nieuwe punten, ff mergen met de juiste intersectie en boem!

Ik vind dat een prima samenwerking, ieder doet wat-ie kan en niemand wordt overvraagd. Anders gezegd: je kan dit van veel meer mensen vragen dan dingen met plugins in OsmAnd, laat staan python scripts of speciale apparatuur.

MapComplete maakt dit mogelijk. Er zijn nog wat onvolwassenheden als het gaat om de “gebruikerservaring”, en het opzetten van een MapComplete-thema is, hoe zal ik het zeggen, knutselwerk met vallen en opstaan dus typisch OSM zeg maar, maar het heeft ook een listig voordeel: op elk punt ziet de gebruiker iets en kan-ie iets doen waardoor zhij een stapje dichter bij OSM komt. Dus het kan nieuwe mappers opleveren.

Dat is dus kompleet anders dan bij bv Maproulette, daarvoor moet je een mapper zijn die OSM al snapt. StreetComplete is nog zo’n ïedereen kan het"-tool, maar dat gaat dan bijvoorbeeld om mensen die graag hun eigen buurt heel gedetailleerd in kaart willen brengen. Daar zit dat fuikmechanisme -pardon ik bedoel, het stapsgewijs aanbieden van de gelegenheid om meer betrokken te raken- trouwens ook wel ingebouwd en als toepassing is het veel volwassener.

Zo, ik heb me even kwaad gemaakt, en gister en vandaag ook de oostelijke helft van het Wandelnetwerk Amstelland (onderdeel van Wandelnetwerk Noord-Holland maar ivm de beheersbaarheid apart gezet) in Openstreetmap gegooid. Dit grotendeels op basis van wandelnet.

In het zuidwestelijke puntje had Peter Elderson al wat gedaan, waarvoor dank. Jij had het in Wandelnetwerk Noord-Holland gezet, ik heb dat naar Amstelland verplaatst.

Wat mij wel opvalt is dat het netwerk van Wandelnet niet 100% overeenkomt met die van wandelnetwerknoordhollandnoord.nl (WNNH). Met name aan de noordwestoever van de Amstel tussen zeg maar Nieuwveen (bij node 61) en Uithoorn mist wat - ik heb de nodes 62,36,35, laten staan zoals Peter ze er in gezet had, maar nodes 22 en 23 staan niet op Wandelnet en mag ik ivm zonder toestemmign niet overnemen van WNNH. Peter, als je daar ooit in de buurt bent voor survey, hou ik me aanbevolen.

Helaas nog 9 facts, allen vanwege incomplete routes, maar die zijn ook daadwerkelijk incompleet. 1 is niet in het veld te zien (al zou het hersteld zijn, maar ik mag er pas na broedseizoen lopen), 2 zijn nog niet open ivm werkzaamheden Gaasperdammertunnel, 3 omdat node 69 bij Holendrecht fysiek ontbreekt, 2 omdat de route bij Ouderkerk fysiek onbegaanbaar is ivm brugwerkzaamheden, 1 vanwege werkzaamheden bij station Diemen.

Dan nog een vraag over knooppuntnet: waarom slagen de nodes aan de “verre” kant van een “connection” niet voor de integrety check? Die node moet ik toch juist niet opnemen in mijn routerelatie? Of wel, maar dan met rol connection?

Nog een vraag: ik zit toch nog een beetje met het massieve netwerk Noord-Holland. Dat bestaat volgens WNNH uit 7 regio’s, ik heb 2 (Amstelland en Gooi- & Vechtstreek) eruit gehaald, en de andere er in laten zitten. Dat is natuurlijk een beetje raar. Maar de naamgeving is nu ook wat raar. Zal ik van die eerste twee iets als “Wandelnetwerk Noord-Holland - Amstelland” maken zodat duidelijk is dat het onderdeel is van NH?

Super!
Ik heb kontakt gehad met het routebureau in NoordHolland over verschillen tussen hun planner, de wandelnet planner en de feiten op de grond; Knooppunten met nummer 0 die er helemaal niet zijn, routes die elkaar kruisen zonder knooppunt en routes die niet aansluiten of dubbel zijn en niet willen plannen, etc. Geen woord over OSM gezegd trouwens.
Eerst wilden ze me afschepen met “meld het bij meldpunt routes”, ik hield aan omdat dit de losse melding toch echt te boven gaat. Nu wisten ze te melden dat er op veel plaatsen aangevuld, aangepast en verbeterd wordt, en dat klopt. Daarna wordt alles goed geregistreerd en daarna aangeleverd aan Wandelnet. Mijn lijstje is doorgegeven aan de uitvoerende tak. Dus ergens in 2022 alles op orde moet haalbaar zijn, schat ik in.

Daarnaast heeft een NoordHollander zich gemeld, rjvdboon, ik heb hem met MapComplete op pad laten gaan en nu zit hij al zelf in JOSM te mappen, af en toe wat aanwijzingen en hopla! Die kan natuurlijk niet heel Noord-Holland doen maar alles helpt. Ik loop zelf nu meer in bossen en heuvels, in aanloop naar een tocht door Zwitserland, dus NoordHolland zit er voorlopig niet in.

Als je een connection route hebt van een node in het ene netwerk naar een node in het andere, en je hebt de route in beide netwerken met rol connection staan, dan horen de integrity checks van de nodes te kloppen, of de nodes nou in de routerelaties staan of niet. Hij telt gewoon het aantal routes dat op een knoop landt en dat moet gelijk zijn aan de expected… waarde. Moet ik s kijken? Welke route gaat het om?

PS vmarc is lekker bezig met de issues! Als dat doorgevoerd verdwijnen er een stel feitmeldingen.

Op welke manier / wanneer is dat een probleem?

Ik vind dat ze soms vreemde keuzes maken en idd snel afwimpelen naar meldpuntroutes. Routes die wel op hun kaart staan maar in het veld er niet zijn, routes die gewoon op paaltjes staan terwijl de onderliggende weg nog niet gemaakt is (“zak ze dan even af” zou ik in OV-termen zeggen), lange verbindingsroutes die langs een IC-station gaan (Duivendrecht) en daar geen node (laat staan een startpunt) hebben en gister zag ik dat ze een aantal keer een dubbele route X-Y hebben met dezelfde 2 nodes (bijv 2 routes 52-58 of 84-86). Daarnaast hebben ze de zeer obvious route over de Oranjesluizen in Amsterdam niet aangelegd, wat jammer is, want daarmee (en het ontbreken van Kennemerland) is er nu géén route van ten noorden naar ten zuiden van het Noordzeekanaal - ja een kronkelroute door Kennemerland die er ongetwijfeld in het echt niet is.

Fijn dat je contact hebt en wat constructieve zaken bij ze kan aandragen.
En ergens jammer, dat er dus (minstens) 3 verschillende dataversies bestaan: die van WNNH, van Wandelnet en van OSM/Knooppuntnet, die ongetwijfeld verschillend zijn.

https://knooppuntnet.nl/en/analysis/network/12222574/nodes en dan filteren op integrity check = no. Dit is volgens mij de “lichte” integrety check. Al deze connection nodes zijn dus nodes aan de “verre” kant zitten, waar de dichtbijzijnde kant Amstelland is.
Ik zie hier (N) R C (C) (E), waarbij
(N) = OK - Not defined in network relation
R = OK - Defined in route relation
C = OK - Connection
(C) = OK - No connection role
(E) = OK - expected route count missing
Dus volgens mij zijn alle zaken ok, want de “missende” zaken zijn optioneel
Overigens begrijp ik die laatste niet: Bij bijvoorbeeld punt 12 staat dat de expected_rwn_route_relations ontbreekt (E) maar die staat er gewoon in.

Ik vind het onbeheersbaar. Je hebt een relatie met bijna 4000 items, het hele netwerk met “download all children” binnenhalen duurt ruim 4 minuten.
Als Amstelland (700) en G&V (750) en het toekomstige Kennemerland-Haarlemmermeer (zeg 300) er bij komen zit je op 6000 items in de relatie.
Volgens mij is er een richtlijn dat relaties liever onder de 3000 items moeten blijven.
Overigens is NH niet de worst offender, Frŷslan zit net over de 5000.
Het lijkt me voor de OSM-servers ook minder prettig, voor elke wijziging wordt de hele relatie opnieuw opgeslagen.
Amstelland heb ik afgesplitst omdat dat in ontwikkeling was en G&V toen ook maar omdat dat anders helemaal los hing van de rest van NHN - de andere 4 regio’s hebben minder duidelijke grenzen.

Eigenlijk is Overijssel de worst offender :slight_smile:
Maar die is altijd al in deelnetwerken opgedeeld.
Netwerk Twente heeft ongeveer evenveel members als Fryslân
En dan komen de overige netwerken er nog bij.
Maar goed de deelnetwerken van Overijssel zijn zeer duidelijk in het veld te herkennen, dus een provinciaal netwerk is absoluut niet zinvol.

Je hoeft die hele netwerkrelatie nooit te gebruiken. Voor beheer (binnenhalen) kan je via de admin-hierarchie bijvoorbeeld een gemeente openen, en dan kun je nog kiezen of hij alleen de punten en de relaties binnenhaalt, of ook de leden van de relaties. Je kunt de details, feiten, kaart en wijzigingen ook per gemeente bekijken, dat is goed te overzien.

Zelf ga ik vaak via de planner, met control-klik op een knooppunt of route en dan details en Openen in JOSM. Of wel via de analyse en de feiten, vervolgens vanuit 1 feit naar het element, en daar weer Openen in JOSM.

Hm, s kijken… de eerste is wkp 12, verbonden met 36.
Knooppunt 12 zit in 2 netwerken, namelijk Rijn- en Veenstreek en Utrecht Groene hart. Een knooppunt precies op de grens, dat kan, maar dan moet het in beide netwerken een rol connection hebben. In feite hoort het alleen in Rijn en Veenstreek, dus zonder connection rol.
36 zit in Amstelland.

12-36 zit alleen in Amstelland, rol connection. Maar dan zou die ook in Rijn- en Veenstreek moeten zitten met rol connection. Dit is denk ik waarom de interiteitscheck niet klopt: hij telt deze verbinding niet mee omdat die niet in de netwerkrelatie zit.

11-12 zit alleen in Rijn en Veenstreek, goed.
12-13 zit in Rijn en Veenstreek én Utrecht Groene Hart, beide met rol connection. Goed.

Dus: wkp 12 uit Utrecht Groene Hart weghalen, en 12-36 toevoegen in Rijn en Veenstreek met rol connection, dan zou het goed moeten zijn!

Ik had dat per gemeente nog niet gedaan.
Vmarc: Overigens krijg ik daar foutmeldingen die ik in de “Per Netwerk”-view niet krijg. Bijvoobeeld Amsterdam, relatie 12-13: RouteNotForward There is no path in the forward direction (from start node to end node).
Terwijl die ook onder RouteIncomplete The route is marked as having an incomplete definition. A route definition is explicitely marked incomplete by adding a tag “fixme” with value “incomplete” in the route relation. staat. Ofwel, we weten dat de route incompleet is, en toch geven we aan dat de route incompleet is.

De reden waarom ik een netwerk binnenhaal in JOSM (niet in knooppuntnet) is dat ik het wel handig vind om het netwerk in JOSM te vergelijken met het netwerk wat je ziet op wandelnet.

Beter in 12-13? (experimental.knooppuntnet.nl toont momenteel veranderingen aan de analyse logica die nog in de test fase zijn)

Vraagje aan mijn geachte medeknooppuntmappers: Hoe belangrijke is de volgorde van de wegen in de knooppuntrouterelatie? In principe wil je hem natuurlijk op volgorde hebben, dat beheert makkelijk, maar als het een keertje niet zo is, wie heeft er dan last van?

  • Waymarkedtrails rendert gewoon, en de gpx is wel op volgorde (tenzij er meerdere fouten en onderbrekingen inzitten, dan geeft de sorteerroutine het op). Met samengestelde/opgedeelde lange routes komt het best vaak voor dat de sorteerroutine het opgeeft, maar bij de relatief simpele knooppuntroutes zelden.

  • Knooppuntnet kijkt zelf hoe je over de gegeven wegen van start naar eind komt, voordat de route verder geanalyseerd wordt en planbaar op de Planner verschijnt

  • Routing engines werken met het “gewicht” van de route, en dat hangt niet af van de volgorde maar van de vraag of de weg uberhaupt lid is van een routerelatie.

Mis ik hier iets? Andere routing mechanismes, andere data users die de precieze volgorde in de relatie nodig hebben?
Ik denk met name aan fietskaarten en fietsrouters, die het verst zijn met het gebruiken van de OSM relaties voor eindgebruikers.

En nog een andere vraag: bij Holtum in Limburg zijn nog state=connection routes voor fietsen.
https://experimental.knooppuntnet.nl/en/analysis/route/6844235/map
https://experimental.knooppuntnet.nl/en/analysis/route/6844559/map
https://experimental.knooppuntnet.nl/en/analysis/route/6844236/map
https://experimental.knooppuntnet.nl/en/analysis/route/8466015/map
https://experimental.knooppuntnet.nl/en/analysis/route/1970111/map

Weet iemand hier meer van? Bijvoorbeeld, hoe dit precies op de weg is aangegeven?
Heeft Holtum inderdaad een knooppunt genaamd “Holtum”? Ik zie op het betreffende punt (opname 2016) wel een bordje dat naar 4 verschillende knooppunten verwijst, maar dat zelf geen knooppuntaanduiding heeft.

Op de punten waar de aantakroutes halverwege een gewone knooppuntroute aanknopen, kan ik geen duidelijke beelden krijgen. Met name hoe er op die punten naar het centrale punt verwezen wordt. Eentje kan ik zien op mapillary https://www.mapillary.com/app/?lat=51.05013299999996&lng=5.838341000000014&z=18.868728336706543&focus=photo&pKey=JgK-Dpp_YeMptepu7D9IIw
Dat lijken inderdaad knooppuntbordje, en als ik ver inzoom dan lijkt het dat ze niet naar het centrale punt, maar de punten daarvoorbij wijzen (16 naar links is de gewone knooppuntroute, naar rechts 23 en 13.
Je kijkt daar vanuit de richting 11->16. Maar bij knooppunt 11 wordt niet verwezen naar 23, dus er is daar geen verbinding 11-23 via Holtum aangegeven. Je ontdekt pas later dat er een tussenafslag naar 23 is.

Onderweg op de aantakroutes zie ik wel knooppuntbordjes richting knooppunten in de omgeving staan., waar telkens 2 nummers op staan, maar in de omgekeerde richting zie ik geen bordjes.

Konklusie
Zoals de tagging nu is, zijn de aantakroutes niet analyseerbaar en planbaar in Knooppuntnet. Het punt in Holtum heeft geen naam of nummer, en er wordt op de weg niet naar verwezen, dus eigenlijk is deze tagging fout. Al zit ik daar niet heel erg mee!
De bewegwijzering is wel zodanig dat ik denk: dit is onderdeel van het fietsnetwerk en zou ook in de planner bruikbaar moeten zijn.
Maar hoe?

Oplossingen?
Sinds enige tijd hebben we “splitspunten”, dat zijn punten zonder nummer waar twee routes onderweg splitsen. Deze punten mogen dus als extra punt binnen een knooppuntrouterelatie voorkomen. De aftakpunten voldoen hieraan. In Knooppuntnet Planner zie je ze wel maar kun je ze niet aanklikken als plan-punt. De aantakroutes hebben dan in ieder geval een network node om op te landen.

Het centrale punt is eigenlijk ook geen knooppunt, maar het is 1 punt in 1 dorp waar een serie routes samenkomen, ik denk dat we dat wel als knooppunt mogen laten staan. Planner output wordt dan iets als [ …06 11 * Holtum * 23 …] wat op zich klopt, maar als nadeel heeft dat de fietser bij 11 niet ziet dat zhij 16 moet volgen om naar het splitspunt voor Holtum te komen. Dat klopt dan wel weer met de bewegwijzering, want die zegt dat bij 11 ook niet!

*Zelf noteer ik dit soort gevallen op papier als … > 11 > (16) maar bij * > Holtum > 23 > …
Het getal tussen haakjes geeft aan: richting dat, maar niet helemaal ernaartoe. *

Samenvatting voorstel
Splitspunten (rcn_ref=*) maken van de aantaknodes.

Is dit iets?

Principieel gezien is een relatie een geordende lijst met dus een volgorde. Een route heeft ook een volgorde, dus de correcte manier is om deze volgorde ook in de relatie aan te houden.

Meer praktisch merk ik dat de volgordefouten de eerste stap zijn in het ontstaan van echte onderbrekingen. Wanneer onderbrekingen daadwerkelijk zijn onstaan, dan is de route in het relatievenster van JOSM zo’n rommel, wanneer de volgorde ook niet klopt, dat het veel tijd kost om de fout daadwerkelijk op te lossen.

Klopt helemaal, voor lineaire routerelaties. Dat is een beheerprobleem wat je niet even kan verhelpen. De vraag is hier meer, wat moet een checker doen. Onderbrekingen signaleren, ja. Dus als je een volgordefout hebt in kombinatie met onderbrekingen, dan wil je een rooie vlag zien. Maar als verder alles klopt, alleen de volgorde is verstoord, zijn de gevolgen voor data users / renderers / routers dan zodanig dat de noodklok geluid moet worden?

Overigens, sinds Id zijn relatiebijwerker onderhanden heeft genomen, komen dit soort problemen in mijn ervaring veel en veel minder voor. Ik baseer dat dan op de langeafstandsroutes, waarin dit op zich al veel vaker voorkwam. Volgens mij had het iets te maken met de grootte van het gebied wat je binnenhaalt voor het editen, als een relatie uitgestrekter is heb je meer kans dat hij onvolledig of niet beschikbaar is en wat er niet of onvolledig is kan de editor ook niet goed checken en bijwerken. Sinds de wijziging halen ze volgens mij meer relaties binnen, ook als er maar een klein deel binnen de bbox valt.

Ik vind het prima wat Knooppuntnet op dit moment doet, zodat we deze fouten op kunnen lossen. Alle fouten zijn gecategoriseerd en volgordefouten staan onderaan, zodat je ze goed kan onderscheiden van belangrijkere fouten zoals onderbroken routes. Ik zou het zeker niet ‘de noodklok luiden’ noemen, maar meer ‘het opmerken van een fout’.

Eerder maakte Knooppuntnet volgens mij onderscheid tussen fouten en waarschuwingen. Daarbij stonden volgordefouten bij de waarschuwingen. Dit onderscheid zou terug kunnen komen, al weet ik niet hoe nuttig het is. De indeling lijkt me ook wat subjectief en daardoor lastig te maken.

Volgordefouten altijd melden.
Ze zijn ook vaak een indicatie dat er meer mis is en ook de begeleidende routes, zoals, LF, fietsroutes, wandelroutes, etc kunnen verstoord zijn, ook kunnen ze signaleren dat er bussen verkeerd liggen.
Veel volgordefouten zijn het gevolg van doorknippen in ID en dan gaat er van alles mis met allerlei routes
Ook weet ID nog steeds niet hoe je forward/backward sorteert en dat wil ik graag verhelpen.

Mijn ervaring is, dat je routes heel moet houden, in de relatie-editor moet de routelijn continu zijn.
Als je volgordefouten laat zitten weet je op het laatst niet meer wat een volgordefout en wat een gat is.
Zoals knooppuntnet het nu meldt is uitstekend.

Wat de route bij Holtum betreft, ik heb daar vanmorgen naar gekeken en ik wil er gewone routes van maken, die elkaar dan in Holtum kruisen. In Limburg liggen nog de nodige onbenoemde splitspunten.

Die andere 2 kunnen ook gewone routes worden met een ster splitspunt

:thumbsup:

Nog een punt (ja, ik ben weer lekker bezig…):

Aansluiten van ln-knooppuntnetwerk op rn knooppuntnetwerk is mogelijk!

Waarschijnlijk weet iedereen dit al, maar ik ik ben er net achtergekomen.
Je kan voor wandelen rwn en lwn netwerken maken. Wij hebben alles rwn gehouden, maar in Frankrijke en Duitsland kiezen ze voor lwn voor de knooppuntnetwerken. Ze vinden de routes en knoppen allemaal lokaal. Dat is ook zo, alleen kan het zijn dat de netwerken regionaal en zelfs landelijk worden maar daar zijn ze nog niet aan toe. Sinds de invoering van network:type=node_network kunnen er in principe ook netwerken van verschillend scope zijn.

Ik was benieuwd/bezorgd of zulke lwn netwerken wel kunnen aansluiten op onze rwn netwerken. Want ik wil wel internationaal kunnen plannen, maar ik wil niet retaggen. Ik denk zomaar dat ik daar wel steun voor heb, voor niet retaggen.

Wat (zonder ingrijpende aanpassingen) niet kan is: een connection route tussen een lwn_ref node en een rwn_ref node. De connection route zou dan zowel rwn als lwn moeten zijn, en je hebt maar 1 network-tag.

Wat zonder meer wél kan is: een connection node maken met zowel een lwn_ref als een rwn_ref. Die heeft dan naar het ene netwerk 1 of meer lwn routes, naar het andere netwerk 1 of meer rwn-routes. De connection node zit in beide netwerkrelaties met de rol connection.

De Planner blijkt dat netjes af te beelden en je kan er knooppunttripjes overheen plannen. In principe gaat dat zelfs goed als je een lwn-netwerken en een rwn-ref netwerk in het zelfde gebied hebt, dus overlappend. Je moet wel per netwerk konsekwent zijn.

Dit vind ik heel bemoedigend voor de internationale ontwikkelingen!