Semantic Integration of Geospatial Data from Earth Observations through Topological Relations

Transcription

1 Semantic Integration of Geospatial Data from Earth Observations through Topological Relations Helbert Arenas, Nathalie Aussenac-Gilles, Catherine Comparot, and Cassia Trojahn Institut de Recherche en Informatique de Toulouse, Toulouse, France Abstract. Earth observation is a rapidly evolving domain. Recently launched satellites, which deliver between 8 and 10TB of image data per day, open emerging opportunities in domains ranging from environmental monitoring to urban planning and climate studies. However, domainoriented applications require raw image metadata to be enriched with data coming from various sources (either static or dynamic), in order to support decision-making processes related to the observed areas. One of challenges to be addressed concerns the integration of heterogeneous data highly relying on spatio-temporal representations. This paper presents a semantic approach to integrate data with the aim of enriching metadata of satellite imagery with various open data sets that are relevant to describe Earth Observations for a particular need. We propose a semantic vocabulary that specializes standards (like SOSA, GeoSPARQL) as well as a process - based on spatial and temporal features - to select, map and integrate heterogeneous geo-spatial data sets. This process relies on image tiles to handle data with a fixed spatial component while the temporal relationships are calculated on the fly based on temporal topology. 1 Introduction Earth Observation (EO) provides added value to a wide variety of areas. Recently, the European Space Agency (ESA) has launched the Sentinel program, with two types of satellites, Sentinel-1 and Sentinel-2 already providing high quality images (estimated between 8 to 10TB of data daily). They provide images of Earth captured with different technologies and available for free. The availability of these data opens up many economic opportunities through new applications in fields as diverse as agriculture, environment, urban planning, oceanography and climatology. These business applications, however, have a strong need to couple these images with data on the observed areas. These data come from various measurement sensors. They are available from different sources with heterogeneous formats and distinct temporal features: they may be either static, like soil data, or dynamic, like weather observations. They can be useful for instance to indicate that an image contains a region affected by a natural phenomenon such as an earthquake or heat wave, and may be used for

