Nov 4 2013
This is the first post of a little series that I’m writing on the back of a project on which I have worked for the past couple of months. This initial feature focuses on the overall architecture and the core elements of the solution. The follow-ups will be dedicated to varied tips and tricks that might help you solve some of the less obvious gotchas when working with a similar software stack.
Introducing Cordiale Project
The copy from the official site defines the overall purpose of the Cordiale framework much better than I possibly could.
Cordiale is a cross-border project working on sustainable landscape management. Its vision is to ‘adopt a common standard for informing and assisting the management of protected landscapes in furtherance of the European Landscape Convention and in the context of climate change’.
I have had the joy to develop the “Landscapes Map” section, which in essence, provides an interactive map with environmental data from 4 protected natural areas that are distributed between the South of England and North West of France.
This is what the finished product looks like, and regardless of my clear bias here, I think it would be fair to immodestly claim that it turned out quite pretty*
So please go ahead, check it out, and let me know your thoughts!
Cordiale is very comprehensive environmental project, that has not only procured a considerably large dataset on landscape management, but also promoted actual hands-on involvement in the concerned areas. Feel free to have a look throughout the main website, there are plenty of interesting materials on the many initiatives that have been led by the project, as it is shown throughout the official case stories
Choosing a client-side library
I came into this project with a little experience on Google Maps, but nothing that you couldn’t learn from reading a few tutorials over a weekend. Due to its popularity, Google Maps would have normally been the top candidate to create this kind of web-based mapping mash-up.
However, we had to steer clear of the Google Maps API from the very beginning, because its licensing terms are not compatible with the publicly-available GIS data that we intended to source from Ordnance Survey.
This particular licensing issue does actually serve as a good example of why you might prefer to go against the grain, and skip the Google Maps API altogether. As a matter of fact, many compatibility issues with Google Maps usually stem from the fact that you have to rely on Google not making an arbitrary legal or licensing decision that might clash with your interests, e.g., Google Maps API v2 required a business (read paid) licence in order to be used over https.
Coming to our rescue, there are some interesting Open Source mapping libraries, that are far more permissive, and can even let you combine the raster imagery from Google with other providers, such as: Bing Maps, Yahoo! Maps, OpenStreetMap, etc.
There are 2 main contenders to consider on the OS side of things, OpenLayers and Leaflet.
Now, bearing in mind that your mileage will definitely vary depending on the requirements of your project. The general consensus is that while OpenLayers is a mature framework, that can be integrated with popular GIS technologies; Leaflet contains a more lightweight codebase, that makes up for its reduced set of functionality with third-party plugins and really straightforward syntax.
In this project we favoured OpenLayers, mainly for its support of the WFS (Web Feature Service) protocol, and the easy integration with GeoServer.
Choosing a back-end for GIS data
The project needed to display a vast amount of GIS-related data at several precision/zoom levels. Mind you, you don’t really need a GIS server for some common web-mapping interactions, e.g., displaying the closest branches of a chain of stores, or maybe overlaying some simple poll results over a country map.
However, in the particular case of Cordiale, the layer with hedgerows information alone, contained 80MB worth of data, and it would have been a bit rude to make a user wait for such a hefty download.
Having a Mapping Web Server, that implements standard protocols from the OGC (Open Geospatial Consortium), like WMS, WFS and WCS, allows you to query for the subset of data that is specifically relevant to a set of constrained coordinates.
In our case, Geoserver stood out as the top candidate, as it is the most widespread and supported Open Source server available.
Speaking of “architecture” might seem a bit ambitious, since the project itself is fairly straightforward in its implementation, but this diagram saves me the thousand words that I’d need to describe how everything gets cobbled together.
ASP .NET Web API has become quite my weapon of choice for any kind of web service-related project. It’s an extremely easy way to get up and running with a REST API, that is, of course, provided that you feel most comfortable with a .NET stack.
Also, if you were to think that a Microsoft framework stands out in the software described on this post, as it doesn’t quite belong with the Open Source tooling, you would then be wrong, very wrong indeed.
Make it cloudy
For the past 3 years or so, I’ve been systematically synchronising all my pet projects with a remote git repository as a standard routine.
It might also be worth noting, that for my non-public projects I chose Bitbucket over Github a good while ago, as their private repos are free of charge.
Well, the point that I was getting to, is that I have really enjoyed the workflows that come with Windows Azure; setting up an external git repository takes no more than couple of minutes.
My resulting development/deployment flow was something along these lines:
- Write some code in Visual Studio
- commit and push to your dev branch with the integrated Git tools
- Perform local tests on Cassini/IIS
- push to the deployment branch when you feel like showing things to others
- Wait a minute for the code to be automagically packaged, compiled and ready to be refreshed on the public site
- All of that, with the added benefit of being able to press the “Oh S***!” button. Which is another way of saying that you can jump back-and-forward between your historical deployments with a single click.
*I would also like to give a shout out to Pete at metazoa.co.uk, who happens to be the guy responsible for the rather sweet look and feel of the Cordiale Project website and the maps above.
If you are needing a web/graphics designer in the Edinburgh area, I would absolutely recommend you to have a chat with him