On-the-fly Edge-Matching Service · Open European Location Services (Open ELS) Final Deliverable...

Open European Location Services (Open ELS)

On-the-fly Edge-Matching Service

Deliverable OpenELS-2.5

Authors: Samuli Kytö, Pekka Latvala, Lassi Lehto

Date: Sep 14, 2018

Version: 1.0


Final Deliverable v.1.0 2

Change Summary

Version Date Author/Editor Change Summary

0.1 12/04/2018 Lassi Lehto First proposal for document structure

0.2 25/05/2018 Lassi Lehto Chapters 1 and 2, f irst draft added

0.3 31/05/2018 Pekka Latvala Chapters 3.2, 3.3 and 4, f irst draft added

0.4 01/06/2018 Samuli Kytö Chapters 3.1 and 5, f irst draft added

0.5 05/06/2018 Lassi Lehto Chapters 1 and 2 edited

0.6 08/06/2018 Pekka Latvala Chapters 3 and 5 edited

0.7 15/06/2018 Samuli Kytö Chapters 3 and 5 edited

0.8 18/062018 Lassi Lehto Slight edits throughout the document

0.9 20/06/2018 Lassi Lehto Final touches after comments from the other authors

1.0 14/09/2018 All Final edits

References

Ref. Tit le/Version/Publication Date/Author

[1] ESDIN D11.3 Best Practices and Pilot Implementations for Edge Matching and

Generalisation in Web Services or GIS Environment, 01/2011, Matthew Beare et al

[2] ELF D2.3.3 Edge Matching, 30/01/2015, Marcus Brühl

[3] ELF D2.7 ELF International Boundaries, 08/11/2013, Marcus Brühl

[4] ELF D2.7-1 ELF International Boundaries – Data Specif ication, 08/11/2013, Marcus Brühl

[5] ELF D4.4 Edgematching, 01/2017, Dorus Kruse et al

[6] ELF D4.10 Edge Matching tools and Edge Matching process Implementation Report,

01/2017, Dorus Kruse



Acronyms

CPU Central Processing Unit

ELF European Location Framework

ELF IB ELF International Boundaries

ELS European Location Services

ESDIN European Spatial Data Infrastructure Network

GML Geography Markup Language

INSPIRE Infrastructure for Spatial Information in Europe

LoD Level of Detail

NMCA National Mapping and Cadastral Agency

OGC Open Geospatial Consortium

RAM Random Access Memory

WFS Web Feature Service

WMS Web Map Service



Contents

1 Introduction ..................................................................................................................................................... 5

1.1 General ................................................................................................................................................... 5

1.2 On-the-Fly Edge-Matching ..................................................................................................................... 5

1.3 Previous Work ........................................................................................................................................ 5

2 Service Architecture ........................................................................................................................................ 6

3 Edge-Matching Process ................................................................................................................................... 7

3.1 Data Sets Involved .................................................................................................................................. 7

3.2 Algorithm Description ............................................................................................................................ 8

3.3 Service Interface................................................................................................................................... 11

4 Implementation ............................................................................................................................................. 12

5 Results ........................................................................................................................................................... 13

5.1 Demonstration client ........................................................................................................................... 13

5.2 Test areas ............................................................................................................................................. 13

5.3 Test cases ............................................................................................................................................. 14

5.4 Performance evaluation ....................................................................................................................... 20

5.5 Remaining problems ............................................................................................................................ 20

5.6 Future work towards operational service ............................................................................................ 20



1 Introduction

1.1 General

The work described in this document has been carried out by the Open ELS Activity 2.5 “On-the-fly

Edge-Matching Service”. This work represents continuation of the actions taken in the area of edge-

matching by previous projects, like European Spatial Data Infrastructure Network (ESDIN) and

European Location Framework (ELF). The main result of the Open ELS Activity 2.5 is a software

implementation of on-the-fly edge-matching functionality. It can be seen as an experimental data

processing component to be potentially attached to the ELS service platform in future.

1.2 On-the-Fly Edge-Matching

Traditionally edge-matching is carried out by National Mapping and Cadastral Agencies (NMCAs) of

neighbouring countries as a careful, long-term process, in which consistent delineation of geometries

crossing the border is agreed upon. The iterative and gradual edge-matching procedure leaves a lot of

room for negotiation, readjustment and testing.

On-the-fly edge-matching is a drastically different approach for achieving consistent depiction of

border areas. On-the-fly edge-matching is performed during the data request processing on the service

level. As such, on-the-fly edge-matching is a single-step process not allowing for any checking or

readjustment.

As the edge-matching procedure requires data at least from two different providers, on-the-fly edge-