2 2 Helbert Arenas, Nathalie Aussenac, Catherine Comparot, Cassia Trojahn deciding what to do in this area or for longer-term analyses. Moreover, by exploiting the spatio-temporal characteristics of a phenomenon (its spatial imprint and its date), it becomes possible to know whether a geo-located entity within the footprint of this image (i.e. a city), has undergone the same phenomenon. In this context, because the images are already described by satellite metadata, one of the challenges is the integration of heterogeneous data from various sources to the image metadata. Previous works have already demonstrated the gain brought by semantic technologies to facilitate this task [21], [23]. In line with recent work on Ontology-based Data Access (OBDA) and Data Integration (OBDI) [16] [15] [8], we present a semantic approach to integrate data with the aim of enriching metadata of satellite imagery with data from various sources that provide EOs for a particular need. OBDA requires to define a semantic vocabulary that will enable an homogeneous data representation and query, and to write mapping rules or algorithms to populate the model with data from the heterogeneous sources. In the particular case of EO data, an important fact is that the data from diverse origin can relate through spatio-temporal topological relationships. Data come from geo-spatial data sets with heterogeneous formats (shapefile, KML, CSV, GeoJSON, TIFF). The data integration process needs to properly manage the spatial and temporal properties and relationships. To avoid duplicating static data that would tag all the images of the same area over time, the notion of tile defined by ESA is very convenient: the Earth surface is associated a grid where a tile represents a fixed area on the Earth surface. In this paper we present a framework where diverse geographical information and metadata of EO images are semantically integrated. First, we propose a straightforward vocabulary that allows the semantic and homogeneous description of geo-spatial data as well as the metadata of satellite images as entities with spatial and temporal properties. A subset of the geo-spatial data to be integrated to the image meta-data is contextual information measured on Earth, so that it can be considered as sensor data. Thus this vocabulary specializes well-known LOD vocabularies, in particular, SOSA 1 and GeoSPARQL [13]. As a second contribution, we defined an integration process that is based on the topology of entities and Linked Data principles. The diversity of data sources raises different heterogeneity issues. For each data set to be integrated, we defined mapping templates and functions. Temporal properties and relations contribute to integrate dynamic data. To handle the spatial component of static and dynamic data the process relies on image tiles. As a side effect, using tiles enables to better scale up by reducing the amount of data to be handled. Last but not least, the integration process produces various triple-stores and JSON files of EOs and measurement data that can be reused for other purposes. For instance, we have generated JSON files and RDF triples 2 that connect the land cover information to the ESA tiles. We illustrate our approach through a case study exploiting Sentinel-2 image metadata and contextual data (weather report data, Earth land cover, agri Data will soon be available on line at

3 Semantic Integration of Geospatial Data through Topological Relations 3 culture reports, etc.). For this study, the semantic representation of the image metadata provided by the CNES (French National Center for Space Studies) are linked to data overlapping the image footprint and with similar capture time, in particular, meteorological data coming from Meteo France, Land Cover and Administrative Units. The rest of this paper is organized as follows. Section 2 discusses the main related work. Section 3 overviews our approach. Section 4 presents the proposed vocabulary and Section 5 details the data selection, alignment and integration processes. Finally, Section 6 concludes the paper and presents future work. 2 Related Work 2.1 Ontology-based Data Integration Ontology-based Data Integration (OBDI) is one of the topics of Ontology-based Data Management (ODBM) which aims at accessing and using data by means of an ontology [16]. The ontology is a means to standardize data access from heterogeneous sources, and to take advantage of the formal semantics for an easier data management, consistency checking or flaws identification [8]. According to this computing paradigm, data access is realized through a three-level architecture, constituted by an ontology O, a set of data sources S, characterized by their schemes, and M the set of mappings between the two. These mappings may be used either to build a knowledge graph from the data, i.e. to design a semantic representation of the data (an ABox) using the classes and properties defined in the ontology; or it may be used on the flow to rewrite ontology-based SPARQL queries into SQL queries to search the data-base and retrieve a small set of data. In both cases, directly rewriting queries avoids rewriting a full data set into RDF to make it accessible in semantic applications; only the required data are represented in RDF. The second approach is a simplification of the first one: it relies on algorithms rather than mappings to rewrite queries. For instance, the REQUIEM algorithm by [19] applies on DL1 description logic models; the SPARQL-generate algorithm matches data files of any format to RDF graphs [15]. Due to the cost of storing and maintaining linked data, many data sets are not made available in the LOD. A solution can be to integrate non-rdf data sets on-demand as Linked Data. ODMTP (for On-Demand Mapping using Triple Patterns) implements a solution using a Triple Pattern Fragments (TPF) server over non-rdf data sets [17]. Some of the more advanced works based on mappings is the MASTRO Studio. Its authors claim that it is the only full-fledged ODBM system which provides, in addition to OBDA functionalities, capacities to document and inspect an OBDA specification. A similar system is QUEST [22], which performs query answering over DL-Lite ontologies, and can work in both classical (i.e. with a local ABox) and virtual mode (i.e. using mappings to query the database).

4 4 Helbert Arenas, Nathalie Aussenac, Catherine Comparot, Cassia Trojahn 2.2 Publishing Linked Data on Earth Observation Collecting and integrating geographical data produced by a variety of disciplines and human activities is at the core of the Digital Earth project [11]. New data driven applications in fields like environment, agriculture [23], risk management [1] or climate watch require data from heterogeneous sources and the ability to integrate data streams. Making geographic data sets available and then interoperable at the semantic level remains an open issue that various projects address by referring to Linked Data principles [6]. Indeed, Linked Data comes with best practices for exposing, sharing, and integrating data via dereferenceable URIs on the Web [12]. Specific guidelines to publish spatial data as Linked Open Data (LOD) are available from the W3C with special attention on the representation of spatial relations and Coordinate Reference Systems (CRS) [24]. Various ontologies and vocabularies are recommended to represent dense geospatial raster data in the LOD. The W3C suggests the RDF Data Cube (QB) ontology [7] in combination with other W3C and OGC standard ontologies including the Semantic Sensor Network ontology (SSN) 3, the Time ontology (Time) 4, the Simple Knowledge Organisation System (SKOS) 5, PROV-O 6 and the recent DataCube extension for spatio-temporal entities, QB4ST 7. EO imagery produces voluminous data sets like gridded coverages derived from Landsat satellite sensors, and even large RDF triple sets. Current triple stores are not suitable for storing such large data sets. A solution is then to keep the data in its original repository and collect the required RDF representations on the flow, thanks to SPARQL queries through an OBDA interface that query observational data sources, coupled with a triple store for observational metadata. 2.3 Interlinking Data on Earth Observation Whereas the first initiatives aimed at publishing data from one single source, recent works showed that LD principles could also make it easier to integrate data from diverse sources in one or several RDF triple-stores [6] [23]. The resulting LD repositories form Virtual Earth Observatories that, thanks to the new links identified between the data and inferred knowledge, provide much richer information sets than EO images and their standard metadata alone [14]. The GeoKnow project share this vision: it leveraged spatial data in the Web of Data, and made available devices to collect, merge and aggregate spatial data as well as a Linked Data stack to publish, reuse and visualize it [9]. Interlinking data on EO means discovering spatial and temporal links among the RDF graph obtained after data publication [5]. Thanks to spatial links, data from observations can be associated to tiles and then to EO images. Thanks to temporal links, temporal observations can be linked to images too. In case

