RAGLD - Rapid Assembly of Geo-Centred Linked Data Applications

Editor's Notes

• #9: 1 Needs a web serverGo to your friendly Nimbus store and pick up one of their standard box sets. For our internal version of RAGLD, we chose a LAMP stack. A basic linux machine, nothing particularly special in terms of memory, processors or disk space. In fact, we only have a default 50g of disk space – Nimbus is keen that people only order the amount of space they need at the time, in the knowledge that it can be extended later. The LAMP stack provides everything we need to build our web applications.On top of the basic services, we added PostGIS as I thought it provided more advanced spatial functionality than the MySQL Spatial Extensions. And it’s also open source, hugely popular and has very good online resources. We also installed the raptor RDF interpreter and a couple of other things. Everything that RAGLD uses is open source and easily available, and to make things easier there is a RAGLD installation script that fetches each of the packages and installs whatever isn’t already available on the host.With all the building blocks in place, we can now run a RAGLD setup script that will create a local environment and we’re good to go.The core of RAGLD is built in php, as are all of the individual services. It’s easily configurable, once you know where to go, and remarkably simply to add new services for additional functionality or to support new data.PostGIS is used to store data. Run spatial queries. Common methods perform the tricky extract of spatial information from online resources.
• #10: To access the local environment, type in the address in a browser. So, for example, lv320.ordsvy.gov.uk/tony, and you get the welcome page
• #11: Click on the index of services to see what services are available in the current environment. All of the available services are written in php and accessed through the address bar (or by clicking on the links).
• #12: This is the section of the config file that sets up the data source for the airports service. The common template file is the GeospatialRelationshipService.php, and that has all the method calls for running spatial queries. To make it specific for airports, we set the datasource in the config file. We’ll do this sort of thing whenever we’ve set up a local store of indexed URIs (basically a PostGIS table of URI/geometry with a spatial index) which simplifies the querying. The URI in the table provides the link back to the big wide world of linked data
• #13: Each of the services are called through a php template file, which has all of the common spatial queries. How the file operates for individual service types (ie to access airports, but stops, postcodes and so on) is configurable in a turtle file in the home directory for the current environment.
• #14: Services are called through a URI. For example, to get a list of the features available in the airports store you would type http://lv320.ordsvy.gov.uk/tony/services/geo/airport/features/ into a browser, and back comes a list of available URIs which you can then click to wander merrily around the online resources.
• #15: Calling the services through URIs is where the RAGLD magic really starts to work. By requesting a service through a URI we are effectively creating a URI that encapsulates the results of that service. So, with the previous example of a service request to list airport features in the index, what we’re effectively doing is creating a URI that embodies that list. So this URI can be passed as a resource to another RAGLD service to do even more interesting things.I’ll go through a simple example to try and explain. Let’s say we want to find B&Bs that are within a certain distance of a planned route
• #16: We start with an indexed store of UK B&Bs derived from online resources. The B&Bs are stored in a PostGIS table to simplify indexing and querying
• #17: This is a geometry of a journey from Totton to Basingstoke which we will use as the input to our query request. The coordinates could be derived in many ways – in this instance, Ian stored GPS coordinates from a drive up the M3. But they could have been digitised, or downloaded, or whatever. These coordinates are in WKT format, to simplify viewing. The important thing is that it has a URI, which is what we will use to reference the route in RAGLD service calls
• #18: We take our URI for the route, and encode it so that it can be passed around the RAGLD services. If we pass the encoded version of the original resource to our ingestion service, we can see the route on a map. Lovely
• #19: Again, we start with our route and encode it so that it can be passed around the services. This time, we will call our buffering service to create a 10km buffer around the original line.
• #20: We then use that URI for the buffered line as the argument to our B&B ‘within’ service. This is asking ‘which of our B&Bs in the store are contained within the buffered version of the original text representation of our line?’ And back comes a list of results. All very nice, but it would be nicer on a map
• #21: So we pass the whole URI of the query of which B&Bs are within our buffered line to thestandard ingestion service to put those results onto a map, with clickable icons that will whizz us off to whatever the online resource is for that URI. So we can do a whole load of things through a single URI that encapsulates calls to various services.Which is all great in theory. But what about in practice? Guy/Lucy can tell us more about whether creating an application in this way is as easy as it sounds