Category Archives: search

Exploring the Locator OS OpenData set

Posted on by

Fiona Hemsley-Flint had a good look at the OS Locator dataset which is available from the Ordnance Survey Open Data portal. I thought a summary of her findings might be of use to others thinking about how to use this dataset.

Overview

OS Locator contains a list of all the road names in UK, “derived from a number of Ordnance Survey datasets [Meridian2, Road database, Locality dataset, Boundary-Line]. These include the roads database which contains information on road names and road numbers and is the latest generation of Ordnance Survey’s sophisticated and highly detailed geographic data”. OS recommend viewing it on top of mid-scale datasets such as 1:10k & 1:25k Raster and streetview (which is freely available via OS opendata).

Geometries

Each feature is geo-referenced by a centre point and a bounding box (although some of the bboxes are actually line features where the road segment of the feature is horizontal or vertical).
OS Locator names shown on OS map
Figure 1. Multiple occurrences of Ferry Road, differentiated by their locality.

Attribution

The roads have a name and/or a classification, where the classification represents a road number, (e.g. ‘A1′ or ‘B1243′). They also have an associated settlement (town), locality, county/region and local authority; the latter two are derived from Boundary-Line, it is unclear what is used to form the ‘Locality dataset’. Locality and settlement are likely to be the most useful of these attributes when displaying result sets. For roads which cross locality boundaries, a point is assigned for each separate locality, therefore one road may have more than one point associated with it, distinguished by its locality.

Storage

851505 rows of data were added to a development server.
Multiple geometry columns have been added to take into account the different geometries available.
A ‘tsvector’ column has also been added to implement Postgres text search functionality. An example query might be:
select name, classification, locality, settlement from os.locator_nov_10 where search @@ to_tsquery(‘high & street & edinburgh’);

Which returns the following result set:

Name	Classification	Locality	settlement
CORSTORPHINE HIGH STREET		Se Corstorphine	EDINBURGH
HIGH STREET		Musselburgh Central	EDINBURGH
HIGH STREET		Musselburgh North	EDINBURGH
HIGH STREET		Holyrood	EDINBURGH
HIGH STREET	A199	Musselburgh North	EDINBURGH
HIGH STREET	A199	Musselburgh Central	EDINBURGH
NORTH HIGH STREET		Musselburgh North	EDINBURGH
NORTH HIGH STREET	A199	Musselburgh West	EDINBURGH
PORTOBELLO HIGH STREET	B6415	Milton	EDINBURGH
PORTOBELLO HIGH STREET	B6415	Portobello	EDINBURGH
NORTH HIGH STREET	A199	Musselburgh North	EDINBURGH

Overall, the dataset contains a comprehensive list of the roads names within the UK. Decisions will need to be made about how to treat multiple features that actually refer to the same real world road.

The main limitation of this dataset is that it can only be used to show the user the general location of a road – it can’t be used as a precise address gazetteer since it only provides street names with no knowledge of building numbers.

Using source identifiers to link data

Posted on by

In the Chalice project we’ve used Unlock Places to make links across the Linked Data web, using the source identifier which appears in the results of each place search. As this might be useful to others, it’s worth walking through an example.

This search for “Bosley” shows us results in the UK from geonames and from the Ordnance Survey 50K gazetteer: http://unlock.edina.ac.uk/ws/nameSearch?name=Bosley&country=uk

Here’s an extract of one of the results, the listing for Bosley in the Ordnance Survey 1:50K gazetteer:

<identifier>11083412</identifier>
<sourceIdentifier>28360</sourceIdentifier>
<name>Bosley</name>
<country>United Kingdom</country>
<custodian>Ordnance Survey</custodian>
<gazetteer>OS Open 1:50 000 Scale Gazetteer</gazetteer>

The sourceIdentifier shown here is the identifier published by each of the original data sources that Unlock Places is using to cross-search.

Ordnance Survey Research re-uses these identifiers to create its Linked Data namespace. For any place in the 50K gazetteer, we can reconstruct the link that refers to that place by appending the source identifier to this URL, which is the namespace for the 50K gazetteer: http://data.ordnancesurvey.co.uk/id/50kGazetteer/

So our reference to Bosley can be made by adding the source identifier to the namespace:

http://data.ordnancesurvey.co.uk/id/50kGazetteer/28360

The same goes for source identifiers for places found in the geonames.org place-name gazetteer.

<sourceIdentifier>2655141</sourceIdentifier>
<name>Bosley</name>
<gazetteer>GeoNames</gazetteer>

Geonames uses http://sws.geonames.org/ as a namespace for its Linked Data links for places. So we can reconstruct the link for Bosley using the source identifier like this:

http://sws.geonames.org/2655141/

Note that the link needs the forward slash on the end to work correctly. If one looks at either of these links with a web browser, one is redirected to a human-readable page describing that place. To see the machine-readable, RDF version of the link’s contents, look at it with a command-line program such as curl, asking to “Accept” the RDF version:

curl -L http://data.ordnancesurvey.co.uk/id/50kGazetteer/28360 -H "Accept: application/rdf+xml"

I hope this is useful to others. We could add the links directly into the default search results, but many users may not be that interested in seeing RDF links in place-name search results. Thoughts on how we could offer this as a more useful function would be much appreciated.

More on the use of Unlock Places by georeferencer.org

Posted on by

Some months back, Klokan Petr Pridal, who maintains OldMapsOnline.org and works with libraries and cartographic institutes across Europe, wrote with some questions about the Unlock Places service. We met at FOSS4G where I presented our work on the Chalice project and the Unlock services.
Petr writes about how Unlock is used in his applications, and what future requirements from the service may be:

