Tuesday 3 February 2009

Output to KML file and more thoughts on implementation

So far I have written the results from DBSCAN as INSERT statements to be run against a postgreSQL database. This is not going to be much use for a client application, so for the next step I’m going to generate a KML file showing the clusters (I’m going to omit noise points to keep the output filesize low). KML has now been adopted as a OGC standard and can be used as input to Google Maps and Google earth.

One problem is that my data is in OSGB co-ordinates whereas KML uses WGS84 lat/long. I've used the Grid InQuest co-ordinate translation program which comes with a DLL file that can be used in Visual Studio. My VB.NET application now outputs the results to a KML file. The code for generating the KML file was adapted from here.

Some sample results:

http://www.gmtu.gov.uk/nmg/citycentre.kml
http://www.gmtu.gov.uk/nmg/heatonsnorth.kml

If these urls are pasted directly into the browser, Google Earth will be fired up (if installed). To use the kml files in Google Maps you can paste the URL into the Search Maps text box on the Google Maps page.

Here is the Heatons North data in Google Maps:


View Larger Map

The number on each point is the clusterID (note that noise points have not been included.

As it stands the KML displays the individual points in each cluster. I perhaps need to think about generalization and generate polygons to display the clusters.

How does this fit in with my eventual implementation? My current thinking is this:

To develop An ASP.NET web application that acts as a “wrapper” around a VB.NET service/application. The wrapper is what the client sees and is in effect the WPS. This is the technique as recommended by Michael and Ames in their early evaluation of WPS. They suggest that the geo-processing takes place in a separate process. This will stop a badly performing process from bringing down the entire WPS (On Windows Server I can put the geo-processing tools in a separate application pool). My ASP.NET application will handle the GetCapabilities and DescribeProcess functions. It will also manage the Execute process by calling the necessary geo-processing service. The geo-processing service will take input from the wrapper and write its results to a results file (e.g. a KML file as above) It will also write to a log file, reporting its progress. The log file can be queried by the ASP.NET wrapper (on request of the client) allowing it to check on progress. The relevant section of the OGC WPS specification is:

"The mandatory Execute operation allows WPS clients to run a specified process implemented by a server, using the input parameter values provided and returning the output values produced. Inputs can be included directly in the Execute request, or reference web accessible resources. The outputs can be returned in the form of an XML response document, either embedded within the response document or stored as web accessible resources. If the outputs are stored, the Execute response shall consist of a XML document that includes a URL for each stored output, which the client can use to retrieve those outputs. Alternatively, for a single output, the server can be directed to return that output in its raw form without being wrapped in an XML reponse document.

Normally, the response document is returned only after process execution is completed. However, a client can instruct the server to return the Execute response document immediately following acceptance by the server of the Execute request. In this case, the Execute response includes a URL from which the response document can later be retrieved during and after process execution. The server can be instructed to provide regular updates to a measure of the amount of processing remaining if the process is not complete. This allows the client to determine the process status by polling this URL. "

The response document will be in effect my log file (an XML document), which while processing is ongoing will provide status updates when queried and when processing is complete will contain URLs to any output e.g. a KML file.

I think this method means generating a separate XML document each time the process is called (each file named with a unique reference number) unless I generate the response document dynamically from ASP.NET.

I need to examine further the approaches taken by 52 North and deegree in their WPS implementations.