5 Semantic Integration of Geospatial Data through Topological Relations 5 entities of the same nature are collected from various sources, an entity resolution algorithm can identify mappings between similar or identical spatial entities. We are concerned only by temporal and spatial relationships. The OGC introduced the notion of geolinked data to refer to geographically related data. In early works, geometry was not directly stored within the attribute data, but in a separate geo-spatial data-set. This option adds constrains when comparing the geometry of each entity. However current repositories store together an RDF representations of the geometry with the RDF spatial entities. Atemezing [3] identified various types of geometries (point, line or polygone) and various tools to build an RDF representation of the geometry (like Geometry2RDF 8 or TripleGeo 9 ). The process defined by Vilches-Blázquez and colleagues [6] precisely compares data geometries, so that spatial data could be retrieved and interlinked on a high level of granularity. We have adopted a similar modality in our approach, and rely on a precise comparison of the spatial component of each entity to integrate data. Atemezing [3] also proposes and models four vocabularies for representing CRS, topographic entities and their geometries. These ontologies extend existing vocabularies and offer two additional advantages: an explicit use of CRS identified by URIs for geometry, and the ability to describe structured geometries in RDF. The data is published as the French authoritative database GEOFLA. Another difficulty of the integration of spatial data comes from the difference in the data temporal validity. Some data, i.e. the position of weather stations, of cities and most of administrative places, and even land cover, are valid for a very long period, larger than the one of the application, and can be considered as stable or static. In contrast, some data streams are continuously providing new data at regular time spans. For instance, temperature measures are given every 3 hours by Meteo France weather reports, and tens of new EO images and their meta-data are available on the PEPS server every day. The W3C RDF Data cube recommendation [7] suggests linking each image to tiles so that one could make statements on the tiles. Tiles are geo-located square areas determined by a grid decomposition of the Earth surface. Each EO image provided by Sentinel 2 Single Tile (S2ST) has already a tile. More recently, [1] proposes a framework in which satellite images are classified and enriched with additional semantic data in order to enable queries about what can be found at a particular location. This is achieved by a reasoning capabilities relying on domain-specific spatial reasoning rules enabling to answer high level queries. 3 Semantic approach for EO data integration: overview and architecture The architecture of our integration platform is modular. Its different levels allow decoupling stages in the process from raw data to semantic data. Figure 1 depicts the architecture, consisting of different modules:

6 6 Helbert Arenas, Nathalie Aussenac, Catherine Comparot, Cassia Trojahn Data selection : the first step of the data integration process is to identify and access the data sources to be collected. A data set is either a file or the result of a query to retrieve data, from a data store. The formats of files currently considered are CSV, RDF, XML, TIFF, Shape files. The data sources used in this work are described in Section 5.1. Data conversion: Once the data sources have been selected and the data gathered, they are first converted into a JSON pivot representation. To do so, we have reused dedicated scripts or developed customized ones, according to the specific kind of data source. The intermediate JSON files are stored in a MongoBD data base as a security back-up. Data alignment: The data in JSON files is mapped to instances of classes in the ontology presented in Section 4. The mapping process relies on a template and a processing mechanism implemented as a Python module. In Section 5.2, we provide examples of the mapping templates. Thanks to the Python module we can implement customized functions that use the values in JSON documents as input data or parameters. Thanks to these functions we can perform sophisticated operations that are not possible in alternative approaches such as RML. Data integration: The integration process relies on the topological relationships between the instances of the model classes. Topological relationships can be either spatial or temporal. At this point, all the instances in our knowledge base have a static spatial representation. Then it is possible to pre-process the topological relationships and store them as declarative statements in the triple store. It is also possible to evaluate the topological relationships on the fly, however this demands a computing cost that due to the nature of our data (fixed positions) we consider unnecessary 10. The temporal component of the entities in the knowledge base is represented using OWL Time. Then temporal topological relationships can be establisehd on demand at query time using SPARQL. This work has been carried out in the context of the SparkInData project 11, which aims at delivering a platform intended to offer a support to deploy applications in the spatial domain. The SparkInData platform includes a cloud architecture and a docker environment to implement services. 4 Model for integration of earth observation data Our model for data integration relies on two existing vocabularies, the SOSA core ontology and GeoSPARQL ontology. In our previous work [2], image metada records and meteorological observations were represented with DCAT and SSN, 10 In the future, as the model evolves, we might use features with a dynamic spatial representation, for instance a weather sensor located in a car. In this case, the identification of topological relationships would need to be done dynamically. 11 SparkInData project is funded by Investing for the Future French program.

