# EPB

## Eindresultaat

type | aantal
-- | --
geen statsec | 54
statsec via gebouwenregister | 65833
statsec via adressenlijst CRAB hoofdadres | 17418
statsec via adressenlijst CRAB subadres | 356
statsec via XY | 2209
statsec via unieke combo straatnaam | 1393
statsec via geocode | 988
Totaal | 88251

## Volledigheid bestand

crab_id? | xy? | geen gbe_id | wel gbe_id
-- | -- | -- | --
geen crab | xy | 0 | 54228
wel crab | geen xy | 19526 | 13997
wel crab | xy | 0 | 500

* indien **enkel** gbe_id altijd xy
* indien crabcode_id **nooit** xy, zélfs indien er wel een gbe_id is
* crabcode_id is een puur intern VEKA gegeven, is geen onderdeel van CRAB
* niet alle adressen met een crabcode_id zijn volledig OK. Er zijn er 1671 waar we enkel CRAB-info hebben (geen gebouwenregister), maar waar er geen crab_huisnummer_id is

De meeste dossiers hebben enkel gebouweenheid_id en xy (54.228)
Een tweede grote groep heeft enkel crabcode (19.526) (geen gebouweenheid-id en geen xy)
Een derde grote groep heeft crabcode en gebouweenheid, maar geen XY (13.997).
Een kleine restcategorie heeft crabcode en gebouweenheid én xy (500).

### Conclusie:
* we kunnen niet met enkel XY-werken
* we kunnen niet met enkel GBR werken
* we kunnen niet met enkel CRAB werken

→ stapsgewijze verwerking

## Hoofdverwerking

### 1. verrijk met statsec op basis van gebouwenregister

