Overleg Wikipedia:Wikiproject/WikidataOpWikipedia/Inwoneraantal

Tabel woonplaatsen Nederlandse gemeente

Doel

Iedere gemeentepagina voorzien van een overzicht (lees: tabel) met daarin alle woonplaatsen en een (recent) inwoneraantal en een markering voor de hoofdplaats (woonplaats waar het gemeentehuis staat).

Middel

Wikipedia

1. Een sjabloon/module die voor een bepaalde gemeente alle woonplaatsen verzamelt, deze in een tabel zet met bijbehorende inwoneraantallen en de hoofdplaats(en) markeert
   • Deze module zou zonder parameters moeten werken
   • Sjabloon:inwonertal wordt gebruikt voor inwoneraantallen
2. Deze module op iedere gemeentepagina zetten

Wikidata

1. Iedere plaats indelen bij een gemeente met Wikidata:Property:P131 (bij plaats) en/of Wikidata:Property:P1383 (bij gemeente)
   • Hiervoor zou organisaties.overheid.nl van pas kunnen komen ("Plaatsen binnen deze gemeente")
2. Iedere plaats voorzien van een recent inwoneraantal met Wikidata:Property:P1082
   • CBS?
3. Iedere gemeente voorzien van (een) hoofdplaats(en) (locatie gemeentehuis/bestuurscentrum) met Wikidata:Property:P1376 (bij plaats) en/of Wikidata:Property:P36 (bij gemeente)
   • Hiervoor zou organisaties.overheid.nl van pas kunnen komen ("Bezoekadres") of de website van de gemeente zelf

Stappenplan

1. Welke property's gebruiken op Wikidata?
2. Sjabloon/module schrijven (WP.1)
3. Voor een testgemeente Wikidata (handmatig) invullen (WD.1, WD.2, WD.3)
4. Evaluatie
5. Proef

Ander overleg

• Help:Helpdesk (okt 2021)
• Wikipedia:Redactielokaal (nov 2021)
• Help:Helpdesk (apr 2022)
• Overleg Wikipedia:Wikiproject/WikidataOpWikipedia (jun 2022)
• Wikipedia:Wikidata-café (jun 2022)
• Overleg gebruiker:Ennomien (jun 2022)
• Wikipedia:Wikidata-café (nov 2022)

Stap 1 (WD)

Inhoud 

@Dajasj, hier een eerste opzet (andere gebruikers zijn ook zeker welkom deel te nemen). Het lijkt erg op wat ik laatst stuurde op Discord, alleen wat uitgebreider. Ik denk dat het handig is om bij het begin te beginnen en te kijken welke property's gebruikt gaan worden op Wikidata. Zo zijn sommige misschien wel logisch, maar toch is het handig om dat even duidelijk te hebben.

1. Property voor inwoneraantal (was er ook niet zoiets als "belangrijkste inwoneraantal"?)
2. Property voor "ligt in gemeente x" o.i.d.
3. Property voor hoofdplaats (op gemeentepagina als "hoofdplaats" of op plaatspagina als "hoofdplaats van"?)

Ik heb geprobeerd het kort en bondig te houden, dus als dingen niet helemaal duidelijk zijn snap ik dat helemaal. Laat het gerust weten. Mvg, Ennomien (overleg) 6 jun 2022 12:23 (CEST)

Wat betreft vraag 1, op Wikidata kan je voorkeur geven aan specifieke waarden. Anders zou je de meeste recente kunnen kiezen of specificeren dat het van CBS moet zijn.

Wat betreft vraag 2, dat is Wikidata:Property:P131.

Wat betreft vraag 3, dat is Wikidata:Property:P1376. Dajasj (overleg) 6 jun 2022 17:10 (CEST)

@Démarche Modi, is dit project ook wat voor jou trouwens? Dajasj (overleg) 6 jun 2022 17:11 (CEST)

Hier al een query voor vraag 1 en 2. Nog wel wat werk te verrichten. Dajasj (overleg) 6 jun 2022 17:28 (CEST)

En query voor vraag 3. Zie hier. Dajasj (overleg) 6 jun 2022 19:47 (CEST)

@vraag 1: Het inwonertal ophalen uit Wikidata kan met het sjabloon:inwonertal.

@vraag 2: Wikidata kan ook een lijst leveren van woonplaatsen in een gemeente, mits iemand ze daar allemaal toegevoegd heeft: zie Help:Helpdesk/Archief/apr 2022#Gedachten, Vragen en Wikidata. Wikiwerner (overleg) 6 jun 2022 20:00 (CEST)

@Dajasj: Top, heb die property's erin gezet. Bij vraag 1 moeten we dus even kijken wat het handigst is: de meest recente, een waarde van het CBS, ...? Wat vind jij?

@Wikiwerner: Ik was denk ik ook wel van plan dat sjabloon te kijken. Ik kan zelf ook de broncode helemaal uitvogelen maar jij weet dit vast: geeft het sjabloon voorkeur aan bepaalde waardes (recent, CBS bijv.)? Mvg, Ennomien (overleg) 6 jun 2022 20:38 (CEST)

Dit staat ook in de sjabloonuitleg: als eerste het inwonertal dat 'preferred' is. Normaal gesproken markeert men het recentste inwonertal in Wikidata als 'preferredIs geen enkele waarde 'preferred', dan verschijnt de eerst gevonden waarde.'. Wikiwerner (overleg) 6 jun 2022 20:50 (CEST)

Dank. Die voorkeursvolgorde lijkt me ook goed dus dat is prima. Voor de volledigheid: onder welke property('s) slaan we de inwonertallen op? Ennomien (overleg) 7 jun 2022 11:47 (CEST)

Wikidata:Property:P1082 :) Dajasj (overleg) 7 jun 2022 11:55 (CEST)

Top! Ennomien (overleg) 7 jun 2022 18:14 (CEST)

Stap 2 (WP)

Inhoud 

Nu stap 1 gereed is, kunnen we door met stap 2 en 3. :D Ik hoop vanavond bezig te gaan met de sjabloon/module. Wil jij stap 3 uitvoeren? Mvg, Ennomien (overleg) 7 jun 2022 18:14 (CEST)

Ja, al ben ik nu gewoon bezig met alles, niet voor één gemeente. Is wel een taakje wat niet 123 gedaan is. Dajasj (overleg) 7 jun 2022 18:52 (CEST)

Is ook goed! Al zou het fijn zijn dat 1 gemeente helemaal compleet is als we willen evalueren, maar dat zal vast goedkomen. Ennomien (overleg) 7 jun 2022 19:02 (CEST)

Ik durf toch voorzichtig te zeggen dat het me al bijna gelukt is de module te maken. Had het niet verwacht dat ik zover zou komen met ongeveer 2 uur werk zonder Lua-kennis. Ik hoop morgen wat meer te laten zien. :) Welterusten voor nu, groet, Ennomien (overleg) 8 jun 2022 23:34 (CEST)

De module kan nu met als input het Wikidata-object (die Q-waarde, die "automatisch" te verkrijgen is op een pagina) het volgende:

• alle kernen in een tabel zetten op aflopende volgorde van inwoneraantal
• de hoofdplaats(en) dikgedrukt maken
• niet-aanwezige inwoneraantallen vervangen door bijv. "?" en onderin neerzetten

Drie vragen voordat ik hem wil publiceren:

1. Wat is een goede naam? Module:Gemeente? (Met in het achterhoofd dat je modules meer kunt laten doen, je kunt later functies toevoegen dus "Module:Tabel inwonertal gemeente" is wat specifiek)
2. Is een optelsom van alle inwoneraantallen onderin gewenst? (Of zogenaamd optellen maar gewoon het inwoneraantal van de gemeente uit Wikidata pakken)
3. Hoe moet de bronvermelding eruitzien? Een referentie met de gebruikte CBS-pagina('s)?

Mvg, Ennomien (overleg) 10 jun 2022 09:48 (CEST)

Ad 2) Het lijkt mij dat altijd een controle van de optelsom zou moeten plaatsvinden en dat het optioneel gebruik in het sjabloon een keuze voor de sjabloongebruiker is. Indien de optelsom niet hetzelfde is als het inwonertal van de gemeente dan een error tonen (dat wikidata of cbs data gecorrigeerd zou moeten worden) en indien de optelsom klopt de waarde tonen (ongeacht welke, want die is hetzelfde), indien de sjabloon-gebruiker dat wenst.

Ad 3) Zie {Inwonertal} voor een voorbeeld. Démarche Modi (overleg) 10 jun 2022 11:07 (CEST)

2) Dat is een goed idee. Echter, dat is alleen nuttig als de data daar ook echt geschikt voor is. Als het bijv. met de goede waardes ook niet klopt is het niet echt nuttig, dan toont hij altijd een error. Ik weet niet hoe consistent de gebruikte data met elkaar is namelijk.

Wat betreft 2, ik weet helemaal niet of alle woonplaatsen optellen tot het aantal inwoners van een gemeente. Of je bijvoorbeeld binnen gemeente maar buiten de woonplaatsen kan wonen. Dajasj (overleg) 10 jun 2022 16:34 (CEST)

Ja precies. Is Purmerend een gemeente waar ik dat kan testen? Is alles daar compleet? Als het daar op hetzelfde uitkomt geldt dat mogelijk ook voor andere gemeenten, als het daar niet gelijk is dan werkt het blijkbaar niet. Ennomien (overleg) 10 jun 2022 16:37 (CEST)

Ik betrap me nu op een denkfout bij mezelf. Eerder heb ik oppervlaktedata vergeleken en ik meen mij te herinneren dat de optelsommen toen klopten. Nu deed ik even een snelle optelsom van CBS data op deze set van 2017 en constateer dat de som der wijken (79915) niet hetzelfde is als het gemeentelijke totaal (79928). Démarche Modi (overleg) 10 jun 2022 17:07 (CEST)

Ook wanneer ik naar [het bronbestand] kijk die Dajasj gebruikte voor de upload, dan kloppen de optelsommen niet.

Het inwonertal van de wijken wordt afgerond, het eindigt altijd op 0 of 5. Meestal klopt de optelsom daarom ook niet. Cattivi (overleg) 10 jun 2022 20:51 (CEST)

Is het dan een idee om een foutmarge toe te voegen? Of gewoon niet checken of het (ongeveer) overeenkomt? Ennomien (overleg) 10 jun 2022 21:00 (CEST)

@Ennomien, ja Purmerend en Groningen zijn uit mn hoofd compleet. Zo niet, dan loop ik het nog na. Dajasj (overleg) 10 jun 2022 23:02 (CEST)

3) Voor ieder inwoneraantal dus een bron in de tabelcel? Ennomien (overleg) 10 jun 2022 16:31 (CEST)

Indien een waarde steeds dezelfde bron heeft dan denk ik dat een vermelding in de kopregel volstaat. Echter, ik neem aan dat de waarde steeds door Wikidata geleverd wordt en (in theorie) zou die dus kunnen afwijken of ontbreken.Démarche Modi (overleg) 10 jun 2022 18:09 (CEST)

Ik zal betreft vraag 1 gaan voor Module:Gemeente in Nederland. Wat betreft vraag 2 en 3 ga ik gewoon bezig en kijken wat handig is. Dat kunnen we dan altijd weer veranderen natuurlijk. Ennomien (overleg) 10 jun 2022 19:46 (CEST)

Resultaat

De module is gepubliceerd, inclusief het bijbehorende sjabloon: Module:Gemeente in Nederland en Sjabloon:Tabel woonplaatsen Nederlandse gemeente. Ping naar @RonnieV en twee vragen (voor hem): kun je de code bekijken/controleren en 2) is het toegestaan stukken code van het internet te kopiëren? De drie aparte, niet heel speciale, functies zijn namelijk gekopieerd van het internet. Voor de rest: zie de module hier in werking of probeer het vooral uit op een gemeentepagina. Mvg, Ennomien (overleg) 10 jun 2022 22:19 (CEST) Edit: het werkt voor nu alleen als je zoals op mijn kladblok een ID opgeeft. Ik kijk morgen verder. Groet, Ennomien (overleg) 10 jun 2022 22:42 (CEST)

Hoi Ennomien,

Ik heb vast eens zitten kijken.

'getEntityIdForTitle' en ook 'getEntityIdForCurrentPage' kan in ieder geval alleen een resultaat geven, als de betreffende pagina ook gekoppeld is aan Wikidata. Dat is jouw kladblok waarschijnlijk niet ;) Je kan ervoor kiezen om niet de standaard foutmelding te laten verschijnen, maar de tabel weg te drukken als page_id een lege waarde blijkt te zijn. Dat kan met deze wijziging. Voor --De hoofdsteden van, kernen in en totale bevolking van de gemeente worden opgehaald uit Wikidata.

Ik heb een paar kleine dingen veranderd (aangevuld) in je code, om het resultaat te verbeteren: aanvullingen.

In je aanroepend sjabloon zou ik niet van 'gemeente_id' spreken. Ik was op zoek naar de 'CBS-code', me ondertussen afvragend of ik 'gwb_code_10' of 'gwb_code_8' zou moeten hebben, of nog iets anders. Het gaat om het Wikidata-id van de betreffende gemeente, dus 'Wikidata-id', 'WD-ID', 'WdIdGemeente',... Je kan wat je doorgeeft aan het sjabloon wel laten staan en daar onder die naam blijven gebruiken.

Zoals je vast ziet op jouw test, krijg je met 'getBestStatements' en met 'normal+' in de invoke (zie inwonertal), de waarde die als 'preferred' is aangemerkt. Dat gaat goed als altijd overal de meest recente waarde preferred zou zijn. Bij Ransdorp is er geen preferred value. Dan krijg je de eerste waarde terug die gevonden wordt, in dit geval die van 1830. Daar valt wel een mouw aan te passen, om toch de meest recente waarde te krijgen (vergt wat programmeerwerk, maar in Module:Zandbak/RonnieV/NMBS ben ik ook niet uitgegaan van de preferred value.

Dit brengt me ertoe om, met de opmerking hieronder van Dajasj over de maandelijkse cijfers voor gemeenten en de jaarlijkse cijfers voor kernen etc., voor te stellen om het iets anders op te pakken. Probeer van de gemeente niet het meest recente inwonertal te pakken, maar dat van de 1e januari van het (meest recente) jaartal waarvan je een kern-inwonertal vindt. Als de waarden per 1 januari optellen tot die van de gemeente per 1 januari, heb je geluk, dat ze gelijk zijn aan het gemeentetal per 1 april is ehhh, onverwacht. Voor dit moment heb ik een peildatum aan de uitkomst van de module toegevoegd, per meting.

Wat betreft het verschil, misschien kan je ook een extra regel toevoegen met 'buitengebied' of 'overig', waarin je het verschil aangeeft. Alleen opnemen als er daadwerkelijk een verschil is. Wellicht beter dan op iedere pagina een foutmelding genereren.

Je sorteert de uitkomst nu op het (aflopende) inwonertal. In het verleden waren de meeste vergelijkbare tabellen gesorteerd op de plaatsnaam. Heb je een goede reden voor deze wijziging?

Op Gebruiker:RonnieV/TestGemeenteTabel mis ik bijvoorbeeld Clinge. Clinge hangt wel (P131) onder Hulst, maar is niet opgenomen in de P1383 van Hulst. Idealiter zou je beide uitlezen en samenvoegen (ontdubbelen!), om zo een completer beeld te krijgen. Maar goed, we kunnen ook proberen om Wikidata completer te krijgen. Het rijtje onder Hulst (gemeente)#Kernen is in ieder geval niet gelijk aan wat ik nu te zien krijg op mijn testpagina. (O ja, het kan handig zijn om je Kladblokpagina's een logische naam te geven, er zit geen limiet op het aantal pagina's dat je aanmaakt en een benoemde pagina zal wellicht langer een nuttige link blijven (en anders herkenbaar zijn) dan een link naar je algemene Kladblok, waar je volgende maand iets heel anders hebt staan).

Wat betreft de code die je van elders haalt, het zou netjes zijn als je aangeeft waar je die vandaan hebt gehaald. Alles wat op internet staat, valt ook onder het auteursrecht, tenzij het is vrijgegeven. Maar goed, iets dat is gepubliceerd zoals op [1], is natuurlijk wel bedoeld om zelf te gebruiken. En dergelijke kleine stukjes gebruiken, is natuurlijk prima toegestaan. Idealiter geef je natuurlijk wel de credits aan de schrijver.

Na het weekend ga ik eens kijken wat je er verder van gemaakt hebt. Met vriendelijke groet, RonnieV (overleg) 11 jun 2022 01:41 (CEST)

Dankjewel! Ik zal per puntje even reageren.

1. Vandaar de optie voor het meegeven van de (ik had al iets verder gelezen) slecht genoemde parameter "gemeente_id". Ik vind een leeg resultaat wat verwarrend overkomen, ik maak daar zo even een foutmelding van (edit: gedaan).
2. Goede aanvullingen!
3. Dat zijn inderdaad betere parameternamen, ik zal een of meerdere daarvan gaan gebruiken en het onduidelijke gemeente_id weghalen (edit: gedaan). Ik moest gewoon even gauw een naam verzinnen. :)
4. Voorkeurswaarden: oh ja, @Dajasj zou als ik het goed zeg alle meest recente waarden als voorkeurswaarde markeren, of denken jullie dat het beter is om gewoon de meest recente waarde zelf op te halen? (na lezen punt 5: niet de meest recente waarde, maar die van 1 januari jongstleden).
5. Goed idee van die datums. Daar ga ik mee bezig. (edit: lijkt niet te hoeven, wordt voor gezorgd op Wikidata)
6. Ja, als de waardes zo betrouwbaar zijn kunnen we dat doen. Dat bouw ik even erin (edit: gedaan).
7. De gedachte daarachter was de belangrijkste kernen bovenaan. Als meer mensen liever sortering zien o.b.v. plaatsnaam wil ik dat uiteraard wel veranderen. @Démarche Modi, @Dajasj?
8. Oh ja, het is de bedoeling dat dat aan de Wikidata-kant opgelost wordt! Zo zijn enkele gemeenten, Purmerend en Groningen, daar al compleet gemaakt.
9. Van het kladblok: dan krijg ik zo veel pagina's, haha. Ik houd het in mijn achterhoofd maar link zelf vaak naar oldid's. In mijn bericht hierboven niet, het was laat denk ik. :)
10. Auteursrechten: beide functies in zijn geheel (en verder ook geen enkele stuk originele code) komen volgens mij van fora als Stack Overflow. Wel bedoeld om zelf te gebruiken dus, maar ik zal ze de credits geven (edit: gedaan bij eentje, de andere 2 waren niet echt originele functies). Bedankt! Mvg, Ennomien (overleg) 11 jun 2022 14:18 (CEST)

ad 7) wellicht interessant om de sjabloongebruiker de keuze te geven uit 1. sortering op plaatsnaam, 2. sortering op inwonertal en 3. de hoofdkern bovenaan te plaatsen (in combinatie met 1 en 2)

ad 8) Volledig mee eens! Toch even mijn reactie die ik niet voor me wil houden... Om omwille van de datakwaliteit functionaliteit te programmeren om de wikidata heen zou persoonlijk niet mijn voorkeur hebben. Streef een logisch en zo eenvoudig als mogelijk sjabloon/module na en pak vervolgens de wikidata aan indien er iets niet goed genoeg is. Persoonlijk zou ik juist graag de foutmelding begrijpen zodat de data op wikidata verbeterd kan worden (@RonnieV, waar ging het precies mis bij Hulst?, kan ik ontbrekende koppelingen uitvragen via de pywikibot en vervolgens corrigeren in wikidata zodat die foutmelding in de toekomst niet optreedt? En waarom een ongelukkig voorbeeld (Ransdorp) van te verbeteren wikidata gebruiken om te pleiten voor omzeilende code? Ik ben wat dat betreft blij dat je schreef: Maar goed, we kunnen ook proberen om Wikidata completer te krijgen. - Wat mij betreft dient dat het uitgangspunt te zijn (goede data zorgt voor goed en simpel gebruik)

Tot slot, op basis van mijn eerdere inspanning om prioriteit van de populatie per gemeente goed te zetten heb ik het script dat ik daarvoor gebruikte doorgetrokken naar de kernen. Ik doe dat top down (Gemeente -> Kern) en maak daar een overzicht van. Dit is relatief veel data en 'work in progress'. Het idee is om daarin op basis van de CBS-bron een controle te doen op de kernen, populatie en datum. Mede vanwege mijn geloof in Wikidata en mijn hoop dat mijn eigen inspanningen nuttig zijn hoop ik dat kwalitatieve data leidend is voor succesvol sjabloongebruik. Dan gaan quasi automatisch ook de datumnotatie en de juiste selectie van de meest recente populatiewaarde goed op basis van rank = preferred. Démarche Modi (overleg) 11 jun 2022 15:12 (CEST)

7. Dat brengt mij op een goed idee! Standaard hoofdkernen bovenaan en de rest op alfabet eronder, gebruikers kunnen met de sortering van de tabel dan op plaatsnaam en inwoneraantal sorteren. Ik denk niet dat er een optie hoeft te zijn voor de sjabloongebruiker (degene die hem toevoegt) wat de standaardsortering is, alle gemeentepagina's mogen hetzelfde lijkt mij.

8. Top! Dus jij zegt dat onvolledigheden in Wikidata niet moeten leiden tot ingewikkeldere modules? Dat is overigens een lange tabel. :D Ennomien (overleg) 11 jun 2022 15:24 (CEST)

Ja, kiss, indien het corrigeren van wikidata gegevens iets - bij de verwerking van wikidata itmes - oplost, dient dat nagestreefd te worden. Indien het euvel niet verholpen kan worden op wikidata, pas dan is een oplossing buiten wikidata, bijvoorbeeld in een module op wikipedia, de overweging waard. _{Die tabel gaat vermoedelijk langer worden, het cbs heeft 1 land aangeleverd, met 352 gemeenten, 3248 wijken en 14080 buurten (1-1-2021)... maar die gebruiken we vermoedelijk niet allemaal. Wel jeukt dit om een bot te maken... maar dat is verder off-topic ;)} Démarche Modi (overleg) 11 jun 2022 15:42 (CEST)

Ennomien (overleg) 11 jun 2022 15:45 (CEST)

Misschien mis ik hier iets hoor, maar wat zijn "hoofdkernen"? Om diverse praktische redenen zou ik voor deze tabel zeker buurten buiten scope laten. Wijken zijn in aantal nog te doen, maar komen vaak niet overeen met woonplaatsen waarover wij artikelen hebben. Dajasj (overleg) 11 jun 2022 16:05 (CEST)

O met hoofdkern bedoelen jullie de hoofdplaats. Dat is ofc prima! Dajasj (overleg) 11 jun 2022 16:09 (CEST)

Terechte opmerking @Dajasj, ik moet nog even kijken hoe ik goed ga koppelen, mogelijk op naam maar ik wil ook nog even naar BAG kijken. Vraagje: hoe weten wij welke woonplaatsen binnen een gemeente horen en hoe heb jij de inwonertallen van de woonplaatsen gevonden? Démarche Modi (overleg) 11 jun 2022 16:18 (CEST)

De link krijg je later van me, maar CBS heeft overzicht van de BAG-kernen icm gemeenten en provincie. De inwoneraantallen haal ik uit de dataset van wijken en buurten. In veel gevallen komt een woonplaats overeen met een wijk of een aantal buurten. Soms kijk ik af hoe het is ingevuld op Wikipedia, dan moet je het even navragen. Het komt er eigenlijk op neer dat je dit handmatig moet doen, niet automatisch, want het is veel maatwerk. Dajasj (overleg) 11 jun 2022 16:24 (CEST)

@RonnieV ik heb het meeste erin verwerkt, zie Speciaal:Diff/62246188. Zie ook de edits in mijn lange bericht hierboven, dat je waarschijnlijk nog niet had gelezen. In het vervolg hoop ik de module niet nog een keer zo grondig overhoop te gooien, dan blijft het wat makkelijker te volgen wat er verandert. Ik zie nu dat je mijn "Edit: het werkt voor nu alleen als je zoals op mijn kladblok een ID opgeeft. Ik kijk morgen verder." waarschijnlijk verkeerd begreep. Natuurlijk moet op mijn kladblok een ID gegeven worden, maar op een pagina mét ID werkt het ook niet. Vermoedelijk pakt hij het ID van het sjabloon dan. Edit 22:38: er zijn nu nog drie dingen open:

1. Kun je kijken naar de functie compare_rows? Zie de comment aldaar. Deze moet zorgen voor een sortering op plaatsnaam, met de hoofdkernen bovenaan (en ook op plaatsnaam gesorteerd). (18:01: opgelost)
2. Het zou ideaal zijn als het sjabloon geen input van Wikidata-ID nodig heeft. Is er een manier om dat wel werkend te krijgen? Of zit er niks anders op dan een parameter meegeven? (18:35: stomme LUA ziet een lege string niet als en:falsy, opgelost nu)
3. We moeten nog even kijken hoe we het gaan aanpakken met voorkeurswaarde, peildatum etc. Démarches en mijn voorkeur is dus het toekennen van voorkeurslabels in Wikidata zodat de module die direct kan ophalen en gebruiken.
4. Zondag, 20:16: de module geeft nu ook een foutmelding als de Wikidata-pagina van de pagina / van het opgegeven Wikidata-ID geen Nederlandse gemeente is (Q2039348) (edit 20:45:) en nu ook voor niet geldige Wikidata-ID's (niet beginnend met de letter Q).

Ennomien (overleg) 11 jun 2022 18:39 (CEST)

• Démarche Modi, naar aanleiding van je opmerking van 11 jun 2022 15:12 (CEST), bij Hulst mis ik een heleboel kernen. De tabel geeft er vijftien, de pagina noemt er 70: 1 stad, 14 dorpen en 55 buurtschappen (waarvan er twee nog niet beschreven zijn). Daarnaast weet ik niet of de BAG-gegevens deze nog alle (h)erkent en van inwoners voorziet (maar dat laatste kan opgelost worden door het actuele inwonertal op 0 te zetten. Daarnaast zijn de twee gevonden inwonertallen uit 1830, de eerst ingevoerde. Maar hier wordt door Dajasj aan gewerkt, begrijp ik. Met vriendelijke groet, RonnieV (overleg) 17 jun 2022 21:52 (CEST)

We beperken ons tot de Bag-woonplaatsen, dat hoeven niet alle dorpen of buurtschappen te zijn. Zover ik kan zien is dat ook geen gedefinieerde term. Dit sjabloon is dus ook geen vervanger van tabellen die dat aanhouden als lat, maar alleen van tabellen die met BAG werken (dat lijken de meeste te zijn). Dat kan per artikel besloten worden. En ik ben bijna klaar met de woonplaatsen kloppend maken. Daarna ga ik de inwonersaantallen toevoegen. Dat duurt even, maar we gaan zeker niet gegevens uit 1830 toevoegen nee. Dajasj (overleg) 17 jun 2022 22:06 (CEST)

Vormen die BAG-woonplaatsen een gesloten deken, of is dat (ook) een verklaring waarom er altijd wel iets onder 'overig' zal vallen?

Ennomien had het hierboven over de aanpak van de voorkeurswaarden. Gebruikelijk en beoogd is dat de nieuwste waarde altijd de voorkeurswaarde is. Dat gaat goed met de woonplaatsen (al zal het soms even duren voordat die van het nieuwe jaar bekend zijn), maar niet voor de gemeenten. Die laatste worden maandelijks bijgewerkt (met wat vertraging) en als het goed is ook in Wikidata gezet als voorkeurswaarde. De Lua-module zal een keuze moeten maken tussen het accepteren van het verschil en het tonen van de data van beide gegevens of het opvissen van het inwonertal per de 1e januari van het hoogste jaartal dat voor de woonplaatsen gevonden wordt. Met vriendelijke groet, RonnieV (overleg) 17 jun 2022 23:31 (CEST)

De BAG-woonplaatsen horen een gesloten deken te vormen. CBS rapporteert alleen geen inwonertallen van woonplaatsen, maar van buurten en wijken. Daar zit dus een definitie-uitdaging in, waar we met de huidige tabellen op Wikipedia óók tegen aanlopen voor zover ik kan zien. We zijn nu eenmaal niet zo goed in definities op Wikipedia.

Wat betreft gemeenten en Wikidata, de relatiteit is dat die niet maandelijks geupdate worden en Demarche Modi ook te horen gekregen heeft dat maandelijks updaten onwenselijk is. Vooralsnog zie ik dat niet als een groot probleem, ook omdat de tabel van Ennomien er eerlijk over communiceert, door de datum van elke entry te vermelden. Dajasj (overleg) 18 jun 2022 09:56 (CEST)

Het kan dan wel "de tabel van Ennomien" zijn, maar het was Ronnie zelf die die kolom toevoegde. ;) Mvg, Ennomien (overleg) 18 jun 2022 14:50 (CEST)

@iedereen: begrijp ik het dan goed dat puntje 3 hierboven zoals het nu lijkt niet nodig is? Dan kunnen we stap 2 (voorlopig) afronden. (Bij geen reactie of enkel instemmingen doe ik dat na het weekend.) Ennomien (overleg) 18 jun 2022 14:55 (CEST)

Wat mij betreft is het volledig afgerond en ligt de focus nu op wikidata. Zie tevens mijn reactie hieronder (red., Stap 4, "Voorkeurswaarde"). Démarche Modi (overleg) 18 jun 2022 15:53 (CEST)

Stap 3 (WD)

Inhoud 

Off-topic 

Wat betreft stap 2 van Wikidata, hier heb ik in het verleden een vraag over gesteld op Wikidata. Zie hier. Het script dat ik geschreven had om de inwonertallen van het CBS op te halen en klaar te maken voor import in Wikidata zou maandelijks gaan draaien. Dit leverde bezwaar op zoals je kunt teruglezen, maar er is ook gelijk een voorstel aangedragen. Het bezwaar is dat het een te lange lijst met P1082 statements oplevert. Het verbetervoorstel is om met twee statements te werken; één P1082 en één P4179. De P1082 is de primaire waarde die het meest recente inwonertal bevat en periodiek moet worden overschreven. De P4179 bevat een verwijzing naar Commons met een tabular population, dit is een lijst met alle historische waarden. Démarche Modi (overleg) 8 jun 2022 15:52 (CEST)

Hmm interessant. Ik snap wel waarom ze maandelijke inwonertallen wat veel vinden, maar jaarlijkse moet gewoon binnen P1082 vallen. Dus niet altijd overschrijven. Die maandelijkse kunnen dan beter binnen P4179. Ook wel benieuwd hoe je P4179 gaat doen als er meerdere bronnen zijn, zoals voor veel oudere jaren het geval is. Overigens moet men gewoon de interface van Wikidata verbeteren: per property maar drie statements laten zien (voorkeur voor preferred) en de rest uitklapbaar. Dajasj (overleg) 8 jun 2022 16:06 (CEST)

Off-topic 

Mijn eerste gedachte (toen, nog niet verwerkt) was om het gewoon jaarlijks te gaan verwerken. Dan levert het script een lijst met de inwonertallen per gemeente per 31/12 bijvoorbeeld (afhankelijk van moment van draaien script) Is dat wat jullie graag willen en kan hiervoor een pythonscript worden gebruikt? Zo ja, dan zal ik daarvoor deze week een concept aanleveren. Iemand anders dient het dan verder op te pakken voor een bot of een import in wikidata.

Jouw idee om historische statements in te klappen vind ik een mooi idee.

Wat betreft P4179, indien er meerdere bronnen zijn, dan dient dit correct in de tabel geschreven te zijn. Zie Data:Taipei Population.tab als voorbeeld. Indien daar waarden bijgeschreven worden uit een andere bron, dan kan deze daar toegevoegd worden en zou de kolom P854_source bijgewekt moeten zijn. Ironisch genoeg zien we daar gelijk een fout, de kolomnaam heeft het over S854 terwijl het property P854 betreft.

P4179 is ruim 2000 keer gevuld in Wikidata. zie hier bij current uses Mijn eerste indruk was eerst positief, echter ik heb geen concreet voorbeeld gevonden (misschien onvoldoende gezocht) Het eerste resultaat - canton of Mérignac-2 bracht me bij de franstalige wiki om uiteindelijk een handmatig gevulde template te vinden.

Het 'formele voorbeeld' op Wikidata laat niet alleen een foute kolomnaam zien, we missen mogelijk ook belangrijke data. In het franse voorbeeld zien we al iets meer datakolommen gevuld. Echter, het is daar een tamelijk technisch verhaal geworden die niet meer leesbaar is zonder de Q items te kennen (zo zou ik een import tabel maken, niet een gepubliceerde lijst). Al met al constateer ik een niet consistente aanpak van Property 4179. Verder heb ik bewust niet verder gezocht naar geschikte voorbeelden van het gebruik van P4179 en riekt de reeds aanwezige data meer naar data creatie - omdat de data beschikbaar was en het nu eenmaal kan - dan naar gewenst data gebruik en daarvoor gerealiseerd (wat mijns inziens leidend moet zijn om explosie van big data te vermijden).

Kortom, mijn (jumping to) conclusie was dat er vanuit Wikidata irritatie was omtrent ellenlange data items met veel statements zoals de populatie en dat er vervolgens voor gekozen is om deze informatie maar over de schutting van Commons te gooien. Een slecht besluit mijns inziens omdat Wikidata haar eigen rol daarmee niet vervult (de dataserver die de data liever op een andere server opslaat). Toen heb ik het maar links laten liggen (tot het nu weer ter sprake kwam). Démarche Modi (overleg) 8 jun 2022 17:30 (CEST)

