As a Google Maps API developer I have recently been thinking about where this kind of API sits within the Geographical Information System (GIS) application domain. GIS is big business, and many large companies and organisations that are responsible for managing distributed assets rely heavily on this type of application. Until several years ago GIS applications were often deployed “behind the scenes” out of the public eye, and tended to be highly specialised, very technical, and when initially constructed both the data itself and transfer/storage mechanisms were quite esoteric. I refer to these as first-gen GIS apps (although I’ll caveat this by stating that there may be existing classifications of GIS apps, of which I am unaware).
2005 heralded the arrival of second-gen GIS apps for general public consumption, which presented a nice Web 2.0 style interface and associated APIs for global mapping applications, such as Google Maps. Now in 2009 everybody and their cat are using these applications daily...
In addition to the locations of roads, petrol station and tourist attractions which are currently spilling out of Google Maps there must also be hundreds of other first-gen GIS applications around the world that hold interesting data. Obviously some of this data is not for public consumption, but even if the data is destined for private use it would surely be reasonable to assume that an organisation could benefit from combining their existing GIS data with the user friendly and highly malleable second-gen style of GIS applications, albeit in a restricted fashion? Combine this with the prevalence of today’s low cost GPS devices, for example packaged within many modern mobile phones, and also the emergence of services such as Google Latitude, we are rapidly hurtling towards a location-aware and highly contextualised future which will only get better with access to more and more data...
So, how easy would it be to integrate first and second generation GIS applications? My main research questions revolved on where the functionality of Google Maps/Earths type applications sit within the GIS domain, identifying any interesting nuances with storing/manipulating data, and the type of functionality offered in terms in interoperability. The preliminary research turned out to be quite interesting...
- GIS apps tend to specify locations and geographical features by latitude, longitude and also elevation. Google Maps doesn’t manage elevation, as this application provides a 2D view onto the globe. Google Earth on the other hand, is quite capable of handling all of this information, and now work is well and truly under way to merge Google Maps and Earth
- Although lat/lngs are used to specify a location, there are variations in different formats (or "datum" in GIS-speak) depending on the map projection used. I am assuming that if a high level of accuracy is required when integrating data from multiple sources that the datums in use throughout the applications would have to be identified and compared. I can’t see any reason why coordinates stored using different datums couldn't be programmatically converted (more info on datums @ http://en.wikipedia.org/wiki/Map_projection#Choosing_a_model_for_the_shape_of_the_Earth and http://en.wikipedia.org/wiki/Datum_(geodesy) )
- There are several GIS standard protocols from the Open Geospatial Consortium which may be of interest:
- Web Map Service (WMS) defines an API to allow a high-level layered image of a specified location to be retrieved. More info @ http://en.wikipedia.org/wiki/Web_Map_Service
- Web Feature Service (WFS) defines an API to enable lower-level manipulation of GIS features and concepts, such as adding data to a location or spatial analysis. More info @ http://en.wikipedia.org/wiki/Web_Feature_Service
- Geography Markup Language (GML) specifies an open XML-based interchange language to express geographical features. More info @ http://en.wikipedia.org/wiki/Geography_Markup_Language
- There is a Java-based open source reference implementation of WFS named GeoServer, which in turn is built upon another Java-based open source GIS Toolkit named GeoTools. These could potentially be integrated into both new and old GIS applications to enable the sharing of data using the above standards, essentially exposing a standard WFS API to third-party developers allowing integration of your data into their GIS apps.
Google happens (by design I’m assuming 
) to be in good standing with its current GIS flavoured offerings:
- Google Maps supports WMS and Google Earth supports WFS.
- Google uses it's own Keyhole Markup Language (KML), which compliments GML, to transfer and manipulate Geographical feature data. If an existing GIS app exposes data using the above standards, then integrating this data (in addition to your data) on Google Maps/Earth should be possible.
That turned into quite a bit of text, but in a nutshell there are plenty of options to support the sharing/integration of data between 1G and 2G GIS apps, which would be made much easier if the above open standards are supported.
The open questions? Do existing first-gen GISs, which would be pervasive within well established organisations/companies, support these standards, and how do we find out about these GISs in the first place?
Daniel
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Daniel Bryant (Director) | Tai-Dev Ltd
www.tai-dev.co.uk - IT Consultancy Services Specialising in JEE, Web 2.0 and RDBMS
