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.

  • 1
    Are you looking for an out of the box API like the ArcGIS flex viewer or something that you want to further customize?
    – artwork21
    Commented Nov 22, 2011 at 16:25
  • I would like to try and customize something (or things). I'm currently using PostGIS for data storage and analysis, and mapserver (but by no means an expert using either). I'm wondering what the next step would be to make this accessible to others and to figure out what I should be learning.
    – djq
    Commented Nov 22, 2011 at 16:39

2 Answers 2


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.

  • Thank you for your thoughts - perhaps I used API incorrectly in my question. I am interested in both a WMS and WFS service (both raster and vector); your explanation is very useful as I think about this more.
    – djq
    Commented Nov 22, 2011 at 16:46

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.