matching can be seen as an auxiliary processing layer on top of the national geodata download services.

Thus on-the-fly edge-matching is an example of process aimed at improving data consistency on service

level. It can also be taken as an example of a tool for adjusting content for a given purpose – various

different cross-border use cases in the context of ELS. Other similar processes include for instance on-

the-fly generalization and schema transformation.

One may justifiably ask, why on-the-fly edge-matching is needed, as the process can be performed in

advance in a more controlled and reliable environment. In some cases, agreement on common

delineation cannot be reached. This might be caused by strong national interests or a hostile

relationship between countries. It is also common that already edge-matched data sets become

discrepant because of updates made only on one side of the border. In those cases, on-the-fly edge-

matching can help in achieving at least rudimentary continuity across the borderline.

An important prerequisite for a successful on-the-fly edge-matching process is the availability of a

mutually agreed borderline delineation between the participating countries and the existence of so-

called connecting features (points or lines). A connecting feature represents an agreed location on the

borderline, where a pair of matching features from the neighbouring countries connect to each other.

1.3 Previous Work

In the ESDIN project a significant amount of work was devoted for developing the idea of an automated

edge-matching in service environment (ESDIN deliverable D11.3 [1]). The process was designed to be

rule-based and quality-controlled. The concept of connecting features database was also explored in

this work. The edge-matching development in the ESDIN context was not aimed at on-the-fly

processing, but rather as a pre-processing step during the database setup. Edge-matching was

developed as service-oriented solution in the ESDIN project. However, data download services were

not connected the edge-matching service directly, but file-based data transfers were used instead.



The work on edge-matching continued in the ELF project. A specification was developed describing the

process of edge-matching generally and the use of ELF International Boundaries (ELF IB) data set and

connecting features (CF) concept in particular [2]. The ELF IB data set was specified, together with some

guidance on the eventual implementation [3], [4]. During the ELF project the work to build up the ELF

IB data set was commenced. Three automated edge-matching tools were also tested by the project in

selected test areas [5]. Mechanisms were developed for utilising connecting features datasets and a

consistent set of edge-matching rules [6].

In the ELF project, a service cascading solution for integrating national download services was

developed. The service, called ELF Cascading WFS, aggregates ELF download services into a single

access point, through which all the ELF data content can be reached. The data offering available in the

ELF platform include altogether over 120 feature types in 11 different INSPIRE data themes from 13

European countries. The on-the-fly edge-matching solution, developed in the Open ELS project and

described in this document, is attached as a new functional component into the ELF Cascading WFS.

However, the current implementation must be seen as a proof of concept, rather than an operational

service solution.

2 Service Architecture

The task of the ELF Cascading WFS service is to facilitate access to national download services providing

master level datasets. National services are direct access download services that conform to OGC’s

Web Feature Service (WFS) specification. The aggregation layer on top of the national services can be

seen as a Cascading WFS implementation (see Figure 1).

Figure 1. On-the-fly edge-matching as a component of the ELF Cascading WFS service solution

A content request (WFS GetFeature) coming from the client application is first analysed by the

Cascading WFS to determine which national level services must be included into the process. Then the

request is forwarded to the involved national services, the resulting datasets are merged together and



finally returned back to the calling application. The analysis on the service inclusion is based on the

bounding box of the query and on the requested feature types. The bounding box is overlaid on top of

a dataset of national borders to determine which countries the query overlap. The actual service inside

the country is then selected, depending on the requested feature type.

The Open ELS on-the-fly edge-matching functionality is integrated into the ELF Cascading WFS. Once

the requested sub-datasets are returned from all the involved national download services, the

integrated response dataset is handed over to the on-the-fly edge-matching component. The edge-

matching component retrieves appropriate boundary lines and connecting feature points from the

attached ELF IB database and then carries out the edge-matching process. While computing the edge-

matching solution, the process also makes use of the country polygons stored in the attached database.

The resulting edge-matched dataset is returned to the ELF Cascading WFS that finally returns it to the

calling client application. This way the whole edge-matching process is carried out during a

synchronous, WFS-compliant data access request and is thus performed on Geography Markup

Language (GML) encoded response dataset. Using an auxiliary query parameter on the WFS service

interface, it can be indicated, whether the edge-matching process should be performed or not.

The main components of the ELS on-the-fly edge-matching solution are thus 1) ELF Cascading WFS

providing the source datasets, 2) edge-matching component responsible for the actual edge-matching

procedure with the help of some database functions, 3) the ELF IB dataset with agreed international

boundaries and connecting features 4) a database containing the polygonal geometries of the

countries involved. At the moment, only linear geometries are considered in the edge-matching

