One of the advantages of travelling as much as I do, is that I have a high probability of meeting interesting people who are doing very innovative things.  I’m currently in Australia to attend next week’s GITA conference in Sydney, and on my way here I ran into Sam Majid of Ennoble Consultancy in Melbourne.  Sam, whom I have known for several years, has implemented a classic architectural design pattern for web-based mapping that can provide scalable, high performance mapping on low cost hardware. 

Architectural Design Pattern for Web Mapping

The design pattern is a three tier architecture, comprised of a client, typically desktop,
tablet or hendheld running a web browser, a middle tier where pre-rendered map tiles are cached, and a data server, where geospatial and other data is stored.  The reason that this is such a successful architecture for low cost, high performance computing is that navigation operations, panning and zooming, only require loading and unloading cache tiles and do not require accessing the data server. Since a pan or zoom operation can involve typically a thousand features, loading a few tiles is much more efficient from a CPU and I/O perspective and dramatically reduces the load on the data server.  The other key to this architecture is that the user only updates the data store, never the cache, so there is only one point of truth.  The cache is refreshed by a background process running in the middle tier or data tier.

Open Source Implementation

Sam has developed his implementation using open source geospatial components, including Open Layers, FDO, and MapGuide Open Source.  Open Layers provides a Javascript-based client-side application environment that will run without a plug-in in any browser supporting Javascript.  Since he chose to use the FDO API, Sam’s application can directly access for both read and update widely used geospatial datastores including shape, Oracle Spatial, ArcSDE (GeoDatabase), MySQL, PostGIS, KML, and SQL Server 2008 Spatial.  Sam showed me an application using this architecture, where the client was in Kuala Lumpur, the cache was in Australia, and the data server was in California.  Performance was impressive, definitely worth taking a look at.