Geotagging is the process of associating with textual data items the geographic position they denote, usually in the form of geographical coordinates (latitude and longitude). Automatic geotagging is often trivial relying on one of the many available gazetteers, such as OpenStreetMap (OSM)1. However, such knowledge bases are not free of errors, and, while this simple match works for popular locations, automatic annotation of less relevant venues and events may be signi cantly inaccurate. The goal of this work is to increase geotagging quality (in terms of completeness and accuracy) by also identifying and jointly exploiting diverse data sources as gazetteers. This will also allow us to cope with ambiguity by additionally performing semantic queries in various open knowledge bases.
The ability to geolocate a user (i.e., to assign a geographic position) enables a number of location-aware applications and services. Similarly, associating geolocation information to data enables managing and analyzing them on the basis of the geographic dimension. When no explicit georeferencing (e.g., in the form of location metadata coming from the application providing data) is available, geolocation can be implicit and can be inferred, with variable degree of con dence, by the data itself, which may contain, for example, names of entities with known spatial location. Georeferencing by place name is an informal and the most common form of georeferencing approach. We commonly use place names in conversations, correspondence, reporting, and documentation.
Data are said to be implicitly (or indirectly) georeferenced [
More preciselly, geotagging is the computational process of transforming a textual location description2 into a location on the Earth's surface (spatial representation in numerical coordinates). The geotagging process therefore produces a function that, given a toponym, returns the corresponding coordinates.
Automatically geotagging is usually trivial using one of the many available
curated geographical knowledge bases. Dictionaries of placenames are called
gazetteers [
The quality problems that may a ect geotagging can be classi ed in three categories: (i) accuracy/correctness issues: datasets can contain human mistakes; (ii) completness issues: no metadata are available; (iii) consistency issues leading to ambiguity: when names of places are generic and there are no additional information to devise whether a name refers to a village or to a mountain and so on. These ambiguity problems are usually di cult to solve even with human intervention.
In this paper, we propose to cope with these issues by jointly exploiting heterogeneous datasets and relying on strong assumptions on the geographical domain, in terms of: (i) a speci c geographical area, and (ii) a speci c domain of interest the geonames refer to.
Diverse data sources are exploited in order to achieve a fast and accurate automatic geotagging, allowing to cope with both human induced errors, gazetteer incompleteness, and ambiguity. In particular, we combine the usage of a geotagging approach relying on a crowdsourced gazetteer containing toponyms related to the speci c domain, with semantic searches on dataset, like DBpedia3, in order to disambiguate toponyms and achieve a higher accuracy.
The advantage of using a combined approach is due to the speci c characteristics of the di erent datasets. Crowdsourced gazetteers help us in addressing the problems related to the use of vernacular and very speci c names. On the other hand, semantic sources help to exploit a semantic layer with the aim of achieving an higher precision and a lower ambiguity. As a speci c use case, we will consider data from an outdoor tourism domain.
Related work. Geotagging consists of toponym recognition and toponym
resolution. Toponym recognition assigns a possible geographical metadata (e.g.,
matching the toponym in a gazetteer) to geographical name. Toponym
resolu2 In the rest of the paper, we will use the words toponym, that means placename, and
geoname, as synonyms, to refer to textual location descriptions.
3 dbpedia.org/
tion, instead, eliminates the geo/non-geo ambiguity (e.g., Washington can be
a city in the USA or the name of a person). There are di erent strategies to
do this: (i) nding names in the text that exist in a gazetteer [
Outline of the paper. The remainder of the paper is structured as follows: Section 2 states the problem and presents the proposed solution, Section 3 illustrates the speci c scenario, and Section 4 concludes by discussing future work. 2
In this section, we rst present the formalization of the problem, starting from a simple geotagging function and extending it to cope with issues that may impact geotagging quality. Then, we present a speci c istantiation of the proposed approach.
Geotagging function. Given a set of input toponyms, belonging to some texts or to an input dataset, we want to de ne a geotagging function associating geographical metadata with these toponyms.
Let C R2 be a set of geographical coordinates corresponding to locations in the physical world, and T be a set of toponyms, i.e., strings denoting locations. Let G be a gazetteer, i.e., a set of pairs of the form (t; c), where t 2 T is a toponym referring to a speci c location c 2 C (coordinates).
The simplest geotagging function fG relying on a gazetteer G is de ned as: fG : T ! C, where fG(t) = c s.t. 9!(t; c) 2 G. We notice that fG is partial since it is unde ned for t if (i) t 62 1(G) or (ii) several pairs in G for t are found.
Assuming that our dataset is split into speci c known geographic bounding boxes de ne as BB C C, e.g., country or geographical regions. We can now de ne the geotagging process related to a speci c geographical area as a bounding box b 2 BB represented as a pair of coordinates. We de ne a function g relying on G that, given a speci c toponym t 2 T and a speci c b 2 BB returns its coordinates c 2 C. More formally, gG : T BB ! C where gG(t; b) = c if (t; c) 2 G and c is included in bounding box b. The g function is partial but the point (ii), explained above, is partial solved.
In Figure 1, we graphically depict the geotagging function for a speci c bounding box.
Issues in geotagging and proposed approach. There are a number of issues in realizing the geotagging function gG: (i) typos and alternatives names, (ii) G incompleteness, (iii) ambiguity. To avoid these issues, in the following we discuss how we extend the geotagging function gG.
Naming di erences and typos. To solve typos and alternative name problems that toponyms can have, we introduce a correction function . For example, we can have di erent toponyms like \Tour Ei el", \Ei el Tower" or \eifel tower" and we would be able to geotag correctly \Tour Ei el" in all these cases. To do this, we de ne as follow: 8t 2 T (t) = t if (t)
1(G) (t) = t0 otherwise where t0 2 T is the toponym closest to t according to a string similarity function (and s.t. t and t0 similarity according to such function is above a xed threshold).
Therefore, we de ne function hG as follows:
hG(t; b) = gG( (t); c) Dataset incompleteness and ambiguity. The problem in the application of function hG is that, in a real scenario, it is di cult to have a set G complete for a speci c set of toponyms T . Since individual datasets are incomplete, we propose the combined use of di erent datasets for which an order has been speci ed. The use of a sequence of gazetteers works like a lter on T . Performing geotagging on di erent gazetteers, we can also disambiguate toponyms. Ambiguity arises when several alternative geographical coordinates are found for one toponym. The same name may indeed denote di erent geolocated objects.
Let G = G1; :::; Gn be a sequence of gazetteers, we de ne a new function k on G as:
kG (t; b) = c if hGi (t; b) = c ^ 8j < i:(t; c) 62 Gj
Note, therefore, to cope with ambiguity, we rely on two approaches: - the usage of bounding box b 2 BB in order to reduce the geographical area in which we search a toponym (see gG). - the usage of multiple gazetteers Gi in order to understand exactly which toponym we found (see kG ).
Instantiation of geotagging function kG We describe a speci c solution exploiting three di erent gazetteers. The described solution relies on the assumption that toponyms refers to a speci c domain of interest. In details, as we can see in Figure 2, the istantiation of G is: 1. G1 : OpenStreetMap(OSM) 2. G2 : DBpedia. 3. G3 : speci c domain websites.
Our function kG cycles on G in order. In the follow, we describe in detail G1; G2 and G3. The way we query these gazetteers is the implementation of hGi . The bounding boxes provided as input to the functions for di erent Gi are the same.
OpenStreetMap We use OSM and OverpassAPI as a geotagger. The use of OSM
helps us to extract vernacular toponyms. Moreover, knowing a speci c tag of
the toponym, we are able to assert the correctness of our preliminary solution.
In this speci c case our correction function is the Levenshtein distance[
DBpedia We use DBpedia for data geotagging. We query DBpedia with a SPARQL endpoint (see the query in Figure 2). The use of semantic information helps us to disambiguate in case of multiple matches coming from the previous step. Moreover, in case of extraction of new toponyms, if we extract more than one solution, we are able to choose the correct one. This is because we know the meaning of this object. With this gazetteer, the correction function in the lter option of our SPARQL query. We use regex function in order to nd similar strings. Web sites We query speci c information from the web that we know being related to our speci c domain. We create a web crawler on websites related to the speci c domain and we extract from them the coordinates of our toponyms. This implementation is still in progress and we cannot provide more details about it. 3
As an application of the proposed approach, we consider a dataset containing toponyms related to the touristic outdoor domain. The dataset used in this application is a private dataset. We are, thus, not allowed to share the data.
The entire dataset contains more or less 50000 toponyms from all over the world. The toponyms are split in three di erent types of area: data from administrative areas (e.g., Ande), countries (e.g., South Africa) and geographical areas (e.g., Caucaso). Therefore, the possibility to split the dataset in subsets related to a speci c geographic bounding box is due to information provided in the dataset itself (and provided by the data owner). These toponyms are not uniformly distributed over the world. In order to provide some information related to the sparsity of the dataset, in South Africa we have 300 toponyms, in the Ande area we have 3000 toponyms and in Causaso we have 100 toponyms.
The data are structured and each data item contains the following elds: toponym name, toponym name without typology, main locality (nullable eld) and altitude (nullable eld). These data have been collected over 30 years from di erent sources (e.g. books, journals, website, ecc.). These data are very noisy and imprecise but the expertise of the owner of the data can give us the assurance that the data are related to the touristic outdoor domain only.
Since we have toponyms from all over the world, our algorithm works on separate subsets of this domain. In case of administrative areas and countries, we have speci c BBs retrieved from geographical gazetteers. The geographical area has a di erent problem: we must choose a priori the relative BB. In this case we can have two di erent problems that could increment errors retrieving toponyms: (i) we can take a BB that does not correctly cover the entire area, therefore loosing some toponyms, (ii) we can take a \big" BB and increment the ambiguity in retrieving toponyms.
Following the process explained in Section3, rst of all we clean the OSM data by ltering out geographic information that are not useful in the outdoor touristic domain. Relying on this external knowledge, we perform a rst level of geotagging. When we obtain only one solution, we can already assume that we found the correct geographical location. Unfortunately, we have a lot of toponyms without a location. On this new subset of data, we will use the second gazetteer. With a speci c SPARQL query on DBpedia, we obtain new results without ambiguity. We can see in Figure 3 an example of ambiguity coming from the
rst geotagging step with OSM. We provide two examples to better illustrate the method: 1- Toponym Cockscomb: It does not exist in OSM. We retrieve this information from DBpedia. This is an example of incompleteness that we solve using di erent gazetteers. 2- Toponym Joubertina: Three di erent points are retrieved in OSM. We found it in DBpedia as a village. This is an example of ambiguity. We solve it with the combined use of a correction function and multiple gazetteers.
Gazetteers, OSM and DBpedia, are not enough to geotag the entire set of toponyms. The third gazetteer will allow us to nd the remaining location.
Using the geotagging function, we obtain a set of toponyms with the corresponding location metadata. As a real scenario, we do not want to compute error measures such as precision and recall, but we use a web visual interface (as the one shown in Figure 3) available on the web platform www.gishosting.gter.it, implemented using the QuantumGIS open source software, in order to get a feedback from the end user of the dataset.
We notice that we are able to show the user the possible location of a toponym. In this case, the end user can assess the correctness of geographical coordinates.
We report information related to the percentage of toponyms that we are able to retrieve. We cannot report all the results because this is work in progress and we have to perform the analysis on the whole world, but on the set of toponyms of South Africa, we geotag 50% of the toponyms with OSM and 20% with DBpedia solving some of the arising ambiguities. 4
In this paper we have proposed the joint use of di erent datasets for improving the quality of geotagging and we have applied the proposed approach in a speci c scenario. The motivation of this work is to meet the needs of the data owner.
We introduced a geotagging function kG , taking as input a toponym and a speci c geographic bounding box. The function, iterating over multiple gazetteers, returns the geographical metadata associated with a toponym. Our function does not perform a simple string matching rather it uses a speci c correction function for each gazetteer. The consciousness of the speci c geographical domain allows us to select and to decide how to use the relevant gazetteers.
This approach is still work in progress. Our future e orts will be the implementation of the web crawler to increase completeness and to complete the experimental evaluation.