process. Feature attributes are currently not involved in the matching process.

3 Edge-Matching Process

3.1 Data Sets Involved

The data connected to the ELF Cascading WFS that were chosen to be edge-matched consisted of linear

geometries. The ELF / INSPIRE feature types Watercourse and RoadLink were selected for the edge-

matching. These feature types can be seen as linear and border-crossing entities of the real world.

Edge-matching is currently based on the ELF International Boundaries data set [3] that consists of:

• International Boundaries: agreed upon delineation of country border lines.

• Connecting feature points: locations on the country borders, where edge-matched geographic

entities from neighbouring countries should connect (see Figure 2). Each of these points contain

several attributes, of which the attributes indicating the involved countries and feature type

are used for filtering the right linear features in the edge-matching process.

The ELF IB dataset is available in two versions that correspond to different Levels of Detail (LoD), Master

and Regional. Both versions were utilized in the edge-matching process. Currently, the more detailed

Master level dataset is only available in the border area between Finland and Norway. The less detailed

Regional level dataset is available for most ELF/ELS countries. The Regional level data was used in tests

on the French-Spanish border.



Figure 2. The concept of edge-matching lines to a connecting feature point.

In order to perform point-in-polygon calculations as part of the edge-matching process, country

polygons were created by using the geometries from the ELF International Boundaries. They are used

for determining the countries, where the line end points that are to be matched are located. Country

polygons were created for Finland, Norway, France and Spain.

3.2 Algorithm Description

The on-the-fly edge-matching is performed as a part of the ELF Cascading WFS query process for

datasets that are returned from the background services. The edge-matching is performed simply by

moving the line end points in appropriate cases to the predefined connecting feature points. The

algorithm is restricted for handling linear features and it does not perform edge-matching for any

polygons. The edge-matching process can be adjusted by setting the value for the connecting feature

point search distance from the line end points (Figure 2). The value used in the demonstration client is

25 meters.

As a preliminary step before the execution of edge-matching, the ELF IB country border lines that are

located within the WFS query’s bounding box window, are retrieved from the database.

The edge-matching process is executed for each country’s dataset feature-by-feature. The process

begins with a calculation that determines, if the start and end points of the line are in the area of the

same country where the dataset originates from. This operation makes use of the country polygons

dataset. Based on the result of this analysis, further processing is divided into 4 different cases that are

described in the following.



Figure 3. Edge-matching scenario in Case 1.

Case 1: The line’s start and end points are both inside the country of dataset’s origin (Country A)

• Check for the line’s start and end points, if the line continues from the point in question with

another line that originates from the same country’s dataset.

• If the line continues with another line, the point will not be edge-matched

• Search the connecting feature points from the line’s start and end points that are within the set

search distance

• If connecting feature points are found, match the line’s start and end points to the nearest

connecting feature points by moving the start/end points to those connecting feature

points.

• If both start and end points are to be matched to the same connecting feature point:

• Calculate distances between the line’s start and end points and the connecting feature

point

Match only the point that is closer to the connecting feature point

If the distances are equal, match the start point



Figure 4. Edge-matching scenario in Case 2 (blue line) and Case 3 (red line).

Case 2: The line’s start point is in the country of dataset’s origin (Country A), end point is not

• Find the intersection points between the line and the country border line

• Shorten the last line segment that is in a foreign country to the border line

• Search the connecting feature points that are within the set search distance from the line’s new

end point

• If a connecting feature points are found, match the line’s new end point to the nearest

connecting feature point

• Check for the line’s start point, if the line continues with another line from that point that originates

from the same country’s dataset

• If the line continues with another line, the start point will not be edge-matched

• Search the connecting feature points that are within the set search distance from the line’s start

point

• Match the line’s start point to the nearest found connecting feature point if it will be

matched to a different point than the line’s end point

Case 3: The line’s end point is in the country of dataset’s origin (Country A), start point is not

• The edge-matching process in case 3 is performed by mirroring the process of case 2.



Figure 5. Edge-matching scenario in Case 4.

Case 4: The line’s start point and end point are both in a foreign country (Country B)

• Find the intersection points between the line and the country border line

• If the line string and border line don’t have any intersection points

Remove the line’s geometry from the WFS output

• If intersection points exist

Shorten the first line segment that is in a foreign country to the country border

line

Search connecting feature points from the line’s new start point that are within

the set search distance

• If connecting feature points are found, match the line’s new start point

to the nearest connecting feature point

Shorten the last line segment that is in a foreign country to the border line

Search connecting feature points from the new line end point that are within the

set search distance

• If a connecting feature points are found, match the line’s new end point

