Designing an API for spatial data

Question

I am considering trying to make an API so that I can make some spatial datasets available to colleagues for analysis.

Part of my work has been to analyze and prepare data which can then be used for further analysis by others. The work (while currently at a smaller scale and less sophisticated) is similar to walkscore but does involve some enormous datasets. There are increasing restrictions on how I can share the original data, but my derivative work is shareable. I have been thinking about about how best to share the results of my analysis (outside of passing on large datasets) and thought that an API would be one approach. What sort of things, should I be thinking about when constructing an API? Are there design specifications that I can follow?

My vision sounds a little more grandiose than it currently is, but I think it would be a useful framework to consider early on in this work.

Answer 1

By API, I presume you mean some sort of network access to your data through an HTTP POST/GET type affair such as the Google Maps API? Will it be raster or vector data? I'll assume vector for the purposes of this discussion. This is really just a communication protocol rather than an Application Programming Interface.

You won't need to design anything from scratch, because there are plenty of standard protocols (rather than APIs per se, I have a bit of a bugbear about calling things APIs when they're not, but I won't bore you!). If you are just interested in serving read-only vector data to your clients, you just need a WFS Server that sits in front of your database. I've used GeoServer in the past, but I prefer the lightweigtness of TinyOWS. Both do the same job: configure them to access your database of derived data, set them running as part of a web server (Apache is common, but I prefer lighttpd), and there you have it. QGIS can load data from a WFS server, and doubtless so can Arc. OpenLayers also has WFS rendering capabilites for a browser-based solution. At the lower level, GDAL can be used to convert the data from WFS to any vector format OGR supports.

If you want editing capabilities, both GeoServer and TinyOWS support WFS-T, enabling your users to upload their analyses back to your server.

Creating your own API really defeats the purpose of having these standards in the first place, unless you're incredibly specialised and you have specific requirements such as performance, and er... that's about all I can think of. Going this route, without a reasonable amount of resources is a fraught - although not impossible - task.

Answer 2

You have a couple of options; the choice of which will depend on your data model, the type of data to be served, the intended usage model, access control as well as the platform of delivery (Web, HTML, Java Server, IIS, static data set).

1. Extend an existing product to consume your data set. You could look at hosting a GeoServer instance on your (or dedicated?) computer and deliver your data that way. If your data is not of a format that GeoServer can understand, you have the option of writing a Java package to provide that ability. The advantage, is that you have a well defined standard for delivering spatial information for both visualisation (WMS) and feature manipulation/download (WFS), as well as other benefits like geocaching and tiling.
2. Take your API option and you have full control over how users interface with it. Which comes to your first task, Define how you want users to interact with your data. This interface to your data will be the key between success or failure. If your interface is too open, it can become complex and unusable, too simple and restrictive, slow or no adoption. Either way, defining the way you want users to access your data, and the way you anticipate users will want to use your data will be important.

Good luck, an API is not a small undertaking as you need to consider release method and cycles, bug fixes, testing. All these contribute to usability. I'm not saying don't do it, it'd be a great experience. Though building upon an existing product could be a positive experience too.