Tuesday, August 16, 2011

Last month Australian Bureau of Statistics (ABS) released the latest version of boundaries for use with Census 2011 data, including the so called non-ABS structures: postal areas and suburbs. It also coincided with a major upgrade to Google’s Fusion Tables, prompting me to redevelop the somewhat clunky version of Postcode Finder served from aus-emaps.com.

Postcode Finder is quite a popular tool. However, I was forced to degrade the functionality of the application after a significant hike in the cost of data service. The first version of the application was built with free postal boundaries data service provided by a third party as a Web Map Service (WMS). I wore the initial cost when the supplier introduced charges for the service but could not justify a subsequent hike in fees, opting instead to build my own version with KML data.

I wanted to avoid implementation and maintenance hassles associated with managing my own GIS infrastructure but the compromise was less than optimal solution in terms of performance and useability. Fusion Tables now offer a great alternative to WMS since it comes with own version of an “image service”, capable of real-time rendering of geographic data (eg. note the shading of a searched postcode on the map).

Functionality of Postcode Finder remains very similar to the previous version but there is a significant improvement in performance and useability (not to mention that the application is now built with version 3 of Google Map API as well). I would like to add more boundary layers over the coming weeks but it is not a straightforward task. Unfortunately, Fusion Tables suffer from some limitations in terms of handling complex polygons so, it is all subject to finding some work around, or Google sorting out the issues.

For example, in case of postal areas, I had to generalise boundaries with the Douglas-Peucker Simplification Algorithm (using 10m tolerance which reduced the file by some 30% without noticeable degradation of the boundary details however, unfortunately, not preserving topological consistency between boundaries) but it was still not enough to import postal area 6740 in WA and 0822 in NT into the Fusion Tables. I had to use 50m tolerance for those two polygons to further reduce their complexity. Google applied its own generalisation algorithms on top of it on import. The side effect is less than perfect match of adjoining boundaries at a street level resolution.

All issues aside, I hope you will find the new version of Postcode Finder much more responsive and better suited to a wider range of requirements.

It should not be very difficult to implement at all. Just try using size of the polygon as a determinant which labels to show (original shp file has sqkm value for each polygon). I used similar approach to manage display of individual electoral boundaries that vary dramatically in size. Rather than removing a boundary at certain zoom level to display a generalised version I determine what that zoom level will be for each polygon in real time.

Thanks for the tip. I will try to implement this option in the next release of Postcode Finder.

More reading and resources

Followers

"It's not the destination, but the journey that counts..."

anonymous

About All Things Spatial Blog

This blog started as a personal journal of an individual passionate about maps, spatial analysis and related technologies. All Things Spatial is now a title in a wider network of associated online media assets.