to the nearest connecting feature point

3.3 Service Interface

Because the developed Open ELS on-the-fly edge-matching process is contained within the ELF

Cascading WFS, the edge-matching is essentially invoked by sending a WFS data query (GetFeature) to

the service. The WFS GetFeature request is extended by a Boolean valued extension parameter “EM”,

by which the client application can indicate, whether edge-matching should be incorporated to the

query processing or not. In the current demo environment there is a front-end servlet module that

interprets the incoming query and, depending on the value of the “EM” parameter, forwards it either

to the normal ELF Cascading WFS or to the edge-matching enhanced version of it. The edge-matching

process is executed for all GetFeature queries covering cross-border areas.



4 Implementation

The on-the-fly edge-matching algorithm is implemented within the ELF Cascading WFS that is a Java-

based Web Servlet.

The database used in the edge-matching is PostgreSQL with the PostGIS spatial extension. The various

spatial operations that are used in the edge-matching process, such as the point-in-polygon operation,

and distance and intersection calculations, are executed as PostGIS queries.

The edge-matching process uses two databases: the first contains the country polygons that are used

while computing the point-in-polygon operations and the other one contains the master and regional

level international boundaries and connecting feature points. The master level connecting feature

points were not exactly on the border line and they were moved to the border line as pre-processing

step by using the PostGIS’ ST_Snap function.

In order to bring the international borders and connecting feature points as WMS layers to the

demonstration client, separate database tables containing the master and regional level border lines

and the Watercourse and RoadLink connecting feature points was created. The database tables were

then configured to be served as WMS layers with the GeoServer application.

The demonstration client application was created with JavaScript-based OpenLayers library. The

demonstration client contains two synchronized map windows that display the original Cascading WFS

result in the left-hand window and the edge-matched result in the right-hand window. The

demonstration client uses the ELS Basemap as the background map and displays also the ELF IB border

line and connecting feature point layers.

The services used in the on-the-fly edge-matching demonstration were installed to a virtual server that

is hosted in the OpenStack-based cloud computing environment run by the Finnish IT Centre for

Science. The virtual server has 2 Virtual CPU’s, 2 GB of RAM and 80 GB disk space.



5 Results

5.1 Demonstration client

The Open ELS on-the-fly edge-matching demonstration client can be found in address:

http://193.166.25.14/OpenELS-EM-Demo.html

5.2 Test areas

The test cases are located in two test areas. The first test area (Figure 6) contains hydrographic

Watercourse features and it is located on the border area between Finland and Norway. This test area

utilizes the Master level IB dataset.

Figure 6. Locations of test cases 1-5 on the border between Finland and Norway

The second test area (Figure 7) is located on the border area between Spain and France. Test cases 6

and 7 show edge-matching of Watercourse geometries. Test cases 8–10 are RoadLink geometries. Blue

lines denote Spanish data and green lines French data. ELF IB data in Regional LoD is used for this test

area.



Figure 7. Locations of test cases 6–10 on the border between Spain and France

5.3 Test cases

In the following comparison images, the original data is shown on the left side, and the edge-matched

result on the right side. The red dots are the connecting feature points. Black line represents the border

between the two countries. Blue lines represent the feature geometries of the Finnish datasets and

green lines corresponding feature geometries in the Norwegian datasets.

Test case 1

Test case 1 originally has two intertwining Watercourse geometries on the northern side of the border.

This test case seems to be successfully edge-matched by visual inspection. The blue line is cut on the

border, and the result is a continuous Watercourse geometry.



Test case 2

In test case 2 there was a gap between the Watercourse features. As the result of edge-matching

process, lines of both countries are connected to each other, which seems like an appropriate result

based on the satellite images that were used for reference.

Test case 3

Test case 3 is more complex than the previous two cases. The Finnish data (blue lines) is once again cut

on the border. However, in the ELF IB data there are only two connecting feature points available,

although there are three blue lines crossing the border. As result, the leftmost blue line is connected

to the same connecting feature point as another blue line, which is most likely a false solution.

Otherwise the edge-matching process enables connectivity and respects the data content of both

countries on their own territory.



Test case 4

In Test case 4, once again, some of the blue lines are cut, since they shouldn’t extend on the Norwegian

side. Overall the result seems like a good solution, as connectivity is enabled and duplicate features

are erased.

Test case 5

Test case 5 shows some of the challenges in edge-matching. Blue lines are cut off on the border, which

leaves partial features that end on the border. As a result, there are no overlapping depictions of the

same Watercourse feature, but as a downside some features are incomplete. This would not be issue,

if the original data collection rules would be identical in both countries.



Test case 6