7 Semantic Integration of Geospatial Data through Topological Relations 7 Fig. 1. Architecture of our services. respectively. Here, we propose instead to adopt SOSA as a core ontology that can be shared across these different types of data, as detailed below. SOSA is a light-weight but self-contained core ontology representing elementary classes and properties of SSN (Semantic Sensor Network). SOSA describes sensors and their observations, the involved procedures, the studied features of interest, the samples used to do so, and the observed properties. SOSA is relevant for a wide range of applications, including satellite imagery. We have hence adopted SOSA for describing image metadata and meteorological observations as respectively, Earth observations and meteorological observations (Figure 2). However, we specialized SOSA in order to better type the instances of these concepts, although the trend in domains largely adopting SOSA, such as IoT, is to avoid this kind of construction and to directly use SOSA as main vocabulary [20]. GeoSPARQL, an OGC standard, defines a small ontology for the representation of features, spatial relations and functions [13] [4]. While alternative vocabularies exist, such as GeoRDF which allows for representing simple data like latitude, longitude, and altitude as properties of points (using WGS84 as reference datum) and GeoOWL, which allows for expressing spatial objects (lines, rectangles, polygons), we opted for GeoSPARQL because it offers good reasoning capabilities to compare geometries. To sump up, we represent temporal relationships mainly using the time properties of SOSA (reusing OWL Time vocabulary), and spatial relations thanks to GeoSPARQL. As depicted in Figure 2, a satellite image metadata record has a spatial dimension and a temporal dimension. Both of these dimensions contribute to link observation data to the image metadata. The temporal dimension of an image metadata record identifies the moment when the image has been captured. The external data source, the weather information, also has a temporal dimension. Weather stations record measurements periodically. So we use the class sosa:observation as a way to connect the measured variables to the weather

8 8 Helbert Arenas, Nathalie Aussenac, Catherine Comparot, Cassia Trojahn station while at the same time, providing a temporal dimension for the observations. Then, we can link with a temporal relationships (before, after) an image metadata record and weather measurements or store periods of interest (e.g., one week after the image was created). With respect the spatial dimension, we use GeoSPARQL to create statements that describe the topological relationships (contains, overlaps) between a satellite image footprint and other entities with a spatial nature. GeoSPARQL allows to express such relationships between two resources (two geometries or two features) using topological properties (direct properties) or topological functions (computed properties). In our model, the class eom:footprint specializes both geo:feature and sosa:featureofinterest: a footprint is a closed polygon (a geometry) that represents the geographic area covered by the image. Thanks to this specialization we are able to link the metadata records with any other information with a spatial component and defined as a geo:feature. Fig. 2. The integration model. The SOSA and GeoSPARQL vocabularies are specialized in 4 modules dedicated to each knowledge source and to the grid representation. We represent a weather station as an instance of the class mfo:meteostation which is a subclass of sosa:platform. The sensors operating in a weather station are represented as instances of mfo:meteosensor which is a subclass of sosa:sensor. The specific geographic position of the measurement is represented as an instance of the class mfo:meteofeatureofinterest, a subclass of sosa:feature- OfInterest. The class mfo:meteofeatureofinterest is also a subclass of geo:feature; thus knowing the position of a mfo:meteofeatureofinterest, it is easy to identify features of other nature that overlap the weather observations.