* op basis van [testbestand hier beschikbaar]( https://overheid.vlaanderen.be/producten-diensten/gebouwen-adressenregister)
* de laag gebouweenheid bevat de nodige unieke ID. Zelf verrijkt met expliciete X-Y en statsec (QGIS)
* resultaat: van 68.725 gevallen met een gbe_id kunnen we er 65.833 verrijken
* oorzaken ontbreken?
* 122 lijken nieuwer te zijn bij VEKA dan in testbestand
* andere oorzaken, geen idee! Wellicht ook hier herorganisatie van de brondata, die ervoor zorgt dat oudere versies van het adres niet meer bestaan. Idealiter geeft AIV een was>wordt service voor dit soort IDs.

### 2. verrijk met statsec op basis van CRAB

* verrijking op basis van open dataset "[adressenlijst](http://www.geopunt.be/catalogus/datasetfolder/6ef348e1-69eb-4cad-8ccd-1c68099afcf3)" (onvolledige weergave CRAB, maar wel eenvoudig in gebruik!)
* zelf verrijkt met statsec en expliciete XY (QGIS)

**Opmerkingen**:
- dit kan niet in alle gevallen werken, aangezien 1671 gevallen wel CRAB-info hebben, maar geen hoofdadres crab-code
- gegeven het datamodel zouden we met het koppelen op hoofdadres voldoende moeten hebben. Maar in de adressenlijst ontbreken enkele hoofdadressen waarvan de subadressen wél beschikbaar zijn. We matchen dus ook nog eens op de subadressen. Dit lijkt een bug te zijn in de generatie van de adressenlijst. Aangezien dat een uitdovend product is, ga ervan uit dat AIV dat niet zal fixen.

**Resultaten**
Van de 32.000 dossiers met volledige CRAB-info zijn er 14.000 al in orde via GBR. Van de 18.538 die we moeten bekijken, lossen we er 17.418 op met hoofdadres en nog eens 356 op met subadres.

We hebben 95% gefixed, nog 4644 cases te gaan.

### 3. Gebruik X-Y coordinaten die al in het bestand zaten

Van die 4644 zijn er 2210 die wel een X-Y hebben in het originele bestand. Dus eenvoudige spatial join in QGIS.
Dat lukt voor 2208 cases. Allemaal zijn dat dossiers met een gbe_id zonder crab_id. Met andere woorden (gok ik): dit dossier WAS in orde in GBR op moment van data-entry, maar nu niet meer. Dit zijn dus interessante gevallen om met AIV op te nemen.

### 4. Unieke straat/statsec combo

Er zijn er nu nog 2435.
Als we de straat kennen, en alle adressen van die straat liggen in één enkele statsec, dan kunnen we op basis van de straat doordrukken. Hiertoe een eigen verwerking van CRAB gedaan. Bij gebruik van threshold 90% zeker (90% van de adressen liggen indezelfde sector) lukt dat voor nog eens 1400 gevallen.

### 5. Geocoderen

Vervolgens gebruiken we CRABmatch om de overblijvende probleemgevallen op te lossen. Dit zijn nog slechts een 1000-tal dossiers. Alvorens manueel werkt te doen aggregeren we die op uniek hoofdadres: er zijn nog 586 verschillende hoofdadressen te verwerken. Dit is dus in principe verwaarloosbaar.

### 6. Post-processing

- Enkele gevallen waar een statsec toegekend wordt die NIET bij de juiste NIS-gemeente hoort. (opgelet: vereist speciale behandeling statsec van recente fusiegemeenten) . Zie [regel 12](https://github.com/provinciesincijfers/EPB-vea/blob/master/scripts/verwerking_opendata/94_verwerken_statsec.sps#L12).
- Ook even [alle niscodes op de NIEUWE gemeenten](https://github.com/provinciesincijfers/EPB-vea/blob/master/scripts/verwerking_opendata/94_verwerken_statsec.sps#L27) zetten (voor interne consistentie)
- In de verwerking in 2017 waren er nog enkele statsec codes anders. Die worden [gehercodeerd naar de nieuwe definitie](https://github.com/provinciesincijfers/EPB-vea/blob/master/scripts/verwerking_opendata/94_verwerken_statsec.sps#L479). Dit is niet 100% zuiver - beter zou geweest zijn om de hele oude verwerking te herhalen. Maar slechts een marginale meerwaarde.
[Blok 496-522](https://github.com/provinciesincijfers/EPB-vea/blob/102067786bfce597721dfa74d7c585efeb76f873/scripts/verwerking_opendata/94_verwerken_statsec.sps#L496)
- Enkele gevallen waar de "niscode" niet van een gemeente is. Indien het adres wel gematched kon worden, behouden we dit resultaat. Als het niet gematched kon worden, dan gaat het naar "Vlaanderen - gebied onbekend"
- Geen statsec maar wel een gemeente: "gebied onbekend van die gemeente"
- Statsec van een andere gemeente dan die van het dossier zelf: "gebied onbekend van de gemeente van het dossier zelf"
- Opgelet: je kan uit eerste vijf tekens van de de statsec de de niscode van de gemeente afleiden, behalve voor de nieuwe fusiegemeenten (vandaar de recode op regel 500)

## Vragen voor VEKA

* Is het nuttig om een aanvulling van X-Y te krijgen?
* Is het nuttig om een aanvulling van gbe voor crab-only te krijgen?

### Hoofdvraag: hoe ziet het proces voor nieuwe records er precies uit?

Onze reconstructie:
* vroeger: data-entry probeert te koppelen aan CRAB-id
* nu: data-entry probeert te koppelen aan gebouwenregister (welke id precies?)
* overgang: indien dossier reeds een CRAB-id heeft, koppel die aan een gebouwenregister-ID

Bijvragen:
- om dat beter te begrijpen: mogelijkheid kruistabel tussen source_statsec en datum data-entry
- adres-id is wellicht ook nuttig om te hebben (doch niet noodzakelijk)
- crabcode_id is "een eigen constructie"?
- gaan jullie onze resultaten naast die van jezelf leggen?
- Is het zinvol dat wij dit bestand verrijken met gebouwid en xy waar dit ontbreekt in de dump?
- blijvend probleem dat adres-identificatoren verdwijnen uit de master databank, zonder eenvoudige oplossing om dat te fixen