[Belgium] whitepaper: Computing a shapefile by Belgian zip codes

[Alexandre Detiste]

Le lundi 30 mai 2016, 12:26:35 joost schouppe a écrit :
> Hi Alexandre,
> 
> A few thoughts:
> 
> * why pay 100 euro's for open data? [1] (note: there's a few errors in this
> file, which make it crash on analysis using QGIS. In my own work, I used
> ArcGIS FIx Geometry as I don't know the right tools in QGIS)

Because this file [1] doesn't contain any zipcode information;
and the file from IGN has a good word of mouth.
I was called to rescue this after the file was already bought anyway.

The zipcode in AD_1_MunicipalSection_WSG84 is already like 90% correct,
with some huge defect for big municipalities like Brussels, Antwerpen, Liège
that have complex zipcode layout; users were happy to get
close to 99% ok with a bit of extra efforts.

The further I tried to improve quality, the more it felt like pushing
a square bloc in a round holde... but end users just didn't cared.

> * Zipcode is a terrible way to handle geographical data, as it often has
> completely illogical borders. From a practical point of view you need it of
> course, as a lot of data are collected at this info. If at all possible,
> the lowest geographical level of a datawarehouse in Belgium should always
> be the statistical sector.

There's always a huge resistance to change, and after having payed a
+10.000€ / year software package user expected that it would automagicaly
answer all questions; so use of extra (even free) software is generally frowned upon.

They were terribly affraid of using the provided geocoding tool:
some .exe that read a text file and write an other one without
some shiny VisualBasic 6 GUI.

I think geocoding + using stat sectors is the correct way to do tough;
but it this case solution had to remain pragmatic & reproducible
by someone else.


In this case, too, the visalisation tool would slow down to a crawl
if too many shapes borders were defined, so zipcodes were
an easy way to merge stat sectors on a map.

> * Careful: aggregating statistical sectors into postal codes is not
> entirely correct, as statistical sectors do have logical borders. See this
> example where buildings are coloured by postal code and overlayed with
> statsitical sectors (black lines) [2] . In the website I co-manage [3], we
> chose to name these merged statistical sectors "postal codes", even if
> that's not strictly true. You can see and download both "our" postal codes
> (with imperfect and strange geometry) [4] and our
> merged-statsec-to-postalcode [5] from the Antwerp open data portal.
> 
> * It's hard to define which sectors to which postal codes. Yes, the letters
> often do give an indication, but in this example [6], some postal codes
> consist of different letters, and some letters belong to different postal
> codes. I think a more correct way would be to do a spatial join of address
> points with statistical sectors, then count the most prevalent address
> postal code within a certain sector. Join the resulting table to the sector
> shapefile (join by attribute niscode), and you can just do a dissolve by
> attribute postal code to get the needed dataset.

It would be nice to share all these insights on a wiki or something
(or a premade file).

I'd look again at how to do that with OSM someday.


Greets,

Alexandre

> 
> 1:
> http://statbel.fgov.be/nl/statistieken/opendata/datasets/tools/big/SH_STAT_SECTORS.jsp
> 2: http://i.imgur.com/El8b4I4.jpg
> 3: https://stadincijfers.antwerpen.be/dashboard/
> 4: http://opendata.antwerpen.be/datasets/postzones
> 5: http://opendata.antwerpen.be/datasets/stadsdeel
> 6:
> https://stadincijfers.antwerpen.be/databank/?sel_guid=bc4433ff-d734-4a54-b1ba-410e8a8cc975
> 
> 2016-05-28 13:23 GMT+02:00 Alexandre Detiste <alexandre.detiste at gmail.com>:
> 
> > http://users.skynet.be/bs366950/whitepaper/