I have always strived to write code that is not tied to a particular technology or platform. Abstracting code from the underlying database is probably the killer example and thankfully over the past few years the Java Persistence API (JPA) standard has evolved through the Java community to make this possible.

JPA is a standard interface for storing objects containing data into a relational database. The standard defines interfaces for annotating Java objects, retrieving objects using queries, and interacting with a database using transactions. An application that uses the JPA interface can work with different databases without using any vendor-specific database code thereby making it easy to port between different database vendors.

In the past I have used the open source Toplink Essentials (by Oracle) implementation with great success.  An alternative implementation spawned from the JBOSS world is Hibernate.  Of great significance in our quest to deal with geographic data is Hibernate Spatial – a generic extension to Hibernate that abstracts away from the specific way your database supports geographic data, and provides a standardized, cross-database interface to geographic data storage and query functions.

To use Hibernate Spatial you first need to get Hibernate and the Java Topology Suite.  Hibernate provides the ORM functionality, and the Java Topology Suite provides the Geometry (and related) types. Hibernate Spatial is the glue between them.

A first rate tutorial on how to get Hibernate Spatial working can be found here http://www.hibernatespatial.org/tutorial.html

In a previous attempt at creating a proof of concept google maps related application, I naively used a plain vanilla mySQL database. Using separate float columns to store the latitude and longitude of points of interest, I was very easily and quickly able to conjure some simple maths and SQL to return all points of interest within a bounding box.  For more complex operations, such as searching for markers within a defined radius, I had to implement an algorithm in Java that would further restrict this (bounding box) subset.

It has to be said that this approach worked rather well for my prototype but after investing some valuable time on research, I quickly realised that there are better and more scalable ways to achieve this.  For example, what if I want to find markers within a complex polygon or distances between points etc?

A better approach is to use a GIS (geographical information system) enabled database which has a fundamental understanding of the geospatial data that I am looking to store and manipulate. Such a class of database provides a rich collection of spatial functions that enable you to perform sophisticated queries on the data.

An analysis of the two main open source databades, MySQL and Postgres, reveals that both can be made spatially aware.  However it was immediately obvious that mySQL had some significant shortcomings over its cousin PostGIS.  For example, performance issues regarding the creation of indexes that contain both numeric and spacial data as reported in http://blog.redfin.com/devblog/2007/11/elephant_versus_dolphin_which_is_faster_which_is_smarter.html.  Furthermore, unlike PostGis, many of the OpenGIS functions remain unimplemented (see below).

PostGIS adds support for geographic objects to the Postgres object-relational database. In effect, PostGIS “spatially enables” the PostgreSQL server, allowing it to be used as a backend spatial database for geographic information systems (GIS), much like ESRI’s SDE or Oracle’s Spatial extension. PostGIS follows the OpenGISSimple Features Specification for SQLand has been certified as compliant with the “Types and Functions” profile.

There is no doubt that the battle for supremacy between these two databases is very closely fought and ever-changing with each release but at the time of writing PostGIS is a clear winner given my requirements.


I recently encountered an issue while trying to connect my android device to my laptop running XP.  Firstly, the installation process did not resemble the instructions as documented here (http://developer.android.com/guide/developing/device.html#XPFreshInstall) in that the new hardware wizard did not automatically kick-in.  Furthermore, it was difficult to know which was the correct target USB driver to update when viewing the Device Manager dialogue.

The solution:
Keep the Device manager open while removing and then reconnecting the android device to your pc/laptop. You should be able to visually see which new USB entry has just appeared in the Device Manager. Then you can update the driver as per the installation instructions.

Once you have successfully installed the device driver, you can test by opening a dos prompt to the <android_sdk>/tools directory and then running the command ‘adb devices’.  If this does not show the new device, try running the command ‘adb kill-server’.  You can then rerun the ‘adb devices’ command to restart the server and list the (hopefully!) updated list of devices!