In test case 6 there are duplicates of most likely the same Watercourse feature. After edge-matching

the result looks much cleaner and lines are connected on the border, where the connecting feature

point exists.

Test case 7

In this test case some of the challenges of the applied rules of edge-matching are shown. There is only

one connecting feature point, although there should be at least three of them. This leads to a

discontinuous result, as the lines are not matched to anything, but cut if they extend to the territory of

another country.



Test case 8

In test case 8 many duplicate RoadLink geometries are removed. Two lines are matched to the

connecting feature point. The southern branch (roads) is outside the search distance, so it isn’t edge-

matched.

Test case 9

In this test case the two countries seem to have different data collection rules for roads. The edge-

matched result seems like a better representation of the road network, as the roads are now connected

on the border.



Test case 10

In test case 10 there are two parallel roads or bridges that cross the water. There is only one connecting

feature point, to which both roads are edge-matched. Compared with the original situation, this

solution could be taken as an edge-matching failure.



5.4 Performance evaluation

The current on-the-fly edge-matching process is not suitable for handling complete datasets in one

run. The process is recommended to be used only for relatively small areas at a time in order to

maintain reasonable processing times. As such, the WFS query context, where result datasets are

typically limited in size, is an appropriate application environment for on-the-fly edge-matching

processing.

5.5 Remaining problems

At the moment of writing, the datasets of many countries are still missing from the ELF Cascading WFS.

Therefore, it is challenging to find neighbouring countries that have data available from the same

feature type.

The proposed edge-matching methodology is also heavily dependent on the availability of the

connecting feature point data. Usable master level connecting feature points were only available in the

border area between Finland and Norway. Connecting feature data is also not complete and, for

instance, there are many watercourse features in the national datasets that cross the country border

and don’t have any corresponding connecting feature points available. In comparison, there are also

connecting feature points that don’t have any corresponding features nearby. The regional level

connecting feature points are more widely available but, similarly, this dataset is not complete. For

future work, improving the connecting feature point and line datasets is recommended.

Some features are also problematic to be edge-matched with the proposed approach. If a line is

following along the border as a one continuous feature, it might pass very close to the connecting

feature point, but not be matched into it if its end points are too far away from the connecting feature

point. Also, if the line is alternating between the countries along the border, the edge-matched end

result may in some cases contain duplicate feature lines that are coming from both of the countries’

datasets. In general, the countries datasets should reach near to the border line. If they are cut too far

away, the lines might not be matched to the connecting feature points, as the distance between the

lines and the connecting feature points exceeds the set search distance.

Validating the results is at times difficult, as the watercourse can be out of sight in orthoimage

products. Proper validation of EM results would require better reference datasets and possibly

checking in the field.

In the proposed solution, the edge-matching process is performed in a simple fashion, by moving the

line end points to the connecting feature points. This creates the required connectivity between the

features that are coming from different datasets but it is not always a visually satisfying solution. A

smoothing methodology, i.e. conflation or rubber-sheeting, would improve the outlook of the result

geometry.

5.6 Future work towards operational service

Datasets that are currently used in the EM process should be quite extensively improved. Now many

connecting feature points are missing or erroneous in the ELF IB dataset. A more complete connecting

points dataset should be created, preferably collaboratively by all European NMCAs. Also, ELS data sets

should be improved to cover more European countries, as data from two neighboring countries are

needed for making edge-matching possible in the first place. Moreover, country polygons used in the

current EM process should be available from all countries.



For the EM process, the feature matching is currently executed simply by moving the line end points,

that are selected for matching, to the location of the agreed connecting feature point. In some cases,

this approach tends to leave visually unpleasing sharp angles to the features. This could be improved

by using a rubber sheeting method that creates smoother features. For operational use, the

performance of the proposed EM process is currently not at a sufficient level. In future, the

performance of the algorithm should be examined and improved.

For reliable on-the-fly EM process, more complete validation of the results would be required. This

would best be done by the NMCA responsible for the dataset in question, preferably together with the

NMCA of the neighbouring country. Validation could be further facilitated by developing custom

validation tools for guiding the process.

At the moment the demonstrative on-the-fly EM process is running on a relatively modest computing

platform. For operational use, a platform enabling shorter processing times and supporting multiple

concurrent users would be required. A hosting organisation must be found for running and maintaining

the service.

Developing tasks for future improvement of the service include functionalities like supporting edge

matching of polygonal features and taking care of topological constraints in the EM process.

On-the-fly Edge-Matching Service · Open European Location Services (Open ELS) Final Deliverable...

Documents

Transcript of On-the-fly Edge-Matching Service · Open European Location Services (Open ELS) Final Deliverable...