9 Semantic Integration of Geospatial Data through Topological Relations 9 In order to link EOs to administrative units of France (regions, departments and cities) thanks to their geographic location (point or polygon), we have enriched the model with the admin:administrativeunit class as a sub-class of geo:feature. Finally, for Sentinel 2 Single Tile images, tiles correspond to the image Feature of interest. 5 Data selection, conversion and alignment 5.1 Data selection Sources of dynamic data As stated above, within the SparkInData project, we use metadata records of Sentinel images 12. The revisit time for Sentinel-1 is twelve days, while for Sentinel-2 it is five days. The metadata records are obtained from RESTO, a data service managed by CNES (Centre National d Etudes Spatiales) [10] in GeoJSON format. For instance the following URL will return all the metadata records for the collection Sentinel-2 Single Tile for France that have been produced between 23:00 on and 00:00 on : T23:00:00&completionDate= T00:00:00. Using the RESTO API it is possible to specify the parameters to be retrieved i. e. Ispecific metadata in the record, such as cloud cover, interval of time, geographic area of interest, etc. We collect this data once every night. As dynamic contextual data, we use weather information provided by SYNOP Meteo France 13. This organization offers data as monthly compiled CSV zipped files. The observations are taken every three hours for each one of the 62 weather stations in France. A separate file contains a list of the weather stations with their position as points encoded as geographic coordinates. Sources of static data The KML grid file is available from ESA 14. In the case of images from the Sentinel-2 Single tile data set, information about the spatial coverage of the image can be obtained from the metadata in two forms: 1) the image footprint, 2) the identifier of the tile that corresponds to the image. Then, it is possible to link the geometry of the tiles to other data sets. Another source of static data, GLC- SHARE (Global Land Cover SHARE) is produced by FAO, and provides Land Cover information. This data set is available as an image in TIFF format. Each pixel has a spatial resolution of approximately 1 sqkm. The land cover information is thematic. The pixel values in the land cover image are integers that represent the most prevalent land cover for the area that the pixel covers. We have pre-calculated the Land Cover composition for each tile over France. Then, we can connect images to this information, no need to do the operation on the fly. For each tile we have information regarding the percentage of each of the land cover classes (artificial surfaces, cropland, tree covered areas, water bodies, etc.) existing in the area the tile covers. Finally, we collect data about administrative units from the Open platform for French public data 15. The data is originally provided as shapefiles (07/2016) 13 (07/2016) 14 article/sentinel-2-tiling-grid-updated 15

10 10 Helbert Arenas, Nathalie Aussenac, Catherine Comparot, Cassia Trojahn 5.2 Data conversion and alignment As presented above, we use data from various sources (metadata from satellite images, Land Cover, Administrative Units, and weather observations) with diverse original formats. In order to standardize procedures, we transform the data into JSON and proceed to apply a mapping tool to obtain RDF. The mapping mechanism will be explained in the following sections, with examples of the conversion of Administrative Units and Weather Observations. The conversion procedure for the other data sources is similar, although mapping mechanism can be more complex due to the amount of items that need to be mapped. Administrative units A common language for the conversion of data into RDF is RML. One of the major limitations of RML is the lack of ease to implement customized functions for particular pieces of information. Let s illustrate these limitations and consider the following JSON document: {"wkt": "MULTIPOLYGON((( , ))...)", "name": "Poitou-Charentes", "geomtype": 5, "inseeinfo": {"admintype": "region", "insee": "54"}} It describes an administrative unit located in France. The value of wkt attribute of the key is the geometry of an administrative unit encoded as Well known text (WKT), while the key name is a string that gives the name of the unit. The key inseeinfo contains information referring to the identification of this unit according to the Institut National de la Statistique et des Etudes Economiques (INSEE) (the statistical bureau of France). Using the information contained in inseeinfo, we could obtain the URI of this administrative unit as it is represented in the INSEE knowledge base. However, this requires to create a SPARQL query, and send it to the INSEE SPARQL endpoint 16. This task is not easy to implement with available RML processors. To solve this problem, we developed a customized solution for mapping JSON into RDF. The solution consists of a triple template and a processor encoded in Python. For the administrative units we use the module admin of the ontology described in Section 4. The following paragraph is an example of a template designed to process the previously described JSON document into the vocabulary geo: admin: < # this template defines the structure of a administrative unit <dummy> a admin:administrativeunit. <dummy> a geturladministrativeunittype($.inseeinfo.admintype). <dummy> admin:hasinseecode stringtoliteral($.inseeinfo.insee). <dummy> admin:hasname stringtoliteral($.name). # here i define the spatial representation of an administrative unit. <dummy> a geo:feature. <dummy> geo:hasgeometry <dummy_geo>. <dummy_geo> a geo:geometry. 16