Inwonertallen per gemeente heb ik nu eigenlijk al gedaan met OpenRefine (een Pythonscript is daar niet waard voor). Woonplaatsen hebben we nog hulp bij nodig, maar daarvoor is geen stabiele identifier zoals er wel gemeentecodes bestaan. Dus daarvoor moet je nog veel handwerk doen. Je kan overigens nog kijken of je "preferred rank" kan wijzigen met Python, maar dit heb ik niet kunnen vinden.

Ik volg ook je betoog over P4179. Interessanter is de opmerking "dan naar gewenst data gebruik en daarvoor gerealiseerd (wat mijns inziens leidend moet zijn om explosie van big data te vermijden)." Ik ben het daar he-le-maal mee eens. Beetje discussie buiten de scope van dit miniproject, maar we moeten gewoon steeds naar concrete usecases toe en zorgen dat die data dan tiptop in orde is, voordat we verder gaan naar het volgende. Alleen Wikidata wordt regelmatig geblokkeerd op Wikipedia waardoor die usecases niet gestart kunnen worden. Nou goed, dat weer mijn mening. Dajasj (overleg) 8 jun 2022 17:37 (CEST)

Zelf ken ik OpenRefine nog onvoldoende. Indien je volgend jaar met een druk op de knop de inwonertallen kan toevoegen dan ben ik het met je eens dat het geen Pythonscript waard is. Indien dat (veel) handwerk is, dan denk ik dat een heroverweging op zijn plaats is.

Voor woonplaatsen (Wijken en Buurten binnen een gemeente) zijn wel CBS identifiers beschikbaar:

::import pandas as pd
::import cbsodata
::WijkenEnBuurten = pd.DataFrame(cbsodata.get_meta('83765NED', 'WijkenEnBuurten'))
::WijkenEnBuurten.to_excel('wijkenenbuurten.xlsx', index=False)

Zo is bijvoorbeeld BU16800000 Annen een buurt binnen de gemeente Aa en Hunze GM1680. De vraag die nu bij mij opkomt is of Wikidata hier ook goed mee om kan gaan en er niet een 'GM' voorzet zoals ik me meen te herinneren.

Aangezien ik geen bot draai kan ik geen wijzigingen doorvoeren op Wikidata met behulp van een script. Wel kan ik desgewenst een overzicht maken met welke items de rank preferred hebben (cbs_claim.getRank() == 'preferred'). Hiervoor moet ik dan weten over welke preferred rank we precies praten. (P1082 neem ik aan) En indien de resultaten niet in de duizenden lopen dan kan ik ze wel handmatig corrigeren (dit heb ik met P382, de CBS codes, al gedaan). Démarche Modi (overleg) 8 jun 2022 18:15 (CEST)

Als iemand die zelf ook eerst begon met Python uploads, kan ik je echt OpenRefine aanbevelen, het is echt makkelijker.

Wat betreft de CBS identifier, er is geen property voor op Wikidata en wat ik begreep zijn de identifiers ook niet stabiel, ze wisselen per jaar. Dat zou ik even moeten navragen aan Wikiwerner, anders is het creëeren van property wellicht het waard.

Wat betreft preffered. Het gaat voor gemeenten al om 350 ofzo, dus handmatig is nuttig maar niet leuk. Het gaat om P1028 inderdaad. Wel benieuwd waarom je geen bot runt trouwens? Dajasj (overleg) 8 jun 2022 18:21 (CEST)

Met P1082 ga ik aan de slag. De wijzigingen in de identifiers vallen volgens mij te overzien; jaarlijks de gemeentelijke herindelingen die zorgen voor nieuwe, gecombineerde en vervallen CBS codes met daaronder de verplaatste Buurten en Wijken naar de nieuwe gemeente. Jaarlijks publiceert het CBS deze wijzigingen op GMcode niveau. https://www.cbs.nl/nl-nl/onze-diensten/methoden/classificaties/overig/gemeentelijke-indelingen-per-jaar Maar wellicht heeft Wikiwerner of iemand anders andere argumenten.

Off-topic 

En de bot mist omdat ik nog nooit de moeite heb genomen om door de aanvraag en acceptatie stappen te lopen. Heb me een klein beetje verdiept in wat de eisen (wikidata) zijn maar nog niet meer dan dat. Démarche Modi (overleg) 8 jun 2022 18:53 (CEST)

@Wikiwerner, ergens las ik van jouw hand dat de identifiers voor buurten en wijken steeds wisselen. Beperkt zich dit tot gemeentelijke herindelingen, of is het in het algemeen te instabiel? Dajasj (overleg) 8 jun 2022 18:58 (CEST)

Ik heb zelf geen idee hoe dat werkt, dus ik kon me niet voorstellen dat ik dat beweerd heb. Een zoektocht door mijn bijdragen in de Helpdesk bracht me echter als eerste hier, waar ik het inderdaad niet zelf beweer, maar citeer uit de uitleg bij het sjabloon:Statistiek kerngebieden Nederland inwoners: "CBS-codes zijn ieder jaar onderhevig aan wijzigingen. Zo had Lobith in 2017 CBS-code 01960000 en in 2018 na gemeentelijke herindeling, 029909. Om deze reden blijft dit sjabloon voorlopig naar de cijfers van 2017 verwijzen". Gek genoeg is het inwonertal van Lobith wel van 2021, gebruikmakend van de {{Infobox plaats in Nederland}}, {{Statistiek woonplaats Nederland inwoners}} en vervolgens ... {{Statistiek kerngebieden Nederland inwoners 2021}}! Ik snapte het toen al niet, en nu nog steeds niet. Wikiwerner (overleg) 8 jun 2022 20:18 (CEST)

Hmm dank voor je toelichting! Dat suggereert wel een zekere consistentie, aangezien gemeentelijke herindelingen redelijk beperkt zijn :) Dajasj (overleg) 8 jun 2022 20:23 (CEST)

Wat mogelijk nog noemenswaardig is, is dat die laatstgenoemde vervolgens een module aanroept: Module:Array_Nederland_kerngebieden_inwonertallen_2021. In deze module treffen we vervolgens een 'array' met inwonertallen en nog wat code aan (hoezo array?). Enfin, ik begrijp Wikiwerner denk ik en ik volg de logica ook niet helemaal maar kan het gebruik denk ik wel toelichten (oude sjablonen bruikbaar houden met laatste data en de titels verder gewoon negeren). Maar dat lijkt me verder off-topic.

Voor wat betreft die gemeentelijke herindelingen en (on)verwachte wijzigingen van CBS coderingen, wellicht is het de overweging waard om jaarlijks, wanneer de gegeven van het laatste jaar weer verwerkt gaan worden, een vergelijk te maken _{(kan bijvoorbeeld met pandas of beyond compare)} van de voorlaatste tabel en de nieuwe. Wat we hier namelijk lijken te missen is de metadata van deze metadata en daar kan dus niet op gestuurd worden. Die voorlaatste moet dan wel goed opgeslagen worden om misverstanden te voorkomen. De gevonden wijzigingen die dan niet gerelateerd zijn aan gemeentelijke herindelingen zijn problematisch en mogelijk kritische vragen aan het CBS (hoewel ze dat al weg-gedisclaimd hebben) en drastische maatregelen voor ons hier. Démarche Modi (overleg) 8 jun 2022 23:26 (CEST)

Ik zie zelf niet in waarom we historische data moeten bewaren. Daar gaat dit project (in eerste instantie) toch niet over? Mvg, Ennomien (overleg) 8 jun 2022 18:35 (CEST)

Is volgens mij volgens mij gewoon bredere Wikidatavraag, inderdaad niet specifiek hiervoor. Dajasj (overleg) 8 jun 2022 18:56 (CEST)

Vanuit Wikipedia's perspectief; Voor items waar de verandering door de loop de tijd beschreven en onderbouwd wordt met een tabel of grafiek denk ik dat het nuttig kan zijn. Bijvoorbeeld de groei van de inwonertallen van een groeiregio en die van een krimpregio. Vanuit Wikidata's perspectief heb ik argumenten gelezen om nooit data te verwijderen, zelfs niet foutieve data en dat hiervoor de deprecated-rank bestaat. Om achterhaalde informatie te kunnen onderbouwen en een geschikt plekje te kunnen geven. Démarche Modi (overleg) 8 jun 2022 19:02 (CEST)

Oké, bedankt beiden. Ik ben het met jullie eens hoor. Maar om toch even streng te zijn: houd deze pagina wel een beetje on-topic. :) Ennomien (overleg) 8 jun 2022 19:08 (CEST)

Zie hier een eerste analyse van de P1082 en ranking. Dit pak ik wel handmatig op voor nu. (1. KeyErrors zoveel als mogelijk eruit, 2. Rank preferred op laatste waarde (2021) en 3. re-run script om te kijken wat het opgeleverd heeft.

Dajasj, binnen de pywikibot is er ook de functie setRank(). Geen idee hoe dat in OpenRefine zit, wel weet ik dat je er ook op kan kweerieën via wikibase:rank.Démarche Modi (overleg) 9 jun 2022 09:33 (CEST)

Oe nice gevonden. Nou als je je verveelt, kun je wel botje maken om bij gemeenten de recente de voorkeursrang te geven en de rest te verlagen. Help ik wel met de aanvraag van toestemming :) Dajasj (overleg) 9 jun 2022 10:15 (CEST)

Gisteren stagneerde ik omdat iets ervoor zorgt dat de loginsessie eruit gegooid wordt... ik ga later nog een poging wagen. Indien ik al niet succesvol op test kan werken heeft het verder geen zin. Voor nu richt ik me op 'mijn task at/by hand'. Démarche Modi (overleg) 10 jun 2022 11:13 (CEST)

Iedere huidige gemeente is nu voorzien van populatie rank = preferred indien er gegevens aanwezig waren. Drie gemeenten hebben geen populatie omdat die op 1 jan 2021 nog niet bestonden. Het [Gebruiker:Démarche_Modi/Kladblok/python/controle_p1082_rank | script] dat ik hiervoor gebruik hanteert de huidige gemeentelijke indeling en CBS code als filter. Démarche Modi (overleg) 10 jun 2022 15:49 (CEST)

Dank :D Dajasj (overleg) 10 jun 2022 16:32 (CEST)

Top! Dan kan ik die voorkeurswaarde gebruiken indien het idee bij vraag 2 onder stap 2 (10 jun 2022 11:07) doorgaat. Zijn er nog geen cijfers van 2022 (zie namelijk dit)? Ennomien (overleg) 10 jun 2022 16:34 (CEST)

Het CBS publiceert maandelijks een update in deze tabel. Démarche Modi (overleg) 10 jun 2022 16:54 (CEST)

Waarom hebben die nieuwe gemeenten dan geen waardes? Die bestonden 1 jan 2022, 1 feb 2022 enz. Ennomien (overleg) 10 jun 2022 19:34 (CEST)

Omdat de data die Dajasj toegevoegd heeft over 1 jan 2021 gaat. Vermoedelijk komen de waardes van de nieuwe gemeenten in die dataset medio Q3 van dit jaar. Démarche Modi (overleg) 10 jun 2022 19:52 (CEST)

Oh, Dajasj gebruikt dus niet de data die maandelijks geüpdatet wordt? Zo ja, dan begrijp ik het. Ennomien (overleg) 10 jun 2022 19:58 (CEST)

Ja Démarche Modi (overleg) 10 jun 2022 20:04 (CEST)

De cijfers die het CBS vrijgeeft over de afgelopen maand(en), zijn voorlopige cijfers. Pas na verloop van tijd worden die definitief. Ik zou er voor de blijvende gemeenten niet voor kiezen om de voorlopige cijfers al te presenteren (om die na een paar maanden weer weg te halen en te vervangen door de definitieve). Voor een net gevormde gemeente zou ik me nog kunnen voorstellen dat we eenmalig de cijfers van net na de vorming gebruiken, met daarbij een indicatie dat het een schatting is. Met vriendelijke groet, RonnieV (overleg) 10 jun 2022 22:52 (CEST)

Nog even een belangrijke opmerking: het gaat niet alleen over gemeenten. De gegevens over de woonplaatsen zelf worden wel maar één keer per jaar gepubliceerd. Die van 2022 moet nog gepubliceerd worden zover ik zie. Dajasj (overleg) 10 jun 2022 23:00 (CEST)

Goede opmerkingen van jullie. Dan lijkt het mij handig voor de gemeentes, waar dus vaker data van bekend is, dezelfde peildatum te pakken als van de kernen. Ennomien (overleg) 11 jun 2022 13:47 (CEST)

Hey, klopt het dat jullie zorgen dat voorkeurswaarden op de goede datum staan? Dat de module daar geen rekening meer mee hoeft te houden. Ennomien (overleg) 11 jun 2022 18:22 (CEST)

Zie nu pas deze vraag @Ennomien, met data invoer ben ik nog niet echt bezig. Voor dergelijke vragen kan ik eventueel wel helpen met een script om te kijken hoe de gegevens in wikidata staan. Zie deze als voorbeeld voor de gemeenten (exclusief de onderliggende plaatsen). Voor die plaatsen had ik al wel een beginnetje gemaakt maar hier heb ik verder nog geen tijd aan besteed. Démarche Modi (overleg) 17 jun 2022 23:31 (CEST)

Top! Ennomien (overleg) 18 jun 2022 16:32 (CEST)

Dit gesprek vervolgde zijn weg hier: 11 jun 2022 18:39 (Stap 2).

Stap 4

Vreemde eenden

Inhoud 

• Harkstede en Lageland zijn woonplaats in Nederland, maar vallen onder twee verschillende gemeenten. Echter is er maar één Wikipedia-artikel per. Op Wikidata kan ik het op zich makkelijk scheiden door twee items aan te maken, maar dan krijgen we dus een rode link. Is dat de meeste wenselijke optie? Dajasj (overleg) 13 jun 2022 20:26 (CEST)

  Ik ben geen Wikidata-held, maar dat klinkt als een goed alternatief. Weet wel dat met de huidige versie van de module links niet rood worden, maar gewoon tekst zijn als er geen pagina is. Misschien verandert dat nog iets voor je. Mvg, Ennomien (overleg) 13 jun 2022 21:02 (CEST)

  Is op zich ook prima, maar gewoon zonde dat het niet gelinkt wordt. Dajasj (overleg) 13 jun 2022 21:03 (CEST)

  Ben het met je eens hoor. Ik kan zo snel ook geen mooie manier bedenken om dat alsnog te doen. Misschien een bepaalde property op die secundaire Wikidata-pagina die aangeeft welke Wikipedia-pagina het eigenlijk betreft. Weet niet of zoiets bestaat. (Ik hoop dat je snapt wat ik bedoel, anders moet je het even zeggen.) Ennomien (overleg) 13 jun 2022 21:45 (CEST)

  Nope, dat bestaat niet... Evenmin dus linken naar doorverwijspagina's Dajasj (overleg) 13 jun 2022 22:02 (CEST)

  Kan in die gevallen op het Wikidata Item gelegen in bestuurlijke eenheid (P131) gebruikt worden waarin de twee gemeenten vermeld staan (met startdatum en zonder einddatum)? En in beide gemeenten omvat plaats (P1383) gevuld worden waarin dezelfde plaats vermeld staat? _{Heb dit niet getest, mogelijk levert het een waarschuwing op, misschien ook niet. Indien dat wel zo is dient er wellicht iets verbeterd te worden op die controle van Wikidata.} Démarche Modi (overleg) 13 jun 2022 23:29 (CEST)

  Ja, maar de inwonertallen per gemeente verschillen, dat is het issue ;) Dajasj (overleg) 13 jun 2022 23:33 (CEST)

  Hmmm, wellicht is hiervoor van toepassing op deel (P518) bedoeld. Dan twee inwonertal (P1082) statements met de gemeentenaam in P518 en rank = preferred in deze plaatsen zodat bekend is voor welke gemeente het betreffende aantal geldt. Démarche Modi (overleg) 13 jun 2022 23:43 (CEST)

  In dat geval dient er dan ook in de module een extra stap toegevoegd te worden die controleert op de aanwezigheid van P518. Indien die niet bestaat (in de meeste gevallen omdat het slechts 1 waarde betreft) dan doorgaan met de gevonden waarde (zoals nu). Indien P518 wel aanwezig is dan dient de P518-waarde overeen te komen met de gemeentenaam waarvoor de tabel gemaakt wordt en overeenkomstig het inwonertal daarvan gebruikt te worden. Démarche Modi (overleg) 14 jun 2022 00:04 (CEST)

  Dat komt helemaal goed in de module. Ik hoor graag van jullie of hiervoor gekozen wordt en hopelijk kan Dajasj met zijn expertise dit goede idee bevestigen. :) Ennomien (overleg) 14 jun 2022 10:32 (CEST)

  @Multichill, volgens mij ben jij wel een expert op het gebied van dit. Is de oplossing van Demarche het handigste? En dus twee BAG-nummers bij deze items? Dajasj (overleg) 14 jun 2022 21:15 (CEST)

• Ook Buurmalsen en Kapel-Avezaath vallen onder 2 gemeenten. Meer op plaatsengids.nl Uwappa (overleg) 17 jun 2022 19:25 (CEST)

  En dan zijn ze Hazelberg nog vergeten. Wikiwerner (overleg) 17 jun 2022 19:53 (CEST)

  Het zijn er nog veeel meer. Maar ben nog niet aan alles toegekomen. ;) Dajasj (overleg) 17 jun 2022 23:16 (CEST)

• Zou het een raar idee zijn om voor het inwonertal en de koppeling met de gemeente op Wikidata twee items aan te maken, Lageland 'buurtschap in Midden-Groningen' en Lageland 'buurtschap in Groningen'? Als bij de volgende herverdeling het Midden-Groningse deel verhuist naar een andere gemeente (of ze een creatievere naam bedenken), dan is er geen man overboord. Bij de complete buurschap kan het inwonertal gegeven worden van de hele buurschap, in de twee subdelen (gekoppeld...) het inwonertal van het relevante deel. De link naar de buurtschap mag dan niet werken in de gecreëerde tabel, maar die is feitelijk toch onjuist. Met vriendelijke groet, RonnieV (overleg) 17 jun 2022 21:42 (CEST)

• Ja dat is een optie, die ik erboven voorstelde. Zou correct zijn volgende BAG, maar gewoon wat ongemakkelijker met die inter wiki links... Maar dat heeft dus jouw voorkeur boven "van toepassing op"? Dajasj (overleg) 17 jun 2022 23:16 (CEST)

• Ja, dat zou mijn voorkeur hebben, omdat je de informatie dan vastlegt bij een zelfstandig object, zoals het hoort. Ik weet dat we op (nl-)wiki veel artikelen hebben waarin we de hoofdplaats van een gelijknamige gemeente in hetzelfde artikel beschrijven, maar een gemeente en een plaats zijn verschillende dingen. Net als een monumentaal pand, waarin nu een restaurant gedraaid wordt. Of een pagina over de moord op ... en de persoon ... zelf. Nu zal in het laatste geval nl-wiki niet altijd een artikel over die persoon krijgen, maar in Wikidata horen het wel twee objecten te zijn: een persoon met geboorte- en sterfdatum (en -plaats), een nationaliteit, naam, beroep,... En een misdaad, met een datum, plaats van delict, slachtoffer(s),... Dat maakt het ook makkelijk om entiteiten te onderscheiden en de juiste informatie op te halen en te tonen. Met vriendelijke groet, RonnieV (overleg) 18 jun 2022 09:00 (CEST)

  Ik ben het eens met alle voorbeelden die je hier geeft, Ronnie. Maar in ons geval, dus geen vermoorde personen maar levende gemeenten, spreken we toch over één woonplaats die in twee gemeenten ligt? Dat de BAG daar onderscheid in maakt is prima (en voor ons doeleinde ook handig), maar inwoners uit Hazelberg in het deel in Meierijstad zijn toch gewoon dorpsgenoten van de mensen in het deel behorend tot Bernheze? Het is één dorp. Dat, plus het feit dat het splitsen juist minder mooie tabellen oplevert (zonder / met rode links), laat mij juist kiezen voor het voorstel van Démarche 13 jun 2022 23:29. Niet dat ik mijn werk staak als ik mijn zin niet krijg, maar ik vind jouw/jullie keuze niet de meest logische noch de meest elegante. Mvg, Ennomien (overleg) 18 jun 2022 14:49 (CEST)

• Zou inwoneraantal per postcode per startdatum een oplossing kunnen zijn? Hoort een Nederlandse postcode (6 chars) altijd bij 1 woonplaats en 1 gemeente? Het inwoneraantal per postcode is vast bekend, want gemeentes weten het aantal inwoners per woning. De data-structuur zou dan kunnen worden:

1. Een woonplaats bestaat uit postcodegebieden. Een postcode kan per startdatum bij een andere woonplaats gaan horen.
2. Een gemeente bestaat ook uit postcodegebieden. Een postcode kan per startdatum bij een andere gemeente gaan horen.
3. Een gemeente heeft via postcodes meerdere woonplaatsen, een woonplaats kan via postcodes onder meerdere gemeenten vallen. De meeste woonplaatsen vallen onder 1 gemeente, de 'vreemde eenden' onder meerdere.

Voor 1 datum, is dan het inwoneraantal van alle postcodes in een woonplaats op te tellen. Idem voor optelling per gemeente. pc6hnr20210801_gwb.csv van het CBS doet vermoeden dat zelfs een Nederlandse postcode nog te grof is, een huisnummer bij een wijk in een gemeente hoort.

Bijzonder: 1 voordeur in het dorp Baarle heeft 2 huisnummers, elk huisnummer in een andere gemeente (Baarle-Hertog, Baarle-Nassau) en zelfs in 2 landen (BE, NL). Elk huisnummer hoort dan wel bij 1 woonplaats, 1 gemeente, 1 land.

Alternatief: Hou het eenvoudig. Haal de 'eenvoudige' grote groep van 1 gemeente per woonplaats uit wikidata. Los de 'vreemde eenden' op met vrije wikipedia tekst. Uwappa (overleg) 18 jun 2022 08:35 (CEST)

Ik vind het een sympathiek voorstel, maar we hebben vooralsnog nul informatie over postcodes op CBS, Wikidata en Wikipedia. Ik kan nergens dat inwonertal vandaan halen, en dat ook lastig linken met objecten die bestaan op Wikidata en Wikipedia.... Dajasj (overleg) 18 jun 2022 09:58 (CEST)

Vervolg op 18 jun 15:53 (Stap 2).
@RonnieV, mijns inziens is het verstandiger om buiten lua in een onafhankelijk script te controleren hoe de kwaliteit van de wikidata gegevens is. Hier hoop ik een steentje in bij te kunnen gaan dragen. Indien het namelijk in een lua script gedaan wordt, dan is er geen compleet overzicht van alle gegeven aangaande die set en is het risico van ongewenste presentatie groter omdat dat overzicht ontbreekt en het niet te doen is om duizenden items te controleren. Het onafhankelijk controleren heeft volgens mij twee voordelen; 1 het lua script blijft zo eenvoudig als nodig (omdat het uitgaat van een standaard data kwaliteit - zoals het hoort volgens die module) en 2 op basis van een compleet overzicht kan er sneller en doeltreffende gewerkt worden met de gegevens op wikidata. Eventueel kan daarmee een bot gevoed worden voor het wijzigen of toevoegen van die data. Ik hoop van ganser harte dat je in dit hoofdstuk mee wil om 'om te denken'; laten we proberen het vanuit de dataset, wikidata, te beredeneren. Jij was het die me eerder enthousiast maakte over wikidata, met het inwonertal sjabloon dat je geschreven hebt. Een puik voorbeeld van hoe eenvoudig iets in een sjabloon gepast kan worden maar tevens de gevoeligheid van de onderliggende data tentoonstelde (zoals je hierboven ook zelf aanhaalt voor een datum uit 1830.) In het geval van de dataset voor de inwonertallen ligt er kennelijk nog wat werk en vragen. Volgens mij komen we - vooral @Dajasj, steeds meer tot de kern(cijfers wijken en buurten). (ik vind dit wel een leuk bruggetje). Die kerncijfers van het CBS, welke door Dajasj onlangs voor de gemeenten opgevoerd heeft, zijn denk ik de beste voor de wikipedia gemeenschap. Het CBS heeft na haar werk het uiteindelijk gepubliceerd (in Q3 van het nieuwe jaar). Daarmee zijn de cijfers wellicht niet de meest recente (minimaal 6 tot maximaal 21 maanden oud), maar ze zijn wel door een onafhankelijke gezaghebbende bron gepubliceerd. _{Overigens ben ik van mening dat die bron het uitgangspunt moet zijn en niet reeds gepubliceerde informatie in een wikipedia artikel. Indien een artikel meer gegevens bevat dan wat er in de KWB set beschikbaar is, dan moet er desnoods een extra bron bijkomen welke wederom herleidbaar is naar een onafhankelijke en gezaghebbende externe partij.} Wat betreft meerdere BAG codes voor een plaats in meerdere gemeentes, wellicht is het verwijderen van enkele waarde-beperking (Q19474404) op BAG-identificatiecode voor woonplaats (P981) de oplossing. Voorts is het toevoegen van unieke waarde-beperking (Q21502410) de overweging waard. In plaats van nieuwe wikidata items aan te maken. Démarche Modi (overleg) 18 jun 2022 15:49 (CEST)

Démarche Modi, als je bedoelt dat je graag met een ander script dan dit Lua-script de inwonertallen van Nederlandse plaatsen uit Wikidata wil lezen en die tegenover de informatie in het bestand dat Dajasj heeft gebruikt, wil zetten, dan valt daar bijvoorbeeld in een WD-query wel wat op te verzinnen. Ook met pywikibot is dat niet zo moeilijk. Voorwaarde voor beide is dat je heel duidelijk definieert wat je wil zien.

Aanpassingen in het datamodel van Wikidata zijn niet zo snel geregeld. Het model is internationaal en wordt graag zo generiek mogelijk gehouden. Een unique value-beperking is ook geen beperking waarop je kan blindvaren, het genereert 'maar' een waarschuwing. Bedenk ook dat er vele scripts, tools,... zijn die gebruik maken van deze info. Een kleine aanpassing kan heel ergens anders iets doen omvallen. Met vriendelijke groet, RonnieV (overleg) 20 jun 2022 11:26 (CEST)

Het lijkt niet nodig, maar toch: Helpt P279, subtype of? Een "Nederlands" subtype maken van een internationaal al gebruikte classe, extra statements en constraints toevoegen aan de subclass, terwijl de internationale superclass onveranderd generiek blijft? Uwappa (overleg) 20 jun 2022 13:17 (CEST)

Volgens mij maakt dit het allemaal veel ingewikkelder dan het is. Er moet gewoon gekozen worden: één of drie items voor vreemde eenden. Dajasj (overleg) 20 jun 2022 13:21 (CEST)

Hoe gaan we hier nu mee om? Ik ben nog steeds voor het idee van 13 jun 2022 23:43, dan is de informatie compleet en heeft tegelijkertijd één dorpje ook maar een pagina op Wikidata, in plaats van meerdere. Ennomien (overleg) 7 nov 2022 18:19 (CET)

Goed dat je de discussie weer aanzwengelt. In al die tijd is er zo te zien weinig extra inzicht gekomen en ik denk dat we VJVEGJG hier wel mogen toepassen. We kunnen Harkstede als oefencase gebruiken en zien hoe het uitpakt. Indien we het inwonertal opknippen per BAG=1349 Harkstede Gemeente Midden-Groningen en per BAG=3635 Hakstede Gemeente Groningen dan levert dat dus twee actuele vermeldingen van het inwonertal (en wellicht later andere parameters). In Wikidata lijkt me dat geen probleem. Daarna wordt het iets uitdagender. In Sjabloon:Infobox plaats in Nederland zal dan ofwel een optelsom van beide waarden of een opgesplitste vertoning moeten volgen. 'Woonplaatscode' of 'cbs' met twee codes gaat dan voor inwonertal niet meer werken en dat impliceert dat er mogelijk een derde stuurparameter bij moet (bijvoorbeeld 'wikidata') die ervoor zorgt dat de inwonertallen dan uit wd gehaald worden en niet uit de arrays of de module. Démarche Modi (overleg) 7 nov 2022 18:53 (CET)

Of we moeten drie inwonertallen opgeven: een voor het deel in de gemeente Groningen, een voor het Midden-Groningse deel, en het totaal, zonder "van toepassing op deel". Kan dit ook? Wikiwerner (overleg) 7 nov 2022 20:51 (CET)

Ja, dat is een optie: gedaan. Het is alleen de vraag of we daar ook goed mee kunnen tellen... Met vriendelijke groeten, RonnieV (overleg) 7 nov 2022 21:08 (CET)

Volgens mij gaat dat niet helemaal goed @RonnieV. De qualifiers ontbreken en het aantal komt niet echt in de buurt van de ruim 3000. Démarche Modi (overleg) 7 nov 2022 23:33 (CET)

De aantallen waren inderdaad puur als voorbeeld (maar ik dacht dat dat duidelijk zou zijn). Voel je gerust vrij om deze aan te passen en om qualifiers toe te voegen. Ik heb 'van toepassing op deel' wel gebruikt. Met vriendelijke groet, RonnieV (overleg) 7 nov 2022 23:41 (CET)

Dat van toepassing op deel (P518) gebruikt kan worden kan je gewoon uit de beschrijving halen van inwonertal (P1082). Volgens mij proberen we hier overleg te voeren en overeenstemming te bereiken en is VJVEGJG niet bedoeld om onzin data toe te voegen om te laten zien dat Wikidata functioneert zoals het neergezet is. https://test.wikidata.org is bedoeld voor testen. Démarche Modi (overleg) 8 nov 2022 07:56 (CET)

Bedankt voor je uitermate vriendelijke benadering, @Démarche Modi. Zorg jij er even voor dat de qualifiers op test.wikidata.org alle op dezelfde manier ingericht zijn? Succes verder! RonnieV (overleg) 8 nov 2022 10:44 (CET)

Jouw handelen (data toevoegen en na feedback simpelweg stellen dat ik jouw rommel mag opruimen) is niet collegiaal. Van iemand met jouw ervaring en ambitie had ik beter verwacht. En indien je vragen of verbeterpunten voorziet op de testserver van Wikidata had je op z'n minst daar aandacht voor kunnen creëeren in de survey. Hoe dan ook is de productieserver geen testomgeving en is het niet mijn taak om voor jou de testserver correct in te richten. Je had gewoon correcte data kunnen opvoeren met gangbare qualifiers en dan had je een goed voorbeeld ingebracht. Démarche Modi (overleg) 8 nov 2022 11:34 (CET)

Goed idee en bedankt voor het kijken of dat werkt. @RonnieV hoe bedoel je "of we daar ook goed mee kunnen tellen..."? Of de module daarmee om kan gaan? Lijkt me wel, nietwaar? Ennomien (overleg) 8 nov 2022 15:22 (CET)

Hoi @Ennomien, de module moet dus heel goed weten dat hij voor een datum meerdere waarden kan krijgen, waarbij deze afhankelijk van de vraag een van deze moet gebruiken. Een van de deelwaarden, of toch de totaalwaarde. Met vriendelijke groeten, RonnieV (overleg) 8 nov 2022 16:23 (CET)

Ah ja, precies. Dan heb ik mooi even wat werk te doen: toevoegen dat de module een vaste datum bekijkt (die uiteraard te veranderen is "achter de schermen") en zorgen dat de juiste deelwaarde wordt gebruikt, indien er deelwaardes zijn. Ennomien (overleg) 8 nov 2022 16:35 (CET)

Idealiter stel je niet een vaste datum in, maar kijk je naar wat er beschikbaar is in het betreffende wikidata-item. Het zou kunnen dat er bijvoorbeeld wel een totaalaantal beschikbaar is voor (1 januari) 2022, maar niet voor de deelgebieden., dat die bijvoorbeeld nog van 2020 zijn. Dan ligt het er net aan wat je zoekt. Met vriendelijke groet, RonnieV (overleg) 9 nov 2022 13:19 (CET)

Wellicht ten overvloede, echter pleit ik ervoor om de complexiteit aan onze kant zo laag mogelijk te houden en Wikidata zo goed mogelijk te gebruiken. Mijn advies zou zijn om (vooral bij dergelijke sporadische vreemde eendjes) te zorgen voor correcte data en (eventueel slechts) een waarschuwing te geven indien iets niet conform verwachting is. KISS. Die waarschuwing zou je eventueel in een controlelijst in de gebruikersruimte kunnen houden zodat niet alle artikelen gecontroleerd hoeven te worden of gewacht wordt tot een lezer met een opmerking komt. Démarche Modi (overleg) 9 nov 2022 13:47 (CET)

Bedankt voor jullie inbrengen. Eens kijken hoe ik die goede ideeën in de praktijk kan brengen. Ik kom daarop terug. Ennomien (overleg) 9 nov 2022 15:39 (CET)

@Démarche Modi - Ik zou hiervoor een trackingcategorie aanmaken, net zoals bijv. de categorie:Wikipedia:Fout in inwonertallensjabloon. Wikiwerner (overleg) 9 nov 2022 21:04 (CET)

👍 Démarche Modi (overleg) 9 nov 2022 22:38 (CET)

