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

[Johan Van de Wauw]

In Flanders, you could use the "adressenlijst" of CRAB to find out the borders.
https://download.agiv.be/Producten/Detail?id=447&title=CRAB_Adressenlijst

On Tue, May 31, 2016 at 9:54 PM, JorisMapMen <joris at mapmen.be> wrote:
> 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
> 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
> 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/
>
>
> _______________________________________________
> Belgium mailing list
> Belgium at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/belgium
>
>
>
> _______________________________________________
> Belgium mailing list
> Belgium at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/belgium
>