11 Semantic Integration of Geospatial Data through Topological Relations 11 <dummy_geo> geo:aswkt valuetowktliteral($.wkt). # here i will link this instance to the corresponding insee administrative unit <dummy> owl:sameas getinseeurl($.inseeinfo). The template consists of triples that contain elements that are replaced by actual values. In some cases, the values contained in the JSON document need further processing. We provide this processing using customized functions, that use as parameters the information extracted from the JSON document. We extract the information from the JSON file, using JSON Path. For instance, in the case of stringtoliteral($.name) the value in the JSON document for the key name is assigned the datatype string literal. In the case of getinseeurl($.inseeinfo) a more sophisticated processing is implemented: the function creates a SPARQL query with the parameter values, sends it to the INSEE SPARQL endpoint, examines the result and returns the URI of the INSEE administrative unit that matches the parameter. The SPARQL query generated by the function getinseeurl() is the following one: PREFIX rdf:< PREFIX igeo:< SELECT?adminUnit WHERE {?adminunit rdf:type igeo:region.?adminunit igeo:codeinsee "54"^^< The resulting RDF is depicted in the following geo: admin: l_admin: < l_admin:region_54 a admin:administrativeunit. l_admin:region_54 a admin:region. l_admin:region_54 owl:sameas < l_admin:region_54 admin:hasinseecode "54"^^xsd:String. l_admin:region_54 admin:hasname "Poitou-Charentes"^^xsd:String. l_admin:region_54 a geo:feature. l_admin:region_54 geo:hasgeometry l_admin:region_54_geo. l_admin:region_54_geo geo:aswkt "MULTIPOLYGON((( , ))...)"^^wkt:Literal. Weather observations The temporal dimension of weather data is of particular importance. The observations contained in the SYNOP dataset have a diverse temporal dimension. For instance, the observations codified as tminsol depict the lowest soil temperature recorded in the previous 12 hours. On the other hand, the code t corresponds to the temperature at the moment of measuring. Using our approach, we can implement functions that are able to handle the diverse temporal nature of this type of data. For instance, the following snippet represents an observation of type tminsol, for the station with id 07747, recorded on the 2017/12/06 03 hrs. { "temporalinfo" : { "timestamp" : , "month" : "12", "day" : "06",

12 12 Helbert Arenas, Nathalie Aussenac, Catherine Comparot, Cassia Trojahn "hour" : "03", "year" : "2017" }, "tminsol" : , "numer_sta" : "07747" } To process observations from Meteo France SYNOP, our processing script implements the function getmfo PhenomenonTime(doc), in which the parameter is the JSON document. In the template this is represented as: <dummy> sosa:phenomenontime getmfo_phenomenontime(doc). The function scans the JSON document, and retrieves the type of observation by identifying the key (tminsol). Using this information, the function knows that it needs to create an instance of the class time:interval. Then, it proceeds to examine the element temporalinfo, and computes the beginning of the interval (The end of the interval is the value contained in temporalinfo). Both, beginning and end of the interval are encoded as instances of time:instant. The result of the function is: gmfo:obs_07747_ _tminsol sosa:phenomenontime gmfo:timeinterval_ _ gmfo:timeinterval_ _ a time:temporalentity. gmfo:timeinterval_ _ time:hasbeginning gmfo:timeinterval_ _ _beginning. gmfo:timeinterval_ _ _beginning time:inxsddatetime " T15:00: "^^xsd:dateTime. gmfo:timeinterval_ _ time:hasend gmfo:timeinterval_ _ _end. gmfo:timeinterval_ _ _end time:inxsddatetime " T03:00: "^^xsd:dateTime. Satellite image metadata The metadata files are obtained in GeoJSON format. The OWL vocabulary we use to represent this information is eom (Section 4). The process to transform metadata records from GeoJSON to RDF is similar to the one previously described for Administrative Units and Weather observations. The only difference is the template, that has to be designed taking into consideration the data source and the target vocabulary. Image tiles Sentinel images, have different characteristics depending on the sensor that create them. In September 2016, ESA started to distribute Sentinel 2 images as single tile (S2ST) packages. A S2ST represents a fragment of the original image with a fixed size (aprox. 100 x 100km). The advantage over a regular S2 image, is that the user can better select its area of interest and download only the information that he/she requires. A S2ST has a smaller file size than a regular S2 image. One S2ST image can be around 500Mb, while a Sentinel 2 image before tiling can be more than 3Gb. The size and shape of the Sentinel 2 single tile images is based on a regular grid provided by ESA as a KML file. In our work we transformed the grid file to JSON and then proceed to process it into RDF using the procedure previously described. The vocabulary we use to represent the grid is grid. It is described in Section 4. We can calculate topological relationships of spatial elements with the tiles, then we can