Ik denk dat P518 hier de perfecte oplossing is. Als ik naar de testbewerking van RonnieV kijk, lijkt het me haalbaar om daar wat zinnigs omheen te coderen. :) Zou ik jou, @Démarche Modi, mogen vragen om zulke data toe te voegen op Wikidata zodat ik daar (hopelijk) morgen mee kan testen en proberen? Bijvoorbeeld voor Harkstede. Morgen zal ik dan namelijk de wijzigingen van het kopje hieronder volledig doorvoeren (categorieën moet ik nog aanmaken) en dan kan ik direct door met het oplossen van de vreemde eenden. De methode is er immers al, nu alleen nog de uitwerking (al komt dat vast goed). Als het meezit zou de module in dat geval morgen af zijn. Mvg, Ennomien (overleg) 11 nov 2022 20:01 (CET)

@Ennomien, ik was even verrast door je verzoek en de korte tijspanne, maar na een leuk liedje opgezet te hebben ben ik aan de slag gegaan. M'n computer vind de standaard bron (grote spreadsheet) die Dajash steeds gebruikte niet fijn, maar met een brandblusser ernaast durfden we het toch aan. Overigens, Harkstede is toch een vreemde eend? Hoe dan ook, het dorp is nu in Wikidata voorzien van twee P1082 population statements. Beide heb ik als voorkeurswaarde neergezet en dit geeft een waarschuwing (net als bij de BAG identifier). Zie Harkstede (Q2594189) Démarche Modi (overleg) 11 nov 2022 23:55 (CET)

Sorry voor de haast, dankjewel voor je inspanning! :) Ik snap je niet helemaal: "Harkstede is toch een vreemde eend?". Ja klopt, daarmee moeten we ook juist testen toch? Daarom de vraag om data voor een vreemde eend in te voeren.

Die waarschuwing klinkt niet fijn. Is er geen andere manier om het in te vullen, bijvoorbeeld een totaal inwoneraantal die de voorkeurswaarde is, met als onderdeel daarvan de deelwaarden? Als zoiets niet mogelijk is, denk ik dat het ook wel lukt zonder een voorkeurswaarde. Ennomien (overleg) 12 nov 2022 13:53 (CET)

Zoals ik jouw zin Morgen zal ik dan namelijk de wijzigingen van het kopje hieronder volledig doorvoeren (categorieën moet ik nog aanmaken) en dan kan ik direct door met het oplossen van de vreemde eenden. lees, dan doe je eerst het ene en daarna de vreemde eenden. Terwijl je in werkelijkheid bedoelt dat je direct met de vreemde eenden aan de slag gaat. Démarche Modi (overleg) 12 nov 2022 14:22 (CET)

Oh ja, ik bedoelde inderdaad dat ik vandaag de categorieën kan aanmaken en om daarna qua coderen direct door te kunnen met de vreemde eenden, vroeg ik jou om de aanpassing op Wikidata. Met die nieuwe data kwam ik een foutje tegen in de module, dat heb ik ondertussen opgelost (nog niet gepubliceerd) en ik zag ook dat de sortering van de inwoneraantallen niet goed werkt. Dat is ook opgelost. Ennomien (overleg) 12 nov 2022 14:47 (CET)

@Démarche Modi had je nog gekeken naar het op een andere manier invullen van de data op Wikidata? Bijvoorbeeld wat ik suggereerde in mijn bericht van 13:53. Anders moeten we het bij de vreemde eenden anders doen, voor andere gebruiksdoeleinden kan het totaal inwoneraantal wel als voorkeurswaarde gemarkeerd worden en de deelwaarden dan maar niet. Ennomien (overleg) 13 nov 2022 13:42 (CET)

Nee, excuses, daar had ik niet naar gekeken (bijvoorbeeld een totaal inwoneraantal die de voorkeurswaarde is, met als onderdeel daarvan de deelwaarden). Later vandaag zal ik even kijken of ik daar iets mee kan. Démarche Modi (overleg) 13 nov 2022 14:36 (CET)

Is goed, alvast bedankt. Ennomien (overleg) 13 nov 2022 14:55 (CET)

Net even gekeken en er 1 statement van gemaakt met 2 references. Twijfel nog over 'including' en 'number / natural number', maar van de beschikbare properties binnen de qualifier constraint lijkt me die het meest logisch. 'Statement is subject of' (onderwerp van verklaring (P805) is wellicht ook een optie. Dat kan nog aangepast worden. Hoe dan ook heb je nu één declaratie in Harkstede (Q2594189) inclusief twee subwaarden per gemeente. Ben benieuwd of dit is waar je op hoopte en of je er mee uit de voeten kan. Démarche Modi (overleg) 13 nov 2022 15:22 (CET)

Fijn! Ik zie nu in ieder geval dat {{Inwonertal}} hier niet verstoord wordt, die geeft nu gewoon de totale waarde.

Ik denk dat ik hiermee wel uit de voeten kan, ik zou moeten kunnen zien of de population (P1082) references heeft. De module gebruikt het Inwonertal-sjabloon, maar voor het checken of er references zijn moet ik dat omzeilen. Dat zal dus bij iedere plaats moeten, en indien die references er zijn komt een nog te schrijven stuk code.

Ik zie hier wel meerdere waarschuwingen (uitroeptekens), vormt dat voor ons een (mogelijk) probleem of zijn die waarschuwingen verder niet erg? Ennomien (overleg) 13 nov 2022 16:08 (CET)

De waarschuwingen geven aan dat er constraint violations zijn, oftewel de gekozen waarde valt niet binnen de verwachting (constraints) van Wikidata. In de praktijk is dat niet erg, de data kan gewoon gebruikt worden. Wel is het een aandachtspunt dat ofwel de data anders neergezet moet worden ofwel de constraints aangevuld moeten worden. Ter lering en vermaak zou je eens kunnen rondneuzen in Wikidata:Database reports/Constraint violations en de subpagina's (waarschuwing: heel veel reports met violation data). Het probleem(pje) met including, die Wikidata liever als qualifier ziet, is dat er dan geen onderscheid gemaakt kan worden tussen de ene gemeente en de andere indien deze als qualifier gebruikt wordt en niet als reference zoals nu. Later zal ik nog even verder speuren en wellicht is deze situatie een vraagstuk waard binnen de Wikidata gemeenschap. Wat wellicht nog de overweging waard is, is om twee keer van toepassing op deel (P518) toe te voegen per reference. Eentje met de gemeentenaam en eentje met het inwonertal. Dan zal de module dat onderscheid alleen moeten gaan zien op basis van data type (ofzo). Démarche Modi (overleg) 13 nov 2022 16:28 (CET)

Dat zijn mooie grote lijsten.

Wat je aan het einde van je bericht zegt moet zeker haalbaar zijn in de module. Als dat beter zou zijn, dan is het wat mij betreft prima om dat door te voeren. Het probleem voorleggen aan de gemeenschap vind ik ook goed, het zou namelijk jammer zijn als we het op een verkeerde of niet-handige manier doen. Ennomien (overleg) 13 nov 2022 17:16 (CET)

Discussion initiated. Démarche Modi (overleg) 13 nov 2022 21:00 (CET)

@Ennomien, er is antwoord gekomen in de Wikidata discussie. De suggestie heb ik verwerkt. Kun je daar mee uit de voeten? In deze registratie heb ik er voor gekozen om geen references op het totaal (preferred rank registratie) te zetten maar op de delen (normal rank). De methode van vaststelling (P459) heb ik op sommatie (Q218005) gezet. Wellicht moet er nog wat getwiekt en getjoent worden aan hoe het er nu staat. Démarche Modi (overleg) 15 nov 2022 09:52 (CET)

Klinkt goed, bedankt daarvoor! Ik ga straks of morgen kijken of ik daarmee iets kan, ik denk het wel. Dit schoot me ineens te binnen, is het handig ergens in/bij de tabel "Meld een fout" te zetten als link om fouten in de tabel te melden op een bepaalde pagina? Ennomien (overleg) 15 nov 2022 17:13 (CET)

Wat bedoel je precies met 'fouten in de tabel'? Bedoel je foutmeldingen of bedoel je dat er iets niet klopt, en zo ja, wat dan bijvoorbeeld? Indien het een foutmelding is (zoals nu hier bijvoorbeeld), dan zou ik het het mooiste vinden indien dat op een dashboard duidelijk is. Die dingen hebben we alleen niet dus is bijvoorbeeld het idee van Wikiwerner hierboven een idee. Ik vraag me alleen af hoe die tot stand gekomen is, mogelijk met de hand. Dat lijkt me minder wenselijk. Het mooiste zou zijn indien er een soort errorhandling plaatsvindt die een pagina automatisch voorziet van een categorie (bijvoorbeeld Categorie:Wikipedia:Foutmelding ERROR in inwonertallensjabloon). Die categorie kan dan na controle en herstel handmatig verwijderd worden. Ik heb alleen geen flauw benul of het automatisch en conditioneel toevoegen van een categorie, vanuit een module, mogelijk is. Misschien kan dat alleen via een bot/batchrun. Démarche Modi (overleg) 15 nov 2022 18:36 (CET)

Dan lijkt me een inimini knopje, Meld een fout, wel een slim idee. Démarche Modi (overleg) 15 nov 2022 18:39 (CET)

Ik bedoelde fouten in de inhoud, dus inwonertallen, ontbrekende plaats e.d. aangezien het voor 9/10 Wikipedianen en voor alle lezers onduidelijk is hoe de inhoud van de tabel kan worden aangepast. Om in het geval van die foutmeldingen op mijn kladblok een categorie toe te voegen vind ik wel een goed idee. Dan voeg ik het knopje ook toe, even kijken waar precies.

Ter verduidelijking: het is heel simpel een categorie toe te voegen met de module. Wat deze module doet is de broncode aanmaken voor de tabel, hoe wij dat ook zouden doen in de bronbewerker. Als je dus aan de brontekst [[Categorie:bla bla]] toevoegt ben je al klaar. Ennomien (overleg) 15 nov 2022 19:25 (CET)

Ok, en de categorie komt dan helemaal onderaan in de brontekst? Hmm, misschien moet ik je magie maar gewoon even afwachten. Démarche Modi (overleg) 15 nov 2022 19:37 (CET)

Zie deze bewerking. Wanneer er een foutmelding komt, staat achter die foutmelding de categorie. Die zie je als lezer natuurlijk niet daar, maar onderaan de pagina. Maar in de brontekst staat die dus niet onderaan. Heb het knopje ook toegevoegd. Met de vreemde eenden nog niks gedaan. Ennomien (overleg) 15 nov 2022 19:56 (CET)

@Démarche Modi zoals je vlak voor of na het lezen hiervan vast is opgevallen, heb ik de pagina die bij dit overleg hoort (ja die bestond ook nog haha) even wat mooier gemaakt. Ik heb uitvoerig getest met de vreemde eenden, het is zeker mogelijk dat te doen. Ik ben er net achtergekomen hoe ik vanuit onze module een andere kan gebruiken (dat was amper vindbaar op internet), dat gaat een hoop werk schelen waarschijnlijk. Module:Wd of Module:Wikidata kan ons helpen. Anders moest ik doorgaan met mijn huidige handmatige manier, maar die twee modules doen het vast wat beter.

Ik wil eigenlijk ook in een beheercategorie pagina's zetten die de wikidatalinks-parameter gebruiken (zie sjabloonpagina voor uitleg, is alleen voor tijdens het bewerken, "Toon bewerking ter controle"). Zal ik die in Categorie:Wikipedia:Tabel woonplaatsen Nederlandse gemeente/Niet-werkende tabel zetten? Dekt niet helemaal de lading, maar we moeten ook niet te veel categorieën krijgen. Ennomien (overleg) 16 nov 2022 17:53 (CET)

Invoke WD wordt ook gebruikt bij het Inwonertal sjabloon. Misschien heeft het z'n beperkingen (wat er namelijk nog niet in zit kan nog niet), maar daarvoor ken ik het inhoudelijk onvoldoende. Het is een kopie van de Engelstalige versie. In die Engelse versie hebben ze er nog een laag tussen gezet (tussen de module en gebruik in sjablonen). Zie hier. Overigens denk ik niet dat er een richtlijn is die gebruik van wd of de functionele tussenlaag voorschrijft en zoals je het nu doet lijkt het me erg leerzaam. Uiteindelijk is het denk ik wel mooier, herbruikbaar en beter beheerbaar indien er een goede gelaagdheid is, zoals de Engelsen nastreven. Dat maakt het beter leesbaar op sjabloonniveau. Dus ja gebruik wd, maar alleen als je uitgeleerd bent. Herschrijf het desnoods later en benoem eventueel missende functies in de bestaande modules.

Indien je met in een beheercategorie pagina's zetten die de wikidatalinks-parameter gebruiken bedoelt dat je wil beschrijven wat er mogelijk is, dan volstaat het om dat allemaal in de documentatie van de module (subpagina ../doc) te benoemen. Indien je iets anders bedoelt, dan heb ik het niet goed begrepen. Hoe dan ook, categorieoverzichten zouden alleen maar relevante artikelen moeten bevatten die voorzien zijn van de categorie, aangevuld met een korte inleidende uitleg bovenaan de pagina. Daar zou eventueel wel de parameter genoemd kunnen worden die ervoor zorgt dat een artikel automatisch gecategoriseerd is. Démarche Modi (overleg) 16 nov 2022 20:34 (CET)

Ik denk maar zo, het wiel opnieuw uitvinden heeft niet veel nut. Daarbij komt dat ik weet hoe ik data uit Wikidata kan ophalen, maar ik ken Wikidata niet goed genoeg om mogelijk optredende fouten te verzinnen (wat als dit mist, wat als dit niet goed ingevuld staat etc.). Module:Wikidata trekt meer mijn aandacht, ik zal het eerst daarmee proberen.

Nee, je snapte het niet. :) Er is in het sjabloon een "wikidatalinks"-parameter, als die "ja" is, toont de tabel rechtstreekse links naar Wikidata-items (met als doel het makkelijk aanpassen van data). Het is de bedoeling dat die functionaliteit alleen wordt gebruikt tijdens het bewerken, dus voor "Toon bewerking ter controle". Daarom wil ik tracken wanneer pagina's onterecht in de opgeslagen versie die parameter=ja hebben. Ik zal dat idee voor nu uitvoeren. Ennomien (overleg) 16 nov 2022 21:05 (CET)

Oh, een soort dev haakje, die zou ik er uiteindelijk uithalen. Maar dat lijkt me voorlopig wel handig. En over alle mogelijke situaties zou ik me niet teveel zorgen maken. Ga uit van de positieve use case (zoals het idealiter hoort), bedenk eventueel een voorbeeld van een of twee afwijkingen zoals missend inwonertal en missende datum. Mocht er onverhoopt nog iets belangrijks missen, dan wordt dat later vanzelf duidelijk. Wikidata is overigens de voorganger van WD en op enwiki reeds deprecated. Démarche Modi (overleg) 16 nov 2022 21:42 (CET)

Ja het is lastig uitleggen en ik weet ook niet hoeveel jij van programmeren afweet, maar even een snel simpel voorbeeld: je hebt bijvoorbeeld een object "auto", "auto.kleur" is bijvoorbeeld "blauw". "auto.stuur.kleur" bijv. "zwart". Maar als "auto.stuur" niet bestaat, geeft "auto.stuur.kleur" een error. Als ik zelf die waardes uit Wikidata haal, moet ik als het ware "auto.bla.blo.bli.blu.bly" doen en met mijn geringe kennis over Wikidata weet ik niet of dat wel zo betrouwbaar is (als .bla niet bestaat geeft het een error, hetzelfde voor .blo enz.). Maar ik ga zorgen dat er uitkom. Ondersteuning voor missende inwoneraantallen bijvoorbeeld is nu al goed verwerkt als het goed is.

Ja inderdaad, die kunnen we er altijd uithalen.

Je hebt gelijk, Wd geeft ook veel meer mogelijkheden. Ik heb daar handige functies in gevonden (in een regel een inwonertal voor een vreemde eend), maar het wil nog niet lukken die module te gebruiken in onze module ... Ik geef het nog een poging. Ennomien (overleg) 16 nov 2022 22:37 (CET)

Mijn kennis van programmeren is niet te vergelijken met die van jou. Zoals ik hier lees kan je met 'require' en 'callParserFunction' andere modules aanroepen. Maar dat is ook gelijk minder efficiënt. Je kan er natuurlijk ook voor kiezen om geen andere modules aan te roepen maar om de functies rechtstreeks op de wikibase te richten. Indien je dan een functie uit WD wil gebruiken is het een kwestie van good 'ol copy paste. Dat voorkomt spaghetti, maar je mist dan mogelijk verbeteringen. Wat betreft die errors, ik zou me daar geen zorgen om maken. Gebruik een goede situatie (dus altijd een Item > Property P1082 > Qualifier P585 en P459 en indien P459 == Q218005 dan P1082's ophalen met zelfde P585), en vang de fouten af. Mogelijk moet je daarvoor pcal gebruiken. Démarche Modi (overleg) 16 nov 2022 23:23 (CET)

Wauw, dat je dat zo snel even gevonden hebt! Copy-paste zou ik zonde vinden en dat kost heel veel ruimte, want die Wd-module is echt een ingewikkelde brei. Goede suggestie die je daar doet, met het kijken of die methode gelijk is aan een sommatie. Daar had ik niet over nagedacht. Maar of we nou die data ophalen of direct "proberen" de deelwaarde op te halen, is gok ik ongeveer even intensief. Dat was namelijk het eerste wat ik bedacht.

bericht gaat verder in stap 5

Voorkeurswaarde

Inhoud 

Volgens mij is de BAG een Nederlandse property, maar ik kan me vergissen en hoeven bovenliggende properties niet gewijzigd te worden. De property is er al, de qualifier velden zijn er, kwestie van invullen bij de plaatsen lijkt me en de constraints desnoods goed zetten (op de bag property en nergens anders) Démarche Modi (overleg) 20 jun 2022 19:08 (CEST)

Dat kan inderdaad sowieso. Dajasj (overleg) 20 jun 2022 19:12 (CEST)

De waarde die we willen gebruiken, wordt die aangemerkt als voorkeurswaarde of moet de module hier nog een rol in spelen? Ennomien (overleg) 7 nov 2022 18:19 (CET)

De voorkeurswaarde wordt standaard opgehaald (zie bijvoorbeeld Sjabloon:Inwonertal: Geeft nu 233.273 voor Groningen (Q892526), de waarde die als voorkeurswaarde vermeld staat.) Démarche Modi (overleg) 7 nov 2022 18:57 (CET)

Dat is niet mijn vraag. Ik wil weten óf de waarde die we willen gebruiken als voorkeurswaarde aangemerkt gaat worden (@Dajasj is er nu weer mee bezig) of dat de module moet zorgen dat de waarde die we willen gebruiken eruit gefilterd wordt. Ennomien (overleg) 7 nov 2022 19:34 (CET)

Ik denk dat het niet verstandig is om ons blind te staren op een aanduiding als 'voorkeurswaarde'. Deze kan in de loop der tijd veranderen (hoort bij de nieuwste waarde te staan, maar dat is niet altijd zo). Ik zou de module dus laten kijken naar de waarden die jij op dat moment zoekt. Bijvoorbeeld de waarden per 1 januari van het meest recente jaar waarvoor die beschikbaar zijn voor alle relevante onderdelen. Met vriendelijke groet, RonnieV (overleg) 7 nov 2022 21:12 (CET)

Dan had ik je niet goed begrepen. Démarche Modi (overleg) 7 nov 2022 23:34 (CET)

Oké helder, dan ga ik ergens komende tijd zorgen dat de module dat gaat doen.

@Démarche Modi maakt niet uit, kan gebeuren. Ennomien (overleg) 8 nov 2022 15:24 (CET)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘

Ik heb zonet voor het eerst na al die maanden weer eens de module doorgenomen, voor wie het vergeten zijn: Module:Gemeente in Nederland. Daarna dus gekeken hoe we zelf kunnen zorgen dat we waardes behorend bij goede datums kunnen kiezen. Het nu gebruikte sjabloon, Sjabloon:Inwonertal, ondersteunt niet het kiezen van een eigen datum. Ik kan dat sjabloon omzeilen en zeggen "pak de inwonertallen op 1 januari 2022, geef anders een lege waarde / streepje terug". Ongewenst, want veel lege cellen. Ik kan ook zeggen "pak overal het recentste inwonertal". Daar worden de tabellen ten eerste heel druk van (kans op veel verschillende datums) en ten tweede vind ik het geen nette oplossing. Ik denk dat het hierin het handigst is de tips van jullie te combineren: "Ik zou de module dus laten kijken naar de waarden die jij op dat moment zoekt." (@RonnieV), "... de complexiteit zo laag mogelijk [...] houden" (@Démarche Modi), "... een controlelijst in de gebruikersruimte ..." (@Démarche Modi) en "Ik zou hiervoor een trackingcategorie aanmaken ..." (@Wikiwerner). Waar ik aan denk is het wél blijven gebruiken van Sjabloon:Inwonertal (en dus de voorkeurswaarde), en om het simpel te houden de gemeenten waarin er een peildatum is die niet gelijk is aan de gewenste peildatum, te plaatsen in een beheercategorie. Dan kan er een soortgelijke categorie komen voor gemeenten die plaatsen bevatten waarvoor geen inwonertal gevonden is. (Zie hier:) dan zou de pagina Groningen (gemeente) in beide categorieën komen, omdat enerzijds (op het moment van schrijven) Harkstede en Lageland geen inwonertal hebben en anderzijds Groningen (stad) niet de juiste peildatum heeft (1 januari 2021 zou anno nu logisch zijn denk ik). Indien akkoord, houdt het de volgende wijzigingen in:

• Toevoegen aan Categorie:Sjabloon:Tabel woonplaatsen Nederlandse gemeente/Onjuiste peildatum wanneer de peildatum niet gelijk is aan de in Sjabloon:Tabel woonplaatsen Nederlandse gemeente meegegeven gewenste peildatum.
• Toevoegen aan Categorie:Sjabloon:Tabel woonplaatsen Nederlandse gemeente/Ontbrekend inwoneraantal wanneer Sjabloon:Inwonertal voor de kern geen inwonertal vindt.
• Een extra parameter wikidatalinks met als werkende waarde "ja" om, wanneer iemand de fouten uit de categorieën wil oplossen, toe te voegen aan het sjabloon en dan "Toon bewerking ter controle" te gebruiken.

Pas hierna wil ik bezig met het kopje "Vreemde eenden". Nog een vraagje: mogen die categorienamen of is het sowieso beter om "Sjabloon" te vervangen door "Wikipedia"? Ennomien (overleg) 10 nov 2022 14:05 (CET)

Volgens mij heb je er goed over nagedacht. Categorie:Wikipedia:etceteta. En {{Hiddencat}} in de brontext. Wat ik mis in jouw aanpak is de wijziging in Sjabloon:Infobox plaats in Nederland en eventueel andere infoboxen die ervoor zorgt dat de huidige artikelen tonen wat er nu is en dat de gewijzigde artikelen gegevens uit wd halen. Dus sturende parameter in infobox per cbs (bestaand), woonplaatscode (bestaand) of wikidata (nieuw). Démarche Modi (overleg) 10 nov 2022 17:18 (CET)

Dankjewel voor je reactie. Laten we inderdaad kiezen voor Categorie:Wikipedia: en niet Categorie:Sjabloon:, dat lijkt ongebruikelijk namelijk. Ik heb vanmiddag al offline een aanpassing voor de module geschreven, die zal ik alvast implementeren. Mochten er geen bezwaren komen, zal ik ook overgaan tot het aanmaken van de categorieën, zodat we daarna verder kunnen met de aanpak van "Vreemde eenden". Ik denk dat jij na al die maanden een beetje bent vergeten waar dit project precies over ging, het is opgestart om tabellen te maken zoals op Sjabloon:Tabel woonplaatsen Nederlandse gemeente. Later kunnen we het inderdaad makkelijk uitbreiden naar infoboxen, maar daar ben ikzelf nog niet mee bezig nu. ;) Ennomien (overleg) 10 nov 2022 18:13 (CET)

Ja... ik dacht inderdaad aan de infobox en niet aan de tabel. Démarche Modi (overleg) 10 nov 2022 19:13 (CET)

Dit onderdeel is nu afgerond met de aanmaak van de twee onderhoudscategorieën Categorie:Wikipedia:Tabel woonplaatsen Nederlandse gemeente/Onjuiste peildatum en Categorie:Wikipedia:Tabel woonplaatsen Nederlandse gemeente/Ontbrekend inwoneraantal. Iedereen bedankt voor zijn/haar input. Ennomien (overleg) 13 nov 2022 14:55 (CET)

Omgaan met afronding

Wikipedia:Wikidata-café#Afronding

Opgelost. Heeft geen invloed op de dataverwerking door de module en onderliggend sjabloon {{Inwonertal}}. Ennomien (overleg) 28 nov 2022 14:17 (CET)

Stap 5 (WP)

Proefversie module

Vervolg op "Vreemde eenden".
Nu het goede nieuws, ik kan met {{Wikidata}} de module ook gebruiken, maar dan met een sjabloon. Dat werkt veel makkelijker. De vreemde eenden zijn dan ook afgerond!!! (en ik ben vermoeid en nog een beetje gefrustreerd). Je zou de module nu volledig moeten kunnen gebruiken. Dan neem ik komende tijd de tijd voor kleine verbeteringen in sjabloon- en module-uitleg en -code. Ennomien (overleg) 16 nov 2022 23:39 (CET)

Moet ik nu nog iets doen? Anders neem ik ook even een break. Démarche Modi (overleg) 17 nov 2022 09:52 (CET)

Als je bedoelt het ondersteunen en helpen bij de module: nee, ik denk niet dat daar nog veel gaat gebeuren. Het zou daarentegen wel tof zijn dat ons werk ook gebruikt gaat worden, misschien kunnen we beginnen met 1 gemeente als "proef"? Ennomien (overleg) 17 nov 2022 14:50 (CET)

Mag ik Groningen (gemeente) / Groningen (Q892526) voorstellen? Deze is voorzien van de plaatsen in de gemeente. Daarna zouden we Purmerend (Q110423208) kunnen doen als tweede proef. Het kan eerst wel als proefpagina in het kladblok van mij. Démarche Modi (overleg) 17 nov 2022 16:20 (CET)

Zie diff #63302218 Démarche Modi (overleg) 17 nov 2022 16:24 (CET)

Ja, goed idee! Heb jij de data om aan te vullen zodat de tabel helemaal compleet is? Ennomien (overleg) 17 nov 2022 16:51 (CET)

Nee, maar het CBS wel. Démarche Modi (overleg) 17 nov 2022 16:59 (CET)