It was great to meet you at FOSS4G in Barcelona and discuss with you
the progress related to Unlock and possible cooperation with
OldMapsOnline.org and usage in Georeferencer.org services.

As you have mentioned, the most important thing for us would be to
have in Unlock API/database the bounding boxes (or bounding polygons) for places as direct part of the JSON response.
We need that mostly for villages, towns and cities and for areas such
as districts or countries – all over the world. We need something like
“bounds” as provided by the Google geocoding API.

The second most important feature is to have the chance to install the
service in our servers – especially in case you can’t provide
guarantees for it in a future.

It would be also great to have chance to improve the service for non-English languages, but right now the gazetteers and text processing is not primary target of our research.

In this moment the Unlock API is in use:

As a standard gazetteer search service to zoom the base maps to a place people type in the search box in our Georeferencer.org service – a
collaborative georeferencing online service for scanned historical
maps. It is in use by National Library of Scotland and a couple of other libraries.

Here’s an example map (you need to register first).

The uniqueness of Unlock is in openness of the license (primarily GeoNames.org CC-BY and also OS OpenData) and also so far very good availability of the online service (EDINA hardware and network?). We are missing the bounding box to be able to zoom our base maps to the correct area (determine the appropriate zoom level). Unlock API replaced Google Geocoder, which we can’t use, because we are displaying also non-google maps (such as Ordnance Survey OpenData) and we are potentially deriving data from the gazetteer database (the control points on the old maps), which is against Google TOS.

In the future we are keen to extend the gazetteer with alternative
historical toponyms (which people can identify on georeferenced old
maps too), or participate on such work.

The other usage of Unlock API is:

As a metadata text analyzer, in a service such as our
http://geoparser.appspot.com/, where we automatically parse existing
library textual metadata to identify place names and locate the
described maps including automatic approximation of their spatial
coverage (by identifying map scale and physical size in the text and
doing a simple math on top of it). This service is in a prototype
phase only, we are using Yahoo Placemaker and I was testing Unlock Text API
with it too.

Here the huge advantage of Unlock would be primarily the possibility
to add custom gazetteers (with Geonames as the default one), language detection (for example via Google Language API or otherwise) and also possibility to add into the workflow other tools, such as lemmatizator for particular language – the simplest available via hun/a/ispellu
database integration or via existing morphological rule-based software
such as:

The problem is that without returning the lemmatization of the text the geoparser is almost unusable in non-English languages – especially Slavic
one.

We are very glad for availability of your results and of the reliable
online services you provide. We can concentrate on the problems we
need to solve primarily (georeferencing, clipping, stitching and
presentation of old maps for later analysis) and use your results of
research as a component solving a problem we are touching and we have to practically solve somehow.”

Very glad that Petr wrote at such length about comprehensive use of Unlock. pushing the edges of what we are doing with the service.

We have some work in the pipeline adding bounding boxes for places worldwide by making Natural Earth Data searchable through Unlock Places. Natural Earth is a generalised dataset intended for use in cartography, but should also have quite a lot of re-use value for map search.

OpenStreetmap and Linked Geodata

Posted on by

I’ve been travelling overmuch for the last six weeks, but met lots of lovely people. Most recently, during a trip this week to discuss the Open Knowledge Foundation‘s part in the LOD2 consortium project, had a long chat with Jens and Claus, the developers and academics behind Linked Geo Data, the Linked Data version of the OpenStreetmap data.

linked geodata browser

The most interesting bit for Unlock is the RESTful interface to search the data; by point, radius, and bounding box, by feature class and by contents of labels assembled from tags. So it looks like Opensearch Geo as much as Unlock’s place search api does.

Claus made up a mapping between tags and clusters of tags in OpenStreetmap, to a simple linkedgeodata.org ontology. Here’s the mapping file – warning, it is quite large – OSM->linkedgeodata mapping rules. Pointed him at Jochen Topf’s new work on OSM tag analysis and clustering, Taginfo.

As well as the REST interface, there is a basic GeoSPARQL endpoint using Virtuoso as a Linked Data store – we ran containment queries for polygons returning polygons with reasonable performance. There is a fracturing in the GeoSPARQL world both in proposed standards and in actual implementation.

So we want to be able to return links to LinkedGeodata.org URLs in the results of our search. Right now Unlock’s place search returns original source identifiers (from geonames, etc) as well as our local identifiers, for place-names and shapes. In fact Unlock could help with the mapping across of Linkedgeodata.org URLs to geonames URLs, which are quite widely used, an entry point into the bigger Linked Data web.

Another very interesting tool for making links between things on the Linked Data web is SILK, by Chris Bizer, Anja Jentsch and their research group at the Freie Universitat Berlin. The latest (or still testing?) release of SILK has some spatial inference capacity as well as structural inference. So we could try it out on, for example, the Chalice data just to see what kind of links can be made between URLs for linkedgeodata things and URLs for historic place-names.

We’ve been setting up an instance of OpenStreetmap for Unlock and other purposes at EDINA recently. Our plan with this is to start working from Nominatim, which has a point-based gazetteer for place-names down to street address level, and attempt to extract and/or generalise shapes as well as points corresponding to the names. We’re doing this to provide more/richer data search, rather than republishing original datasets in some more/differently interpretable form. So there’s lots of common ground and I hope to find ways to work together in future to make sure we complement and don’t duplicate.