Historical maps provide a rich source of data for social science researchers since they contain detailed documentation of a wide variety of factors, such as land-use changes, development of transportation networks, changes in waterways, destruction of wetlands, etc. However, these maps are typically available only as scanned documents and it is labor intensive for a scientist to extract the needed data for a study. In this paper, we address the problem of how to convert vector data extracted from multiple historical maps into Linked Data. We describe the methods for e ciently nding the links across maps, converting the data into RDF, and querying the resulting knowledge graphs. We present preliminary results that demonstrate that our approach can be used to e ciently determine changes in the Los Angeles railroad network from data extracted from multiple maps.
Historical map archives contain valuable geographic information on both
natural and man-made features across time and space, but the information is only
available as scanned images. There exist many studies in developing technologies
for extracting information from scanned historical maps to then integrate the
extracted information with other datasets in Geographic Information Systems
(GIS) [
However, there are still major challenges with integrating datasets extracted
from scanned maps and using them for analytical tasks. First, existing work on
integrating vector datasets such as con ation [
To enable change analysis over time periods and across spatial scales, we present an approach to integrating map data using Linked Data as the representation. This approach is not only helpful in making the data widely available to researchers, but also in enabling the ability to answer complex queries from social sciences researchers, such as investigating the interrelationships between human and environmental systems. The approach also bene ts from the open and connective nature of Linked Data. Compared to existing tools such as PostGIS4 that can only handle queries related to geospatial relationships within local databases, Linked Data can utilize other widely available knowledge sources (e.g. GeoNames) in the Semantic Web and enable rich semantic queries.
In this paper, we present a general pipeline for constructing the semantic representation of extracted map data, which is demonstrated using railroad geographic features. The pipeline consists of three major steps (Figure 2). The preprocessing step includes 1) automatic line segmentation, using PostGIS to process railroad features, and 2) data preparation to generate necessary metadata for semantic modeling. Then, we use Karma5 to map the geographic features to an ontology and publish the mapped data in RDF. Finally, we run SPARQL queries against Apache Jena, which stores the geospatial Linked Data. 4 https://postgis.net/ 5 http://karma.isi.edu/
Fig. 2. General pipeline for processing the extracted map feature data
Given a set of railroad map vector data extracted from separate map editions covering the same region, the goal is to match the line segments that represent the same line segments across multiple maps published at di erent points in time. Such relationships are key to support the queries for nding changes in the feature of interest through time.
The rst challenge that we need to address is vector-to-vector matching. Consider an example consisting of vector features from two maps (Figure 3), where map A represents an older map edition and map B is the latest map edition with a part of the railroad that has been changed. In order to link only the parts that are common across the two maps, we split each of these vector features into several features, as shown in the gure.
In order to e ciently identify the portions of the railroads that are common across two maps, we use PostGIS, which is a powerful PostgresSQL extension for spatial data storage and query. PostGIS o ers various functions to manipulate and transform geographic objects in databases. As shown in Figure 3, rst we create bu ers for the vector data in Map A and B for a particular bu er size using the PostGIS function ST Buffer. Second, we extract the bu er intersection with the function ST Intersection. Third, we use this bu er intersection to run ST Intersection again with each of the original vector features from map A and map B to determine where to split the line segments in each of the original maps. The process records both the new segmentation and the \sameAs" relationships among the split line segments if their bu ers intersect.
The segmentation process can also handle vector datasets from more than two map sources. With multiple vector datasets as the input, the segmentation process rst processes two datasets and then integrates more datasets one at a time. During the integration step, the segmentation process stores the \contains" hierarchical relationship (Figure 4) for tracking the segmentation result for each additional dataset and uses the hierarchical relationship to handle the \sameAs" relationships for multiple sources.
The data structure and steps for handling multiple datasets are as follows. In the hierarchical relationship, each node in the tree stands for a line segment from one or more vector data sources. The nodes with two parents are the common line segments shared by two maps. When a third map source, C, comes in, the segmentation process repeats the ST Buffer and ST Intersection procedures using the line segments of C and all of the leaf nodes at the second level of the tree, generates new segmented line segments shown as the new leaf nodes, and records the newly identi ed \sameAs" and \contains" relationships (Figure 5). 2.2
Once we identify the \sameAs" relationships, we need to convert the data into Linked Data. To do so, we need to perform several additional data preparation steps.
tation There are several popular meth- Fig. 5. Incrementally integrate vector datasets from multiple ods for representing map sources geometries, such as GML (Geography Markup Language), WKT (Well-Known Text), and WKB (Well-Known Binary). We need to describe the geometries in a compact and human-readable way; therefore WKT format is chosen for further preprocessing. URI The rst thing we need for representing the integrated vector data as Linked Data is the unique IDs for individual line segments. We could use the geometry representation of a line segment as its unique ID because two geographic line segments typically are not exactly same. However, a line segment in the WKT format is a long string, containing commas and spaces which are invalid for a URI. To overcome this problem, we apply a hash function on the line segment in WKT to obtain a relatively short string to describe the URI. Considering hash collision, especially two line segments from di erent maps may be similar, we add additional metadata of individual line segments (i.e., the source map) to the corresponding hash results. Relationship between line segments Since line segments are represented by URIs, which are persistent, we can add relationships between two line segments using their corresponding URIs. The relationships between line segments include \sameAs" to link segments across maps and \contains" to describe how a segment is broken down into subsegments. If an existing line segment has to be split into smaller segments to link with a new map source, the split segments will have their own URIs and will be linked to the original line segment with the \contains" relationship.
Metadata Most line segments from a map share the same metadata, so we only store the metadata for map entities and link the line segments to their source map instead of storing the metadata for each line segments. 3
To represent geographic line segments in RDF, we use the semi-automatic tool
Karma [
Entity The map metadata are represented by schema:MapType, and the geographic vector data are described by schema:Map.
Relationship If two line segments from multiple maps are identi ed as the same entity, their relation is schema:sameAs. If a line segment is derived from a historical version of a segment (i.e., existing segment from a previous source), their relation is schema:contains.
We want to avoid updating all of the existing geographic vector data. Adopting this method, we store historical version of knowledge graph rst, and when a new map comes in, we just need to handle it incrementally, i.e. just import new vector data and their connections resulting from the steps described in Section 2. 4
With the knowledge graph generated using Karma, we can set up queries to solve some interesting, realworld problems. Figure 6 provides an example query for nding the changed segments of railroads in two map editions (circa 2000 and 2005).
Line segments from more than one source are also stored in the knowl- Fig. 6. Query to nd the changes in railedge graph to track the provenance. roads between maps In the query result, we only return the latest version of the line segments that meets the query criteria, i.e., the leaf nodes, because they are the smallest line components after the split.
PREFIX schema: <http://schema.org/> select distinct ?a ?mapa where {?a schema:geo ?geo.
?a schema:mapType ?mapa. ?mapa schema:releaseDate "2000". filter not exists{ ?a schema:sameAs ?b. ?b schema:mapType ?mapb.
?mapb schema:releaseDate "2005".} minus{?a schema:contains ?x}} To test our approach on real datasets, we used the railroad data from three sources: 1) USGS vector data for Los Angeles, California6 (822 features), 2) California Rail Network7 (149 features), and 3) National Atlas of the United States8 (45 features). All the data was input in ESRI shape le format and we cropped them for the area of Los Angeles (Figure 7).
Line segmentation in PostGIS We transformed all data to the same Coordinate Reference System (CRS), EPSG:4269,9 bu ered map (a) and map (b) with 0.0005 in degrees, segmented the vector data, and generated the \sameAs" and \contains" relationships. When we added map (c), we bu ered line segments from maps (a) and (b) as well as line segments from map (c) with 0.0015 in degrees. This larger bu er for handling map (c) is because map (c) has a smaller map scale compared to maps (a) and (b) due to increasing levels of generalization in feature representation, hence the positional o sets is potentially larger (than between maps (a) and (b)). Then we repeated the intersecting step until all relationships of \sameAs" and \contains" among three maps were identi ed. It took 36 seconds altogether to run all queries computing bu ers and intersections for processing the three maps.
Data preparation The identi ed relationships and segmented vector data were stored in PostgresSQL. In this step, we exported the tables from PostgresSQL to CSV les. We used the WKT format to represent geometries and added URI and other metadata including map year and source so that we could perform semantic queries to nd changes of the vector data by years in the next step. Here we recorded map (a) with the year 2000 and map (c) with the year 2005. Create vector Linked Data CSV les were loaded into Karma to map the data to ontologies and produce output in RDF format.
Querying RDF les were then stored in Apache Jena, where we could query to nd the di erence between maps using SPARQL. Using the query in Section 4 we produced the result shown in Figure 8 in 63ms. The visualization was created with the resulting WKT using QGIS. 6 https://viewer.nationalmap.gov/basic/ 7 http://www.dot.ca.gov/hq/tsip/gis/datalibrary/Metadata/Rail_13.html 8 https://nationalmap.gov/small_scale/ 9 https://epsg.io/4269
The mainstream work on geospatial data
integration focuses on vector data con ation,
which is a reconciliation process of two maps
in the same area to achieve a better positional
accuracy for one of the datasets (e.g., [
Ruiz et al. [
Using Linked Data to integrate geospatial information is a growing topic,
which enables the data integration process to take advantage of the open and
distributed Linked Data sources with great opportunities and challenges at the
same time [
In addition, current work on geospatial change analysis (e.g. glacier change
[
We presented an end-to-end approach to integrating geographic data from multiple sources and publishing the integrated data as Linked Data. We demonstrated the approach with railroad vector data extracted from three maps and showed queries for identifying changes in the vector data over time. This approach would also work for other types of linear features, and the case study uses railroads to explain the idea. The resulting tools and datasets will be bene cial for geography and social science researchers for conducting change analyses related to transportation infrastructure, land use, and land cover.
In future work, we plan to explore the use of GeoSPARQL for querying geographic RDF data and creating links to other existing sources to answer other types of research questions. For example, the addition of demographic data as Linked Data would allow us to examine relationships between changes in population distributions and changes in transportation infrastructure.
This material is based on research sponsored in part by the National Science Foundation under Grant Nos. IIS 1563933 (to the University of Colorado at Boulder) and IIS 1564164 (to the University of Southern California).