13 Semantic Integration of Geospatial Data through Topological Relations 13 extrapolate these information to the images. For instance, by knowing that images [img1, img2, img3] share the tile tile 1, and that the tile 1 overlaps adminunit i, we can infer that [img1, img2, img3] also overlap adminunit i. Land cover In our research we use Land Cover as a contextual data set. In order to integrate this data source, we use a service implemented as a Django module in Python. The service has a REST interface, it accepts as a parameter a WKT polygon in SRS EPSG:4326. The service crops the original data set into a temporal file using the polygon. Then it creates a frequency table. The response of the server is JSON document containing the percentage of the area for each land cover class. In our work, we use this JSON document as the input for our JSON to RDF transformation procedure. 5.3 Data integration Integration of data with fixed spatial component Spatial relations that are relatively stable e.g. topological relations between grids (SS2) and administrative units (image Y overlaps region R), or land cover information for each cell of the grid are computed and stored in the triple store (Figure 3 ). In our approach, we use a python script to calculate the topological relationships between instances of classes. The python script uses the library shapely to make the topological comparisons. Then we register them in a triple store using declarative statements involving GeoSPARQL topological properties Fig. 3. The spatial integration of geolocalized features. Links correspond to spatial topological properties of GeoSPARQL used to linked instances of the classes. Integration of data with temporal dimension It is possible to establish temporal relationships between an image metadata record and weather measurements or to establish periods of interest. A user can define a relevant period of time and link an image metadata record to the available weather information (e.g., weather information captured one week after the image was created). The user defined period works as a temporal buffer that provides context to the image metadata record. 6 Conclusion The integration of EO data from heterogeneous sources with satellite image metadata can be gain a lot thanks to semantic web technologies and OBDM. Publishing some data

14 14 Helbert Arenas, Nathalie Aussenac, Catherine Comparot, Cassia Trojahn sets and image metadata as LOD opens new opportunities to use satellite images in a larger variety of applications by providing an easier access to linked Earth observations. Moreover, for large and dynamic data sets, using SPARQL queries to jointly search observational databases and LD enables to create RDF triples on the flow and avoids to convert huge data sets into RDF triples. In this paper, we have proposed a spatial data integration framework. Several of our contributions improve this process: we designed a vocabulary to represent EO data and image metadata; we proposed an RDF conversion process using resource specific templates and a Python library that overcomes some of the RML limitations; we also proposed an integration process that exploits the data geometry and GeoSparql to link spatial data, and finally SPARQL queries to get dynamic data linked to images according to spatial and temporal features. As future work, we plan to consider domain-oriented sources of data for a particular use case (agriculture and data sources as agricultural reports) and provide rules and reasoning capabilities that help the specific domain analysis. References 1. M. Alirezaie, A. Kiselev, M. Lngkvist, F. Klgl, and A. Loutfi. An ontology-based reasoning framework for querying satellite images for disaster monitoring. Sensors, 17(11), H. Arenas, N. Aussenac-Gilles, C. Comparot, and C. Trojahn. Semantic integration of geospatial data from earth observations. In Knowledge Engineering and Knowledge Management - EKAW 2016 Satellite Events, pages , G. A. Atemezing. Publishing and consuming geo-spatial and government data on the semantic web. PhD thesis, Thesis, R. Battle and D. Kolas. Enabling the Geospatial Semantic Web with Parliament and GeoSPARQL. Semantic Web, 3(October 2012): , L. M. V. Blázquez, V. Saquicela, and Ó. Corcho. Interlinking geospatial information in the web of data. In Bridging the Geographic Information Sciences - International AGILE 2012 Conference, Avignon, France, April, 24-27, 2012, pages , L. M. V. Blázquez, B. Villazón-Terrazas, Ó. Corcho, and A. Gómez-Pérez. Integrating geographical information in the linked digital earth. International Journal of Digital Earth, 7(7): , D. Brizhinev, S. Toyer, K. Taylor, and Z. Zhang. Publishing and using earth observation data with the rdf data cube and the discrete global grid system. Technical report, W3C and OGC, M. Console and M. Lenzerini. Reducing global consistency to local consistency in ontology-based data access - extended abstract. In M. Bienvenu, M. Ortiz, R. Rosati, and M. Simkus, editors, Informal Proceedings of the 27th International Workshop on Description Logics, Vienna, Austria, July 17-20, 2014., volume 1193 of CEUR Workshop Proceedings, pages CEUR-WS.org, A. García-Rojas, S. Athanasiou, J. Lehmann, and D. Hladky. Geoknow: Leveraging geospatial data in the web of data. In Open Data on the Web, J. Gasperi. Semantic Search Within Earth Observation Products Database Based on Automatic Tagging of Image Content. In Proceedings of the Conference on Big Data from Space, pages 4 6, A. Gore. The digital earth. Australian Surveyor, 43(2):89 91, T. Heath and C. Bizer. Linked Data: Evolving the Web into a Global Data Space ; Lectures on the Semantic Web: Theory and Technology. Morgan & Claypool, 2011.

