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

Tue May 31 12:54:14 PDT 2016

Hello 

I made a mapof postal codes (.shp), a couple of months ago by way of exercise. Made from combining data from cadastre maps (which contain old commune borders pre-fusion) “deelgemeenten”
and adresslists of primary schools (VL-BXL-W) (in every village there is one, and they all have a postcode mentioned)

sample controlling showed very satisfying result. 

ready to share 
contact me.

Joris Hintjens
Mapmen
Hofstraat 21 
1982 Elewijt
Joris at mapmen.be <mailto:Joris at mapmen.be>
www.mapmen.be <http://www.mapmen.be/>
tel 0472 473 178

> Op 31 mei 2016, om 06:27 heeft Alexandre Detiste <alexandre.detiste at gmail.com> het volgende geschreven:
> 
> 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 <http://statbel.fgov.be/nl/statistieken/opendata/datasets/tools/big/SH_STAT_SECTORS.jsp>
>> 2: http://i.imgur.com/El8b4I4.jpg <http://i.imgur.com/El8b4I4.jpg>
>> 3: https://stadincijfers.antwerpen.be/dashboard/ <https://stadincijfers.antwerpen.be/dashboard/>
>> 4: http://opendata.antwerpen.be/datasets/postzones <http://opendata.antwerpen.be/datasets/postzones>
>> 5: http://opendata.antwerpen.be/datasets/stadsdeel <http://opendata.antwerpen.be/datasets/stadsdeel>
>> 6:
>> https://stadincijfers.antwerpen.be/databank/?sel_guid=bc4433ff-d734-4a54-b1ba-410e8a8cc975 <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 <mailto:alexandre.detiste at gmail.com>>:
>> 
>>> http://users.skynet.be/bs366950/whitepaper/ <http://users.skynet.be/bs366950/whitepaper/>
> 
> _______________________________________________
> Belgium mailing list
> Belgium at lists.osgeo.org <mailto:Belgium at lists.osgeo.org>
> http://lists.osgeo.org/mailman/listinfo/belgium <http://lists.osgeo.org/mailman/listinfo/belgium>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/belgium/attachments/20160531/db8f513a/attachment-0001.html>