I have set up a SQL Azure 90 day trial (as of 18th November) to test whether ArcSquirrel can work with Azure. This was prompted by an email from Robert Cheetham, CEO at Azavea, who is investigating cloud solutions for their Cicero product. Here are some notes about
- setting up and accessing SQL Azure databases
- using SQL Azure with ArcGIS + ArcSquirrel and MapLink
- using SQL Azure with Quantum GIS and MapServer.
Azure Management Portal
Although I’ve never set up any cloud services before (other than Arvixe web hosting) it was incredibly easy to setup a trial SQL Azure subscription (“Windows Azure Platform Introductory Special”), create a database, and add some firewall rules to control access. I didn’t dig deep, but the “Management Portal” seems nice and simple:
It helpfully tells you your connection string for ADO.Net, ODBC and PHP (passwords not included!):
See this page for details of the Windows Azure Platform Introductory Special including what you get for no charge and the pricing for the rest.
MapLink, ArcSquirrel and Azure
Hartmut connected up our MapLink to the database and pushed some spatial data into my Azure database from ArcGIS – 20,000 polygons took about 75 minutes. Hartmut had the layers drawing in ArcMAP, performing as well as in a normal SQL Server instance apparently, with only minor mods to our code to make the initial connection. However editing will not work without some more tweaks - MapLink and ArcSquirrel rely on some SQL metadata that is a little different on Azure.
SQL Server Management Studio and MS Access
Connecting with SSMS is simple, however you get reduced functionality – for example you cannot right-click > edit top 200 records or anything, so quick edits of a small table need to be done with SQL or in MS Access or some other client. Fortunately connecting with MS Access (ODBC + SQL Native Client 10) is also simple, and the Azure database behaves just like a local SQL instance – remarkable querying speed (all things considered), though slower inserts (10,000 records took something like 15 minutes). NB you cannot directly link a spatial table into Access because it doesn’t recognize the geometry data type; but to update attributes you can link a view.
Also, in SSMS you get no designer tools, e.g. for creating a view; everything has to be done with T-SQL.
SQL Azure Database Manager
After writing the above I found the database manager in the Azure control panel, which has functionality similar to SSMS, including the ability to edit the tables*:
* spatial data types not supported for view or edit.
You get a designer for creating/modifying tables, but views and stored procedures are T-SQL only.
MapServer, OGR and Azure
Next I wanted to try serving the data through MapServer, and viewing/editing the data in Quantum GIS or MapInfo. MapServer and QGIS require the “geometry_columns” and “spatial_ref_sys” tables, and the easiest way to create these is to push some data in with ogr2ogr.
So I tried this from one of our London servers. I loaded a few hundred linear features, but got four errors like “INSERT command for new feature failed… incorrect syntax…”. On checking the results, a) while the geometries had loaded fine, all the attribute fields were NULL, and b) the spatial_ref_sys table was empty. I had four attribute fields, so my guess is that each syntax error was one field update across all records using a join on the incoming data.
Next I hooked up a MapServer WMS to my SQL Azure tables. MapServer had no trouble connecting to my Azure tables, but initially wouldn’t draw anything… on investigating I found that ogr2ogr had not correctly set the SRID of the geometries, so I had to update them “manually” with:
update esdm_waters set ogr_geometry.STSrid = 4326
(which, incidentally, took 1 minute 52 seconds for 788 rows, demonstrating that updating an Azure database ain’t quick).
Clearly OGR needs a little work to do on SQL Azure support, but this was enough to get me going.
The WMS worked, so to challenge it a little more I set up another WMS onto a table with about 8000 sub-tidal habitat polygons, showing red in this OpenLayers map:
And here showing the rivers WMS as well (blue lines):
Performance of these two layers was perfectly acceptable, though actually about 100% slower than the same WMS working from a local SQL Server 2008 Express instance. It would be interesting to see what it could do with MapServer also running on Azure.
I also tried a WFS – again, performance was acceptable though significantly slower than running with a local SQL instance (though I didn’t do strict comparisons).
Quantum GIS and SQL Azure
I found this really helpful blog post to get started: http://woostuff.wordpress.com/2011/03/13/opening-ms-sql-spatial-in-qgis/
Adding the layers requires some python script, but I’m sure someone will write a GUI plugin for QGIS soon.
First make sure you are running a version of QGIS that has GDAL/OGR 1.8 libraries – I’m on 1.7.0 which is OK.
Open the Plugins menu > Python Console
and type in these two commands (modified for your data):
uri = "MSSQL:server={serverName};database={databaseName};tables={tableName};trusted_connection=yes"
qgis.utils.iface.addVectorLayer(uri,'{yourLayerNameHere}','ogr')
In my case:
uri = "MSSQL:server=tcp:a0awtn7gg9.database.windows.net;database=ArcSquirrel1;tables=esdm_waters;Uid=exegesis@a0awtn7gg9;Pwd=myPassword;"
qgis.utils.iface.addVectorLayer(uri,'Rivers','ogr')
Without any fuss my rivers dataset appeared:
And I can create and edit features and their attributes, here adding a test line off the Hebrides:
And to prove it, here’s my new feature in OpenLayers…
And finally, here we have the habitat polygons (EPSG:27700) colour coded by habitat type, as well as the rivers (EPSG:4326), in QGIS. Polygon editing also worked fine, once I’d worked out why my new polygons kept vanishing (doh, classified symbols).
Lots to think about, and I look forward to editing the same data with ArcGIS and ArcSquirrel soon…