15 Semantic Integration of Geospatial Data through Topological Relations D. Kolas, M. Perry, and J. Herring. Getting started with GeoSPARQL. Technical report, OGC, M. Koubarakis, M. Karpathiotakis, K. Kyzirakos, C. Nikolaou, S. Vassos, G. Garbis, M. Sioutis, K. Bereta, S. Manegold, M. Kersten, M. Ivanova, H. Pirk, Y. Zhang, C. Kontoes, I. Papoutsis, T. Herekakis, D. Mihail, M. Datcu, G. Schwarz, O. Dumitru, D. Molina, K. Molch, U. Giammatteo, M. Sagona, S. Perelli, E. Klien, T. Reitz, and R. Gregor. Building virtual earth observatories using ontologies and linked geospatial data. In M. Krötzsch and U. Straccia, editors, Web Reasoning and Rule Systems: 6th Int. Conf. RR 2012, Vienna, Austria, Sept , Proceedings, pages , Berlin, Heidelberg, Springer. 15. M. Lefrançois, A. Zimmermann, and N. Bakerally. A SPARQL extension for generating RDF from heterogeneous formats. In Proc. Extended Semantic Web Conference (ESWC 17), Portoroz, Slovenia, May M. Lenzerini. Ontology-based data management. In Proceedings of the 20th ACM International Conference on Information and Knowledge Management, CIKM 11, pages 5 6, New York, NY, USA, ACM. 17. B. Moreau, P. Serrano-Alvarado, E. Desmontils, and D. Thoumas. Querying nonrdf datasets using triple patterns. In Nikitina et al. [18]. 18. N. Nikitina, D. Song, A. Fokoue, and P. Haase, editors. Proc. of the ISWC 2017 Posters & Demonstrations and Industry Tracks co-located with (ISWC 2017), Vienna, Austria, Oct.23rd-25th, 2017, volume 1963 of CEUR Workshop Proceedings. CEUR-WS.org, H. Pérez-Urbina, B. Motik, and I. Horrocks. A comparison of query rewriting techniques for dl-lite. In B. C. Grau, I. Horrocks, B. Motik, and U. Sattler, editors, Proceedings of the 22nd International Workshop on Description Logics (DL 2009), Oxford, UK, July 27-30, 2009, volume 477 of CEUR Workshop Proceedings. CEUR- WS.org, A. Pomp, A. Paulus, S. Jeschke, and T. Meisen. Eskape: Platform for enabling semantics in the continuously evolving internet of things. In 2017 IEEE 11th International Conference on Semantic Computing (ICSC), pages , F. Reitsma and J. Albrecht. Modeling with the semantic web in the geosciences. IEEE Intelligent Systems, 20(2):86 88, M. Rodrguez-muro and D. Calvanese. High performance query answering over dl-lite ontologies. In Proceedings of KR 12, pages , D. Sukhobok, H. Sánchez, J. Estrada, and D. Roman. Linked data for common agriculture policy: Enabling semantic querying over sentinel-2 and lidar data. In Nikitina et al. [18]. 24. J. Tandy, L. van den Brink, and P. Barnaghi. Spatial data on the web best practices, w3c working group note. Technical report, W3C and OGC, 2017.