Automatic matching of two street networks

Question

I'm faced with the problem of matching two street networks. I have these two differently sourced networks. The links in each network can be segmented, i.e. there is not necessarily a single whole link between two intersections, instead the link can be broken into an arbitrary number of segments with different attributes.

I should transfer the attributes from one network to the features of the other network and I figured for doing that I will have to match corresponding streets/street segments.

My current idea is to densify the links in either network and then do an analysis of the cumulative distances between vertices in the two networks?

If the nodes of two segments overall have small distances from each other, the two links probably correspond?

However, I can see problems if two corresponding road segments are expressed in links of wildly different length in the two networks. That notwithstanding, I'm unsure as to how to best go about implementing a method that would analyse the two networks and maybe also offer a way of visually exploring the quality of the matching.

On the plus side I'm familiar (to different degrees) with many platforms (ArcGIS, QGIS, SAGA, R, Python, ...) and can install any promising tool.

Answer 1

A robust method to match networks is described in Mustière, S., Devogele, T., Dec. 2008. Matching networks with different levels of detail. GeoInformatica 12 (4), 435-453.. It has been used at the French national mapping agency to match 2 geographical databases with different levels of detail (see image below). The purpose was to do exactly what you need: Transfer of attributes.

This matching process compares the two network elements taking into account geometrical and also topological criteria: Network elements are not matched only if they are closed to each other (using Hausfdorff distance) and with comparable shapes, but also if they are connected to other network elements that are matched together. One-to-many relations are used.

A good news: This process is implemented in the opensource GéOxygene library. This document describes how to use it. Bad news: You have to speak both Java and French to use it...

Answer 2

I think an ArcGIS Desktop solution to this would need to involve Linear Referencing and, in particular, use of the Overlay Route Events (Linear Referencing) tool.

Answer 3

I've recently worked on a project where we did semi-automatic matching between 2 road networks and the automatic portion was an ArcObjects command line exe (c#). There were a lot of non-GIS business related data on the road network that I was modifying and we had to ensure was not harmed during the conflation process.

We developed a method of scoring based on the geometry and attributes(both the feature & external) and an array of tolerances for the scoring (so that could be different depending on the road classification). Not unlike the scoring in an ArcGIS geocode result. The actual scoring wasn't anything fancy, but it was enough to help us dial in the tolerances. And we executed these in SDE versions, so the results could be visualized against the original set of data. We also added a weighting system to the scoring, but that was not used during the production runs. But based on the scoring, the program would decide whether or not to attempt conflation of the geometry + attributes, which was generally straightforward once a match was determined. In cases, where we ended up with 2 edges above the match score threshold...we didn't conflate.

And since were executing multiple passes, some edges failed in earlier passes would succeed in later ones since they shared an endpoint with a successfully matched edge that was modified(which resulted in moving the node).

All that said, I'll confirm some your initial ideas:

1. Densifying edges did improve our results and it was the first step of our process. As long as the business data was correctly adjusted, we could split edges all day long. And a few unnecessary splits didn't bother anyone or the integrity of the external data.

2. The distance between the endpoints (of 2 edges) was one of our geometric measurements. Length was another. IIRC, the percent of one edge along another was another factor in the scoring. I want to say there was 1 or 2 more--earlier on, we had more than that but they didn't produce any better results so we reduced it down to 4 or 5 measurements. All of these values were averaged to produce a geometry "score".

Answer 4

There a great (open source) tool for conflation between two road network: OpenJUMP (OpenJUMP website) with the roadmatcher plugin (Roadmatcher Plugin) , doing both semi-automatic and manual conflations, but needs installation of (java based) OpenJUMP

A description of the tool (initially created by VividSolution) is available here : VividSolution Roadmatcher