Of via de link die we al referentie gebruiken (zie hier. Dat werkt voor mij(n computer) alleen niet zo goed. Démarche Modi (overleg) 17 nov 2022 17:02 (CET)

Oh, maar dan moet ik eerst even uitzoeken hoe ik dat moet doen. Ik dacht dat jullie in eerste instantie van de data waren en ik me daar later bij aan zou sluiten. Ik wil eerst even de zaken hier volledig afronden eigenlijk. Ennomien (overleg) 17 nov 2022 18:25 (CET)

Heb net even gekeken naar de gegeven in Wikidata en die in de tabel. Kan jij de volgende vragen beantwoorden?

1. Waarom wordt Lageland nu wel getoond (met een vraagteken als resultaat) en Pannekoek niet?
2. Is de optelsom daadwerkelijk een optelsom van de plaatsen of is het de P1082 waarde van de gemeente? Is die tevens met elkaar vergeleken?
3. Is het niet mooier om 'Meld een fout' rechtsonder de tabel te plaatsen? Op de plek boven (links of midden) de naam van de tabel (bijvoorbeeld 'Inwonertallen Groningen per woonplaats') En eventueel li:nksonder de referenties. Zoals ook bij de tabel 'Historische ontwikkeling van het aantal inwoners'.
4. Wat is 'Overig'? Waar komt deze waarde vandaan? Of is dit een foefje om het totaal kloppend te maken?

Démarche Modi (overleg) 17 nov 2022 18:17 (CET)

1. Pannekoek? Waarom zou die er moeten staan? Autocorrectie?
2. De optelsom is van de gemeente van Wikidata, een handmatige optelling van de kernen + overig levert diezelfde optelsom.
3. Oh ja, ik kreeg het zo snel niet onder de tabel op een mooie manier (met weinig afstand tussen tekst en tabel), ik zal daar nog even aandacht aan besteden. Dan neem ik de titel en referenties ook mee.
4. Zie 2. Die maakt het dus kloppend.

Ennomien (overleg) 17 nov 2022 18:32 (CET)

Dit gesprek vervolgde zijn weg hier: 17 nov 2022 19:25 ("Totstandkoming inwoneraantallen").

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘

Is het een idee een proefversie te laten zien op bijv. Groningen (gemeente) en de gemeenschap te vragen wat ze ervan vinden in de Kroeg? Of vinden jullie dat het vraagstuk hieronder daarvoor eerst moet worden opgelost? Trouwens, vergeet je niet als deelnemer in te schrijven voor dit project op de pagina behorend bij deze OP, als je dat wilt. Mvg, Ennomien (overleg) 24 nov 2022 23:02 (CET)

Ja dat is een goed idee. We kunnen de gemeenschap zelf ook vragen hoe ze het zouden oplossen. Démarche Modi (overleg) 25 nov 2022 09:11 (CET)

Ik vind het een goed idee om de gemeenschap mee te nemen. Misschien moeten we wel duidelijk maken wat we onder een woonplaats verstaan, voordat we de vraag krijgen waarom Pannekoek en De Poffert (en anderen) niet in de lijst staan. RonnieV (overleg) 25 nov 2022 10:09 (CET)

Goeie punten. Het antwoord op die vraag is dat dat formeel gezien buurten/wijken zijn en geen woonplaatsen? Ennomien (overleg) 25 nov 2022 14:45 (CET)

Prima dat je de discussie goed rangschikt, mits we in de proefversie natuurlijk wel transparant zijn in wat er voor uitdagingen liggen. Dus laten we de voorbeelden iets uitbreiden. Bijvoorbeeld Westerveld, Utrecht, Waddinxveen, Rotterdam, Purmerend, Groningen en Aa en Hunze. En vervolgens per gemeente aangeven waar we tegenaan gelopen zijn in ons werk. Démarche Modi (overleg) 25 nov 2022 16:39 (CET)

Uiteraard moeten we transparant zijn. Alle, maar dan ook daadwerkelijk al het overleg dat on-wiki plaatsvond (een nietszeggend deel rond juni op Discord) is hier te vinden, dan wel op deze pagina dan wel onder #Ander overleg. De rangschikking was puur bedoeld om structuur te behouden, niet om tegenslagen maar naar onderen te verplaatsen. :) Je maakt het met je suggestie wel iets ingewikkelder, het werk is nog niet afgerond (jullie zijn druk aan het overleggen!) dus lijkt het mij beter om een werkend en kloppend voorbeeld te laten zien en ook te melden dat er nog problemen opgelost moeten worden m.b.t. de gegevens en daarvoor te verwijzen naar dit overleg. Met de mededeling dat iedereen natuurlijk welkom is te helpen. Ennomien (overleg) 25 nov 2022 18:42 (CET)

Ja, er is een hoop overleg geweest. Het probleem daarbij is dat men, tl;dr, al snel afhaakt. Een samenvatting is verstandig denk ik. Wat betreft de ontbrekende gegevens op Wikidata, dat kan voor een deel wel toegevoegd worden. De discutabele woonplaatsen moeten dan nog even wachten en daarmee is het ook duidelijk in de tabel. Wellicht is dat het gewenste resultaat (de module as-is), met een beknopte disclaimer die aangeeft dat de ontbrekende gegevens niet achterhaald kunnen worden en onder 'Overig' vallen. Démarche Modi (overleg) 25 nov 2022 19:07 (CET)

Ja een samenvatting, dat kan ik wel even doen. In principe werkt het nu voor de "simpele gemeentes" en zijn we (lees: jullie) druk bezig met de lastige jongens. Ennomien (overleg) 25 nov 2022 19:23 (CET)

Ondertussen zal ik proberen om een overzicht te maken van de voorgestelde gemeenten. Moet me dit weekend wel lukken vermoed ik. Démarche Modi (overleg) 25 nov 2022 19:28 (CET)

@Ennomien, @RonnieV, @Wikiwerner, zie Wikipedia:Wikiproject/WikidataOpWikipedia/Inwoneraantal/Voorbeelden voor een eerste opzet. Op- en aanmerkingen, verbeteringen, aanvullingen en hulp bij Wikidata invoer is wenselijk. Démarche Modi (overleg) 25 nov 2022 20:11 (CET)

Hoi @Démarche Modi, een mooi begin, maar nog veel werk aan de winkel.

Definities: Inwonertal hoeft niet per se van CBS te komen, dus dat zou ik niet zo in de definitie durven stellen.

Woonplaatsen zijn meestal niet 1-op-1 te koppelen aan een enkele CBS-entiteit, vaak is het een combinatie van een aantal wijken en/of buurten.

In een aantal gevallen valt de buurt volledig samen met de wijk.

Groningen zou wellicht een goed voorbeeld kunnen zijn, maar je laat Aa en Hunze zien.

Purmerend gaat fout: je combineert nu zaken van 2022 (indeling) en 2021 (bevolkingscijfers), dat is uiteraard niet wenselijk. De indeling zou zo veel mogelijk moeten aansluiten bij de meest actuele cijfers.

Rotterdam: het inwonertal per 1-1-2021 is op en-wiki gebaseerd en lijkt daar niet terug te vinden te zijn. Niet uitgezocht wie dat heeft ingevoerd. Kunnen we beter, met wat we hebben (maar ik op jouw verzoek nog niet naar Wikidata heb gebracht). Botlek, Europoort, Vondelingenplaat hebben ±0 inwoners, dat is beter dan al die vraagtekens. Ook de data uit 1830 zijn natuurlijk niet handig.

Waddinxveen: mooi, maar het inwonertal zou juist aan de woonplaats gekoppeld moeten zijn en niet via 'Overig' mogen verschijnen. Mogelijk moeten we in Wikidata een onderscheid maken tussen de gemeente en de plaats, zoals dat voor Purmerend wel gebeurd is.

Westerveld: wat mij betreft voorlopig de grootste hobbel. Misschien moeten we de gemeente benaderen, kijken of zij ons gegevens voor de 26 (in hun woorden) dorpen kunnen geven.

Met vriendelijke groet, RonnieV (overleg) 25 nov 2022 20:48 (CET)

Dat van Groningen had ik ook gezien. Ik heb zojuist het Q-nummer van de gemeente Groningen er neergezet. Aa en Hunze staat ook al verderop. Wikiwerner (overleg) 25 nov 2022 20:54 (CET)

Dank voor de terugkoppeling. Ik was al begonnen met Wikidata vandaar de verschillen in jaartal. Verkeerd Q nummer was een foutje, teveel AA en een beetje van Hun en Ze de laatste tijd denk ik... Ik gebruik de 2022 data, met de hand. Dus ik ga nu even iets anders doen. Later verder. Overige feedback pak ik dan op. Démarche Modi (overleg) 25 nov 2022 21:01 (CET)

Goede pagina! Als ik het goed begrijp is de data achter de pagina nog in aanbouw, zoals bijv. bij Waddinxveen het geval was en het goede voorbeeld van Rotterdam wordt vast ook nog aangevuld. Ik ga er morgen even mee bezig, o.a. een proefversie voor het "promotiepraatje". :p Voor RonnieV: zie hier voor Rotterdam. Ennomien (overleg) 25 nov 2022 21:42 (CET)

Als we eens goed naar de noten kijken, zien we meteen waarom het verstandig is om de cijfers zo veel mogelijk op precies dezelfde wijze aan te maken. Het maakt uit of je het CBS als organisatie kiest, of met de hand intikt, het maakt uit of je al dan niet de titel opgeeft. Wellicht kunnen we er beter voor kiezen om de bron aan te maken als zelfstandig Wikidata-item, om daar vervolgens consequent naar te verwijzen. Wel zo mooi als er straks een bron staat, waar een kleine 2500 keer naar verwezen wordt. (Vraag me af of de software daarmee uit de voeten kan, wordt het dan een verwijzing als ^cba? Met vriendelijke groet, RonnieV (overleg) 25 nov 2022 23:12 (CET)

@Démarche Modi: Welke data voer je in in Wikidata? Kan jouw script ook omgaan met wijken en buurten die niet geheel in één woonplaats liggen? Wikiwerner (overleg) 26 nov 2022 11:54 (CET)

Indien ik, nu na het aandachtiger lezen van jouw feedback @RonnieV, het goed begrijp dat zijn de meeste opmerkingen te relateren aan Wikidata. Dat wordt nog bijgewerkt. Zodra dat klaar is - voor zover mogelijk - dan geef ik een seintje. Opmerkingen, of beter nog, verbeteringen in de pagina zijn ook welkom, ik heb het slechts opgezet vanuit mijn beperkte visie. Wat we er eventueel nog bij zouden kunnen maken is een quasi stemming; waarbij we een aantal oplossingsrichtingen voorleggen en dat men daar uit kan kiezen. (Bijvoorbeeld; laten zoals het nu is, sjabloon dwingend niet te gebruiken in bepaalde gemeenten, sjabloon aanpassen zodat onmogelijk te koppelen inwoneraantallen anders behandeld worden (en daar dan 2 of 3 smaakjes voor)).

@Wikiwerner, ik gebruik de gegevens van het CBS die vermeld staan bij de definities. Zie de tabellen 85318NED voor de inwoneraantallen en 85210NED voor de woonplaatsen.

@Ennomien, zoals we nu in de tabel van Rotterdam zien zijn er echt woonplaatsen met 0 inwoners. Dit betreffen postcodegebieden in de Rotterdamse haven die een eigen BAG code hebben en woonplaats binnen de gemeente Rotterdam zijn.

@All, voor wat betreft de invoer van de gegevens. Zelf probeer ik dat zo consequent als mogelijk te doen. Daarbij is alleen de URL voor bron (P854) een vrij in te vullen waarde. De overige gegevens zijn allemaal ofwel een datum ofwel een Wikidata item. De situatie uit 2021 die we zien, waarbij er verschillende noten ontstaan die in principe hetzelfde zouden moeten zijn, is mogelijk te herleiden naar de verschillende invulsessies van bijvoorbeeld @Dajasj en @Wikiwerner. Wanneer we als voorbeeld naar Groningen (Wikiwerner) en Garmerwold (Dajasj) kijken, dan zien we dat er verschil zit tussen de attributen en properties die meegegeven worden. Door dat verschil wordt er uiteindelijke door de module een andere opbouw van de noot teruggegeven. Volgens mij is de oplossing eenvoudig, consequent dezelfde gegeven invoeren. Daarbij kies ik voor de wijze waarop Dajasj het nu doet (zonder title!). Zie bijvoorbeeld deze toevoeging. Overigens is dit alleen een probleem indien het in een gemeente niet hetzelfde is (zoals voor 2021 in Groningen). We gaan de tabel van verschillende gemeentes immers niet in de praktijk in hetzelfde artikel plaatsen. Althans, dat verwacht ik. Démarche Modi (overleg) 26 nov 2022 13:15 (CET)

@Démarche Modi: De 85318NED en 85210NED bevatten geen lijst van wijken buurten die (gedeeltelijk?) behoren tot een zekere woonplaats. Hoe heb je dan toch inwonertallen gevonden? Wikiwerner (overleg) 26 nov 2022 13:47 (CET)

@Wikiwerner: Tot nu toe heb ik alleen de inwonertallen van Rotterdam, Purmerend en Waddinxveen ingevoerd in Wikidata. Kijk maar even mee, zie jij daar vreemde eenden? Het is sowieso niet als dusdanig vastgelegd door het CBS, dit soort deelgebieden moeten we voor zover mij bekend zelf herkennen. Zoals bij Harkstede. Démarche Modi (overleg) 26 nov 2022 15:38 (CET)

@Démarche Modi: Bij Rotterdam vermeldt Allecijfers.nl: "De woonplaats Rotterdam valt niet precies samen met de gemeente en ook niet met 1 of meerdere wijk(en) of buurt(en). (...) De cijfers voor de woonplaats Rotterdam zijn bepaald door de gegevens voor deze buurten gewogen te combineren." We kunnen dus niet gehele wijken en/of buurten optellen. Daarom nogmaals de vraag: hoe heb je dan toch inwonertallen gevonden? Wikiwerner (overleg) 26 nov 2022 16:17 (CET)

Dit gesprek vervolgde zijn weg hier: 26 nov 2022 16:27 ("Omgaan met niet-overeenkomende grenzen"), hier.

@Démarche Modi als jouw ping naar mij als reactie op mijn bericht van 23 nov 2022 17:45 hieronder was, 0 inwoners kan ik prima begrijpen, maar een onbekend aantal inwoners van een woonplaats niet. Hoe dan ook, ik heb wat kleine wijzigingen gedaan aan de pagina dus wat mij betreft is die goed zo, nadat Wikidata aangevuld is. Als proefversie voor de tekst in de Kroeg (alfabetisch volgorde namen):

Hallo Kroeg,
@Dajasj, @Démarche Modi, @RonnieV, @Wikiwerner en ik zijn de afgelopen tijd druk bezig geweest met het Wikiproject "Inwoneraantal". We zijn bezig geweest met het aanmaken van op Wikidata gebaseerde tabellen met woonplaatsen in een Nederlandse gemeente, met als doel de overzichten met woonplaatsen, die tegenwoordig op allerlei manieren of niet aanwezig zijn, volledig te maken. Het systeem werkt nu voor de "simpele gemeentes". We zijn nu bezig met het oplossen van de laatste gevallen, het is namelijk minder eenvoudig dan het lijkt. Het CBS voorziet ons niet met een lijst woonplaatsen per gemeente en hun inwoneraantallen. Zie voor de simpele gemeentes en de uitdagingen deze pagina. Zie voor achtergrondinformatie onderaan die pagina, of vraag een van ons. Wij willen graag jullie mening vragen over dit project en jullie input over de volgende uitdagingen:
1. Aa en Hunze:
2. Westerveld:
3. Utrecht:
4. Rotterdam:
Mvg, Ennomien (overleg) 26 nov 2022 15:25 (CET)

Zou een van jullie de uitdagingen willen formuleren? Ik weet wat de problemen zijn, maar niet wat we precies willen vragen/voorleggen. Ennomien (overleg) 26 nov 2022 15:25 (CET)

Kunnen we dit doen zodra we de gegevens in Wikidata hebben geprobeerd in te voeren? Dan is het mogelijk goed duidelijk hoe we het willen formuleren. Démarche Modi (overleg) 26 nov 2022 15:40 (CET)

@Ennomien, wellicht moeten we Rotterdam ook toevoegen als uitdaging. Zojuist was ik in overleg met @Wikiwerner op deze pagina. Mogelijk komt er meer duidelijkheid dat ook die gemeente niet goed te splitsen is naar de woonplaatsen. Démarche Modi (overleg) 26 nov 2022 17:04 (CET)

Is goed, dan wachten we daar nog even mee. Ik las het, ik zal die toevoegen aan de opsomming zodat we die niet vergeten. Ennomien (overleg) 26 nov 2022 18:07 (CET)

Totstandkoming inwoneraantallen

Vervolg op 17 nov 2022 18:32 ("Proefversie module").

Inhoud 

Zie Pannekoek (Q2269094) die hangt onder Groningen, en er zijn wel meer voorbeelden die wel in Wikidata onder Groningen hangen maar niet in de tabel getoond worden. Overigens vind ik 'Overig' geen geschikte oplossing omdat het mogelijk ervoor zorgt dat men plaatsen over het hoofd ziet. Ook bestaat 'overig' niet, althans, bij een kloppend overzicht. Ik zou zelf eerder voor afrondingsverschil kiezen omdat de wijken en buurten op 5tallen afgerond worden terwijl gemeenten op hele mensen worden afgerond. De minimale waarde is dus minimaal totaal - (n * 2) en de maximale waarde is dus maximaal totaal + (n * 2) waarbij totaal de optelsom van de kernen is, n het aantal kernen en het resultaat de bandbreedte die aantoont waarbinnen de totaalwaarde van de gemeente hoort te liggen. Indien die daar niet ligt klopt er zekersteweten iets niet. Zoals nu het geval is. De mogelijke bandbreedte is namelijk 231220 - 231284 terwijl de waarde 233273 is. Wat me ook opvalt is dat er nogal een verschil zit tussen de indeling op Wikidata en die van het CBS. Zo zijn wijken soms gewoon wijken in een stad maar zijn wijken soms ook verzamelingen van verschillende dorpen. Op lager niveau (buurten) zien we dat dan wel weer terug, maar het is ontzettend onhandig. Het, door mij, kloppend maken van deze data is op dit moment geen optie. Excuses indien je daar op hoopte. Mocht ik daar in de toekomst toch aan toe komen dan ben ik van mening dat bovenstaande problemen (vooral de eerste, totaaloverzicht. Dus, waarom Lageland wel en Pannekoek en al die andere niet in de tabel?) eerst opgelost dienen te zijn. Démarche Modi (overleg) 17 nov 2022 19:25 (CET)

De kwestie Pannekoek is niet echt een "probleem", het is gewoon een kwestie van niet goed-ingevoerde data. Alle items met is een (P31) = woonplaats in Nederland (Q1852859) die in omvat plaats (P1383) van Groningen (Q892526) staan, komen in de tabel. Pannekoek (Q2269094) heeft niet die P31-waarde, vandaar de fout. Ik zal zorgen dat dit soort zaken beschreven worden in de documentatie.

Inderdaad, uiteraard zou overig zo klein mogelijk moeten zijn en klopt er dus nu iets niet. Het was de suggestie van @RonnieV en ik was en ben het daarmee eens. We moeten op een manier duidelijk maken dat er een verschil zit. Ik kan het lastig hernoemen naar "Afrondingsverschil", dat dekt de lading zeker niet in dit stadium. Dan moet ik er zelf maar mee aan de slag gaan. Ennomien (overleg) 17 nov 2022 20:01 (CET)

Nee, dat verwoord je verkeerd. Tenminste, indien ik het nu goed begrijp. De tabel accepteert alleen plaatsen en geen buurtschappen, gehuchten en dergelijke. Pannekoek is een buurtschap, net als Poffert. En er was nog zo'n naam in dat hoekje. Het correcte antwoord had moeten zijn dat Pannekoek niet in de tabel thuis hoort. Dus, het aantal locaties van P1383 kan meer omvatten dan het aantal plaatsen in de uiteindelijke tabel.

Desalniettemin blijft er een uitdaging liggen met betrekking tot de CBS data en de invulling van de plaatsen. Om het project te laten slagen is niet alleen een goed werkende module nodig maar ook zeker een goed werkbare data aanpak. Het is belangrijk dat daar eerst een goede keuze in gemaakt wordt. De proef zou dan ook het beste resultaat moeten opleveren, dus de data goed in Wikidata en de tabel zoals de werkelijkheid is. Anders dan groeit dat probleem en zal je dit stadium (met Overig als opvulling) moeilijk of misschien zelfs niet achter je kunnen laten. Een gemeente bestaat uit een aantal plaatsen en de som is binnen de marge kloppend. Indien je volhardt dat Overig acceptabel is dan accepteer je ook dat er plaatsen ontbreken in de tabel en de gegevens simpelweg niet kloppen. Gegeven de bron van het CBS die we beschikbaar hebben lijkt me dat onacceptabel voor de encyclopedie.

Nu heb ik niet alle historie paraat, maar ik meen me te herinneren dat Dajasj voorstander is van de BAG indeling. Deze zou 1-op-1 gekoppeld kunnen worden met de CBS codering. Wellicht is dat de beste aanpak. Dat betekent dan mogelijk dat 'vreemde eenden' niet meer bestaan. Harkstede en Harkstede GN zijn dan twee verschillende entiteiten. Dan kan tevens de structuur van het CBS (Gemeente - Wijk - Buurt) gevolgd worden en de tabel uitgebreid met soort (Wijk, cluster Dorpen, Dorp, etc.). Het voordeel daarvan is dan dat de data structuur overeenkomt met de bronnen van BAG en CBS. Indien we dat namelijk niet zouden doen, en we voor Harkstede bijvoorbeeld twee waarden optellen, dan kan dat beschouwd worden als eigen origineel onderzoek. Want waarom zouden we bijvoorbeeld Lageland niet tot Harkstede rekenen of Scharmer of Woudbloem? Wat ook nog overwogen kan worden is om het totaal (en dus ook Overige) buiten beschouwing te laten en eventueel een opmerking toe te voegen dat buitengebieden buiten beschouwing gelaten zijn. Dan kunnen we ons preciezer richten op dorpjes zonder ons druk te maken over precieze indelingen van gemeenten. Tot slot, dat we een dergelijke detaillering misschien beter buiten de encyclopedie kunnen houden. Wellicht is dat zelfs beter, want wat zeggen actuele inwonertallen nu echt over een dorp(je) of gemeente? Interessanter voor de encyclopedie is historisch verloop (wat ook op basis van Wikidata kan). Démarche Modi (overleg) 17 nov 2022 22:33 (CET)

Oké, ik dacht dat alle nederzettingen gewoon woonplaats in Nederland (Q1852859) hadden. Welke Q-waarden moeten nog meer meegerekend worden om het compleet te maken?

Je had met al deze punten van aandacht veel eerder kunnen komen. Waarom moet dat nu als het werk aan "mijn" kant zo goed als af is? "Het is belangrijk dat daar eerst een goede keuze in gemaakt wordt." Dat had toch allang kunnen gebeuren en in mijn beleving hebben we hierboven over alles uitgebreid overlegd en was dat dus allang gebeurd. Waarom hebben we vorige week besloten de vreemde eenden op deze manier aan te pakken, maar praat je nu opeens over twee entiteiten? Dat idee was hier allang geopperd. En nee, er moet geen hele tabel komen met de wijken, buurten etc. Dit (deel)project gaat om een overzicht van de woonplaatsen in een gemeente, al kunnen we altijd voortbouwen op de data die we hebben en meer overzichten / aan Wikidata gekoppelde inwoneraantallen tonen.

Ik weet oprecht niet wat ik met je reactie aan moet. Ik ben niet in staat de ideeën die je oppert uit te voeren, om meerdere redenen, ook al geloof ik dat het goede ideeën zijn. Ik wil best uitgewerkte ideeën implementeren, maar mijn bordje wordt te vol als ik die ideeën eerst nog zelf grotendeels moet uitwerken. Als wat er nu staat goed werkt wil ik dat eerst afronden.

Wat ik wel ga doen is jouw antwoord op mijn vraag bovenin afwachten en daaropvolgend kijken wat er kan gebeuren met "Overig", kijken of ik dat tot 0 kan laten naderen. En de peildatum bij vreemde eenden moet nog even goed opgehaald worden uit Wikidata. Ook moet ik de documentatie nog afronden. Daarna ga ik, in de hoop dat alles ondanks de bezwaren hierboven wél werkt, de module proefdraaien en ervan "genieten". Ennomien (overleg) 17 nov 2022 23:56 (CET)

Ooh, het is geenszins mijn intentie jouw werk te ondermijnen. Sorry indien ik doordraafde. Nu ik meedenk en naar de situatie kijk komen er allerlei vragen in me omhoog en het is heel goed mogelijk dat die reeds behandeld zijn. Mijn geheugen is niet zo goed en mijn gebrek aan takt zorgt er wel vaker voor dat ik onprettige vragen of suggesties voordraag. Dat doe ik echter alleen maar om te helpen en er voor te zorgen dat we niet de verkeerde kant opgaan. De data is nog wel een dingetje en ik maak me daar oprecht zorgen over, zonder de uitdaging goed te overzien. Wat betreft de vraag over de 'Q-Waarden', oftewel welke type plaatsen, denk ik dat woonplaats in Nederland (Q1852859) voldoende zou moeten zijn. Dat zeg ik zonder de brij aan data goed te kennen. Maar mochten we besluiten een type erbij te plaatsen, dan volstaat denk ik een extra if is_instance in die ene for loop. Mijn inschatting is dat het niet nodig zal zijn. Démarche Modi (overleg) 18 nov 2022 00:18 (CET)

@Démarche Modi, 17 nov 2022 22:33 - Bij de gemeente Groningen ontbreekt alleen voor Lageland het inwonertal in Wikidata. Voor mijn gemeente Apeldoorn ontbreken er veel meer (met {{Tabel woonplaatsen Nederlandse gemeente|wikidataid=Q101918}}, dus deze kan er inmiddels anders uitzien):

Woonplaatsen in de gemeente Apeldoorn

Woonplaats	Inwoneraantal	Peildatum
Apeldoorn	138945 138.945	1 januari 2021
Beekbergen	0 ?	1 januari
Beemte Broekland	0 ?	1 januari
Hoenderloo	0 ?	1 januari
Hoog Soeren	0 ?	1 januari
Klarenbeek	0 ?	1 januari
Lieren	0 ?	1 januari
Loenen	1077 1.077	1 januari 1815
Radio Kootwijk	0 ?	1 januari
Uddel	0 ?	1 januari
Ugchelen	0 ?	1 januari
Wenum-Wiesel	0 ?	1 januari
Overig	24759 24.759
Totaal:	164781 164.781	1 januari 2021

Ik vrees dat dit slechts één voorbeeld is. We hebben de gegevens van 2021 beschikbaar in het sjabloon:Statistiek woonplaats Nederland inwoners. Kunnen we deze met een bot invoeren in Wikidata? (Ik heb zelf wel en botaccount hier, maar geen botrechten op Wikidata, en geen ervaring met het scripten op Wikidata.) Wikiwerner (overleg) 18 nov 2022 21:38 (CET)

Alleen Groningen en Purmerend zijn - voor zover ik weet - zo goed als mogelijk gevuld. Kennelijk nog met missende puntjes op de spreekwoordelijke i-tjes. Uiteraard lijkt het me technisch mogelijk om data vanuit Wikipedia naar Wikidata over te hevelen. Echter, ik twijfel of dat de juiste aanpak is. De inwonertallen kunnen volgens mij beter rechtstreeks vanuit de CBS bron gehaald worden en het zou mooi zijn indien dat proces geautomatiseerd plaats kan vinden. Dat maakt het voor volgend jaar eenvoudiger.

Wat overigens eerst aandacht vergt, als je het mij zou vragen, is hoe de inrichting van de gemeente precies vastgesteld zou moeten worden. Welke plaatsen zijn 'woonplaatsen in Nederland', en welke niet. Wat hoort er eventueel bij de woonplaats (i.e. 'e.o.', oftewel 'en omstreken')? Een onderwerp waar ik de afgelopen dagen even naar gekeken heb en waar ik nog geen pasklaar antwoord op heb. Enerzijds ben ik er voorstander van om de bron(logica) te volgen, anderzijds kennen veel (kleine) woonplaatsen een historie en dient dat in de encyclopedie tot recht te komen. Wellicht ligt het beste antwoord in het midden en zal er een uitputtende mapping tussen de data en de items/artikelen plaats gaan vinden.

Wat betreft een bot op Wikidata, het korte antwoord is: ja, dat kan. Daarvoor dient wel eerst een procedure doorlopen te worden. Eerst een werkende bot op test.wikidata.org laten functioneren (tenminste, dat zou ik doen en vergewis je ervan dat het datamodel daar wezenlijk anders is (tranen met tuiten) maar toch doen om de bot in basis (voornamelijk schakelen met authenticatie) goed te laten functioneren), daarna een botaanvraag indienen en een testrun op Wikidata uitvoeren. Zoals ik hierboven aangaf, denk ik dat het verstandiger is om vanuit een gezaghebbende bron te werken en niet vanuit een Wikipedia bron. (ondanks dat die te herleiden is naar een geschikte bron) Hoe het verder precies in z'n werk gaat binnen de Wikidata gemeenschap indien een bot, die reeds botrechten heeft, nieuwe functies (i.e. uploads) gaat uitvoeren, dat weet ik niet.

Wellicht is de gemeente Apeldoorn een leuk casus voor jou, indien je je daartoe geroepen voelt. Vragen die ik me daarbij zou stellen zijn: Welke items te verwachten in Wikidata? Welke properties van die items dienen gevuld te worden? Welke qualifiers horen daar altijd bij? Waar haal ik de data vandaan? Die laatste drie vragen kan ik zo voor je beantwoorden, de eerste vergt denk ik even wat uitzoekwerk. Dat geeft dan voor de bot een geschikte controle voor aanvang; klopt het dat alle items beschikbaar zijn? Die eerste vraag, of het antwoord erop, de basis aan items goed hebben staan, impliceert hoogstwaarschijnlijk handwerk omdat de 1-op-1 mapping vanuit CBS of BAG vermoedelijk geen gewenste optie zal zijn. (dus uiteindelijk 345-ish x aantal plaatsen)

Zelf zou ik ook wel weer met een bot aan de slag willen gaan. Eerder heb ik een beetje gespeeld vanaf mijn computer met pywikibot.py ofzo. M'n computer trok het alleen niet helemaal (oud beestje) en hij is me te dierbaar om over de toeren te draaien. Misschien pakte ik het ook te grootschalig aan met grote pandas dataframes enzo... daarnaast kamp ik met wat persoonlijke uitdagingen, waardoor ik er nu voor kies om niet te ver de diepte in te gaan. Maar mocht ik beide uitdagingen het hoofd kunnen bieden in de toekomst, dan kom ik graag helpen. Démarche Modi (overleg) 18 nov 2022 22:32 (CET)

Hoi allen,

Ik zit even te kijken naar de informatie die we nu hebben:

1. Een Wikidata waarin 2466 woonplaats in Nederland (Q1852859) te vinden zijn;
2. Een Wikidata waarin 2509 plaatsen met BAG-identificatiecode voor woonplaats (P981) te vinden zijn (of beter: 2505 met en 4 zonder);
3. 44 BAG-codes die niet onderkend worden;
4. Een lijstje BAG-codes die niet onderkend worden;
5. Een array waarin 2465 BAG-codes ondergebracht zijn;
6. Een nog niet onderzocht aantal buurten en wijken die niet gekoppeld zijn aan een BAG-code (in onze array).

Met wat we wel hebben, kan ik vrij eenvoudig een lijst maken met de gemeenten, de daaronder vallende BAG-eenheden (soms plaats, soms wijk, soms buurt) en de inwonertallen daarvan per 1 januari 2021. Helaas, Pannekoek (Groningen) en De Poffert komen daar niet als zelfstandige eenheid in voor, zij zijn geen woonplaats met een BAG-code, maar een buurt of gehucht dat ergens onder valt.

Aan de eenheden met een eigen (unieke!) BAG-code kan, zo het niet op WD staat, een inwonertal per 1 januari 2021 worden toegevoegd (natuurlijk met bron etc.). Daarmee zou het aantal personen aardig gelijk moeten lopen, mits we ook het gemeentelijk inwonertal per diezelfde datam hanteren.

Groningen (Q749) heeft BAG-code 1070.

1070 levert de gwb_code_8 verzameling (001400,001401,001402,001403,001404,001405,001406,001407,001408,001409,001410,001411,001412,001413) op

CBS levert voor die (in dit geval allemaal wijken) als totaal inwonertal 202.905 op.

Apeldoorn (Q3018561) heeft BAG-code 3560.

3560 levert de gwb_code verzameling (020001,020002,02000303,02000304,02000305,02000307,02000308,02000309,02000310,02000311,020004,020005,020006,020007,020008,02001101,02001601) op (deels wijken, deels buurten).

Dit levert voor Apeldoorn 138.960 inwoners op. (15 meer dan WD)

Beekbergen (2258) (CBS: Wijk- Beekbergen en omgeving) levert via 020014 4935 inwoners op.

Beemte-Broekland (CBS: Buurten 'Beemte' en 'Agrarisch gebied Beemte Broekland') levert via 02001702 en 02001706 1040 inwoners op.

Loenen (2251) (CBS: Wijk - Loenen en omgeving) levert via 020013 3380 inwoners op.

Hoenderloo is meteen een van de uitdagingen: 2257 en 2272, deels Apeldoorn, deels Ede. Maar de CBS-buurten Hoenderloo, Bosgebied Hoenderloo en Miggelenberg zijn goed voor 1390 inwoners.

Hoog Soeren (3564) CBS-buurten Hoog Soeren en Bosgebied Hoog Soeren komen op 240 inwoners.

Klarenbeek sluit aan bij Hoenderloo (2248 en 2606 (Voorst)): voor het Apeldoornse deel (Klarenbeek, De Hooilanden en De Hooilanden-Oosterhuizen) staan 1750 inwoners genoteerd.

Lieren (2250) komt op 1220 inwoners.

Radio Kootwijk (3563) komt op 95 inwoners.

Uddel (3562) komt op 3335 inwoners.

Ugchelen (2256) telt er 6275.

Wenum-Wiesel (3561) telt er 2170.

Totaal: 164790

9 meer dan in de tabel van @Wikiwerner, en dat durf ik wel als afrondingsverschillen aan te duiden. Een tabel die niet optelt, komt op mij niet als zorgvuldig over. Is straks overal het verschil beperkt tot zeg maximaal 20 personen, dan zou ik me kunnen vinden in het vervangen van 'Overig' door 'Afronding'. Misschien kan @Ennomien dat conditioneel instellen?

De Groningse buurt Lageland komt op 80 inwoners, voor het Midden-Groningse deel staan er 160 te wachten.

Met vriendelijke groeten, RonnieV (overleg) 19 nov 2022 01:16 (CET)

@RonnieV, jouw bijdrage komt op mij een beetje chaotisch over. Indien ik het allemaal goed begrepen heb;

- BAG codes die 'niet onderkend' zijn; dit kunnen items zijn inclusief een geldige BAG. Het eerste resultaat van Weesp toont dit aan (BAG = 3631)

- Die array (van ons) lijkt me een handige controlelijst, echter dat lijkt me geen valide bron. Er kunnen immers fouten in geslopen zijn.

- De twee queries die je gedraaid hebt op Wikidata, de eerste heeft minder resultaten dan de tweede terwijl je in de tweede een optionele waarde toevoegt (BAG) (je wil kennelijk per item de waarde van bag erbij zien). Deze tweede query geeft meer resultaten dan de eerste. Mijn eerste indruk is dat er dan iets niet goed gaat. Hoe zit dat precies?

Verder laat ik jouw bijdrage even voor wat het is. Wel wil ik iedereen waarschuwen dat je beter geen data kan toevoegen indien het mogelijk nog niet klopt dan dat je om een doel te bereiken snel data gaat toevoegen. Je kan beter zorgen voor een goed (repeteerbaar) systeem dan systeemloos een doel nastreven en uiteindelijk naast schieten. (absoluut geen knipoog naar voetbal) Tevens ben ik van mening dat 'het systeem', hoe dat dan ook precies zal werken, (zelf)controlerend zou moeten zijn zodat er zonder twijfel antwoord gegeven kan worden op de vraag hoe de data precies staat en tot stand gekomen is (en dus klopt). Zo lang dat niet kan is het te risicovol om aan duizenden items te gaan werken. Zoals je nu te werk gaat is het te risicovol dat je voortborduurt op andermans fouten. Démarche Modi (overleg) 19 nov 2022 09:47 (CET)

Met Weesp is het heel simpel: Weesp heeft 2 BAG-identificatiecodes voor woonplaats: eentje tot 2016 en eentje sinds 2016. Ik heb de laatste zojuist als 'preferred' gezet.

Het optellen van gwb_codes, zoals RonnieV doet, is toch precies wat het sjabloon:Statistiek woonplaats Nederland inwoners doet? Die inwonertallen staan nu overal in de infoboxen. Het CBS rondt de inwonertallen van wijken af op vijftallen vanwege privacy; dat verklaart de verschillen tussen de gemeente als geheel en de som van de woonplaatsen. Wikiwerner (overleg) 19 nov 2022 11:53 (CET)

Vermoedelijk is het korte antwoord: 'Ja'. Via wat omzwervingen kan in de infobox gebruik gemaakt worden van 'CBS' en dan wordt die lijst gebruikt, of er wordt gebruik gemaakt van 'woonplaatscode' en dan wordt uiteindelijk Module:Array Nederland kerngebieden inwonertallen 2021 gebruikt. (als ik dit goed herinner, het is al met al een tamelijk gedetailleerde oplossing) Plus, indien Wikidata de databron wordt komt er (hopelijk tijdelijk) een derde sturingsparameter bij, naast 'woonplaatscode' en 'cbs' zoiets als 'wikidata'. Ps. ik zal een poging wagen om die BAG-CBS mapping beter te gaan begrijpen. Démarche Modi (overleg) 19 nov 2022 13:43 (CET)

Dank jullie wel voor jullie bijdragen.

@Démarche Modi, dan laat ik "woonplaats in Nederland" nu als enige instance, ook omdat volgens RonnieV de module nu juist het totaalbeeld geeft en het toevoegen van Pannekoek gaat zorgen voor dubbele tellingen ("Helaas, Pannekoek ..."). Ik was eergisteren een beetje klaar met de module en blij dat alles af was, de feedback kwam dan ook niet goed aan. Zie onderaan dit bericht.

@Wikiwerner, het klopt inderdaad dat nog lang niet alle data beschikbaar is, dat was namelijk de volgende stap. ;)

@RonnieV: "Hoenderloo is meteen een van de uitdagingen", met de huidige (en misschien tijdelijke) manier van werken inmiddels niet meer, dat is opgelost. Ik ga later vandaag verder met de moduledocumentatie dus dan verwijs ik je graag daarnaar voor toelichting, maar jij bent ook wel in staat de module zelf (incl. comments) te lezen dacht ik. Over dat "conditioneel instellen", ja dat kan ik wel toevoegen. Misschien omdat er altijd maximaal 2 naast gezeten kan worden, lijkt me aantal plaatsen * 2 dan netter.

Ik merk dat het overleg een beetje versnippert en door elkaar heengaat voor mijn gevoel, misschien moeten we bij het begin beginnen (1): is de huidige manier van werken daadwerkelijk verkeerd en niet kloppend/volledig of moeten we overstappen op iets met BAG en CBS?

RonnieV liet 19 nov 2022 01:16 zien dat de huidige manier werkt bij de gemeente Apeldoorn. Voordat we de hele structuur gaan veranderen, waar ik open voor sta, wil ik graag een concreet voorbeeld zien van waar dat fout gaat. Bijvraag (2): mag ik zeggen dat de huidige manier gewenster is dan met BAG/CBS, of zijn er mensen die vinden dat die optie hoe dan ook bekeken moet worden? Een (korte) reactie zal ik zeer op prijs stellen, dan hebben we weer even een gezamenlijk startpunt, anders kunnen we met z'n vieren wel lange berichten blijven typen maar dan verlies ik de weg naar de oplossing uit het oog. Ennomien (overleg) 19 nov 2022 14:22 (CET)

De huidige manier is toch met BAG/CBS, zoals ik aangaf op 19 nov 2022 11:53? Die inwonertallen moeten we alleen nog in Wikidata zetten. Dan krijgt Loenen gelijk een recenter inwonertal dan uit 1815. Dat maakt niks uit voor de bouw van de module. Wikiwerner (overleg) 19 nov 2022 15:06 (CET)

Aanvulling: ik heb zojuist op Wikidata de stad Groningen een inwonertal gegeven van 2021 en Lageland ingevuld. Kijk nu nog eens op de kladpagina van Démarche Modi: slechts 7 inwoners (negatief, dat dan weer wel) verschil! Wikiwerner (overleg) 19 nov 2022 18:01 (CET)

@Ennomien, wat Wikiwerner schrijft wou ik ook (ongeveer zo) schrijven. Wat ik overigens onderaan het bericht moet duiden als 'kwam dan ook niet goed aan' ontgaat me een beetje. Ik mag toch hopen dat we hier op een constructieve wijze kunnen samenwerken waarbij kritische vragen gesteld kunnen worden? Er is ook niks mis mee dat iemand (waaronder ik zelf) soms de boel de boel laat om wat voor reden dan ook. Echter, quasi persoonlijk terugkaatsen alsof er onbehoorlijk gedrag is, terwijl het (slechts) kritische vragen en opmerkingen zijn, vind ik eerlijk gezegd niet collegiaal. Jouw bijdragen en jouw snelle manier van het aanleren van Lua worden echt wel gewaardeerd. Ook dat je mij benaderd hebt om te helpen waardeer ik, ik hoop dan ook dat je mijn bijdrage kan waarderen zonder het je persoonlijk aan te trekken. Het startpunt is er (we willen op het niveau onder/binnen de gemeente per woonplaats inwonertallen registreren en tonen), de weg ernaartoe dient alleen zorgvuldig bewandeld te worden zodat we volgend jaar en de jaren daarna nog steeds een goed werkbare situatie hebben. Echter, dat is hoogstwaarschijnlijk louter data gerelateerd. Je zou dus kunnen stellen dat de module voor nu klaar is en dat jouw werk als modulebouwer afgerond is en mocht het tzt nodig zijn om de code aan te passen, dan volgt dat vanzelf. Dit is immers Wikipedia. Démarche Modi (overleg) 19 nov 2022 15:25 (CET)

@Wikiwerner: ik zie dat ik, ondanks mijn zorgvuldigheid, de vraag niet goed doordacht had. Je hebt volkomen gelijk, maar ik verwoordde m'n vragen verkeerd. Ik zal nog een poging doen. Bedankt voor het completeren van Groningen, de uitkomst is goed om te zien!

@Démarche Modi: je hebt helemaal gelijk. Jouw feedback is, en was eergisteren ook, scherp en terecht, maar ik kon die eergisteren even niet hebben. Uiteraard waardeer ik de samenwerking en jouw kritiek (het moet inderdaad goed werkbaar worden). Nu kijk ik met een positieve blik naar jouw feedback en daarom stuurde ik aan de hand daarvan de twee slecht geformuleerde vragen. Ik zal ze opnieuw stellen:

1. Is hoe het hier ontwikkelde systeem (Wikidata + module) nu werkt daadwerkelijk verkeerd en niet kloppend/volledig en moeten we overstappen op een alternatieve manier (2e alinea 17 nov 2022 22:33)? (Apeldoorn (correctie=-9) en Groningen (correctie=-7) laten dat niet zien.)
2. Mag ik zeggen dat hoe Wikidata en module nu samenwerken gewenster is dan de alternatieve manier, of zijn er mensen die vinden dat die optie hoe dan ook bekeken moet worden?

Afhankelijk van jullie antwoorden kunnen we of (1) het achterliggende datasysteem laten zoals het nu is, (2) kijken hoe het uitpakt als we met wijken/buurten e.d. gaan werken en/of (3) daadwerkelijk overstappen op die door DM voorgestelde methode. Mvg, Ennomien (overleg) 19 nov 2022 19:30 (CET)

(edit:) als abs(overig) <= aantal_kernen * 2 dan heet de tabelrij "Afrondingsfout". Misschien een extra of bestaande categorie toevoegen voor pagina's waar "Overig" te groot is? Ennomien (overleg) 19 nov 2022 19:52 (CET)

@1: Het systeem van Wikidata + module werkt correct, zoals te zien is op de kladpagina van Démarche Modi. Zelfs Lageland, dat in 2 gemeenten ligt, gaat goed: van de 240 inwoners komen alleen de 80 inwoners in de gemeente Groningen in de tabel, de 160 in Midden-Groningen terecht niet.

@2: De cijfers in Wikidata van het jaar 2021 zijn identiek aan de cijfers in onze infoboxen. De laatste zijn verkregen door het optellen van wijken en buurten, via het sjabloon:Statistiek woonplaats Nederland inwoners. Het verschil is hooguit dat ons sjabloon en de arrays daarachter tot nu toe jaarlijks bijgewerkt zijn. Met Wikidata moeten we dat maar afwachten, tenzij er iemand botrechten heeft/krijgt aldaar om jaarlijks de cijfers van het nieuwe jaar toe te voegen. Wikiwerner (overleg) 19 nov 2022 20:19 (CET)

Dat laatste lijkt me een goed idee! Wat betreft 'mijn alternatieve manier', dat gaat louter over de totstandkoming van de data op Wikidata en impliceert niet dat de module herzien moet worden. Behoudens de suggesties die ik eerder heb genoemd (error handling, zie https://www.lua.org/pil/8.4.html en het automatisch toevoegen aan een categorie indien fouten optreden - voor zover niet aanwezig, ik heb de code niet opnieuw bekeken), die bedoeld zijn om overzicht te verkrijgen in wat er dadelijk - eventueel - niet goed gaat, heb ik voornamelijk zorgen over de totstandkoming van de data. Daarmee bedoel ik hoe de duizenden items op Wikidata staan en aangevuld gaan worden. Démarche Modi (overleg) 19 nov 2022 20:31 (CET)

Lees dan eens de documtatie bij het statistieksjabloon, dat we ook gebruiken in de {{Infobox plaats in Nederland}}: die getallen kunnen een op een naar Wikidata. Wikiwerner (overleg) 19 nov 2022 21:44 (CET)

Bedoel je Sjabloon:Statistiek kerngebieden Nederland inwoners 2021 of Sjabloon:Statistiek woonplaats Nederland inwoners? Hoe dan ook, beide zijn niet de juiste bron (in mijn optiek) voor Wikidata. (dat zou zoiets zijn als de slager die z'n eigen vlees keurt) Coderingen wijzigen, indelingen kunnen veranderen, etc. Dergelijke lijsten zijn hooguit handig om te controleren of 2021 conform verwachting is. Om het proces van datavulling herhaalbaar te maken is het noodzakelijk om vanuit de (externe en gezaghebbende) bron te werken. De huidige lijsten zijn immers ook zo tot stand gekomen. Démarche Modi (overleg) 19 nov 2022 22:05 (CET)

Ik bedoel beide sjablonen: de tweede maakt gebruik van de eerste en van het sjabloon:Array Nederland woonplaatsen kerngebieden 2021. De tweede wordt normaliter jaarlijks aangepast zodat die verwijst naar de sjablonen van het nieuwe jaar. Uiteraard moet je die niet door elkaar gebruiken. Gek genoeg bestaat het sjabloon:Statistiek kerngebieden Nederland inwoners 2022 nog niet, maar het sjabloon:Array Nederland woonplaatsen kerngebieden 2022 al wel. Wikiwerner (overleg) 20 nov 2022 10:06 (CET)

Volgens mij wordt door deze regel (inwoners = {{#if:{{{woonplaatscode|}}}|{{#ifeq:{{Statistiek woonplaats Nederland inwoners|{{{woonplaatscode}}}}}|onbekend||{{Statistiek woonplaats Nederland inwoners|{{{woonplaatscode}}}}}{{Statistiek woonplaats Nederland inwoners|TXT=Ref}}|}}|{{#if:{{{cbs|}}}|{{Statistiek kerngebieden Nederland inwoners|{{{cbs|}}}{{Statistiek kerngebieden Nederland inwoners|TXT=Ref}}}}|{{{inwoners|}}}}}}} in Sjabloon:Infobox plaats in Nederland gebruik gemaakt van beide, naast elkaar. Afhankelijk van de gebruikte parameter 'woonplaatscode' of 'cbs'. De ene komt uit in de module Module:Array Nederland kerngebieden inwonertallen 2021 en de andere in het sjabloon Sjabloon:Array Nederland woonplaatsen kerngebieden 2021. Démarche Modi (overleg) 20 nov 2022 12:30 (CET)

Die laatste 2 moeten dus altijd van hetzelfde jaar zijn. Wikiwerner (overleg) 20 nov 2022 12:38 (CET)

Aha, het kwam op mij over alsof die nieuwe manier voor totstandkoming van de data een grote verandering zou zijn, dat er Wikidata-items werden gemaakt van iedere buurt en wijk etc., maar dat heb ik dan verkeerd aangenomen. Als ik het goed begrijp is momenteel de enige vraag die rest op welke manier we die inwoneraantallen bepalen, overgenomen vanuit de arrays hier, rechtstreeks vanuit de primaire bron of door het optellen van wijken/buurten (dan kan de structuur van het CBS gevolgd worden, als ik het goed begrijp). Daarin laat ik me graag adviseren, want jullie zitten beter in die stof merk ik al. ;)

Jouw twee punten van error handling en beheercategorieën zijn eigenlijk al toegepast, wanneer ik morgen (heb het helaas moeten uitstellen) verderga met de documentatie zal ik dat daar ook in verwerken, o.a. iets met een categorie voor te grote aantallen "Overig". Betreft error handling; tijdens het coderen probeer ik al fouten te bedenken en te coveren. Zo'n functie waarnaar jij linkt zou ik kunnen toevoegen, maar ik ben meer voorstander van gewoon de fout oplossen i.p.v. zulke functies te gebruiken. Wat nuttig zou zijn is alles in zo'n error-functie zetten en indien er dan toch een error voorkomt, de gebruiker in een bericht verwijzen naar deze pagina i.p.v. dat hij/zij een Lua-foutmelding te zien krijgt. Ik zet dat op het lijstje. Ennomien (overleg) 19 nov 2022 22:24 (CET)

Nou ja, als het goed gaat dan geeft pcall je geen reden om nieuwe errors af te handelen. Je schrijft overigens Daarin laat ik me graag adviseren, wat verwacht je precies aan advies (wat niet al gegeven is)? Démarche Modi (overleg) 19 nov 2022 23:01 (CET)

Nee, maar als je alleen pcall gebruikt kom je de gebruiker niet tegemoet, je kunt de gebruiker dan niet vertellen wat er fout gaat. Door de errors zelf af te handelen kun je voor meerdere mogelijke fouten een bericht tonen dat direct duidelijk maakt wat er mankeert. Liever dit dan voor alle fouten een algemene foutmelding.

Ik bedoelde daarmee te zeggen dat ik denk dat jullie beter de beslissing kunnen nemen hoe het qua data moet dan dat ik dat zou kunnen. Maar met alle informatie die hier nu gedeeld is, zie ik eigenlijk geen reden om het te veranderen. De manier van Groningen en Apeldoorn lijkt prima te werken. Ennomien (overleg) 20 nov 2022 12:27 (CET)

Maar pcall en gerichte error afhandeling kunnen toch naast elkaar bestaan? Démarche Modi (overleg) 20 nov 2022 12:31 (CET)

Of beter geformuleerd: het geheel aan code kan toch binnen pcall afgehandeld worden. Démarche Modi (overleg) 20 nov 2022 12:33 (CET)

Inderdaad. Dat is wat ik naar aanleiding van jouw advies voorstelde aan het eind van m'n bericht 22:24. Dat ga ik straks doen. :) Ennomien (overleg) 20 nov 2022 12:47 (CET)

Ik heb dat toegevoegd. Nu wordt altijd deze bovenste regel getoond met daaronder de zelfgeschreven foutmelding of niet opgevangen Lua-error. Een vraagje, m.n. aan @Démarche Modi omdat jij er bij was toen we het daarover hadden: die beheercategorieën worden nu een beetje rommelig en gaan hun doel voorbij. Is het een idee om een categorie Categorie:Wikipedia:Tabel woonplaatsen Nederlandse gemeente/Tabel waar iets mee is aan te maken voor foute peildatums, missende data en te grote "Overig" en Categorie:Wikipedia:Tabel woonplaatsen Nederlandse gemeente/Tabel waar iets mee is/Dringend voor tabellen met errors en tabellen waar de wikidatalinks onterecht nog getoond worden (mag alleen in "Toon bewerking ter controle")? Dan blijft het overzichtelijk en kun je ook snel zien wat belangrijk is en wat ietsje minder. Oprecht een grote verbetering nu met die pcall. Ennomien (overleg) 20 nov 2022 16:37 (CET)

Netjes! :) Ik zou per voorziene foutsituatie (fouten m.b.t. Wikidata-ID, ontbrekend Inwonertal en onjuiste peildatum, te grote Overig) ze elk in een eigen categorie plaatsen (dan kan er gerichter/geclusterd gewerkt worden aan de oplossing) en een afzonderlijke categorie, bijvoorbeeld (onvoorziene fouten) voor wat niet voorzien is.

Wat betreft 'toon wikidatalinks' ben ik er voorstander van om dat t.z.t. eruit te halen. Voorlopig kan het echter handig zijn en ik denk daarom dat dit gewoon net als voorziene foutsituaties behandeld zou moeten worden (en dus een eigen categorie). Tabellen 'met errors', anders dus dan de voorziene, vallen volgens mij allemaal in de onvoorziene.

Dus kort en krachtig, per voorziene error eigen categorie, en onvoorziene in eigen categorie:

- Categorie:Wikipedia:Module_Gemeente_in_Nederland Opgegeven WikiID niet geldig

- Categorie:Wikipedia:Module_Gemeente_in_Nederland Ontbrekend WikiID

- Categorie:Wikipedia:Module_Gemeente_in_Nederland WD-item is geen gemeente in Nederland

- Categorie:Wikipedia:Module_Gemeente_in_Nederland Ontbrekend inwonertal

- Categorie:Wikipedia:Module_Gemeente_in_Nederland Onjuiste peildatum

- Categorie:Wikipedia:Module_Gemeente_in_Nederland Overig te groot

- Categorie:Wikipedia:Module_Gemeente_in_Nederland Onvoorziene foutmelding

Let wel, dit is mijn persoonlijke voorkeur, en ik wil het niet opdringen. Indien eerst alles meer op een hoop terecht komt is ook goed en dan kan er later altijd nog gekeken worden wat er beter kan. (Tenminste, als er niet botmatig tewerk gegaan wordt en de categorie niet overspoeld raakt.)

Het stemt me positief dat je pcall er nu in hebt geprogrammeerd en ben blij te vernemen dat je het een verbetering vindt. Démarche Modi (overleg) 20 nov 2022 18:15 (CET)

Ik denk inderdaad dat je deels gelijk hebt, we moeten het wel redelijk gaan onderverdelen. Wmb vallen jouw categorie 1, 2, 3 en 7 (+wikidatalinks) samen in een categorie, die gevallen zouden niet moeten voorkomen dus zie ik ze liever in één categorie, dat is wat overzichtelijker dan dat ik door 4 categorieën moet gaan om dat lijstje spoedgevallen op te lossen. 5, 6 en 7 apart lijkt me prima. Als iemand dan bezig wilt met inwonertallen aanvullen, komt hij/zij geen onjuiste peildatums tegen bijv. Indien akkoord ga ik dat regelen. Verder onderverdelen als dat blijkt te moeten kan altijd.

Wat vooral handig is aan het werken met pcall is dat je de kans krijgt bij niet-verwachte errors om de pagina aan een categorie toe te voegen. Anders blijven die errors onzichtbaar. En je kunt er zelf een bericht omheen typen, nu met verwijzing naar deze pagina. Ennomien (overleg) 20 nov 2022 18:46 (CET)

Wikidatalinks had ik vergeten te melden. Kloppen jouw getallen verder? Bij '7' raak ik een beetje in de knoei. Morgen of overmorgen zal ik eens kijken of ik een gemeente kan oppakken. Zonder een belofte te willen doen, mogelijk moet ik het aan me voorbij laten gaan. Démarche Modi (overleg) 20 nov 2022 19:07 (CET)

Ja, met 7 bedoelde ik de zevende in jouw lijstje, dus de onderste. Maak je niet druk over beloftes, ik had de moduledocumentatie ook allang af moeten hebben. :)

De namen die ik voorstel voor categorieën:

Categorie:Wikipedia:Tabel woonplaatsen Nederlandse gemeente/Ontbrekend inwoneraantal

Categorie:Wikipedia:Tabel woonplaatsen Nederlandse gemeente/Onjuiste peildatum

Categorie:Wikipedia:Tabel woonplaatsen Nederlandse gemeente/Te veel overig

Categorie:Wikipedia:Tabel woonplaatsen Nederlandse gemeente/Directe actie nodig

zoiets? Ennomien (overleg) 20 nov 2022 19:59 (CET)

Wat mij betreft prima! Démarche Modi (overleg) 20 nov 2022 20:02 (CET)

Fijn, dan vraag ik nu hernoeming aan voor Categorie:Wikipedia:Tabel woonplaatsen Nederlandse gemeente/Niet-werkende tabel naar de laatste van de vier. Ennomien (overleg) 21 nov 2022 23:55 (CET)

Dit is bijgewerkt. Dan kan ik de module binnenkort voorlopig afronden, al durf ik daar geen datum op te plakken. Ennomien (overleg) 22 nov 2022 23:48 (CET)

De module is nu helemaal klaar! Ook qua documentatie, sjabloonuitleg, uitleg bij beheercategorieën en de pagina behorend bij deze OP is het helemaal af. Dat wil zeggen, alles is netjes en duidelijk, actueel en zonder bekende fouten en alle gegeven feedback is verwerkt. Ik sta uiteraard open voor veranderingen. Ennomien (overleg) 23 nov 2022 23:04 (CET)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ 'Even' bijgelezen, nu tijd voor een inhoudelijke reactie.

• Foutmeldingen (categorieën): ik zou het aantal niet te groot maken in het begin, zien we dat er veel fouten in een bepaalde categorie vallen en dat aantal groeit, dan kunnen we dat altijd gaan preciseren. Het is zonde om zeven categorieën aan te maken en te gaan coderen, om er vervolgens achter te komen dat drie ervan leeg blijven.
• BAG vs. CBS: BAG onderscheidt anno 2022 2501 woonplaatsen, een meer dan vorig jaar. (Labeltje 'Woonplaatsen' aanklikken en in het popup-scherm een vinkje zetten voor 'Woonplaatsen'; dan komen ze alle 2501 in beeld. Een nadere bestudering van deze lijst laat zien dat bijvoorbeeld de woonplaats Achterveld bestaat uit een dorp in de gemeente Leusden en een buitengebied in de gemeente Barneveld. De gemeentegrens die de woonplaats doorsnijdt, vormt ook nog eens een provinciegrens. In dit geval zijn het twee artikelen op nl-wiki, met -als het goed is-, allebei een eigen BAG-code in het gekoppelde WD-item: d:Q1975538#P981 en d:Q2011587#P981: Check!.
• Deze lijst sluit grotendeels, maar niet volledig, aan bij onze gegevens in Wikidata: deze lijsten kunnen we beide naast elkaar leggen en vergelijken, de verschillen zijn dan vrij snel duidelijk. Mogelijk zijn deze verschillen toe te wijzen aan recente ontwikkelingen, maar met of zonder goede verklaring, is het aan te passen in de data (vergelijk het antwoord van Wikiwerner over Weesp.
• BAG verdeelt iedere woonplaats in minimaal 1 wijk en iedere wijk in minimaal 1 buurt. CBS rapporteert inwonertallen op deze indeling, waarbij de gegevens op buurt- en wijkniveau afgerond worden op een vijfvoud. De cijfers op gemeenteniveau zijn wel exact. Hier is een eerste verklaring te vinden voor (kleine) verschillen.
• In de loop der jaren zijn buurten gaan schuiven over de omgeving. De indeling is niet zo dat we de buurten (neem Groningen) zonder meer kunnen koppelen aan hetzij de stad Groningen hetzij een van de andere woonplaatsen in deze gemeente. Soms is het nodig om de inwonertallen van verschillende buurten bij elkaar moeten tellen om de gegevens van een bepaalde woonplaats te verkrijgen. Voor een groot aantal plaatsen hebben we dat goed opgevangen in ons array-sjabloon. Zo vinden we daar dat de stad Groningen (1070) de wijken 001400 tot en met 001413 beslaat, en de woonplaats Haren (1266) de wijken 001417 en 001418. De woonplaats Glimmen (1267) bestaat uit drie BAG-buurten, met een niet aaneengesloten nummering: 00141900, 00141903 en 00141908.
• Pakken we de CBS-tabel met de inwonertallen per buurt, en gaan we daar met 'onze' BAG-array doorheen, dan blijkt dat we een aantal buurten niet hebben ingedeeld. Dat geldt bijvoorbeeld voor de buurt 'Appelbergen Onnen' (00141909). Gelukkig (voor ons) is het afgeronde inwonertal van deze buurt anno 2022 nul, dus voor de uitkomst maakt het niet uit. In de gegevens zoals die hier staan, betekent dat wel dat de wijk 'Glimmen-Onnen-Noordlaren' (001419) niet volledig afgedekt is, dus ook de gemeente Groningen (0014). Al met al kwam ik, met de gegevens die ik vrijdagavond had, mede door deze stapeling, op 109 buurten, wijken, gemeenten, die niet volledig waren ondergebracht, op een totaal van 17.680. 11 daarvan hebben nul inwoners, maar met de andere aantallen kunnen we niets zonder enige context (de 233.273 inwoners van Groningen veranderen niet, en de 2605 van de wijk Glimmen-Onnen-Noordlaren blijven ook gewoon in beeld).
• Intrigerend is dat een deel van de buurten aan twee bag-codes gekoppeld wordt, en enkele zelfs aan vijf: kennelijk hebben we ons in het verleden niet verdiept in de verdeling van 3104, 3110, 3118, 3119 en 3120 (Ansen, Dwingeloo, Pesse, Ruinen en Spier), waardoor deze in de array op een hoop zijn gegooid. Hierin hebben we iets uit te zoeken en uit te splitsen.
• Hebben we deze zaken uitgezocht en verwerkt, dan is onze array nog beter bruikbaar dan nu en kunnen we met de verbeterde resultaten een nog beter resultaat naar Wikidata brengen.
• Voor komende jaren moeten we de ontwikkelingen bijhouden, maar dat moet nu ook gebeuren. Het bij elkaar tellen van de inwonertallen en dat overbrengen naar WD is dan het minste klusje. Overigens wil Multichill hier vast ook wel een zegje over doen.
• Een onafhankelijke en gegarandeerd actuele bron waaruit we steeds de koppeling tussen BAG-buurtcode (of -wijkcode) en woonplaats kunnen vinden, zou mooi zijn. Of een CBS-tabel die de gegevens dus niet zo ver opsplitst maar keurig geeft voor de (nu) 2501 woonplaatsen.
• Willen we een heel andere opzet, waarbij we niet kijken naar de 2501 woonplaatsen van BAG, maar bijvoorbeeld naar de 14080 buurten, dan kan dat. Moeten we even kijken welke van deze buurten nog niet bestaat op Wikidata, die aanmaken en voorzien van een inwonertal. Dan heeft de gemeente Groningen opeens 150 buurten (De Indische buurt is dan met 8245 inwoners de buurt met de meeste inwoners, maar dat pannenkoekenhuis moeten we nog altijd ergens plaatsen).
• Zoals Wikiwerner al aangeeft, is het gebruiken van deze werkwijze zonder enige correctie identiek aan de huidige werkwijze. Iedere verbetering zorgt ervoor dat het resultaat ook beter is dan nu. Die correcties kunnen rechtstreeks op Wikidata gedaan worden (na de import), maar ook vooraf. Soms moet je een afweging maken waar je iedereen het meest mee helpt. Met vriendelijke groeten, RonnieV (overleg) 22 nov 2022 00:18 (CET)

Wow hoe kom je daaraan?! Over het punt van de buurten in meerdere BAG-codes: van die codes gebruiken we alleen 3110 (Dwingeloo). Ons inwonertal van 4.085 klopt dan ook niet: hier staat 2755, net als in de module:Array Nederland kerngebieden inwonertallen 2022. Misschien wil Wikipedist3425 aangeven waarop bijv. het sjabloon:Array Nederland woonplaatsen kerngebieden 2022 gebaseerd is? Wikiwerner (overleg) 22 nov 2022 19:33 (CET)

Voor het overbrengen naar Wikidata is het misschien zinnig om de woonplaatscodes in onze infoboxen te vergelijken met die in Wikidata en met de CBS-lijst. In Pesse (Q2459510) stonden er bijv. 2, zonder "van toepassing op deel", en in Lageland (Q2408524) stond er niet een. In het weekend wil ik wel broeden op een pythonscript om een overzicht te genereren van de codes in de infoboxen en Wikidata. Is hier behoefte aan? Wikiwerner (overleg) 22 nov 2022 19:33 (CET)

Momenteel kijk ik naar een script die alle informatie (BAG code, CBS code, inwonertal) samenvoegt vanuit het CBS. Daarna kijk ik of ik de informatie goed kan koppelen aan Wikidata Items en genereer ik overzichten van welke informatie er mogelijk niet klopt of ontbreekt in Wikidata. (...) Uiteindelijk, indien alle inwonertallen uit Wikidata gehaald worden (en Wikidata dus klopt) dan is de CBS code en Woonplaatscode in de infobox niet meer nodig. De module haalt het immers rechtstreeks (via de Wikidata - Wikipedia koppeling) op. Mede daarom ben ik van mening dat het niet heel belangrijk is wat er nu op Wikipedia staat, maar het kan zeker handig zijn zodra er dadelijk situaties uitgezocht moeten worden. De enige echte fout die ik me voor kan stellen is indien een Wikipedia artikel aan het verkeerde Wikidata item gekoppeld is. Mits mijn gedachtegang uiteraard klopt. Wel zou het een logische stap zijn later om alle infoboxen bij te werken. Indien je graag met me meekijkt / meedenkt met wat ik probeer, dan wil ik gerust mijn code binnenkort met je delen. Er zal ongetwijfeld wat aan te verbeteren zijn. Indien je toch graag een overzicht wil maken van wat er nu op Wikipedia en Wikidata staat dan denk ik dat er mogelijk behoefte aan kan zijn voor uitzoekwerk. Voor Wikidata kan ik je hem vermoedelijk deze week wel geven (kwestie van items ophalen met de pagegenerator en correcte properties eruit pakken, althans zo doe ik het). E.e.a. onder voorbehoud want ik weet niet zeker of de computer het nog lang volhoudt... hopelijk doe ik er verstandig aan dit te proberen. Fingers crossed. Démarche Modi (overleg) 22 nov 2022 21:20 (CET)

Hoi Démarche Modi, welke informatie wil je precies bijeenbrengen? Woonplaatsen in Nederland 2022 bevat de woonplaatscode (WP), gemeentecode (GM), provincie (PV) en het landsdeel (LD). De inwonertallen per buurt, wijk en gemeente vind je in de kerncijfers. Voor het genereren van de inwonertallen per woonplaats (die 2501 woonplaatsen) is een koppeling nodig tussen buurt (of wijk of gemeente) met de woonplaats. Die is grotendeels beschikbaar in onze array, maar ik zoek nog naar een betere bron. In ieder geval biedt onze array nog ruimte voor enige verbetering, zoals je hierboven vast gelezen hebt.

@Wikiwerner, van welk stuk(je) informatie vraag je je af waar ik dat vandaan heb?

Met vriendelijke groeten, RonnieV (overleg) 23 nov 2022 13:57 (CET)

@RonnieV Excuses, ik lees deze reactie nu pas. (na dat Ennomien hem aanpaste) Na het eten zal ik even goed naar de bronnen kijken en die array bestuderen. Mogelijk kan ik daarmee mijn onderstaande uitdaging oplossen. Dank in ieder geval voor het meedenken!! Démarche Modi (overleg) 23 nov 2022 17:41 (CET)

@RonnieV: ik doelde op de wijken en buurten die niet behoren tot een woonplaats, of die behoren tot meerdere woonplaatsen; dat had ik inderdaad duidelijker mogen aangeven. Wikiwerner (overleg) 23 nov 2022 20:07 (CET)

@Wikiwerner, ik heb net een aantal bestanden op GitHub geplaatst. Voor het achterhalen welke buurten en wijken niet (of meerdere keren) toegewezen zijn, zie regel 24-37 van inw_test.py. De database is ook toegevoegd, zodat je zelf ook kan experimenteren.

Ik haal de bag-woonplaatsen op, achterhaal welke buurten/wijken daaraan gekoppeld zijn, en verhoog van deze het aantal keren dat deze is voorgekomen. Idealiter heeft daarna alles de waarde 1. Voor wijken die hun buurten aan twee of meer woonplaatsen kwijt zijn, doorloop ik het geheel nog eens, om de wijk alsnog op 1 te zetten als deze nog op 0 stond, maar alle buurten wel zijn ondergebracht. Datzelfde doe ik voor de gemeenten. (regel 39-50).

Ja, de code kan vast netter, maar dit werkt ;) Met vriendelijke groet, RonnieV (overleg) 23 nov 2022 21:18 (CET)

Ziet er goed uit! Als buurten meerdere keren 'gebruikt' worden, dan kan dit ook komen doordat een woonplaats niet altijd samenvalt met een of meerdere gehele buurten, zo leert googelen op 'woonplaatscode' en 'wijken'. Op https://allecijfers.nl/woonplaatsen staat vaak: "De woonplaats X valt niet precies samen met de gemeente en ook niet met 1 of meerdere wijk(en) of buurt(en). Er zijn 14 buurten die tesamen geheel of ten dele de woonplaats vormen. De cijfers voor de woonplaats X zijn bepaald door de gegevens voor deze buurten gewogen te combineren." Geen idee hoe Allecijfers.nl dan bepaalt welk deel van een buurt behoort tot woonplaats X en welk deel niet. Wikiwerner (overleg) 24 nov 2022 20:31 (CET)

Reactie op je laatste zin: ik las onderstaande zin alsof het inwoneraantal van een buurt die in drie woonplaatsen valt, evenredig verdeeld wordt over die woonplaatsen (1/3 per woonplaats dus). Of ik heb het mis. Uiteraard is dat geen betrouwbare manier. "De cijfers voor de woonplaats X zijn bepaald door de gegevens voor deze buurten gewogen te combineren." Ennomien (overleg) 24 nov 2022 20:46 (CET)

Voor wat betreft achterhaal welke buurten/wijken daaraan gekoppeld zijn wil ik graag nogmaals aandacht vragen voor de situatie die hieronder besproken is (Aa en Hunze). Het is niet altijd duidelijk hoe de koppeling van BAG naar CBS te bepalen is. Neem bijvoorbeeld Marwijksoord en Eldersloo. Démarche Modi (overleg) 24 nov 2022 20:56 (CET)

Alle cijfers... Gegoochel ten top ;)

Als ik daar zoek naar Balloërveld, staat er dat De woonplaats Balloërveld ligt in de gemeente Aa en Hunze binnen de provincie Drenthe en telt 8 adressen en 17 inwoners.. Daar wil ik best in meegaan. Maar dan: De woonplaats Balloërveld is een onderdeel van de buurt Balk, de cijfers voor woonplaats Balloërveld zijn daarom afgeleid van de cijfers van buurt Balk. Balk is een mooie buurt, ligt in de gemeente De Fryske Marren. Nu delen Friesland en Drenthe ergens een stuk provinciegrens, maar volgens mij houden gemeentegrenzen en buurtgrenzen (anders dan woonplaatsgrenzen) rekening met provinciegrenzen. Alleen als je Balk en Balloërveld op de kaart opzoekt (topografie van dorpen in Noord-Nederland was niet zo sterk in mijn onderwijs aanwezig), ga je je toch achter de oren krabbelen. Maps biedt een route aan van 99 km...

En dan durft alle cijfers verzamelingen die zij gemaakt hebben op grond van de CBS-cijfers aan te bieden voor toch heel leuke prijsjes. Met vriendelijke groet, RonnieV (overleg) 25 nov 2022 17:00 (CET)

Ik ben het met je eens dat www.allecijfers.nl geen gezaghebbende bron is waaraan wij informatie kunnen ontlenen. Wel zou het als inspiratie kunnen dienen met dien verstande dat het niet achterhaald kan worden hoe de informatie daar tot stand gekomen is en mogelijk foutief is. Echter, gegeven Balloo in Rolde en Balloërveld ernaast is het logisch om te bekijken of die bij elkaar horen. Démarche Modi (overleg) 25 nov 2022 17:09 (CET)

Het ging me er meer om dat een woonplaats dus niet altijd exact een combinatie is van gehele wijken en/of buurten. Onze array's gaan daar wel van uit. Voor de rest vind ik het ook een schimmige bron. Wikiwerner (overleg) 25 nov 2022 19:19 (CET)

Ik ben pas net weer begonnen met het teruglezen van alles, dus kom vast op andere dingen terug. Maar de buurt- en wijkcodes zijn instabiel van jaar tot jaar. Het is dus een beetje een risico om daarvoor items aan te maken. Dajasj (overleg) 22 nov 2022 21:37 (CET)

@Dajasj: Het is mij op dit moment nog niet volkomen helder of buurt- en wijkcodes als sleutel toegepast kunnen worden. Echter, het CBS heeft in de Toelichting variabelen KWB 2019 de variabele 'IndelingswijzigingenWijkenEnBuurten' beschreven: (ik citeer)

" ind_wbi: Indelingswijziging wijken en buurten [code] Deze indicator geeft per wijk en buurt aan of de cijfers uit deze tabel zonder problemen kunnen worden gekoppeld aan en vergeleken met de cijfers van een jaar eerder, of dat er wijzigingen in de Wijk- en Buurtindeling zijn waardoor dit niet kan. Detailinformatie over wijzigingen in de Wijk- en Buurtindeling kan worden verkregen door de wijk- en buurtkaart van twee opeenvolgende jaren met elkaar te vergelijken."

Het is me opgevallen dat in veel gevallen de waarde op 1 staat, soms kom ik een andere waarde tegen. Mijn vermoeden is dat bij elke wijziging dit getal met 1 opgehoogd wordt. Wellicht is een jaarlijks vergelijk t.o.v. het voorgaandejaar dan voldoende om er grip op te houden. Démarche Modi (overleg) 23 nov 2022 13:46 (CET)

Daarmee bedoel ik overigens niet dat elke buurt en wijk een wikidata item moet krijgen. Démarche Modi (overleg) 23 nov 2022 13:48 (CET)

Beste @Démarche Modi, als je de volgende paragraaf leest (ook p.7), weet je dat er drie waarden mogelijk zijn en wat deze drie betekenen. Ook weet je dan welke grensverleggingen als niet-significant beschouwd worden. Het gaat niet om het aantal wijzigingen in de loop der tijd. Met vriendelijke groet, RonnieV (overleg) 23 nov 2022 14:02 (CET)

Ok, thx! Maar het is dus wel een parameter waarmee we grip kunnen houden op deze codes? Démarche Modi (overleg) 23 nov 2022 14:07 (CET)

Ja, deze parameter kan ons helpen om te signaleren welke wijken wellicht aandacht behoeven. Anderzijds, als we buurt 1234 koppelen aan woonplaats 1 en buurt 1235 aan woonplaats 2, dan maakt een grenswijziging per 1-1-2023 tussen deze twee buurten het alleen lastig om de inwonertallen te vergelijken. Maar als we de met de CBS-cijfers van 2022 aan de gang gaan krijgen beide woonplaatsen bijvoorbeeld 100 inwoners uit deze buurten, en in 2023 krijgt de ene er 150 en de andere 50. Voor de verwerking en de tabellen maakt dat niet uit. Het wordt vervelender als buurten worden overgeheveld van de ene woonplaats naar de ander. Met vriendelijke groet, RonnieV (overleg) 24 nov 2022 10:21 (CET)

Vannacht ben ik, geholpen door het zichtbaar maken van de resultaten, erin geslaagd om de meeste grote verschillen weg te werken. Er zat (niet geheel onverwacht) een aantal onvolkomenheden in onze array. Ik zal later met deze nieuwe indeling nog eens kijken welke gaten er nu nog vallen. Zo weet ik dat alle buurten die nu eindigen op 9999 nog aandacht behoeven.

Opvallende uitkomst (zie o.a. Utrecht): de totalen van de buurten, de totalen van de wijken en het aantal voor de gemeente kunnen best flink uit elkaar lopen.

Met vriendelijke groeten, RonnieV (overleg) 24 nov 2022 10:25 (CET)

Afgezien van de gemeente Westerveld, lijk ik een aardige dekking bereikt te hebben. Ik mis nog wel enkele buurten in de rest van het land, maar dat zijn (vrijwel) allemaal buurten met (afgerond) 0 inwoners. Natuurlijk willen we die ook toegewezen hebben, voor het geval er volgend jaar opeens een (over)bevolkte Vinex-wijk in die buurt staat, maar voor de huidige resultaten zijn buurten als Appelbergen Onnen, De Groote Peel, Vathorst-Bovenduist en Veerse Meer niet zo interessant.

In Westerveld heb ik de wijken Lhee (170104) en Eemster (170105) en de buurt Verspreide huizen Dieverbrug (17010709) over, samen goed voor 870 inwoners. RonnieV (overleg) 25 nov 2022 10:09 (CET)

@RonnieV, in de gemeente Aa en Hunze ontbreekt Balloërveld BAG=1153 nog in het overzicht op jouw kladblokpagina. Zojuist heb ik er even naar gekeken en misschien is het Mogelijk: Verspreide huizen Rolde (BU16801909), Verspreide huizen Gasteren (BU16800309) of Verspreide huizen Anderen (BU16800409)? Die laatste twee lijken me logischer, maar ik kan het nog niet logisch bepalen. Verspreide huizen Rolde zou overigens gewoon het gebied ten westen van Rolde kunnen zijn, deze is nu gemapt als Marwijksoord. Het gebied ten westen van Rolde lijkt me logischer, omdat mijn inschatting is dat hier eerder 150 mensen wonen dan in Marwijksoord. Er is namelijk een woonzorgcomplex gelegen in de bossen van Rolde waar relatief veel mensen ingeschreven kunnen staan. Marwijksoord zijn hooguit 15 boerderijen en een handjevol huizen. Tevens is Eleveld niet en Eldersloo wel gekoppeld terwijl ze mogelijk beide binnen Verspreide huizen Ekehaar (BU16802109) vallen, net als Marwijksoord. Dit soort onduidelijkheden waar wij tot op heden geen goed antwoord op weten te geven dienen ook meegenomen te worden in deze bevraging van de gemeenschap. Ik ben namelijk van mening dat indien de BAG-CBS lijst dergelijke aannames bevat, dat we dat niet zouden moeten gebruiken (conform WP:GOO). Démarche Modi (overleg) 25 nov 2022 13:06 (CET)

Gezien de locatie van de huizen, aan de Visvliet ten noorden van het heidelandschap, lijkt BU16800309, 'Verspreide huizen Gasteren', het meest voor de hand te liggen.

Eleveld, Ekehaar en Marwijksoord zouden we verder in moeten duiken. RonnieV (overleg) 25 nov 2022 17:07 (CET)

Het blijft een aanname. 'Anderen' is qua postcode (9465) dichterbij dan Gasteren (9466), postcode Balloërveld is 9459. Balloo is 9458 (valt binnen Rolde)... Démarche Modi (overleg) 25 nov 2022 17:14 (CET)

De cijfers voor 'Verspreide huizen Rolde' sluiten niet aan bij de 8 huizen en 22 bewoners van Balloëveld (of er moet recent veel bijgebouwd zijn sinds 2016).

De cijfers voor 'Verspreide huizen Gasteren' zijn wat lager, die van 'Verspreide huizen Anloo' iets hoger. Beide zouden een optie kunnen zijn. Of de woonplaats (besluit gemeente) is geen complete buurt (besluit CBS).

RonnieV (overleg) 25 nov 2022 17:26 (CET)

@RonnieV, aanvullend graag aandacht voor Purmerend (Q110423208), zie de inwoneraantallen van het CBS en de woonplaatsen conform het CBS, deze gemeente heeft de woonplaatsen Middenbeemster 2170, Noordbeemster 2171, Purmerend 3103, Westbeemster 2172 en Zuidoostbeemster 2173. De BAG-CBS array heeft al deze woonplaatsen als Purmerend 3102=0439 (op gemeentelijk niveau). Purmerend wordt dus niet onderverdeeld.

Waneer we verder kijken naar de Array dan zien we dat al deze 'Beemster' BAG codes binnen de (voormalige) gemeente Beemster vallen:

|2170=03700801

|2171=03700802

|2172=03700803

|2173=03700804

Op basis van deze bron kunnen we echter vaststellen dat de herindeling hier debet aan is. Echter, aangezien je werkt met de datasets van 2022 dan kan ik - helaas - niet anders dan concluderen dat het gebruik van de Array momenteel voor onjuistheden zorgt. Démarche Modi (overleg) 25 nov 2022 17:05 (CET)

Nee hoor, ik werk nog met de cijfers van 2021.

Hoe we de wijken en buurten van 2021 van Beemster terugvinden in de gegevens van 2022, heb ik al bekeken. Deze compleet doorgeschoven, 03700801 (Middenbeemster) naar 04390801 (Purmerend stopte in 2021 netjes bij 04390705. We moeten inderdaad even de nummertjes aanpassen. Met vriendelijke groeten, RonnieV (overleg) 25 nov 2022 17:18 (CET)

Klopt. Maar ik vrees dat met deze manier van werken de juistheid van de Array in het geding komt. Is er niet een mogelijkheid om op basis van een python script een sluitend overzicht samen te stellen? Dat script dient dan na een gemeentelijke herindeling, jaarlijks, aangepast te worden, zoals bijvoorbeeld voor Beemster/Purmerend. Voor 2023 weten we al wat ons te wachten staat. Démarche Modi (overleg) 25 nov 2022 17:31 (CET)

Er is nu (ook) geen sprake van 'de array', er is sprake van de array voor 2020, voor 2021 en voor 2022. Het lijkt me verstandig om uit te gaan van een veranderlijke wereld, een veranderlijke omgeving.

Voor Beemster en Purmerend betekent dit dat in de array vijf waarden moeten worden aangepast:

|2170=04390801

|2171=04390802

|2172=04390803

|2173=04390804

|3102=043901,043902,043903,043904,043905,043906,043907

De nieuwe kerncijfers erbij en we kunnen de boel opnieuw overnemen naar Wikidata. Met vriendelijke groet, RonnieV (overleg) 25 nov 2022 17:50 (CET)

Hopelijk wacht je wel met een botmatige upload tot dat we overeenstemming hebben m.b.t. de data. Zie mij reactie hieronder m.b.t. verspreide huizen. Het doel zou niet moeten zijn om Wikidata z.s.m. te vullen, het doel zou moeten zijn om Wikidata zo goed als mogelijk te vullen. Démarche Modi (overleg) 25 nov 2022 17:59 (CET)

@RonnieV, aanvullend, met betrekking tot 'Verspreide huizen' dienen we vermoedelijk bedachtzaam om te gaan. De naam zegt het immers al: 'Verspreid'. Indien die verspreide huizen allemaal in een woonplaats zouden staan, dan had het CBS toch wel voor die naam gekozen? Het lijkt mij niet ondenkbaar deze restcategorie maar zo alle huizen buiten de bebouwde kom ten Noorden, Oosten, Zuiden en Westen van een plaats bevatten. En dus geografisch 'ontkoppeld' zouden kunnen zijn. Plaatsen als Balloërveld, Eldersloo etc vallen officieel buiten de bebouwde kom. Wellicht is onze enige mogelijke en logische conclusie dat bepaalde woonplaatsen het inwoneraantal deelt met andere woonplaatsen. Zoals bijvoorbeeld Eldersloo en Eleveld. En dat we dat overeenkomstig zouden moeten tonen. (De Woonplaats ABC heeft 123 inwoners.* Bron CBS, gedeelde waarde met ABC, DEF, ...) ofzo Démarche Modi (overleg) 25 nov 2022 17:47 (CET)

Het betekent in mijn ogen dat we moeten accepteren dat we voor sommige woonplaatsen (met name de kleinere) niet volledig uit de voeten kunnen met de informatie van het CBS. Maar bijvoorbeeld voor Balloërveld moeten terugvallen op de gemeente, die voor de afzonderlijke plaatsen cijfers per 1-1-2016 gepubliceerd heeft. Wellicht heeft die gemeente nieuwere beschikbaar, die we hiervoor kunnen krijgen en gebruiken, en anders moeten we het met een acceptabel aantal voor een acceptabele datum oplossen.

Kijk ik naar jouw formulering, dan zou ik geen idee hebben waar die 123 vandaan komt, op grond waarvan je een verdeling zou maken over ABC, DEF en de rest,... Met vriendelijke groet, RonnieV (overleg) 25 nov 2022 18:01 (CET)

Dat was pseudo-achtig voor de verzameling woonplaatsen wat er overblijft binnen verspreide huizen en alles wat niet op woonplaatsnaam te koppelen is. (want dat is uiteindelijk, op basis van de woonplaatsnaam, hoe de BAG-CBS koppeltabel gemaakt is.) Daarmee halen we alle aannames eruit. Démarche Modi (overleg) 25 nov 2022 18:14 (CET)

En wat denk je van iets als deze oplossing? Ik (of beter: Ennomien in de module) moet dan alleen nog de onderste twee jaartallen weghalen, of vervangen door een reeks (2016-2021). Dit zijn, voor de vier lastige plaatsen, wel betrouwbare data voor deze woonplaatsen, die zonder meer naar Wikidata kunnen. Met bron en al. Met vriendelijke groet, RonnieV (overleg) 25 nov 2022 19:36 (CET)

Daar kan ik wel mee leven. Maar moeten de overgebleven puzzel stukjes (Verspreide huizen Rolde en Verspreide huizen Ekehaar) dan wel of niet buiten de inwonertallen blijven? Van 2021, of dadelijk 2022, uiteraard. Démarche Modi (overleg) 25 nov 2022 20:09 (CET)

Ik snap het niet helemaal. De module zou dan, als die data in Wikidata staan, toch een tabel genereren met op sommige plekken 2016 en op andere plekken 2021? Ennomien (overleg) 25 nov 2022 21:44 (CET)

Je hebt gelijk, @Ennomien, dat doet hij al. Verstandig om ons te realiseren (en dan ook meteen aan te geven) dat het combineren van cijfers van allerlei verschillende data zonder meer een recept is voor een niet-sluitende optelling. Misschien zouden we daar wel een opmerking over moeten plaatsen bij de tabel (als het speelt). Wij zitten er een stuk verder in dan de gemiddelde lezer. Met vriendelijke groet, RonnieV (overleg) 25 nov 2022 23:01 (CET)

Ja, indien we dat (inwoneraantallen uit verschillende jaren) accepteren . Alternatief is dat we dat niet doen en alleen uitgaan van hetzelfde jaartal. Voorbeeld van Aa en Hunze is van 2016: 6 jaren verschil tov 2022. Dat is fors. Démarche Modi (overleg) 26 nov 2022 13:24 (CET)

Dan snap ik het weer. We zouden bij de tabelrij "Overig" (of "Afrondingsverschil" = o/a) een opmerking, waarschijnlijk in de vorm van een referentie, kunnen plaatsen als "Er zijn voor deze tabel inwoneraantallen van verschillende jaren gebruikt. Deze waarde (verwijzend dus naar o/a) zal afwijken van de werkelijkheid." Die opmerking moet dan wel alleen tevoorschijn komen als dat bewust vanuit ons is gebeurd. Dat vergt wat kleine aanpassingen. Het alternatief van DM kan ook, dat vergt geen aanpassingen. Ik vind het lastig kiezen. Ennomien (overleg) 26 nov 2022 14:49 (CET)

@RonnieV, voor Utrecht kan ik niet vaststellen wat de inwoneraantallen zijn voor alle woonplaatsen. Haarrijn kan wel/niet bij Haarzuilens/Utrecht horen. Maximapark kan wel/niet bij Vleuten/De Meern horen en Rijnenburg kan wel/niet bij De Meern/Utrecht horen. Démarche Modi (overleg) 26 nov 2022 16:32 (CET)

---

Bronnen, noten en/of referenties

Analyse Aa en Hunze

Vandaag heb ik de gemeente Aa en Hunze opgepakt. Zie Gebruiker:Démarche Modi/Module Gemeente in Nederland voor mijn aantekeningen. Hier is een tabel (Analyse) toegevoegd en de eerste conclusies die ik hieruit kan trekken is dat het overgrote deel goed gevuld kan worden. In de laatste kolom opmerking zie je bij een aantal woonplaatsen een vraag staan, het zijn deze woonplaatsen waarbij ik geen inwonertallen kan vinden. Hoe kunnen we hier mee omgaan? Is er een manier om de gegevens te koppelen? Willen we deze leeg laten en de vraagteken blijven tonen? Démarche Modi (overleg) 23 nov 2022 16:50 (CET)

Dankjewel voor de analyse. Om een van de vragen te beantwoorden (de laatste): de tabel moet woonplaatsen in een gemeente tonen. Een wijk/buurt hoort zover ik weet bij een woonplaats of is zelf een woonplaats en staat dus in de lijst of de inwoners ervan zijn meegeteld bij een woonplaats. Als die woonplaatsen echt woonplaatsen zijn, zouden ze toch een inwoneraantal moeten hebben? Als er niemand woont, wat ook kan, zou dat ook zo in de tabel moeten. Maar ik kan het niet begrijpen dat er een woonplaats in de tabel komt waarvan het inwoneraantal onbekend is. Ennomien (overleg) 23 nov 2022 17:45 (CET)

Zie Gebruiker:RonnieV/Module Gemeente in Nederland voor hoe we (ik) Aa en Hunze nu eruit kunnen laten zien door 'onze' data naar Wikidata te brengen. Met vriendelijke groeten, RonnieV (overleg) 23 nov 2022 18:19 (CET)

Dat is toch echt het geval. Balloërveld, Eldersloo, Eleveld, Geelbroek, Marwijksoord en Vredenheim kan ik niet herleiden naar een plaats, wijk of buurt. Het zijn allen kleine plaatsen. Alle plaatsen hebben een BAG en worden ook door het CBS gepubliceerd, zowel in 84992NED (dataset Woonplaatsen in Nederland 2021) als in 85210NED (dataset Woonplaatsen in Nederland 2022).

@RonnieV, wat heb je precies gedaan om die tabel zo te krijgen? Démarche Modi (overleg) 23 nov 2022 18:22 (CET)

Oh, ik denk dat ik het al begrijp. Je hebt een wikitable gemaakt en de woonplaatsen met de ontbrekende waarden eruit gelaten. Démarche Modi (overleg) 23 nov 2022 18:27 (CET)

Hmm, nou ja dat is wel gek. Hopelijk heeft iemand anders een verklaring/oplossing. Marwijksoord en Eldersloo hebben wel een plekje in de tabel van RonnieV, daarentegen. Ennomien (overleg) 23 nov 2022 18:33 (CET)

@Ennomien, ik vermoed dat @RonnieV hiervoor Sjabloon:Array Nederland woonplaatsen kerngebieden 2021 gebruikt heeft. Oorspronkelijk aangemaakt door @Wikipedist3425. Enkele BAG codes ontbreken in de lijst en voor Marwijksoord en Eldersloo is er een CBS code gegeven. Echter, op basis van de CBS data kan ik niet vaststellen dat Marwijksoord bij de plaats Rolde hoort (en niet bij Ekehaar) en ook kan ik niet vaststellen dat Eldersloo het volledige buitengebied van Ekehaar omvat. Dat buitengebied (Verspreide huizen Ekehaar - BU16802109) met 155 inwoners kan maar zo bestaan uit de woonplaatsen (i.e. postcodegebieden) Eldersloo (BAG 1160), Eleveld (BAG 1161) en Marwijksoord (BAG 1170). Echter, ook dat kan ik nu niet hard maken. Daarom ping ik Wikipedist3425 ook omdat er hopelijk duidelijkheid verschaft kan worden waar de bestaande mapping in het array op gebaseerd is (en daarbij Marwijksoord 1170 en Eldersloo 1160 in het bijzonder). Démarche Modi (overleg) 23 nov 2022 19:21 (CET)

De verklaring is inderdaad niet zo moeilijk: deze plaatsen waren niet bekend in de genoemde array, Eldersloo en Marwijksoord wel. Inmiddels heb ik 38 woonplaatsen toegevoegd, zodat we bij de volgende update, voor Aa en Hunze of een willekeurige andere gemeente, in beeld krijgen welke woonplaatsen wel onderscheiden zouden moeten worden, maar nergens aan gekoppeld zijn. Deze drie in Aa en Hunze lijken een minimaal aantal inwoners te hebben, ik tel telkens maar enkele huizen.

In de bijgewerkte versie van mijn pagina vallen deze drie nu wel op.

@Démarche Modi, in jouw pagina bevat de eerste tabel alle waarden dubbel. En ik ben er geen voorstander van om tabellen dicht te klappen, als je wil dat die bekeken worden: extra werk voor de lezer. Met vriendelijke groeten, RonnieV (overleg) 23 nov 2022 19:34 (CET)

Ik reageerde met mijn zin "Hopelijk heeft iemand anders een verklaring/oplossing." op dat die kernen woonplaatsen zijn, maar geen inwoneraantal hebben en ook niet ergens bij horen. Dus dat zijn volgens de bronnen die DM gebruikt wel woonplaatsen, maar ze hebben geen inwoners. Dit staat dus los van de arrays hier. Ennomien (overleg) 23 nov 2022 19:50 (CET)

@Ennomien, Doordat de bag-woonplaatscode niet gekoppeld is aan een buurt (of wijk of gemeente) van CBS krijgen ze geen inwoners. Die koppeling komt binnen via die array. Met vriendelijke groet, RonnieV (overleg) 23 nov 2022 20:06 (CET)

Ooh, dus je wilt daarmee zeggen dat die vreemde situatie van ontbrekende inwoneraantallen niet komt door rare situaties bij het CBS ofzo, maar dat het simpelweg kwam door het onvolledig zijn van de array? Ik dacht dat DM de array niet gebruikt had. Dan snap ik 'm weer. :) Ennomien (overleg) 23 nov 2022 20:13 (CET)

Ik zou graag het antwoord van Wikipedist3425 willen afwachten alvorens we verder gaan. Wat is een redelijke termijn? (Zie Speciaal:Bijdragen/Wikipedist3425) Démarche Modi (overleg) 23 nov 2022 19:58 (CET)

Een week? Heb je trouwens de eerste paar regels broncode van Sjabloon:Array Nederland woonplaatsen kerngebieden 2022 gezien? Ennomien (overleg) 23 nov 2022 20:03 (CET)

Ok, een week. Ja, ik heb gelezen dat BAG niet altijd overeenkomt met CBS. Ook zag ik dezelfde bron die we hier gebruiken. Wat dit eventueel zou kunnen betekenen voor de Module laat ik nog even rusten. Maar we kunnen allemaal wel alvast eens kunnen nadenken wat we zouden moeten doen met woonplaatsen die we niet (uniek) kunnen voorzien van een inwoneraantal. Démarche Modi (overleg) 23 nov 2022 20:55 (CET)

'Mijn' pagina is inmiddels uitgebreid met alle gemeenten, Aa en Hunze staat nu op zijn plaats. Met vriendelijke groet, RonnieV (overleg) 23 nov 2022 20:01 (CET)

Ik vind het indrukwekkend hoe je zo'n lap data genereert! Kunnen/mogen we de gebruikte code ook ergens inzien zodat we goed begrijpen en kunnen zien hoe dat tot stand gekomen is? Démarche Modi (overleg) 23 nov 2022 20:57 (CET)

@Démarche Modi, de code (en de database) staat inmiddels op Github. In inv_uit.py staat alles wat ik nodig heb om de pagina aan te maken op mijn harde schijf. (Hardgecodeerd de map Wikipedia in de root van de D-schijf). De uitdagingen lijken me voor dit moment te liggen in de tabel bag-regio, daar moeten we wat puzzeltjes oplossen. Maar deze pagina helpt wel om ze sneller te vinden. RonnieV (overleg) 23 nov 2022 21:23 (CET)

Dankjewel. Inhoudelijk moet ik er nog even goed voor gaan zitten. Wat ik echter denk te missen, en dat komt vermoedelijk uit jouw database, is de bron van de informatie. Om je een idee te geven waar ik hoop dat we naartoe kunnen (werken vanuit een externe bron) heb ik de code die ik gebruikt heb om het overzicht van Aa en Hunze te maken toegevoegd Gebruiker:Démarche Modi/Module Gemeente in Nederland/code. Démarche Modi (overleg) 23 nov 2022 22:21 (CET)

@23 nov 2022 16:50 (CET) - Zelfs het CBS zegt: Inwoneraantallen per woonplaats publiceren wij niet (...) Wellicht een optie beide lijsten naast elkaar te leggen. Wikiwerner (overleg) 23 nov 2022 21:22 (CET)

Omgaan met niet-overeenkomende grenzen

Vervolg op 26 nov 16:17 ("Proefversie module"), hier.
Die heb ik uit de tabel van het CBS gehaald. Wat ik gedaan heb ik het geval van Rotterdam is de aantallen op de andere woonplaatsen invullen en het overgebleven deel aan Rotterdam toekennen. Zo even uit mijn hoofd waren dat alleen nog hele wijken die overbleven. De opmerking van die website is een instinkertje omdat de stad Rotterdam dezelfde naam heeft als de gemeente. In gemeenten met meerdere plaatsen en dezelfde naam is het altijd zo dat de gemeentegrenzen niet overeenkomen met de woonplaatsgrenzen. Zoals ook bijvoorbeeld voor Groningen en Utrecht. Démarche Modi (overleg) 26 nov 2022 16:27 (CET)

Nog een keer dan: "De woonplaats Rotterdam valt niet precies samen met de gemeente en ook niet met 1 of meerdere wijk(en) of buurt(en)". Er moet dus ten minste nog een andere woonplaats zijn waarvoor dit geldt, maar je gaat ervan uit dat de andere woonplaatsen wél bestaan uit gehele wijken en/of buurten? En zie mijn reactie van 26 nov 2022 13:47: de twee CBS-tabellen bevatten geen lijst van wijken buurten in een zekere woonplaats. Hoe kom je daar dan toch aan? Wikiwerner (overleg) 26 nov 2022 16:39 (CET)

Welke andere gemeenten/woonplaats is dat? Wellicht is ook hier de conclusie dat we niet kunnen bepalen hoeveel mensen er in de woonplaats Rotterdam wonen. Wellicht is het een wijk of buurt van een aangrenzende gemeente. Ik weet het niet. Als het klopt wat je probeert duidelijk te maken: dat een deel van de woonplaats Rotterdam buiten de gemeente Rotterdam valt, dan moet Rotterdam mogelijk ook naar het rijtje met problemen. Echter, je zwaait nu slechts met de bron allecijfers.nl, ik zou dit graag hard willen kunnen maken op basis van de CBS data. Een logische twijfel is wat mij betreft al voldoende. Die had ik bij Rotterdam niet gezien (maar ik keek dan ook niet naar andere gemeenten). Démarche Modi (overleg) 26 nov 2022 16:52 (CET)

Hier vinden we een indruk welke gemeenten het eventueel kunnen zijn die een deel van de Rotterdamse bevolking in bureaucratisch ballingschap houden. Het zijn er aardig wat die aan Rotterdam grenzen. Démarche Modi (overleg) 26 nov 2022 17:27 (CET)

Ik bedoel niet aan te geven dat een deel van de woonplaats Rotterdam buiten de gemeente Rotterdam valt. Ik begreep altijd dat het CBS een gemeente altijd exact verdeelt in een of meerdere wijken en/of buurten. Over woonplaatsen is het CBS echter niet de baas, maar de gemeente. Op Woonplaats in Nederland staat: "In Nederland zijn het de gemeenten die bepalen hoe hun gebied is onderverdeeld in woonplaatsen." Een gemeente kan dus doodleuk bepalen dat de grens tussen 2 woonplaatsen dwars door een CBS-buurt loopt. Het ene deel behoort dan bijv. tot de woonplaats Rotterdam en het andere deel behoort bij een andere woonplaats in de gemeente Rotterdam. Als we dergelijke wijken en/of buurten volledig meetellen bij beide woonplaatsen, zoals ons huidige array misschien ook doet, dan tellen we inwoners dubbel. Wikiwerner (overleg) 26 nov 2022 18:12 (CET)

Ja, ik heb de bron even niet paraat, maar volgens mij was jij het die met een bron kwam dat het CBS woonplaatsen altijd rangschikt naar wijken en buurten. Was dat een antwoord van een CBS medewerker op hun eigen forum? Indien het CBS namelijk altijd rangschikt in wijken en buurten dan kunnen we met een grote mate van zekerheid vaststellen dat bepaalde gemeenten conform de woonplaatsen ingedeeld zijn (o.b.v. de naam). Indien dat niet zo is, dan is onze hele aanpak om woonplaatsen te voorzien van inwoneraantallen vanuit wijken en buurten op losse schroeven. Dus, ik waardeer je inbreng, maar het zijn nu vooral niet onderbouwde twijfels. Ik wil je dan ook vragen om het te onderbouwen met concrete voorbeelden waar de twijfel bestaat in de gemeente Rotterdam. Pas dan kunnen we er iets mee. Tot die tijd wacht ik het even rustig af. Ik heb namelijk niet de bronnen om jouw beweringen of twijfels te onderbouwen. Démarche Modi (overleg) 26 nov 2022 19:21 (CET)

Nee, ik gaf juist een bron voor het feit dat het CBS geen inwonertallen publiceert op woonplaatsniveau: op 23 nov 2022 21:22 (nu nog helemaal onderaan deze pagina). De suggestie dat wijken en/of buurten deel kunnen uitmaken van meerdere woonplaatsen, kwam doordat RonnieV ontdekte (om 22 nov 2022 00:18 en om 23 nov 2022 21:18) dat sommige wijken en buurten deel uitmaken van meerdere woonplaatsen en sommige van niet een, en ik vervolgens Allecijfers.nl tegenkwam met uitleg daarover (24 nov 2022 20:31). Zojuist heb ik even gezocht in het array voordat RonnieV gisteren aanpassingen deed: de wijkcodes 17010300, 17010301, 17010302, 17010309, 170104, 170105, 170106 en 17010709 komen 5 keer voor en 17010000 en 17010009 komen 2 keer voor. Een van de woonplaatscodes van de set die 5 keer voorkomt, hoort bij Dwingeloo: dat volgens ons 2745 inwoners heeft, en 4137 volgens Allecijfers.nl. Genoeg reden voor twijfel dus. Wikiwerner (overleg) 26 nov 2022 21:37 (CET)

@Wikiwerner Ok, maar hoe zit het dan met Rotterdam? Démarche Modi (overleg) 26 nov 2022 22:00 (CET)

En hier vinden en we een visuele weergave van de BAG indeling. Démarche Modi (overleg) 26 nov 2022 18:08 (CET)

De genoemde uitleg op Allecijfers.nl staat ook bij Rotterdam. Wikiwerner (overleg) 26 nov 2022 22:18 (CET)

Gaan we Allecijfers.nl nu als bron gebruiken voor onze eigen beweringen? Hoe kunnen wij zelf die twijfel aantonen? Op basis van informatie uit gezaghebbende bronnen. Démarche Modi (overleg) 26 nov 2022 22:23 (CET)

@Wikiwerner, dit heb ik kunnen vinden vanuit het CBS m.b.t. de inrichting conform WBI en BAG. Hierin is vermeld dat er een richtlijn bestaat waarbij woonplaatsen altijd geheel overeenkomen met een buurt of wijk. Hier lees ik vervolgens dat er wel degelijk binnen het CBS op basis van geodata een koppeling bestaat tussen de BAG en de buurten. Ik citeer: "Met ingang van 2012 wordt de koppeling van de buurtcode aan de adressen berekend uit de coördinaten van de adressen uit de Basisadministratie Adressen en Gebouwen (BAG).". Echter, wat lijkt te ontbreken, en dat is vermoedelijk te wijten aan de bovengenoemde richtlijn die nog niet volledig geïmplementeerd is, is dat er geen koppeling gepubliceerd is die de WBI-BAG beschrijft. We zien dat ook terug in het praktijkvoorbeeld Verspreide huizen Ekehaar (BU16802109) waarbij de richtlijn niet gevolgd is en het onmogelijk is om het inwoneraantal per woonplaats vast te stellen. Alle voorbeelden waarbij we wel per woonplaats de inwoneraantallen vastgesteld hebben zijn in feite gebaseerd op de aanname dat de inrichting WBI-BAG conform deze richtlijn (en onze verwachting) is. Dat blijft helaas een aanname.

@Ennomien, @RonnieV en @Dajasj; Dus, concluderend, mocht Dajasj of iemand anders hier de beschikking hebben over informatie waaruit de WBI-BAG koppeling gelegd kan worden, bijvoorbeeld op basis van door gezaghebbende bronnen gepubliceerde geodata, dan is dat nog de overweging waard. Zelf die geodata gaan onderzoeken valt mijns inziens onder WP:GOO en moeten we daarom niet doen. Dit inzicht brengt mij ertoe om vooralsnog niet verder te gaan met de invoer van (mogelijk foutieve) inwoneraantallen per woonplaats. Mocht er in de toekomst een gezaghebbende bron beschikbaar komen die aangeeft welke WBI-BAG indeling er is, dan is het wel mogelijk om die informatie toe te voegen. Daarmee kom ik tot de conclusie dat wij als Wikipedia, voor wat betreft de inwoneraantallen, niet verder zouden moeten gaan dan de gemeenten. Hiervoor is namelijk wel de juiste brondata beschikbaar en kunnen we als gemeenschap hard maken dat die informatie klopt.

Ennomien, ik betreur het dat ik tot deze conclusie ben gekomen. Echter, ik kan er niets anders van maken dan wat ik hier geschreven heb. De module kan volgens mij blijven bestaan maar dan zonder de inwoneraantallen. Mochten die in de toekomst toch beschikbaar komen dan kunnen we de module weer maken zoals die nu is. Dit haalt ook de huidige uitdagingen uit het project, we hoeven immers geen discussie meer te voeren, hier of in de gemeenschap, met betrekking tot wat wenselijk is. De BAG vertelt ons welke woonplaatsen er in een gemeente bestaan en die kunnen we tonen in de tabel. Als tussenoplossing is een 'toggle on/off' nog de overweging waard dat indien er op gemeentelijk niveau wel een geschikte bron is met inwoneraantallen per woonplaats, dat voor die gemeente de tabel uitgebreid wordt met inwoneraantallen. Echter, dit lijkt mij persoonlijk een onwenselijk scenario vanwege de mogelijke verschillen in de data (voornamelijk de jaartallen).

@Iedereen; aanvullende ben ik van mening dat we onze inspanningen moeten verleggen en dat we de bestaande onvolkomenheden (i.e. de inwoneraantallen per woonplaats) uit de arrays, infoboxen en artikelen zouden moeten verwijderen indien die gebaseerd zijn op CBS WBI gegevens. De misleidende arrays waarbij er een BAG-WBI indeling is dienen we te verwijderen. Voorts kunnen we daarover helder (wellicht na een peiling of stemming bindend) communiceren zodat ongewenste acties van andere Wikipedianen zonder al te veel poespas teruggedraaid kunnen worden. Vervolgens kunnen we ons, desgewenst, alvast voorbereiden op de toekomst: dat indien het CBS duidelijk publiceert met inwoneraantallen per woonplaats, dat we die dienovereenkomstig in Wikidata en de encyclopedie opnemen. Daarvoor een geschikte procedure inrichten op gemeentelijk niveau lijkt me een goede eerste stap. Démarche Modi (overleg) 27 nov 2022 16:24 (CET)

Voor mij niet acceptabel. Ik wacht reacties van de andere gespreksgenoten af. Ennomien (overleg) 27 nov 2022 21:10 (CET)

Hmm @Démarche Modi, stel dat we de geogrenzen wel kunnen matchen tussen bwi en bag, is het dan nog echt GOO? Ik vind dat redelijk onschuldige vergelijking van feiten. Risico is alleen dat er kleine insignificante verschillen in zitten. Dajasj (overleg) 27 nov 2022 21:28 (CET)

Mijns inziens is het essentieel voor Wikipedia dat er, gebaseerd op externe en gezaghebbende bronnen, informatie wordt gepubliceerd die onderbouwd kan worden. Indien er redelijke twijfel bestaat over de juistheid van die informatie, dan doet Wikipedia er verstandig aan die informatie niet te publiceren, of in geval van belangrijke onderwerpen dat er expliciet vermeld staat dat een externe gezaghebbende partij daar een bepaalde uitspraak of publicatie over heeft gedaan. Zelf uitingen gaan doen die mogelijkerwijze foutief kunnen zijn, hoe klein ook, hoort in principe niet op Wikipedia. In het geval van geodata, indien we kunnen aantonen dat op basis van brondata (hetzij van CBS, hetzij van Kadaster) een exacte match is tussen een wijk/buurt en een woonplaats, dan is dat geen GOO. Mits er geen datamanipulatie gedaan wordt om het gewenste resultaat te verkrijgen. Het hangt dan af van hoe de data te herleiden is (bron), de interpretatie van die data gedaan is (code) en hoe wij die informatie beschikbaar stellen voor het publiek (presentatie - visuele overlay of coördinaten lijsten vergelijk). Dat dient dus meer te zijn dan een berekening van een Wikipediaan vanachter het bureau die daarna stelt, 'check de data zelf maar, ik zeg dat het klopt, AGF'. Transparantie van bron tot conclusie is mijns inziens essentieel. In theorie is dit denkbaar (zie bijvoorbeeld de Arcgis website hoe geodata getoond kan worden, hoewel daar onduidelijk of niet transparant genoeg voor Wikipedia wat mij betreft) maar in de praktijk is het - voor mij nu in ieder geval - een brug te ver. Wellicht zijn er hier mensen die dit al wel kunnen, dan kom ik graag terug op mijn conclusie. Démarche Modi (overleg) 27 nov 2022 21:59 (CET)

Aanvullend: indien we geodata gebruiken voor de mapping, dan blijven er sowieso wijken/buurten over die niet overeenkomen. Verspreide huizen Ekehaar (BU16802109) (met de woonplaatsen Eldersloo en Eleveld) (Zie hier, layer=Administratief-Wijk 1995 tot huidig) is daar een voorbeeld van. We kunnen hoe dan ook maar een (overgroot meren)deel gebruiken. @RonnieV, fyi, die arcgis bron toont aan dat zowel Balloërveld als Marwijksoord bij Rolde horen. Overigens een interessante visualisatie door ESRI, er is zeker iets mogelijk met geodata. Démarche Modi (overleg) 27 nov 2022 22:51 (CET)

@Démarche Modi, even reageren op dit laatste stukje.

Rolde (168019) is een wijk binnen de gemeente Aa en Hunze (1680). De wijk bestaat uit meerdere buurten.

Rolde is een zelfstandige woonplaats, net als Balloërveld en Marwijksoord. Woonplaatsen worden in een zogeheten woonplaatsenbesluit vastgesteld door de betreffende gemeente(raad). Veruit de meeste woonplaatsen zijn in 2008 vastgesteld.

Volgens Arcgis liggen Balloërveld en Marwijksoord binnen de wijk Rolde (168019). Dat wil echter nog niet zeggen dat ze bij die (woon)plaats horen. Ook is niet duidelijk uit Arcgis tot welke buurt ze wel behoren.

De gemeente Nuenen heeft in haar woonplaatsbesluit (2 oktober 2008, helaas een onveilige link), juist besloten dat de gehele gemeente als een woonplaats wordt aangeduid, zoals Waddinxveen dat ook gedaan heeft.

De grenzen van de woonplaatsen zijn bekend, of in ieder geval te achterhalen. Deels lopen die samen met grenzen van buurten (arcgis zoomt niet verder in dan wijken), deels zullen er soms meerdere woonplaatsen in een buurt vallen (zoals Balloërveld, waarvan we een inwonertal hebben uit 2016 dat niet te rijmen valt met een van de specifieke buurten in de wijk Rolde), maar veelal zullen woonplaatsen een aantal buurten omvatten. Waar een gemeentegrens door een woonplaats loopt, worden hier in BAG standaard meerdere woonplaatsen van gemaakt, zoals bij Achterveld.

Met vriendelijke groeten, RonnieV (overleg) 28 nov 2022 15:08 (CET)

Tsja, het is mij in ieder geval duidelijk dat wij in veel gevallen - nog - niet met zekerheid kunnen stellen dat de BAG grenzen overeenkomen met de WBI grenzen. Arcgis is geen gezaghebbende bron. BAG is duidelijk welke woonplaatsen er zijn, daarvoor is geen lokaal besluit vereist. Wat ons ontbreekt is de mapping naar WBI grenzen van het CBS. De BAG en CBS geodata zijn beschikbaar en mogelijk bieden deze bronnen de benodigde informatie om vast te stellen dat grenzen wel/niet overeenkomen. Démarche Modi (overleg) 28 nov 2022 15:50 (CET)

Het is precies andersom: de BAG-wwonplaatsenlijst volgt uit de gemeentelijke woonplaatsbesluiten. Bij de besluiten zit een kaart waarin precies is aangegeven welk deel van de gemeente tot welke woonplaats behoort. Daarmee heb je een complete, en wettelijke, dekking.

De geografische informatie van al die woonplaatsbesluiten zou, in samenhang met een grafische presentatie van de buurtenindeling van CBS (een CBS-wijk is een samenvoeging van een of meer buurten) een oordeel geveld moeten kunnen worden welke woonplaatsen wel en welke niet samenvallen. Hou ook in de gaten dat de inwonertallen per buurt en per wijk afgerond zijn. Ik zie soms ('mijn' lijst) afwijkingen die groter zijn dan onze eerder genoemde 2 personen per woonplaats per gemeente, want verklaard kan worden omdat er meerdere buurten en wijken tot een woonplaats worden samengevoegd. Valt het aantal binnen 2 x het totale aantal onderscheiden/benodigde eenheden, dan is dat mogelijk een afronding. Het grote verschil bij Utrecht zou dan ofwel zijn ontstaan omdat er heel veel buurten zijn die naar boven worden afgerond, terwijl de wijken allemaal naar beneden worden afgerond, of toch ergens door een verkeerde waarde. Ik heb nog niet de optelling van de buurtbewoners per wijk gemaakt om te kijken of ik daarmee tot een nadere verklaring kan komen. RonnieV (overleg) 28 nov 2022 17:12 (CET)

Waarom 345 bronnen hanteren indien er een bron is met dezelfde informatie? Démarche Modi (overleg) 28 nov 2022 17:26 (CET)

@Ennomien, kun je aangeven wat er niet acceptabel is? Bedoel je daarmee dat het niet acceptabel is om twijfelachtige gegevens te gebruiken of bedoel je dat het niet acceptabel is om de module niet te gebruiken zoals we dat beoogden? Démarche Modi (overleg) 27 nov 2022 22:21 (CET)

Ik had niet door dat mijn reactie dubbelzinnig zou kunnen zijn. Ik kan het niet accepteren dat het hele project wordt stopgezet om een paar gemeentes waar het misgaat. Maar als wij een bron hebben die zegt A heeft X inwoners en een bron (al dan niet visueel) A ligt in B dan doen wij niks meer dan het combineren van bronnen en dat is toegestaan volgens GOO. Dat het dan soms (net) niet overeenkomt vind ik geen reden om er maar mee op te houden. Sowieso is dit project een flinke verbetering van de huidige situatie. Zou je een voorbeeld kunnen geven van waar het niet goed gaat, dan weet ik ook waarover ik precies praat. Ennomien (overleg) 28 nov 2022 12:58 (CET)

Je overdrijft nu volgens mij, ik heb niet gezegd dat we dit project moeten stoppen en er zijn voorbeelden gegeven waar het misgaat. Wat betreft Maar als wij een bron hebben die zegt A heeft X inwoners en een bron (al dan niet visueel) A ligt in B dan doen wij niks meer dan het combineren van bronnen en dat is toegestaan volgens GOO. > Dat is te kort door de bocht geformuleerd. Waar het om gaat is dat de woonplaatsgrenzen overeenkomen met de wijk- en buurtgrenzen. Waar die niet overeenkomen kunnen we de gegevens van het CBS niet gebruiken. Die overeenkomst kunnen we - vooralsnog - niet aantonen en dat is wat mij betreft een blokkerend issue voor het gebruik van de inwoneraantallen per woonplaats. Démarche Modi (overleg) 28 nov 2022 14:32 (CET)

Ik ben het met @Ennomien eens dat jouw opmerkingen van 27 nov 2022 16:24 wel zo overkomen als dat jij het hele project maar wil stilleggen, of in ieder geval jouw handen ervan aftrekt.

Zonder nader onderzoek beweren dat wij in veel gevallen - nog - niet met zekerheid kunnen stellen helpt ook niet om het project verder af te maken. Wat vind jij veel? In hoeveel gevallen hebben we nu wel het juiste aantal? Welke verbeteringen zijn er al bereikt (aanpassingen aan de array)? En over welke marge hebben we het?

In de beschrijving van ons proces tot nu toe ontbreekt feitelijk een derde component, namelijk de BRP. BAG geeft aan wat de precieze coördinaten zijn van een woning en wat het adres is. Op grond van die coördinaten en het woonplaatsbesluit is duidelijk in welke woonplaats een woning staat. BRP vertelt hoeveel inwoners er op 1 januari 2021 (of welke datum dan ook) op dat adres staan ingeschreven. CBS haalt gegevens uit BRP en weet dan dat er op de Kerkstraat 3 in Lutjebroek vijf mensen staan ingeschreven. Met de coördinaten van Kerkweg 3 worden die mensen aan een bepaalde woonplaats toegewezen, en aan een bepaalde buurt.

Of de koppeling WBI-BAG gepubliceerd is, maakt in mijn ogen niet zo heel veel uit. Waar die ons wel mee zou kunnen helpen, is om vast te stellen dat een deel van buurt x in de wijk Rolde in de gemeente Aa en Hunze valt onder de woonplaats Balloërveld en de rest onder de woonplaats Rolde (of wellicht een derde, vierde,... woonplaats). Alle buurten die eenduidig zijn toe te wijzen aan een woonplaats, zijn voor mij opgelost voor dit project. De onduidelijke woonplaatsen moeten we anders oplossen. Bijvoorbeeld het inwonertal van Balloërveld uit de gemeentegegevens halen (kijken of er ergens nieuwere te vinden zijn dan 1 januari 2016) en wellicht de gegevens voor die buurt volledig baseren op die peildatum. RonnieV (overleg) 28 nov 2022 17:38 (CET)

Tsja, lees mijn bijdragen dan nogmaals. Ik heb bij Ennomien reeds aangegeven dat ik het project niet stil wil leggen maar dat wij op de huidige manier niet met zekerheid kunnen vaststellen dat de inwoneraantallen kloppen. Daar trek ik vervolgens bepaalde conclusies uit en dat is voldoende uitdaging om de komende week (of langer?) zoet te zijn. Door de bewijslast om te draaien ben je in mijn optiek projectverstorend bezig en ondermijn je Wikipedia. We hebben immers aangetoond dat er onduidelijke of foutieve informatie in dataset en de array zit en daarmee in de huidige methodiek. Die methodiek in een ander jasje (lees Wikidata-Module) stoppen verandert daar niets aan. Het zou voldoende moeten zijn dat indien er in enkele gevallen van een dataset of methodiek redelijke twijfel en onmogelijke koppeling bestaat dat dan de methodiek geen stand houdt en dat daar eerst een geschikte oplossing voor moet komen. Voorts trek ik nergens mijn handen vanaf, ik ben hier volgens mij nadrukkelijk met jullie in overleg. Het lijkt er alleen op dat jullie mijn bijdragen niet goed gelezen hebben en/ of willen begrijpen. Het kan toch niet zo zijn dat je een foutieve methodiek doordrukt om maar een inwoneraantal te tonen, om maar te kunnen zeggen, 'poe poe, kijk eens wat we gedaan hebben'. Terwijl je weet dat de nietsvermoedende lezer van foutieve informatie wordt voorzien. Démarche Modi (overleg) 28 nov 2022 18:03 (CET)

Ik deel jouw zwarte kijk op de wereld niet.

Het klopt dat er foutjes in de array zaten. Een groot deel daarvan hebben we al weten op te lossen.

Het klopt dat we voor een paar woonplaatsjes hebben waar een uitdaging ligt, waar we op een andere manier de inwonertallen van moeten zien te achterhalen, zoals Balloërveld. Dat is in mijn ogen echter geen reden om niet bij de woonplaatsen waar geen gerede twijfel over de aantallen bestaat, deze aantallen niet op Wikidata toe te voegen, of deze getallen in Wikipedia te presenteren in infobox en via de module.

Dat staat in mijn ogen inderdaad lijnrecht tegenover jouw voorstel om arrays, infoboxen en artikelen (te) verwijderen. Verbeteringen aanbrengen is prima, dat is wat velen hier dagelijks doen. maar dat is iets anders dan maar klakkeloos van alles verwijderen omdat er misschien wel ergens een onvolkomenheid in zou kunnen bestaan. Ik zou er niet vanuit durven gaan dat alle cijfers van het CBS zonder meer kloppen, andere bronnen zijn evenmin feilloos. Ze zijn wel een gerespecteerde bron voor informatie, en mogen gebruikt worden. Let wel, dit is geen oproep om bewust onjuiste informatie in Wikidata op te gaan nemen, wel een oproep om gegevens die we als zeker mogen aannemen te publiceren en te gaan gebruiken. Als we altijd overal gaan zitten wachten totdat de wereld en het beeld daarvan perfect is, dan wordt er nooit iets gedaan. RonnieV (overleg) 28 nov 2022 18:31 (CET)

Ik heb geen zwarte kijk op de wereld RonnieV. Dat is jouw interpretatie en daarvoor draag ik geen enkele verantwoordelijkheid. Indien je me beter zou kennen dan zou je je woorden beter wegen en meer begrip tonen voor mijn inbreng. Voorts bestaat er altijd de mogelijkheid dat een bron onjuiste informatie bevat, echter dat is heel wat anders dan wanneer we bij ons zelf een foutieve methodiek aan het licht brengen. Dat zijn twee verschillende zaken, de eerste daar hebben we geen invloed op, de tweede wel. Tevens lees je mijn bijdrage fout. Ik heb nergens gezegd dat de infoboxen en artikelen verwijderd dienen te worden. Verder is jouw redenatie om aannames voor lief te nemen een bron voor fouten. Kies voor de juiste methodiek en dan is het risico van foutieve gegevens beheerst. Kies voor een versnipperde aanpak per woonplaats (x 2500) en het risico op foutieve gegevens is groot. Goh, hoe luidde die oneliner ook alweer? 'Assumption is the..." Wat betreft jouw idee om de BRP te gebruiken, dat lijkt me niet de juiste aanpak. Het CBS komt met de statistieken. BRP geeft niet altijd alle informatie, bijvoorbeeld in het geval iemand een geheim adres heeft. Die aantallen kunnen dus een vertekend beeld geven. Tenzij je natuurlijk een datalek bij het Kadaster weet te gebruiken. Maar daar zou ik niet al teveel hoop op vestigen. Desalniettemin ben ik benieuwd of ik er niet naast zit. Dus, hoe zou de methodiek met de BRP ons van de juiste aantallen kunnen voorzien? Démarche Modi (overleg) 28 nov 2022 18:44 (CET)

Ik heb gesproken met iemand van CBS, hoewel niet iemand die hier expert op is. Werd me duidelijk dat er geen garantie is dat inderdaad buurt- en woonplaatsgrenzen matchen. We kunnen dus matchen op geo en kijken hoe ver we komen. De oorspronkelijke aanmaker doet ook iets met postcodes, zie hier. Ben ook wel benieuwd daarnaar, hopelijk reageert de gebruiker.. Dajasj (overleg) 28 nov 2022 23:10 (CET)

Ooh mensen, ik wou dat ik deze bron en dan specifiek de 'Datasets' Overige Kaarten - Basisregistratie Adressen en Gebouwen (BAG) - Woonplaatsen EN CBS Gebiedsindelingen 2022 Buurt gegeneraliseerd - Wijk gegeneraliseerd - Gemeente gegeneraliseerd. en de aanverwante labelpoints, eerder had gevonden. Dit is namelijk een viewer van het Kadaster met CBS gegevens erin. Door voorgenoemde datasets aan te zetten zien we de overlap en verschillen op buurtniveau en woonplaats. Zodra je iets aanklikt krijg je rechtsonder in het scherm 'Object informatie' te zien en kan er eenvoudig op de verschillende niveaus' geklikt worden. Morgen hoop ik me hier verder in te verdiepen en ik hoop dat jullie daar ook gelegenheid toe zien. Mijn oprechte excuses dat ik dit niet eerder gevonden heb. Démarche Modi (overleg) 29 nov 2022 00:19 (CET)

Goed nieuws! Maakt me nog een beetje hoopvoller dan zonet, zie bws (had je bericht toen nog niet gelezen). Mvg, Ennomien (overleg) 29 nov 2022 00:24 (CET)

FYI; wegens omstandigheden pak ik dit vandaag niet verder op. Démarche Modi (overleg) 29 nov 2022 16:58 (CET)

@RonnieV, @Wikiwerner, @Ennomien, @Dajasj en andere geïnteresseerden, is het mogelijk wat jullie betreft dat we consensus bereiken dat de hier genoemde bron als leidraad gebruikt dient te worden om aan te tonen dat de woonplaatsgrenzen overeenkomen met de wijk/ buurtgrenzen? En dat indien die niet overeenkomen, dat we de inwoneraantallen dan ook niet gebruiken? Indien we die overeenstemming weten te bereiken dan stel ik voor om het stelselmatig per gemeente af te handelen. Daar wil ik dan wel een overzicht voor samenstellen. Voor de komende jaren kan dat hopelijk als baseline gebruikt worden. Vanuit het CBS kunnen we vervolgens achterhalen welke wijken/buurten gewijzigd zijn in een nieuw jaar. Tenminste, als ik die 1-2-3 parameter goed begrepen heb. Vanuit het Kadaster kunnen we hopelijk ook vaststellen welke wijzigingen er zijn met betrekking tot de woonplaats(grenz)en in een nieuw jaar. Op dit moment is dat deel, wijzigende woonplaatsgrenzen, mij nog onduidelijk. Indien iemand daar meer informatie over heeft dan is dat volgens mij erg waardevol. Démarche Modi (overleg) 30 nov 2022 11:58 (CET)

Wat mij betreft prima, met als kleine wijziging dat indien die niet overeenkomen, we kijken of er nog een andere betrouwbare bron is en anders zit er inderdaad niks anders op. Zijn er al gevallen bekend waar die niet overeenkomen? Ennomien (overleg) 30 nov 2022 18:54 (CET)

Heb je een andere betrouwbare bron? Ik denk namelijk dat Kadaster (BAG) en CBS (WBI) de enige twee bronnen zijn. Voorbeelden: op Texel viel me Oudeschild op, in Limburg de wijk 2022BU09710002 (Stein/ Elsloo), Eleveld en Eldersloo waren al genoemd en verder heb ik nog niet gekeken. Achteraf kunnen we precies aangeven hoeveel van de 2501 woonplaatsen afwijkende grenzen hebben. Hoe ik ze vind? Klik een woonplaats aan en vervolgens klik ik alle buurten aan die ik binnen de woonplaats zie. Indien er dan een selectie buiten de woonplaats zichtbaar wordt, dan komen de grenzen niet overeen. Uiteraard met de datasets 'buurt_gegeneraliseerd' en BAG aan. Démarche Modi (overleg) 30 nov 2022 19:11 (CET)

Ah oké, op die manier. Ik denk dat we altijd tegen die tijd kunnen kijken hoe we dat zouden kunnen oplossen, of toch moeten gaan omzeilen. Ennomien (overleg) 30 nov 2022 20:08 (CET)

Ik kan akkoord gaan met het gebruik van de viewer van pdok als hulpmiddel om te kijken wat de verschillen zijn in de grenzen. Zijn er geen verschillen (dat wil zeggen een woonplaats bestaat uit een of meer complete buurten en verder niets), dan is het eenvoudig. Zijn er minimale verschillen, dan moeten die beoordeeld worden. Zo zie ik in de noordwesthoek van Waddinxveen een minimaal verschil tussen de grenzen, maar hier zit geen woning tussen. Dan zie ik dat als een niet-significante afwijking en zou ik de gegevens zo gebruiken. Is het verschil groot (verspreide huizen Rolde), dan moeten we kijken naar andere bronnen. Zo hebben we voor de woonplaats Balloërveld al een inwonertal uit 2016 achterhaalt bij de gemeente. Zijn er meer woonplaatsen waar dit voor speelt, dan moeten we dus gewoon gaan zoeken naar betrouwbare gegevens. Gemeenten aanschrijven kan daarbij prima, zeker met de WOO achter de hand. Het is lastig als we woonplaats- en gemeentecijfers van verschillende data hebben, niet onoverkomelijk. RonnieV (overleg) 1 dec 2022 22:07 (CET)

Eens met RonnieV. Dajasj (overleg) 3 dec 2022 13:16 (CET)

@29 nov 2022 00:19 (CET): Inderdaad een goed idee! De gemeenten waarvoor dit opgaat, kunnen we misschien snel vinden:

1. Laat de module tijdelijk niet de inwonertallen ophalen uit Wikidata, maar door het retourneren van de wikitekst {{Statistiek woonplaats Nederland inwoners|woonplaatscode}}. Dit sjabloon werkt met het optellen van gehele wijken en/of buurten. De woonplaatscode kan uit Wikidata komen, of uit de {{infobox plaats in Nederland}}; de eerste lijkt mij het makkelijkst.
2. Maak daarmee een overzichtspagina aan met een woonplaatstabel voor elke gemeente.
3. Als het totaal van de woonplaatsen binnen een gemeente gelijk is aan het CBS-aantal van de hele gemeente (binnen een zeker afrondingsverschil), dan is dat het bewijs dat de woonplaatsen bestaan uit gehele wijken en/of buurten. In andere gevallen is nader onderzoek nodig: welke woonplaatsen bestaan wel uit gehele wijken en/of buurten en welke niet?

Wikiwerner (overleg) 3 dec 2022 14:52 (CET)

@Wikiwerner Levert deze aanpak niet zogenaamde foutpositieven op? Bij deze aanpak gaan we er immers vanuit dat de gegevens in Wikipedia correct zijn, terwijl we reeds aangetoond hebben dat dit niet altijd het geval is. En, terugkomend op jouw eerdere zorgen omtrent de vaststelling van de inwoneraantallen in Rotterdam, hoe kunnen we met deze methode vaststellen dat in dergelijke gevallen dan wél de aantallen correct zijn en juist zijn vastgesteld? Démarche Modi (overleg) 4 dec 2022 13:58 (CET)

De fout op Wikipedia is juist dat wordt aangenomen dat woonplaatsen altijd bestaan uit een (combinatie van) hele wijken en/of buurten, en dat hebben we ontkracht. Een voorbeeld is inderdaad Rotterdam: het totaal van de woonplaatsen = 651.530 en de gemeente had er 652.541 in 2021 (code 0599), dus daar faalt stap 3.

En ja, het kan gebeuren dat er een flink verschil is tussen de gemeente en het totaal van de woonplaatsen, terwijl de woonplaatsen toch allemaal bestaan uit een (combinatie van) hele wijken en/of buurten. In dat geval lopen we onterecht de woonplaatsen in die gemeente na m.b.v. de site die jij gaf. Het alternatief is dat we alle 2501 woonplaatsen daarmee nalopen. Dus zeg het maar ... Wikiwerner (overleg) 4 dec 2022 14:43 (CET)

Ik weet niet zeker of ik je kan volgen en of mijn vraag of deze procedure geen foutpositieven oplevert beantwoord is. De hoeveelheid data is daarvoor simpelweg te groot en mogelijk is de methode gebaseerd op de aannames dat de woonplaatscodes van alle correcte wijken/buurten is voorzien en dat de inwoneraantallen kloppen. Daar zit volgens mij het probleem en ik zie nog niet hoe je op deze manier dat probleem verhelpt. Het argument dat het alternatief is dat we 2501 woonplaatsen langs moeten lopen houdt volgens mij geen stand omdat we nu juist op zoek zijn naar de methode om te bewijzen dat die 2501 woonplaatsen correct gevuld zijn. Een bulkcontrole uitvoeren op oude data levert niet per se de bewijslast dat het nu wel klopt. Overigens, wanneer we de PDOK methode op Rotterdam uitvoeren voor 2022 dan zien we 123 verschil, nog steeds te groot maar dat is mogelijk te wijten aan de afronding op buurtniveau. En dan zou het zo maar kunnen kloppen. Maar dat is een aanname van mij. Mijns inziens is het hele eierreten dat we genoodzaakt zijn om alle gemeenten en woonplaatsen langs te lopen omdat er in de loop der tijd fouten in de gegevens zijn ontstaan. 345 gemeenten, 5 personen, dus 69 gemeenten per persoon. Bij gemiddeld 1 per dag is dat ongeveer 2 maanden doorlooptijd. Wat mij betreft acceptabel, mits we beschikbaar en gemotiveerd zijn uiteraard. Démarche Modi (overleg) 4 dec 2022 15:28 (CET)

Het "bewijzen dat die 2501 woonplaatsen correct gevuld zijn" kunnen we dus ook doen door alle 2501 woonplaatsen na te lopen met jouw website. Geef jij anders eens een reden waarom er toch fouten in zitten, als ons totaal van de woonplaatsen gelijk is aan het officiële inwonertal van de gemeente, uiteraard binnen afrondingsmarges? Overigens heb ik nog steeds geen antwoord op mijn vraag aan het begin van dit kopje, om 26 nov 2022 16:39, terwijl je die inwonertallen wel al in Wikidata gezet hebt. Wil je deze nog beantwoorden? Wikiwerner (overleg) 4 dec 2022 16:01 (CET)

Zie de pdoc website van het Kadaster, wat overigens niet 'mijn website' is. Daar meen ik te constateren dat Rotterdam wel degelijk correct ingedeeld is en dat allecijfers.nl er naast zit. Maar ik kan me natuurlijk vergissen. Overigens is het niet mijn taak om na deze lange discussie met voorbeelden te komen die aantonen dat er nog meer fouten in het eindresultaat zitten. Simpelweg aantonen dat de huidige methodiek soms faalt (en dus in theorie ook valse positieve resultaten zou kunnen laten zien _{(Het gaat immers niet om de aantallen op gemeentelijk niveau, dat is eenvoudig, gegeven de CBS data. Het gaat om de veel lastigere aantallen op woonplaatsniveau. Een foutieve optelsom kan alsnog het verwachte totaal per gemeente tonen.)}) zou vanuit een academisch perspectief voldoende moeten zijn om die methodiek en de bijbehorende resultaten te verwerpen en te zoeken naar een methodiek die wel de beproeving, die we logischerwijs kunnen bedenken en uitvoeren, doorstaat.

Enfin, ik begrijp dat we op dit punt nog geen consensus kunnen bereiken. Zou je als je er tijd voor en zin in hebt eens willen kijken naar Rotterdam, de CBS aantallen en de kadastrale indeling (PDOC) en dan willen heroverwegen of deze voorgestelde methodiek beter is dan de huidige die gebaseerd is op Wikipedia's bestaande gegevens? Mocht er onverhoopt toch nog iets niet kloppen in de aanpak via pdoc, dan moet daar nog even goed naar gekeken worden. Démarche Modi (overleg) 4 dec 2022 17:01 (CET)

Je geeft weer geen antwoord op mijn vraag, wat inmiddels vervelend begint te worden. Nogmaals: als het officiële cijfer van de gemeente (bijna) gelijk is aan het totaal van de woonplaatsen, slechts dan vind het voldoende aannemelijk dat we geen wijken en/of buurten dubbel tellen. Ik stel juist voor om de fouten te vinden door te kijken waar deze 2 cijfers van elkaar verschillen. Maar jij vindt het dus niet aannemelijk dat we geen woonplaatsen dubbel tellen als de 2 cijfers gelijk zijn? Dan rest niks anders dan het nalopen van alle andere bijna 2500 woonplaatsen a.d.h.v. 'jouw' pdoc-website (= de website die jij aanhaalde), net zoals je zojuist gedaan hebt voor de gemeente Rotterdam.

En nogmaals: waar komen jouw cijfers vandaan? Wikiwerner (overleg) 4 dec 2022 17:53 (CET)

Deze discussie begint onderhand aardig zinloos te worden in mijn optiek. Heb je nu de hakken in het zand gezet omdat ik de door jou herhaaldelijk aangehaalde en kwalitatief slechte bron 'allecijfers.nl' onderuit gehaald heb of doe je dat omdat jouw voorstel om de module te herprogrammeren zodat deze een (potentieel misleidende) controle kan uitvoeren door mij als onvoldoende wordt bestempeld? Wat begrijp je niet aan foutpositief? Het gaat niet om de gemeente maar om de woonplaats. Stel twee woonplaatsen bevinden zich in een buurt en de ene woonplaats krijgt het totaal van die buurt en de andere woonplaats niets, dan zien we niets aan het totaal in de gemeente en kloppen beide aantallen niet (=foutpositief). Terwijl beide woonplaatsen een eigen inwoneraantal zouden moeten hebben. (Verspreide huizen Ekehaar) En welke bron staat er vermeld op Wikidata? Die bron kan bekeken worden en als je wil kan je ook de code zien bij de voorbeeldpagina. Volgens mij geef ik ruim voldoende en duidelijk antwoord op jouw vragen. Tevens zou ik je willen vragen om iets respectvoller met me om te gaan, het is nadrukkelijk niet mijn website maar de website van het Kadaster, de gezaghebbende bron en een autoriteit in de materie van woonplaatsen. Démarche Modi (overleg) 4 dec 2022 18:33 (CET)

Wederom lees je blijkbaar niet goed. Ik geef het op. Sterkte met de bijna 2500 overgebleven woonplaatsen.

De bron op Wikidata is CBS Statline. Maar het CBS geeft helemaal geen inwonertallen van woonplaatsen, zoals ik ook al eerder heb aangegeven. Wikiwerner (overleg) 4 dec 2022 19:13 (CET)

CBS is degene die de statistieken per gemeente, wijk en buurt publiceert. Ook dat is hier ruimschoots aan bod gekomen en je eigen voorstel om tellingen te doen gaat uit van diezelfde wijk/buurt indeling. Afwijkingen (per RonnieV) kunnen elders gevonden worden, maar dat zijn uitzonderingen. Volgens mij is dat zo helder als het maar kan en dat het CBS niet per woonplaats maar per (soms afwijkende) buurt rapporteert is precies het euvel waar wij tegenaan lopen. Enfin, dank je wel voor het hart onder de riem. Kan daaruit opgemaakt worden dat je je handen er vanaf trekt en het verder aan de anderen overlaat? Gegeven jouw bijdragen hier en op andere plaatsen omtrent inwoneraantallen op Wikipedia zou ik dat erg jammer vinden. Een nieuwe aanpak dient immers gedragen te zijn door de gemeenschap, er zou consensus moeten zijn. Geen consensus en doordrukken is tamelijk zinloos en zonde van de inspanning. Indien we nu geen consensus kunnen bereiken, wat is daar dan nog voor nodig? Wellicht kunnen we daar later, na vandaag, overleg over voeren. Dit onderwerp speelt al een tijdje en volgens mij hebben we geen haast. Démarche Modi (overleg) 4 dec 2022 19:45 (CET)

Ik zal het even overnemen van Wikiwerner, ik hoop dat hij dat waardeert en dat ik hem goed begrijp.

Volgens Wikiwerner valt de woonplaats Rotterdam niet volledig samen met de gemeente en ook niet met verschillende wijken en buurten bij elkaar opgeteld, met als bron Allecijfers.nl. @Démarche Modi, hoe heb je voor de woonplaats Rotterdam dan toch het inwoneraantal berekend? Als gelijk aan de gemeente, een optelsom van buurten/wijken (welke, en welke bron?) of anders? Of Allecijfers.nl gelijk heeft maakt daarbij niet uit, hij vraagt zich volgens mij alleen af hoe je dat inwoneraantal hebt berekend.

@Wikiwerner, jij stelt dat indien het gemeente-inwoneraantal min of meer overeenkomt met de som van de buurten/wijken volgens de arrays hier, er geen fouten zijn (goed verwoord?). DM zegt dat delen van die som fout zouden kunnen zijn, maar het totaal nog wel goed en we die dan niet detecteren. (plaats A: 2000 inwoners, B 5000. Foute data: 3 en 4 duizend. Optelsom is goed, maar in de som gaat er dan wel iets fout). Misschien dat jullie adhv dit of een ander simpel voorbeeld jullie kunnen verwoorden, dat werkt vast beter. Ennomien (overleg) 5 dec 2022 15:11 (CET)

Optelsom wijken/buurten per CBS Statline, grenzen/indeling later gecontroleerd per Kadaster PDOC na de geüitte zorgen van Wikiwerner. Démarche Modi (overleg) 5 dec 2022 17:03 (CET)

Nee, de som van de woonplaatsen moet (bijna) gelijk zijn aan het gemeente-inwoneraantal. Als een wijk deel uitmaakt van 2 woonplaatsen waardoor die bij beide woonplaatsen volledig meegeteld wordt, dan wordt deze dubbel geteld in de som van de woonplaatsen (zie 26 nov 2022 18:12).

En @DM: opnieuw vermeld je niet hoe je bepaalt welke buurten samen een woonplaats vormen. Het CBS publiceert die gegevens niet. Hoe doe je dat dan, voordat je die bepaling controleert a.d.h.v. PDOC? Wikiwerner (overleg) 5 dec 2022 21:10 (CET)

Ok Wikiwerner. Ik laat het voorlopig even aan de anderen over. Je reactie raakt kant noch wal. Je mag Rotterdam nalopen a.d.h.v. statline en pdoc en aangeven indien er iets fout is gegaan. Indien het goed is gegaan verneem ik het ook graag. Fijne avond. Démarche Modi (overleg) 5 dec 2022 21:37 (CET)

@DM, je zegt "... later gecontroleerd per Kadaster PDOC na de geüitte zorgen van Wikiwerner." Hoe heb je dat dan daarvoor gedaan?

@Wikiwerner, dat zeg ik toch? Indien een wijk/buurt dubbel geteld is, komen de totalen niet overeen en is er iets fout. Anders, als de totalen min of meer overeenkomen, zou jij het dus aannemelijk vinden dat er geen fouten zijn (gisteren, 17:53). Toch? Dan zal ik de vervolgvraag van DM opnieuw stellen. (Ik probeer alleen maar te helpen.) Ennomien (overleg) 5 dec 2022 22:40 (CET)

(fyi) Démarche Modi (overleg) 5 dec 2022 23:19 (CET)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘

Oké, even terug naar wat we wél hebben en terug naar links. We hebben bijna alles: inwoneraantallen, een goede gespreksgroep, een werkende interface en de benodigde kennis/intelligentie. We missen (nog) één ding: de middelen voor de omzetting van inwoneraantallen behorend bij buurten/wijken naar inwoneraantallen voor woonplaatsen. Démarche Modi heeft daar een mooie en betrouwbare/gezaghebbende tool voor gevonden, de PDOK Viewer. Als de verschillende grenzen daar overeenkomen/samenvallen, dan zit niks ons meer in de weg. Als die niet (exact) overeenkomen, hebben we een "probleem". Ik stel voor dat we die verschillen (hoe klein dan ook?) op gaan slaan in een tabel zodat we daar later naar kunnen kijken. Of we dat ook met heel kleine verschillen doen, kunnen we over praten. Als ik het goed begrijp zijn er genoeg gemeenten waar dat probleem zich niet voordoet en waar we dus niet meer over hoeven te overleggen, toch? Er is helemaal geen hindernis meer, maar het gesprek liep vast toen Démarche Modi en Wikiwerner elkaar niet meer goed begrepen. Als dat gesprek nog moet worden voortgezet, gaat uw gang. Ik zou het prachtig vinden als we dit project nog dit jaar kunnen gaan uitvoeren. Met vriendelijke groet, Ennomien (overleg) 13 dec 2022 19:18 (CET)

Zo'n lijst met afwijkende woonplaatsen kan handig zijn, maar is alleen waardevol indien je er in de toekomst ook echt iets mee kan. Tevens vergeet je dan eventueel wijzigingen in 'goede' woonplaatsen. Volgens mij is het verstandig om eerst duidelijk te formuleren hoe we in de toekomst omgaan met wijzigingen vanuit het Kadaster en het CBS. Eerder reageerde ik op @Dajasj met deze bijdrage waarna @RonnieV me terecht aanvulde, echter ik kan dat nu niet meer terugvinden op deze pagina. Zodoende kom ik nu, helaas, ook met de opmerking dat het erg onhandig is om het overleg te herschikken. Daar zal ongetwijfeld een goede bedoeling achter zitten, maar het maakt de discussie in mijn optiek niet duidelijker. Als verbeterpunt wat dat betreft is het handiger om de discussie gewoon op zijn natuurlijke beloop te laten en de belangrijkste punten (besluiten, actiepunten, onderzoeksvragen, enzovoorts) te organiseren op een andere pagina.

Na mijn op- en aanmerkingen met betrekking tot de recentelijke inbreng van Wikiwerner heb ik aangegeven het voorlopig even aan de anderen over te laten. Daar blijf ik vooralsnog bij omdat ik mijn punt heb gemaakt. Anderen kunnen hun inhoudelijke inbreng op de kwestie (nut en noodzaak om data analyse te doen door 'productiecode' te wijzigen waarbij (alleen ik?) de kwaliteit van de analyse betwijfel), die ontstond na het vragen om uit te spreken over consensus, geven. Zolang Wikiwerner (of jullie) zich daar niet over uitspreken - hetzij dat hij zich kan vinden in de aanpak via PDOC/Statline, hetzij dat hij zich er niet in kan vinden maar zich bij de meerderheid neerlegt, hetzij dat hij met een beter voorstel komt - hebben we wat mij betreft een patstelling.

Overigens verdient het sowieso onze aandacht om eerst duidelijk te formuleren hoe het Kadaster wijzigingen doorvoert en hoe wij daarvan op de hoogte gebracht kunnen worden. Zodra we 2501 woonplaatsen verwerkt hebben willen we volgend jaar toch eenvoudiger een update kunnen doorvoeren, nietwaar? Een gewijzigde parameter van het CBS (IndelingswijzigingenWijkenEnBuurten is niet 1) is volgens mij een trigger, wat rest zijn wijzigingen in de tweede bron, de woonplaatsgrenzen van het Kadaster.

Voorts ben ik sowieso niet in de gelegenheid om dit project nog dit jaar af te ronden en kan ik daarna over mijn beschikbaarheid (voor relatief arbeidsintensief bureauwerk) nu nog geen toezeggingen doen. Waarom zouden we ons überhaupt zo'n deadline opleggen? Démarche Modi (overleg) 13 dec 2022 20:23 (CET)

Volgens deze bron, wat op een redelijk formele handleiding van de BAG lijkt (maar op Github? is imbag formeel van het Kadaster/BAG?), dienen we voor gewijzigde woonplaatsgrenzen de verschillende woonplaatsbesluiten (x 345) te raadplegen. Nu vraag ik me af of de CBS parameter (IndelingswijzigingenWijkenEnBuurten) dat niet ook al omvat... anders komen we toch uit op de woonplaatsbesluiten die @RonnieV eerder ook aanhaalde. Démarche Modi (overleg) 13 dec 2022 20:51 (CET)

Iets specifiekere bron url: https://imbag.github.io/praktijkhandleiding/gebeurtenissen/wijzigen-woonplaatsgrens Démarche Modi (overleg) 13 dec 2022 20:52 (CET)

Dat je die aanvulling van RonnieV niet meer kunt vinden (met CTRL+F neem ik aan), heeft er enkel mee te maken dat ik delen heb ingeklapt. Puur voor laadtijd/overzicht. In de bewerkingsmodus kun je prima zoeken, of je kunt alle stukken eerst uitklappen. Ik kan me in ieder geval nog herinneren wat Ronnie toen aanvulde.

Ik ben van mening dat we gewoon eerst eens aan de slag gaan en de problemen die we tegenkomen bewaren en op het eind doen, dan hebben we (iig ik) er ook een beter beeld bij. Ik ben een leek op dit vlak, ik lees graag mee, maar significant bijdragen aan het gesprek kan ik niet. Dus als jullie het wel van tevoren al willen oplossen, vind ik dat goed.

Je interpreteerde mijn opmerking niet letterlijk genoeg, met kunnen gaan uitvoeren bedoelde ik een begin maken. Afronden zeker niet, haha, al zou het mooi zijn. Ennomien (overleg) 13 dec 2022 21:21 (CET)

Die meningen deel ik niet met je. Het lijkt me zonde van de tijd om 2501 woonplaatsen te verwerken om daarna erachter te komen dat we ze niet goed kunnen onderhouden. Maar wellicht hebben de anderen een andere kijk hierop. Ook kunnen we Wikiwerner niet zomaar passeren, toch? Wat betreft zoeken in de bewerkingsmodus, dat gebruik ik niet zoals jij dat voorstelt. Maar goed, VJVEGJG geldt hier natuurlijk ook gewoon. Ik voel me alleen niet zo vrij om nu aan de slag te gaan, omdat dat ik het geheel niet goed kan overzien. Misschien komt daar later verandering in. Wanneer we bijvoorbeeld kijken naar de inwoneraantallen van gemeenten, dan zien we daar reeds een issue. De aantallen zijn voor 2021 ingevoerd in Wikidata, maar voor 2022 nog niet. Op Wikipedia zien we daarentegen wel dat het bijgewerkt is voor 2022. Ondanks dat ik Wikidata prefereer boven de Wikipedia 'arrays' lijkt het me essentieel om eerst consensus te bereiken in de gemeenschap, een goede methodiek en aanpak te hanteren en vervolgens tot realisatie over te gaan (eerst overleg, vervolgens consensus en dan pas implementeren). Kortom, wellicht doen we er verstandiger aan om eerst de inwoneraantallen van de gemeenten goed neer te zetten op Wikidata, de oude aanpak op Wikipedia te verwijderen en zodra dat goed werkt dit gedetailleerdere niveau, de woonplaatsen, te realiseren. Dan hebben we ondertussen ook de tijd genomen om goed te onderzoeken hoe we die data willen onderhouden in de toekomst. En als bonus hebben we dan een aanpak die daadwerkelijk door de gemeenschap geaccepteerd wordt. We kunnen Wikidata niet opdringen, beter zoeken we naar een Wikidata aanpak die door de gemeenschap gedragen wordt. Dat scheelt uiteindelijk ook veel werk voor een handjevol individuen. Ongetwijfeld kan er overigens nu al veel gedaan worden door een bot, zoals de jaarlijkse inwoneraantallen per gemeente en het onderhouden van alle artikelen die deze data gebruiken. Voor diegenen die bots runnen dan. Daar doe ik (nog?) niet aan mee. Démarche Modi (overleg) 13 dec 2022 23:42 (CET)

Goed idee, we wachten reacties van (de) anderen af. Ik ben trouwens van mening dat wij aan niemand toestemming (acceptatie) hoeven te vragen voor het uitvoeren van dit project (VJVEGJG). Het idee voorstellen en tips/feedback vragen, daar ben ik wel voorstander van. Ennomien (overleg) 14 dec 2022 17:56 (CET)

@DM: Ik vind het dus ook onnodig om alle 2501 woonplaatsen na te lopen. Daarom noemde ik (zie 3 dec 2022 14:52) een stappenplan om te bepalen voor welke gemeenten de som van de inwonertallen van de woonplaatsen van die gemeente (bijna) gelijk zijn aan het gemeente-inwonertal. Dan hoeven we alleen iets te doen voor de gemeenten waarvoor die niet gelijk zijn.

Het toevoegen van de nieuwe gemeente-inwonertallen aan Wikidata staat hier los van. Dat kunnen we gewoon doen. De volgende stap wordt dat we die cijfers ook gaan gebruiken in de infobox gemeente Nederland. N.B.: in Frankrijk gaat dit al zo. Als de anderen zien dat dat goed werkt, dan kunnen de arraysjablonen worden genomineerd voor verwijdering. Overigens bestaat het sjabloon:Array Frankrijk gemeentes inwonertallen nog wel. Misschien die eerst maar eens nomineren? Wikiwerner (overleg) 14 dec 2022 21:17 (CET)

Dan hoeven we alleen iets te doen voor de gemeenten waarvoor die niet gelijk zijn. --> Dat kan je dus niet met zekerheid stellen met die aanpak. En wat betreft Het toevoegen van de nieuwe gemeente-inwonertallen aan Wikidata staat hier los van. --> De huidige stand van zaken omtrent de inwoneraantallen per gemeente tonen aan dat het relatief zinloos is om Wikidata te gaan vullen indien dat op Wikipedia niet gebruikt wordt, omdat men hier een eigen oplossing hanteert. Overigens acht ik het noodzakelijk om de 2501 woonplaatsen na te lopen, maar dat is alléén nuttig indien we daarbij een goed beheersbare methodiek toepassen en het tegelijkertijd geïmplementeerd zien in Wikipedia. Anders herhaalt de situatie van de 2021 inwoneraantallen per gemeente, die met name door @Dajasj ingevoerd zijn in Wikidata, maar toch nog op Wikipedia onderhouden worden voor 2022. Het lijkt me dan ook zinvoller om eerst te zorgen dat de inwoneraantallen vanuit Wikidata per gemeente goed staan, goed blijven staan en goed gebruikt worden en dat we daarna verder gaan met de woonplaatsen. Een data-analyse met potentieel foutpositieven en een vergelijk met de Franse gegevens verandert daar niets aan. Al met al zijn er twee oplossingen; 1: er wordt actiever en doelgerichter data gebruik vanuit Wikidata doorgevoerd (opgelegd aan de gemeenschap) of 2: er wordt bredere consensus voor datagebruik vanuit Wikidata bereikt (gedragen door de gemeenschap). Wellicht kan 1. ervoor zorgen dat 2. uiteindelijk een feit wordt maar mijn indruk is dat een deel van de vrijwilligers hier zo koppig is dat het geen zin heeft en men vast wil houden aan zijn/haar eigen aanpak en blind en doof is voor goed onderbouwde rede. Fouten worden bewust genegeerd. Dat zie ik bijvoorbeeld ook terug bij jou Wikiwerner, je lijkt immers de kritiek op jouw aanpak geheel te negeren. En zodoende vrees ik dat 3 een feit zal zijn: er is geen goede oplossing op dit moment. Maar VJVEGJG en dan kijken we na de vakantie of later wel hoe het ervoor staat. Démarche Modi (overleg) 14 dec 2022 22:35 (CET)

@Wikiwerner, dan zal ik nog even toelichten wat DM bedoelt met Dat kan je dus niet met zekerheid stellen met die aanpak. Hij begrijpt jouw stelling en onderbouwing, maar zegt dat die niet betrouwbaar is (mijn woorden). Want als het totaal van woonplaatsen ~ongeveer gelijk is aan het totaal van de gemeente, zegt dat niks over of de individuele aantallen (van de woonplaatsen) ook correct zijn. En die willen we ook tonen, dus die moeten ook kloppen. Ennomien (overleg) 15 dec 2022 14:58 (CET)

Dan rest niks anders dan ze alle 2501 na te lopen. Mijn suggestie diende slechts om dit gedeeltelijk te omzeilen. Zie dan echter wel DM 13 dec 2022 23:42. Wikiwerner (overleg) 16 dec 2022 15:56 (CET)

Ja, ik baal daar ook wel van moet ik zeggen. :)

Wat is er met dat bericht van DM? Om welke passage gaat het? Ennomien (overleg) 16 dec 2022 19:07 (CET)

De 2e zin. Wikiwerner (overleg) 16 dec 2022 19:17 (CET)

Aha ja, zo'n vermoeden had ik al. Ik ga daarin met jullie mee. Wat wordt het exacte plan van aanpak?

Trouwens, dat verwijderen van die arraysjablonen moeten we na die tijd doen. Eerst zorgen dat alles goed werkt en dan op de andere plekken (infoboxen bijv.) data uit arrays vervangen, het liefst nemen we dan direct de hele infobox mee natuurlijk. Althans, dingen die relatief "vast" staan overzetten naar Wikidata, denk aan oppervlakte en andere wetenswaardigheden. Ennomien (overleg) 16 dec 2022 19:25 (CET)

Ik doe wel een voorzetje. Un momento por favor. Démarche Modi (overleg) 16 dec 2022 19:34 (CET)

Zie hier, ik ga er zondag nog even verder mee en daarna later na de vakantie. Vul gerust aan. Démarche Modi (overleg) 16 dec 2022 20:12 (CET)

Ziet er goed uit, heb een paar kleine bewerkingen gedaan. Ik snap de achterliggende gedachte van niet-overeenkomende grenzen, maar voor mij is het niet duidelijk hoe ik dat precies moet gaan constateren met de PDOK-viewer. Daarin ben ik misschien ook niet de enige. Misschien handig om erbij te vermelden hoe dat geconstateerd kan worden. Ten minste een vermelding van een "goede" en "foute" woonplaats zal misschien al genoeg zijn om te zien hoe het werkt. Ennomien (overleg) 17 dec 2022 21:18 (CET)

Dank je wel voor die wijzigingen. Zo is het een stuk beter. Zojuist heb ik gelijk maar even gekeken naar de goede en foute woonplaatsen. Tot mijn verbazing moet ik constateren dat Rotterdam toch fout is (wat dit betreft dan hè): de buurt Eemhaven ( BU05992196 ) overlapt met zowel de woonplaats Pernis (3085) als Rotterdam (3086). Ik plaats het daarom bij de foute voorbeelden. Verder heb ik nu een goed voorbeeld (Woerden) uitgewerkt (controle grenzen PDOC, bepalen inwoneraantallen Statline en invoer Wikidata). Is dit iets waar je mee uit de voeten kan? Kan je tevens in mijn laatste wijziging zo'n mooie Diff voor Wikidata toevoegen? Nu staat er nog de volledige URL, dat kan volgens mij mooier maar ik ben vergeten hoe precies. Démarche Modi (overleg) 18 dec 2022 10:45 (CET)

Vanaf heden ben ik tot nadere orde niet beschikbaar. Het is nog onduidelijk wanneer ik weer kan aanvangen. Vermoedelijk vanaf februari weer. Indien er korte vragen zijn kan ik proberen om vanaf mijn mobiel toch te helpen. Ping me dan en dan kijk ik wat ik kan doen. Verder vertrouw ik erop dat er nu voldoende basis staat, maar schroom vooral niet om het aan te vullen op de plaatsen waar dat noodzakelijk is. En voel je uiteraard vrij om alvast een aantal woonplaatsen te verwerken. Rest me dan nu niets anders dan jullie allemaal alvast fijne feestdagen en een voorspoedig nieuw jaar toe te wensen! Hartelijke groet, Démarche Modi (overleg) 18 dec 2022 16:06 (CET)

Het is nu goed duidelijk! Toch handig om het even op papier te hebben, ook al had ik wel een vermoeden hoe het zou moeten. Ik heb de diff vervangen.

Ah dat is jammer, ik hoop er wel al eerder aan te beginnen. Wel een grappig werkje eigenlijk.

Klein vraagje: bij Zegveld zie ik wel enkele relatief grote verschillen in de grenzen (rechts), jij "keurde" die wel goed. Was dat bewust? Omdat daar toch geen huizen staan?

Bedankt en alvast fijne feestdagen en een goede jaarwisseling! Mvg, Ennomien (overleg) 18 dec 2022 16:22 (CET)

Bespreek die grensverschillen alsjeblieft met @Dajasj, @RonnieV en @Wikiwerner. Volgens mij zijn dit namelijk acceptabele verschillen, maar indien de anderen daar anders over denken dan dient dat aangekaart te worden. Overigens is het PvA een concept waarin verbeteringen welkom zijn. Wellicht is het wenselijk om dergelijke grensverschillen expliciet te behandelen in de aanpak. Démarche Modi (overleg) 18 dec 2022 17:11 (CET)

Het leek mij ook zeker een acceptabel verschil. Zoiets lijkt me een goed eerste uitgangspunt. Ennomien (overleg) 18 dec 2022 17:17 (CET)

Mee eens. Wikiwerner (overleg) 18 dec 2022 21:02 (CET)

Wijzigende woonplaatsgrenzen

Beste teamleden,

Weet iemand hoe we in de toekomst om kunnen gaan met wijzigende woonplaatsgrenzen? Hoe weten we bijvoorbeeld zeker dat BAG woonplaatsgrenzen in 2023 nog hetzelfde zijn als in 2022? Deze vraag stel ik om voorbereid te zijn en te voorkomen dat we de grote klus van 2501 woonplaatsen controleren niet elk jaar uit hoeven te voeren. Het antwoord kan ikzelf helaas niet geven. Groet, Démarche Modi (overleg) 10 jan 2023 17:51 (CET)

Mijn ervaring is dat woonplaatsgrenzen toch wel vastliggen en niet jaarlijks wijzigen. Gemeentegrenzen kunnen wijzigen, maar dan is een woonplaats vaak toch blijvend. Ik heb de grenswijziging van Gemeenten Hoorn en Drechterland mee mogen maken. Daarbij kwam een voormalig veilinggebouw op het adres Veilingweg 1-1a in de gemeente Hoorn te liggen, maar de woonplaats bleef Oosterblokker. Zie ook de lijst van gemeentelijke monumenten in Blokker. Woonplaatsgrenzen kunnen wel gewijzigd worden als het gaat om grote bouwprojecten die op de grens van twee plaatsen liggen en waarbij een straat niet de grens volgt, maar er doorheen gaat. Hoe vaak dat gebeurd weet ik niet.

Ik moet wel vermelden: ik ben geen Ruimtelijke Ordening-ambtenaar, dus mocht ik hier een echt foutief of incompleet antwoord geven, corrigeer me gerust. Dqfn13 (overleg) 10 jan 2023 18:17 (CET)

Daar zit het risico; de aanname dat de wijzigingen wel meevallen maar niet de zekerheid wat er wijzigt. De wijzigingen van gemeentegrenzen zijn relatief eenvoudig en kunnen bij het CBS nageslagen worden. Het CBS schrijf met betrekking tot de BAG registratie hier het volgende: De BAG-gegevens zijn continu aan verandering onderhevig en kunnen maandelijks worden aangepast. Oftewel onze gezaghebbende bron, het CBS, die het ene deel van de informatie levert, geeft aan dat hun gezaghebbende bron, de BAG-registratie van het Kadaster, maandelijks aan verandering onderhevig kan zijn. Het Kadaster heeft in haar eigen handleiding de gebeurtenis van een wijzigende woonplaatsgrens beschreven. De bron is duidelijk; het gemeentelijk woonplaatsbesluit. Nu kunnen wij op Wikipedia nastreven om 345 woonplaatsbesluiten te controleren om zodoende grip te houden, echter het Kadaster doet dat reeds. Het zou bijzonder wenselijk zijn om het resultaat van dat Kadasterwerk eenmaal per jaar te kunnen raadplegen. Démarche Modi (overleg) 10 jan 2023 18:45 (CET)

Voor (nieuwe) meelezers, de context hier is toch hier puntje 3? Ennomien (overleg) 10 jan 2023 19:04 (CET)

BAG omvat meer dan alleen de woonplaats. Daar gaat het ook om percelen (splitsingen, samenvoegingen, etc.) en die kunnen inderdaad dagelijks een update krijgen. De vraag ging echter over woonplaatsgrenzen en het antwoord van Démarche Modi ging meer over wijzigingen algemeen. De wijziging die het Kadaster noemt, is een wijziging die uiteraard zelden voorkomt. Een keer per jaar een update lijkt mij prima. Dqfn13 (overleg) 10 jan 2023 19:24 (CET)

@Dqfn13, waaruit maak jij op dat het antwoord van Démarche Modi ging meer over wijzigingen algemeen? Hoe kan je vaststellen dat die uiteraard zelden voorkomt? En hoe kan je vaststellen dat die uiteraard zelden voorkomt? Démarche Modi (overleg) 11 jan 2023 00:47 (CET)

@Démarche Modi: in jouw antwoord gaf jij niet aan om wat voor wijzigingen het ging, dan is het dus een wijziging in het algemeen. Gemeentelijke grenswijzigingen komen zelden voor, omdat die vrijwel nooit nodig zijn. Ja ik ken ze en in mijn omgeving weet ik er van meerdere, maar dat zijn er iets van 5 en dat verspreid over 10 jaar. Dit aantal wijziging is inclusief 4 gemeentelijke fusies. Het is dus niet iets wat ik van het nieuws heb, het is een eigen ervaring, volgende keer zal ik dat ook vermelden. Dqfn13 (overleg) 11 jan 2023 09:55 (CET)

@Dqfn13 ik ervaar het als vervelend dat je deze discussie kaapt met de poging om een soort van eigen gelijk te halen. Het simpele feit dat het CBS bij haar publicatie over de woonplaatsen een opmerking maakt over de aan verandering onderhevige brondata van het Kadaster (de BAG registratie) zou voldoende moeten zijn om te begrijpen dat er wel degelijk een relevant en in ogenschouw te nemen verband is tussen die twee (CBS en BAG). Dat jij ervaringen hebt met iets van 5 en dat verspreid over 10 jaar zou tevens een indicatie moeten zijn om te beseffen dat we hier te maken hebben met een wijzigende werkelijkheid. Als encyclopedie willen we - voor zover mij bekend althans - uitgaande van gezaghebbende bronnen de werkelijkheid publiceren. Indien we een gerede twijfel hebben dat die werkelijkheid niet (meer) klopt dan dienen we dat uit te zoeken en niet weg te wuiven met een mening die aangeeft dat het wel mee zal vallen. Plain and simple. Kortom, indien je geen duidelijkheid kan verschaffen in onze praktische vraag (zoiets als: hoe kunnen we wijzigingen in de gemeentegrenzen van de BAG registratie jaarlijks nagaan?) wil ik je vriendelijk doch dringend verzoeken om je verder afzijdig te houden in deze discussie. Démarche Modi (overleg) 11 jan 2023 12:11 (CET)

Is goed. Wat hebben wij een fijn en respectvol gesprek gehad. Goede opmerking om iemands dag te verzieken Démarche Modi. Dqfn13 (overleg) 11 jan 2023 12:37 (CET)

@Dqfn13, goh, een persoonlijke aanval van een moderator? Démarche Modi (overleg) 11 jan 2023 13:05 (CET)

Het schijnt dat ik ook een mens en gebruiker ben met gevoelens. Aangeven dat jij mijn dag hebt verziekt is geen persoonlijke aanval. De aanval die ik wel even heb geplaatst, die heb ik al teruggetrokken. Aangezien ik jou mijn verdere aandacht niet waard vind, ga ik dingen doen die ik wel belangrijk vind. Dqfn13 (overleg) 11 jan 2023 13:09 (CET)

@Dqfn13 Het gaat in deze discussie niet om jou of om mij maar om een praktische vraag die we vanuit dit deelproject hebben. Maar dat staat nu reeds enige tijd buiten beschouwing... Aangeven dat mijn inhoudelijke reactie op jouw speculaties en/ of mijn verzoek jouw dag zogenaamd verzieken is toch echt een persoonlijke aanval; je doet immers voorkomen dat mijn handelen jouw gemoedstoestand beïnvloeden en ik daaraan dus schuldig ben terwijl je die schuldvraag louter en alleen bij jezelf kan neerleggen. Overigens beschouwde ik wat jij omschrijft als de aanval die ik wel even heb geplaatst initieel slechts als incompetentie om de materie goed te begrijpen, kennelijk bedoelde je het dus anders en had je daar oneerbare intenties. Wat dat betreft zou ik me - als ik moderator zou zijn - afvragen of dat gepast gedrag is voor een moderator. Démarche Modi (overleg) 11 jan 2023 13:22 (CET)

(Naar aanleiding van Help:Helpdesk#Wijzigende woonplaatsgrenzen.) Zie bij Lijst van gemeentelijke monumenten in Amersfoort#Hoogland hoe ik in 2017 een gewijzigde woonplaats heb opgelost bij Boerderij Sneul, zowel boven als onder de subkop Hoogland. De woonplaatswijziging was ergens in de jaren 1990. JoostB (overleg) 11 jan 2023 15:02 (CET)

@JoostB Betreft dat een gemeentelijke herindeling (gemeentegrenzen wijzigen) of een woonplaatsgrenswijziging? Indien het een woonplaatsgrenswijziging betreft, weet je nog hoe je dat toentertijd vastgesteld hebt? We zijn op zoek naar informatie hoe we vast kunnen stellen dat woonplaatsgrenzen (conform de BAG registratie van het Kadaster) wel/niet gewijzigd zijn. Démarche Modi (overleg) 11 jan 2023 16:02 (CET)

Een woonplaatswijziging, reeds in 1974 was de gemeente Hoogland opgegaan in Amersfoort. Nog jaren viel het agrarisch buitengebied onder het dorp Hoogland, postcode 3828. De nieuwbouwwijk Nieuwland is vanaf ong. 1992 aangrenzend aan het dorp gebouwd en is onder de woonplaats Amersfoort gaan vallen. Boerderij Sneul is ingebouwd door de nieuwe wijk. In de referentie staat het voormalige adres Sneulseweg, maar de foutieve straatnaam 'De Vergulde Paarden' wat 'De Rode Leeuw' moet zijn. Reeds voor ik dit lemma voor het eerst wijzigde in 2017 stond er al 'De Rode Leeuw 11A (vh. Sneulseweg 2)'.

Ik ben opgegroeid in het dorp Hoogland en ben ook bekend met de situatie in het vormalige buitengebied. En ik kwam vanaf de bouw van Nieuwland bij diverse mensen over de vloer.

JoostB (overleg) 11 jan 2023 16:22 (CET)

Op basis van de huidige stand van zaken kom ik tot de conclusie dat het geen nut heeft om tot verdere datainvoer over te gaan. We kunnen nu welliswaar een goede basis realiseren maar om het beheer in de toekomst het hoofd te bieden ontbreekt het ons aan voldoende inzicht in de gang van zaken omtrent wijzigingen in de BAG registratie van het Kadaster. Zoals het met de meeste kennis gesteld is kan die alleen goed beheerd worden indien de bron van voldoende kwaliteit is. In het geval van zoiets als een BAG registratie omvat die kwaliteit ook een duidelijke, door het Kadaster uitgegeven, beschrijving van de wijzigingen. Dat is nu helaas niet het geval. Een poging om binnen de gemeenschap tot beter inzicht te komen heeft tot vrijwel niets geleid.

Tot mijn spijt moet ik dan ook concluderen dat de voorgenomen actie om tot datainvoer over te gaan niet de juiste zet is. Immers, indien we relatief actuele (i.e. jaarlijks) de encyclopedie willen voorzien van de juiste informatie, dan moeten wij in staat zijn om 1) die gegevens zonder twijfel te onderbouwen en 2) die gegevens op een hanteerbare manier te beheersen. In mijn optiek is daarbij inzicht in de wijzigingen noodzakelijk. Dat ontbreekt en daarom komt het tot een stilstand.

Wellicht deelt niet iedereen mijn mening. Dat vind ik prima, voel je vrij en ga je gang geldt hier natuurlijk ook gewoon. Besef alleen wel dat huidige inspanningen tot datainvoer later voor problemen kunnen zorgen indien die niet goed bijgewerkt worden. Bijvoorbeeld omdat de informatie niet meer klopt en dat er dan getwijfeld kan worden aan de kwaliteit van Wikipedia. Mijn advies is om - indien je die kwaliteit in de toekomst onvoldoende kan waarborgen - daarom nu niet tot datainvoer over te gaan. Ik zal het sowieso laten. Démarche Modi (overleg) 29 jan 2023 18:12 (CET)