The past contents will stay here and also be duplicated at the new blog. Thanks.
The Unlock Places API was recently upgraded to include Ordnance Survey’s Open data. This feature rich data from Code-Point Open, Boundary-Line and the 1:50,000 gazetteer includes placenames and locations (points, boxes and shapes) and is now open for all to use! You can just get started with the API.
We’ve also added new functionality to the service, including an HTML view for features, more feature attributes, the ability to request request results in different coordinate systems as well as the usual speed improvements and bug-fixes.
The new data and features are available from Tuesday, 20th April 2010. Please visit the example queries page to try out some of the queries.
We welcome any feedback on the new features – and if there’s anything you’d like to see in future versions of Unlock, please let us know. Alternatively, why not just get in touch to let us know how you’re using the service, we’d love to hear from you!
Full details of the changes are listed below the fold.
The April 1st release of many Ordnance Survey datasets as open data is great news for us at Unlock. As hoped for, Boundary-Line (administrative boundaries), the 50K gazetteer of placenames and a modified version of Code-Point (postal locations) are now open data.
We’ll be putting these datasets into the open access part of Unlock Places, our place search service, and opening up Unlock Geocodes based on Code-Point Open. However, this is going to take a week or two, because we’re also adding some new features to Unlock’s search and results.
Currently, registered academic users are able to:
- Grab shapes and bounding boxes in KML or GeoJSON – no need for GIS software, re-use in web applications
- Search by bounding box and feature type as well as place name
- See properties of shapes (area, perimeter, central point) useful for statistics visualisation
And in soon we’ll be publishing these new features currently in testing:
- Relationships between places – cities, counties and regions containing found places – in the default results
- Re-project points and shapes into different coordinate reference systems
These have been added so we can finally plug the Unlock Places search into EDINA’s Digimap service.
Having Boundary-Line shapes in our open data gazetteer will mean we can return bounding boxes or polygons through Unlock Text, which extracts placenames from documents and metadata. This will help to open up new research directions for our work with the Language Technology Group at Informatics in Edinburgh.
There are some organisations we’d love to collaborate with (almost next door, the Map Library at the National Library of Scotland and the Royal Commission on Ancient and Historical Monuments of Scotland) but have been unable to, because Unlock and its predecessor GeoCrossWalk were limited by license to academic use only. I look forward to seeing all the things the OS Open Data release has now made possible.
I’m also excited to see what re-use we and others could make of the Linked Data published by Ordnance Survey Research, and what their approach will be to connecting shapes to their administrative model.
MasterMap, the highest-detail OS dataset, wasn’t included in the open release. Academic subscribers to the Digimap Ordnance Survey Collection get access to places extracted from MasterMap, and improvements to other datasets created using MasterMap, with an Unlock Places API key.
David Martin spoke in the EEO seminar series last Friday. Here are my notes:
In the last decades we have become “sophisticated in our tools, but our fundamental techniques and results aren’t very different”. Census data is not the same as demographic data, however census approaches to modelling population have become dominant – a “long-term reliance on census-based shaded area map to inform spatial decision-making.
Importance of small area population mapping for policy – resource allocation and site location decisions, calculation of prevalence rates. “Who is present in a small area, and what characteristics do they have”. A house or flat becomes a “proxy” for a person, who is tied to the space.
This doesn’t give a clear usage picture, specifically it is night-time activity rather than day time which has very different patterns of repetition and variation of movement.
More general problems with census-taking –
- spatially concentrated error
“We could cut the city differently and produce variations in the pattern” – research in automated generation of census zones, looking for areas with social homogeneity, size, population, based on previous samplings.
“Population distribution is not space-filling but is quasi-continuous”.
“Interest in surfaces, grids and dasymetric approaches”. Using a grid to slice and visualise population data. The grid gives us a finer grained depiction of actualy activity.
Interestingly, shift in government policy regarding census taking. Rapid development of space, and new tech, cause problems – people are more mobile, with multiple bases; concerns about data privacy are more mainstream.
The US Census Bureau has dropped the “long-form” return which used to go to one in six recipients. In France the idea of a periodic census has been dropped completely, they now conduct a “rolling census” compiled from different data sources.
“Register-based sources” – e.g. demographic data is held by health services, local government, transport providers, business associations, communications companies. It’s possible to “produce something census-like”, but richer, by correlating these sources.
Also the cross-section of other sources gives an idea of where census records are flawed and persistently inaccurate, e.g. council tax records not corresponding to where people claim they live.
Towards new representations of time-space
Temporal issues still neglected by geodata specialists, in fact some of the issues are gnarlier and trickier than spatial representation is.
Dr Martin identified “emergent issues” affecting this practise- “Spatial units, data sources as streams, representational concepts”. His group has a some software in development to document the algorithm for gridding data space – I wanted to ask whether the software and implicitly the algorithm would be released as open source.
A thought about gridded data is that it’s straightforward to recombine (given grid cells for different sources are the same size). Something like OGC WCS but much, simpler.
One promising presentation I saw last week at the Jornadas SIG Libre – Oscar Fonts’ work in the Geographic Information Group at the Universitat Jaume I building on OpenSearch Geospatial interfaces to different services.
Some are “native” OpenSearch services, like the GeoCommons data deposit and mapmaking service, the interfaces published by Terradue as part of the European GENESI-DR earth observation distributed data repository project.
The UJI demo also includes an API adapter for sensationally popular web services with geographic contents. Through the portal one can search for tweets, geotagged Flickr photos, or individual shapes from OpenStreetmap.
Oscar’s talk highlighted the problem of seeming incompatibility between the original draft of the OpenSearch Geospatial extensions, and the version making its way through the Open Geospatial Consortium’s Catalog working group as a “part document” included in the next Catalog Services for the Web specification.
The issues currently breaking backwards-compatibility between the versions are these:
geo:namein the OGC draft version.
geo:polygonwas omitted from the OGC draft version, and replaced with
geo:geometrywhich allows for complex geometries (including multi-polygons) to be passed through using Well Known Text.
1) looks like syntactic sugar – geo:name is less typing, and reads better. geo:locationString can be deprecated but supported.
2) geo:geometry was introduced into the spec as a result of work on the GENESI-DR project, which had a strong requirement to support multi-polygons (specifically, passes over the earth of a satellite, which crossed the dateline and thus were made up of two polygons meeting on either side of the dateline).
geo:polygon has a much simpler syntax, just a list of (latitude, longitude) pairs which join up to make a shape. This also restricts queries to two dimensions.
This seems to be the nub of the discussion – should geo:polygon be included in the updated version – risking it being seen as clashing with or superfluous to geo:geometry, leading to end user confusion?
There is always a balance to be met between simplicity and complexity, Oscar pointed out in his talk what I have heard in OGC Catalog WG discussions too – that as soon as a use case becomes sufficiently complex, then CSW is available and likely fitter for the job.
geo:geometry is already at the top end of acceptable complexity.
It’s about a year since I helped turn Andrew Turner’s original draft into an OGC consumable form. Anecdotally it seems like a lot more people are interested in seeing what can be done with OpenSearch Geo now.
The OGC version is not a fork. The wiki draft was turned into a draft OGC spec after talking with Andrew and Raj Singh about the proposed changes, partly on the OpenSearch Google Group. The geo:relation parameter was added on the basis of feedback from the GeoNetwork and GeoTools communities. There’s been a Draft 2 page, as yet unmodified, on the OpenSearch wiki since that time.
In order to build the confidence of potential adopters, these backwards-incompatibilities do need to be addressed. Personal point of view would be to update the wiki draft, deprecating locationString and including both polygon and geometry parameters.
I was impressed by the work of Oscar and collaborators, though wondering if they are going to move in to aggregation and indexing, search-engine-style, of the results, or just use the OpenSearch interface to search in realtime fairly fast moving sources of data. I wish I’d asked this question in the session, now. It all offers reinforcement and inspiration for putting OpenSearch Geo interfaces on services nearby – Go-Geo!, CKAN. The NERC Data Discovery Service could benefit, as could SCRAN. We’ll get to see what happens, which I’m glad of.