<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Archiving and Interchange DTD v1.0 20120330//EN" "JATS-archivearticle1.dtd">
<article xmlns:xlink="http://www.w3.org/1999/xlink">
  <front>
    <journal-meta>
      <journal-title-group>
        <journal-title>Workshop on STDBM
Seoul, Korea, September</journal-title>
      </journal-title-group>
    </journal-meta>
    <article-meta>
      <title-group>
        <article-title>Automatically and Efficiently Matching Road Networks with Spatial Attributes in Unknown Geometry Systems</article-title>
      </title-group>
      <contrib-group>
        <contrib contrib-type="author">
          <string-name>Ching-Chien Chen</string-name>
          <email>jchen@geosemble.com</email>
          <xref ref-type="aff" rid="aff0">0</xref>
          <xref ref-type="aff" rid="aff1">1</xref>
          <xref ref-type="aff" rid="aff2">2</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Cyrus Shahabi</string-name>
          <xref ref-type="aff" rid="aff0">0</xref>
          <xref ref-type="aff" rid="aff1">1</xref>
          <xref ref-type="aff" rid="aff2">2</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Craig A. Knoblock</string-name>
          <email>knoblock@usc.edu</email>
          <xref ref-type="aff" rid="aff0">0</xref>
          <xref ref-type="aff" rid="aff1">1</xref>
          <xref ref-type="aff" rid="aff2">2</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Mohammad Kolahdouzan</string-name>
          <email>mohammad_ysm@yahoo.com</email>
          <xref ref-type="aff" rid="aff0">0</xref>
          <xref ref-type="aff" rid="aff1">1</xref>
          <xref ref-type="aff" rid="aff2">2</xref>
        </contrib>
        <aff id="aff0">
          <label>0</label>
          <institution>Geosemble Technologies 2041 Rosecrans Ave</institution>
          ,
          <addr-line>Suite 245 El Segundo, CA 90245</addr-line>
          ,
          <country country="US">USA</country>
        </aff>
        <aff id="aff1">
          <label>1</label>
          <institution>University of Southern California Department of Computer Science Los Angeles</institution>
          ,
          <addr-line>CA 90089 shahabi</addr-line>
          ,
          <country country="US">USA</country>
        </aff>
        <aff id="aff2">
          <label>2</label>
          <institution>Yahoo! Search Marketing Burbank</institution>
          ,
          <addr-line>CA</addr-line>
          ,
          <country country="US">USA</country>
        </aff>
      </contrib-group>
      <pub-date>
        <year>2006</year>
      </pub-date>
      <volume>11</volume>
      <issue>2006</issue>
      <abstract>
        <p />
      </abstract>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>-</title>
      <p>Vast amount of geospatial datasets are now
available through numerous public and private
organizations. These datasets usually cover
different areas, have different accuracy and level
of details, and are usually provided in the vector
data format, where the latitude and longitude of
each object is clearly specified. However, there
are scenarios in which the spatial attributes of the
objects are intentionally transformed to a
different, and usually unknown, (alien) system.
Moreover, it is possible that the datasets were
generated from a legacy system or are
represented in a native coordinate system. An
example of this scenario is when a very accurate
vector data representing the road network of a
portion of a country is obtained with unknown
coordinate. In this paper, we propose a solution
that can efficiently and accurately find the area
that is covered by this vector data simply by
matching it with the (possibly inaccurate and
abstract) data with known geocoordinates. In
particular, we focus on vector datasets that
represent road networks and our approach
identifies the exact location of the vector dataset
of alien system by comparing the distribution of
the detected road intersection points between two
datasets. Our experiment results show that our
technique can match road vector datasets that are
* This work was done when the author was working at University of
Southern California as a Post-Doc Research Associate.
composed of thousands of arcs in a relatively
short time with 91% precision and 92.5% recall
for the matched road feature points.</p>
    </sec>
    <sec id="sec-2">
      <title>1. Introduction</title>
      <p>
        With the rapid improvement of geospatial data collection
techniques, the growth of Internet and the implementation
of Open GIS, a large amount of geospatial data are now
readily available on the web. The examples of
wellknown vector datasets are US Census TIGER/Line files1
(covering most roads over the United States),
NAVSTREETS from NAVTEQ,2 VPF data from NGA
(U.S. National Geospatial-Intelligence Agency), 3 and
DLG data from USGS (U.S. Geological Survey). 4 The
Yahoo Map Service, 5 Google Map Service, 6 Microsoft
TerraService7 [
        <xref ref-type="bibr" rid="ref1">1</xref>
        ] are good examples of map or satellite
imagery repositories. These datasets usually cover
different areas, have different accuracy and level of
details, and some of them are provided in the vector data
format, where the latitude and longitude of each vector
object is clearly specified. However, there are scenarios in
which the spatial attributes of the vector objects are
intentionally transformed to a different, and usually
unknown, (alien) system. Moreover, it is also possible that
the datasets were generated from a legacy system or are
represented in a native coordinate system.
      </p>
      <p>Figure 1 illustrates a scenario where we want to locate
the area of a USGS raster topographic map (as shown in
1 http://www.census.gov/geo/www/tiger/
2 http://www.navteq.com/
3 http://www.nga.mil/</p>
      <sec id="sec-2-1">
        <title>4 http://tahoe.usgs.gov/DLG.html</title>
      </sec>
      <sec id="sec-2-2">
        <title>5 http://maps.yahoo.com/</title>
      </sec>
      <sec id="sec-2-3">
        <title>6 http://maps.google.com</title>
      </sec>
      <sec id="sec-2-4">
        <title>7 http://terraserver-usa.com/</title>
        <p>(a) A USGS topographic map (b) The extracted road network in (c) The U.S. Census TIGER/Lines road
a native coordinate system network</p>
        <p>
          Figure 1: Two road networks cover overlapping areas
Figure 1(a)). The map covers partial area of St. Louis distribution of detected feature points from each road
County, MO in U.S.A., but its exact geocoordinates are network forms a particular (and probably unique) point
inaccessible. The map is first processed to extract road pattern for the road network. In order to improve the
network (as shown in Figure 1(b)) by using a running time, our approach exploits auxiliary spatial
text/graphics separation technique developed by us [
          <xref ref-type="bibr" rid="ref2">2</xref>
          ] . information to reduce the search space for the
Obviously, the extracted road network is in a native transformation T. Once the matched points across
coordinate system (i.e., raster pixel x/y in Cartesian different road networks are identified, the system can then
system). Meanwhile, a larger road network covering this utilize this transformation to map the road network of
county is publicly available from US Census alien geometry (coordinate) system into a known
TIGER/Lines. By identifying matched features between coordinate system (e.g., geodetic coordinate system).
the two road networks, the system can then automatically To illustrate the usefulness of our approach, consider
infer the geocoordinate of the extracted map road network the matching of two road networks: one is in an unknown
(as the area highlighted in Figure 1(c)). coordinate system but with more accurate geometry and
        </p>
        <p>
          There have been a number of efforts to automatically the other has rich attributes and a known coordinate
or semi-automatically detect matched features across system but with poor geometry. Applying our matching
different road vector datasets [
          <xref ref-type="bibr" rid="ref3 ref4 ref5 ref6 ref7">3, 4, 5, 6, 7</xref>
          ]. Given a algorithm to these two road networks can result in a
feature point from one dataset, these approaches utilize superior road network that combines the accuracy of the
different matching strategies to discover the road geometry from one vector dataset and rich attributes
corresponding point within a predetermined distance (i.e., from the other. Furthermore, these matched points can be
a localized area). This implies that these existing used as control points to conflate these two road network
algorithms only handle the matching of vector datasets in datasets [
          <xref ref-type="bibr" rid="ref6">6</xref>
          ].
the same geometry system (i.e., the same coordinate The remainder of this paper is organized as follows.
system8). Hence, to the best of our knowledge, no general Section 2 describes our approach in details. Section 3
method exits to resolve the matching of two vector data in provides experimental results. Section 4 discusses the
unknown geometry systems. Furthermore, processing related work and Section 5 concludes the paper by
large vector datasets often requires significant CPU time. discussing our future plans.
        </p>
        <p>Our methodology, described in this paper, is able to
automatically and efficiently handle the matching of 2. Proposed Approach
diverse and potentially large vector datasets, independent
of the coordinate system used. In particular, we focus on In this section, we first describe our overall approach to
vector datasets that represent road networks. match two road networks. Then, we describe the details of</p>
        <p>The basic idea of our approach is to find the our techniques.
transformation T between the layout (with relative
distances) of the feature point set on one road network 2.1 Approach Overview
and the corresponding feature point set on the other road
network. This transformation achieves global matching
between two feature point sets by locating the common
point pattern among them. More precisely, the system can
detect feature points from both road networks. The
Intuitively, matching road networks relies on the process
of matching the road segments from two vector datasets to
find the corresponding road segments. However, this is a
challenging task for two large road networks, especially
when one of the road networks is in a different or
unknown geometry system. To address this issue, we
propose to match two datasets based on some feature
points detected from the road networks. In particular, we
8 In this paper, we use the terms “geometry system” and
“coordinate system” interchangeably.</p>
        <p>A road network with
lat/long known coordinate system</p>
        <p>Detected intersections</p>
        <p>A road network with
unknown coordinate system
?
?
lat/long</p>
        <p>Point Pattern</p>
        <p>
          Matching (PPM)
Detected intersections
utilize road intersections as the feature points. Road
intersections are good candidates for being matched,
because road intersections are salient points to capture the
major features of the road network and the road shapes
around intersections are often well-defined. In addition,
various GIS and computer vision researchers have shown
that the intersection points on the road networks are good
candidates to be identified as an accurate set of matched
points [
          <xref ref-type="bibr" rid="ref10 ref7 ref8 ref9">7, 8, 9, 10</xref>
          ].
        </p>
        <p>After detecting a set of intersection points from each
road network separately, the remaining problem is how to
match these intersection points effectively and efficiently
to locate a common distribution (or pattern) from these
intersections. Our system perceives the distribution of
detected intersections from each road network as the
fingerprint of the road network. Then our system finds the
transformation T between the layout (with relative
distances) of the feature point set on one road network
data and the feature point set on the other road network.</p>
        <p>This transformation achieves global alignment between
two intersection point sets by locating the common point
pattern among them.</p>
        <p>Figure 2 shows our overall approach. Using detected
road intersections as input, the system locates the
common point pattern across these two point sets by
computing a proper transformation between them. The
system can then utilize this transformation to map the
road network in unknown geometry system into a known
coordinate system. We describe our detailed techniques in
the following sections.</p>
        <sec id="sec-2-4-1">
          <title>2.2 Finding the feature points from vector datasets</title>
          <p>The technique to detect road intersections from road
network relies on the underlying road vector data
representation. Typically, there are two common ways to
represent the geometry of a road vector dataset: (1). The
road network is composed of multiple road segments
(polylines), and the line segments are split at intersections
(as the example shown in Figure 3(a)). (2). The road
network is composed of multiple road segments
(polylines), but the line segments are not split (if not
necessary) at intersections (see Figure 3(b)).</p>
          <p>
            This generation of our system focus on handling
vector data represented in the first way (i.e., the line
segments are split at intersections), because most of the
popular road vector datasets (such as US Census
TIGER/Line files and NAVSTREETS from NAVTEQ)
represent their datasets in such way. Based on this sort of
road segment representation, the process of finding the
intersection points from the road network is divided into
two steps. First, the system examines all line segments in
the vector data to label the endpoints of each segment as
the candidate intersection points. Second, the system
examines the connectivity of these candidate points to
determine if they are intersection points. In this step, each
candidate point is verified to see if there are more than
two line segments connected at this point. If so, this point
is marked as an intersection point and the directions of the
segments that are connected at the intersection point are
calculated. In practice, the search of road intersections
from large road networks is supported efficiently by
spatial access method R-tree [
            <xref ref-type="bibr" rid="ref11">11</xref>
            ].
          </p>
        </sec>
        <sec id="sec-2-4-2">
          <title>2.3 Finding the matched feature points by Point</title>
        </sec>
        <sec id="sec-2-4-3">
          <title>Pattern Matching (PPM)</title>
          <p>Now that we have described how to detect feature points
from a road network, we now describe how this
(a) Road segments are split at intersections
(b) Road segments are not split at intersections
Figure 3: Different ways to represent a
crossshaped road network with one intersection
information can be used to automatically match two road
networks. Let U= {ui | ui= (xi, yi ), where (xi, yi ) is the
location of intersections of the first road network} and
V= {vj | vj= (mj, nj), where (mj, nj) is the location of
intersections of the second road network}. Our objective
is to locate the set: {RelPat={(ui,vj) | where ui is the
intersection on the first vector dataset and vj is the
corresponding intersection (if any) on the second dataset.</p>
          <p>That is, point ui and vj are formed by the same intersected
road segments}. Consider identifying matched point
pattern between two road networks. If the system can
recognize the names of road segments that meet at
intersections, it can use these road names to infer the set
RelPat. However, road vector data may not include the
non-spatial attribute, road name. Instead, we propose our
approach that relies on some prominent geometric
information, such as the distribution of points, the degree
of each point and the direction of incident road segments,
to locate the matched point pattern. In other words, the
problem of point pattern matching is at its core a
geometric point sets matching problem. The basic idea is
to find the transformation T between the layout (with
relative distances) of the point set U and V.</p>
          <p>The key computation of matching the two sets of
points is calculating a proper transformation T, which is a
2D rigid motion (rotation and translation) with scaling.</p>
          <p>Because the majority of vector datasets are oriented such
that north is up, we only compute the translation
transformation with scaling. Without loss of generality,
we consider how to compute the transformation where we
map from a fraction α of the points of U to the points of
V. The reason that only a fraction α of the points of U is
considered is that one road vector dataset could be
detailed while the other one is represented abstractly or
there may be some missing/noisy points from each road
network. The transformation T brings at least a fraction α
of the points of U into a subset of V. This implies:</p>
          <p>
            ∃ T and U’ ⊆ U , such that T(U’) ⊆ V , where | U’ | ≥
α| U | and T(U’) denotes the set of points that results from
applying T to the points of U’. Or equivalently, for a 2D
point (x, y) in the point set U’ ⊆ U, ∃ T in the matrix form
Sx 0 0
 0 Sy 0 (Sx and Sy are scale factors along x and y
Tx Ty 1
direction, respectively, while Tx and Ty are translation
factors along x and y directions, respectively), such that
Sx 0 0
 
[x, y, 1] *  0 Sy 0 = [m , n, 1] , where | U’ | ≥
the datasets. Therefore, when checking whether a 2D
point p belongs to the point set V, we declare that p ∈ V,
if there exists a point in V that is within Euclidean
distance δ of p for a small fixed positive constant δ, which
controls the degree of inaccuracy. The minimum δ such
that there is a match for U’ in V is called Hausdorff
distance. Different computations of the minimum
Hausdorff distance have been studied in great depth in the
computational geometry literature [
            <xref ref-type="bibr" rid="ref12">12</xref>
            ]. We do not seek to
minimize δ but rather adopt an acceptable threshold for δ.
          </p>
          <p>
            The threshold is relatively small compared to the average
inter-point distances in V. In fact, this sort of problem was
categorized as “Nearly Exact” point matching problem in
[
            <xref ref-type="bibr" rid="ref13">13</xref>
            ].
          </p>
          <p>Given the parameters α and δ, to obtain a proper
transformation T, we need to compute the values of the
four unknown parameters Sx, Sy, Tx and Ty. This implies
that at least four different equations are required. A
straightforward (brute-force) method is first choosing a
point pair (x1, y1) and (x2, y2) from U, then, for every pair
of distinct points (m1, n1) and (m2, n2) in V, the
transformation T’ that map the point pair on U to the point
pair on V is computed by solving the following four
equations:
Sx* x1 + Tx = m1 Sy* y1 + Ty = n1
Sx* x2 + Tx = m2 Sy* y2 + Ty = n2</p>
          <p>
            Each generated transformation T’ is thus applied to the
entire points in U to check whether there are more than
α|U| points that can be aligned with some points on V
within the threshold δ. This process is repeated for each
possible point pair from U, which implies that it could
require examining O(|U|2) pairs in the worst case. Since
for each such pair, the algorithm needs to try all possible
point pairs on V (i.e., O(|V|2 )) and spends O(|U| log|V|)
time to examine the generated transformation T’, this
method has a worst case running time of O(|U|3 |V|2
log|V|). The advantage of this approach is that we can find
a mapping (if the mapping exists) with a proper threshold
δ, even in the presence of very noisy data. However, it
suffers from high computation time. One way to improve
the efficiency of the algorithm is to utilize randomization
in choosing the pair of points from U as proposed in [
            <xref ref-type="bibr" rid="ref14">14</xref>
            ],
thus achieving the running time of O(|V|2 |U| log|V|).
          </p>
          <p>However, their approach is not appropriate for our
datasets because it is possible one vector dataset is in
detailed level while other vector dataset is represented
abstractly.</p>
          <p>
            In fact, in our previous work [
            <xref ref-type="bibr" rid="ref15">15</xref>
            ], we utilized the
similar technique to match two point sets detected from a
raster map and an image. More precisely, in [
            <xref ref-type="bibr" rid="ref15">15</xref>
            ], we
proposed an enhanced point pattern matching algorithm to
find the overlapping area of a map and an imagery by
utilizing map-scale to prune the search space of possible
point pattern matches (by reducing the numbers of
potential matching point pairs needed to be examined). In
the following sections, we focus on finding the matching
Tx
          </p>
          <p>Ty</p>
          <p>1
α| U | and the 2D point (m, n) belongs to the intersection
point set V on the second vector dataset. With this setting,
we do not expect point coordinates to match exactly
because of finite-precision computation or small errors in</p>
          <p>(a) The two networks to compare
(b) Using Point connectivity and Angles of the point to prune the search space</p>
          <p>(110)
(c) Using Angles between the points to prune the search space</p>
          <p>Figure 4: Comparing two road networks by using Geo-PPM
between different road networks and developing more is detailed and the other one is represented abstractly),
efficient techniques by utilizing some additional spatial this condition will not be valid for a large portion of the
information that can be inferred from the road vector intersections and may only be valid for major roads’
datasets. In addition, we also discuss how to prioritize the intersections.
potential matching point pairs needed to be examined. 2. Angles of the point: The angles of a point are defined
as the angles of the road segments that intersect at that
2.4 Enhanced PPM Algorithm: Prioritized Geo-PPM point. Similar to the connectivity, a point P’1 in S2 can
Due to the poor performance of the brute-force point only be considered as a candidate for point P1 in S1 only if
pattern matching algorithm mentioned in the previous the two points have similar angles, or the difference
section, PPM cannot be applied to large datasets where between their angles is less than a threshold value. To
the number of points (or intersections) is in the order of illustrate, consider comparing two road networks as the
thousands (such as the road networks covering large example shown in Figure 4(a). Whenever the system
areas). Consequently, we utilize some auxiliary chooses a point (as the point shown in the left figure of
information that can be extracted from the road vector Figure 4(b)) in one road network, it only has to consider
data to improve the performance of PPM for larger road the candidate matched points with same connectivity and
networks. With the goal to reduce the numbers of similar directions of intersected road segments from the
potential matching point pairs needed to be examined, the other network (as some possible candidates marked in the
intuition here is to exclude all unlikely matching point right figure of Figure 4(b)). Note that if the densities of
pairs. For example, given a point pair (x1, y1) and (x2, y2) the datasets are different (i.e., one dataset is detailed and
in S1, we only need to consider pairs (x’1, y’1) and (x’2, the other one is represented abstractly), this condition will
y’2) in S2 as candidate pairs such that the real world not be valid for a large portion of the intersections and
distance and angle between (x1, y1) and (x2, y2) is close to may only be valid for major roads’ intersections.
the real world distance and angle between (x’1, y’1) and 3. Angle between the points: The angle between two
(x’2, y’2). In addition, (x’1, y’1) would be considered as a points is defined as the angle of the straight line that
possible matching point for (x1, y1) if and only if they connects the points. Clearly, a pair (P’1,P’2) can be
have similar connectivity and road directions. We considered as a possible candidate for the pair (P1,P2) only
categorize the auxiliary information we utilize to the if the angle between P’1 and P’2 is similar to the angle
following groups. between P1 and P2, or the difference between their angles
1. Point connectivity: We define the connectivity of a is less than a threshold value. Note that this feature can
point as the number of the road segments that intersect at only be utilized when the second dataset is not rotated and
that point. Clearly, if datasets S1 and S2 have very close has the same direction as the first dataset. Consider the
densities (i.e., number of intersections per one unit of example shown in Figure 4(c). Whenever the system
area), a candidate matching point P’1 in S2 for a point P1 chooses a point pair (as the point pair shown in the left
in S1 must have the same connectivity as P1. Note that if figure of Figure 4(c) and the angle between these two
the densities of the datasets are different (i.e., one dataset points is about 110 degree) in one road network, it only
has to consider the candidate matched point pairs with the
similar angle (as some possible candidate point pairs
marked as dash lines in the right figure of Figure 4(c)).
4. Distance between the points: The distance between
two points is defined as the length of the straight line that
connects the points in Euclidean space. Similar to the
previous case, a pair (P’1,P’2) can be considered as a
possible candidate for the pair (P1,P2) only if the length of
the line connecting P’1 and P’2 is similar to the length of
the line connecting P1 and P2, or the difference between
the lengths is less than a threshold value. Note that this
feature can only be utilized when the relationship between
the geometry of the datasets is known and hence, the
distances between objects in two datasets are comparable.</p>
          <p>By applying the above conditions simultaneously, the
Geo-PPM approach can be defined as a specialization of
PPM where only the candidate pairs that have similar
point connectivity, angles of the point, angles between the
points, and distances between the points, will be
considered. This will greatly reduce the size of the search
space. However, this is still a very complex approach
when the number of points in the datasets is in the order
of thousands. Hence, we propose prioritized Geo-PPM
that can dramatically reduce the complexity of Geo-PPM
for large networks by examining the points that have the
minimum number of candidates.</p>
        </sec>
        <sec id="sec-2-4-4">
          <title>Prioritized Geo-PPM</title>
          <p>The intuition behind prioritized Geo-PPM is to increase
the possibility of examining the correct matching pair
from the candidates by first examining the pairs of points
that have the minimum number of candidates. Suppose
that there are n1, n2, n3 and n4 points in the pool of
candidates for points P1, P2, P3, and P4, respectively. This
means that the number of possible candidate pairs for (P1,
P2) and (P3, P4) that must be examined by Geo-PPM is
n1n2 and n3n4, respectively. Note that the values of n1 to n4
could be very large, especially for urban areas where the
road networks follow a grid pattern and hence, a large
portion of the intersections have the same connectivity
and angles. Also note that from these possible candidate
pairs, only (a maximum of) one pair is the correctly
matching one. Hence, by first examining the combination
that contains the minimum number of points, we can
significantly increase the possibility of finding the correct
matching pair sooner. Consider the example shown in
Figure 5. Our system can start the matching process by
first examining the combination that contains the
minimum number of points. As the point pair chosen in
the left figure of Figure 5(b), it has less potential matching
point pairs as shown in the right figure of Figure 5(b),
comparing to the point pair examined in the left figure of
Figure 5(a).</p>
        </sec>
      </sec>
    </sec>
    <sec id="sec-3">
      <title>3. Evaluations</title>
      <p>We performed several experiments with real world
datasets to examine the performance of our prioritized
Geo-PPM. We used three road networks obtained from
USGS, NGA and US Census, covering the streets in the
area of (-122.5015, 37.78) to (-122.3997, 37.8111). Figure
6(a) shows USGS road network with accurate geometry
but with poor attributes. Figure 6(b) shows the US Census
TIGER/Lines road network with rich attributes (e.g., road
names, road classifications) but with poor geometry.</p>
      <p>Figure 6(c) shows the NGA road network with some
specific attributes (e.g., road surface type). Also note that,
as shown in the figure, while the data from USGS and US
Census have almost similar granularity, the NGA data is
an abstract level data (i.e., only major roads are stored).</p>
      <p>We manually transformed each dataset to unknown
geometry systems by multiplying and subsequently
adding different values to latitudes and longitudes of the
vector objects in each dataset. Moreover, we filtered the
south west quarter of the datasets to generate datasets with
smaller sizes to examine how our approach behaves for
different sizes of data.</p>
      <p>Figure 7 shows the partial result of matched feature
point sets for the USGS and US Census road networks.</p>
      <p>We also performed a quantitative analysis to measure the
performance of our approach. Toward that end, we
developed two metrics, precision and recall, to measure
the performance of our Geo-PPM technique, since the
accuracy of the matched points significantly affects the
matching of the two road networks. Let the point pattern
generated by Geo-PPM be defined as a set:
(a) A bad starting point pair candidate (several potential point pairs needed to be examined in the other
road network)
(b) A better starting point pair candidate (only two potential point pairs needed to be examined in the
other road network)</p>
      <p>Figure 5: Picking up proper point pair by using Prioritized Geo-PPM</p>
      <p>RetPat={(mi, sj) | where mi is the intersections on the
first vector dataset and sj is the corresponding
intersections located by prioritized Geo-PPM}</p>
      <p>To measure the performance of Geo-PPM, we need to
compare the set RetPat with respect to the real matched
point pattern set RelPat (defined in Section 2.3).</p>
      <p>Using this term, we define</p>
      <sec id="sec-3-1">
        <title>Intuitively, precision is the percentage of correctly</title>
        <p>matched road intersections with respect to the total
matched intersections detected by prioritized Geo-PPM.
Recall is the percentage of the correctly matched road
intersections with respect to the actual matched
intersections. Table 1 shows the results of our
experiments for three combinations of these datasets. As
shown in the table, the average number of candidates (i.e.,
the number of points in the second dataset with the same
connectivity and angles as compared to a point in the first
dataset) varies between 371 and 637. This shows that the
possibility of selecting 2 pairs from the candidate pool
which are exactly matched to 2 points selected from the
first dataset is very low, meaning that random selection of
points in Geo-PPM will result to a very large number of
possibilities and hence, to a very large processing time.
For example, for the USGS+US Census combination, the
possibility that randomly selected pair of points from the
pool of candidates is exactly matched to the pair of points
1 × 1 = 1
selected from the first dataset is 637 637 405769 .
However, as shown in the table, by utilizing prioritized
Geo-PPM we could achieve an acceptable precision (i.e.,
over 80% for USGS+NGA data and over 90% for other
cases) and recall (i.e., over 90%) by examining between
33 and 52 candidate pairs. This means that using the
prioritized Geo-PPM, the possibility of selecting the
3 2
actual matching pair is between 100 to 100 , which is
up to 4 orders of magnitude better than that of Geo-PPM.</p>
      </sec>
    </sec>
    <sec id="sec-4">
      <title>4. Related Work</title>
      <p>
        There have been a number of efforts to automatically or
semi-automatically detect matched features across
different road vector datasets [
        <xref ref-type="bibr" rid="ref3 ref4 ref5 ref6 ref7">3, 4, 5, 6, 7</xref>
        ]. Given a
feature point from one dataset, these approaches utilize
different matching strategies to discover the
corresponding point within a predetermined distance (i.e.,
a localized area). This implies that these existing
algorithms only handle the matching of vector datasets in
the same geometry systems (i.e., the same coordinate
system). Hence, to the best of our knowledge, no general
method exits to resolve the matching of two vector data in
unknown geometry systems. In addition, various GIS
systems (such as ESEA MapMerger 9 ) have been
implemented to achieve the matching of vector datasets
with different accuracies. However, most of the existing
systems require manual interventions to transform two
road networks into same geocoordinates beforehand.
Thus, they are not suitable for handling road networks in
unknown geometry systems, while our approach can
match two road networks in unknown geometry systems.
      </p>
      <p>Finally, our approach discussed in this paper utilizes a
specialized point pattern matching algorithm to find the
corresponding point pairs on both datasets. The geometric</p>
      <sec id="sec-4-1">
        <title>Datasets</title>
      </sec>
      <sec id="sec-4-2">
        <title>Number of</title>
        <p>Intersections</p>
      </sec>
      <sec id="sec-4-3">
        <title>Average</title>
        <p>Number of
Candidates
Point Pairs
Examined</p>
      </sec>
      <sec id="sec-4-4">
        <title>Processing</title>
        <p>Time
Precision</p>
      </sec>
      <sec id="sec-4-5">
        <title>Recall</title>
      </sec>
      <sec id="sec-4-6">
        <title>USGS+ US Census 2367 + 2456 637</title>
        <p>
          point set matching in two or higher dimensions is a
wellstudied family of problems with application to area such
as computer vision, biology, and astronomy [
          <xref ref-type="bibr" rid="ref12 ref14">12, 14</xref>
          ].
        </p>
      </sec>
    </sec>
    <sec id="sec-5">
      <title>5. Conclusion and Future Work</title>
      <p>In this paper, we proposed an efficient and accurate
technique, termed prioritized Geo-PPM, to locate the
matched points between two road network datasets when
the spatial attributes of the datasets are in unknown
systems. In our solution, we first select pairs of points in
the first dataset with the minimum number of candidates
(i.e., point with similar connectivity and angles) in the
second dataset, and then perform our PPM method on
these pairs. Although our technique matches road
networks at the point level (not at the road segment level),
it takes the road connectivity, road directions and global
distribution of road intersections into consideration. Our
experiments show that this approach provides acceptable
precision and recall values by only examining a very
small number of pairs.</p>
      <p>We plan to extend our approach in several ways. First,
we plan to examine prioritized Geo-PPM for even larger
road networks and for different patterns of road networks
(e.g., rural roads and urban roads), and consider the
orientations of the road networks as well. Second, we
intend to investigate the appropriate order of utilizing the
auxiliary information described in Section 2.4. Third, we
would like to perform comprehensive comparisons
between our approach and the related techniques
described in Section 4. Finally, we also plan to use these
matched points as control points to integrate different
road network datasets.</p>
    </sec>
    <sec id="sec-6">
      <title>6. Acknowledgements</title>
      <p>This research is based upon work supported in part by the National
Science Foundation under Award No. IIS-0324955. The views and
conclusions contained herein are those of the authors and should not be
interpreted as necessarily representing the official policies or
endorsements, either expressed or implied, of any of the above
organizations or any person connected with them.</p>
    </sec>
    <sec id="sec-7">
      <title>7. Reference</title>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          1.
          <string-name>
            <surname>Barclay</surname>
            ,
            <given-names>T.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Gray</surname>
            ,
            <given-names>J.</given-names>
          </string-name>
          , and
          <string-name>
            <surname>Stuz</surname>
            ,
            <given-names>D.</given-names>
          </string-name>
          <string-name>
            <surname>Microsoft TerraServer: A Spatial Data</surname>
          </string-name>
          <article-title>Warehouse</article-title>
          .
          <source>in the 2000 ACM SIGMOD International Conference on Management of Data</source>
          .
          <year>2000</year>
          . Dallas, TX: ACM Press.
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>
          2.
          <string-name>
            <surname>Chiang</surname>
          </string-name>
          , Y.-Y. and
          <string-name>
            <surname>Knoblock</surname>
          </string-name>
          ,
          <string-name>
            <surname>C.</surname>
          </string-name>
          <article-title>A. Classification of Line and Character Pixels on Raster Maps Using Discrete Cosine Transformation Coefficients and Support Vector Machines</article-title>
          .
          <source>in the 18th International Conference on Pattern Recognition</source>
          .
          <year>2006</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref3">
        <mixed-citation>
          3.
          <string-name>
            <surname>Walter</surname>
            ,
            <given-names>V.</given-names>
          </string-name>
          and
          <string-name>
            <surname>Fritsch</surname>
            ,
            <given-names>D.</given-names>
          </string-name>
          ,
          <article-title>Matching Spatial Data Sets: a Statistical Approach</article-title>
          .
          <source>International Journal of Geographic Information Sciences</source>
          ,
          <year>1999</year>
          .
          <volume>13</volume>
          (
          <issue>5</issue>
          ): p.
          <fpage>445</fpage>
          -
          <lpage>473</lpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref4">
        <mixed-citation>
          4.
          <string-name>
            <surname>Ware</surname>
            ,
            <given-names>J.M.</given-names>
          </string-name>
          and
          <string-name>
            <surname>Jones</surname>
            ,
            <given-names>C.B.</given-names>
          </string-name>
          <string-name>
            <surname>Matching</surname>
          </string-name>
          and
          <article-title>Aligning Features in Overlayed Coverages</article-title>
          .
          <source>in the 6th ACM International Symposium on Advances in Geographic Information Systems (ACMGIS'98)</source>
          .
          <year>1998</year>
          . Washington, D.C: ACM Press.
        </mixed-citation>
      </ref>
      <ref id="ref5">
        <mixed-citation>
          5.
          <string-name>
            <surname>Cobb</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Chung</surname>
            ,
            <given-names>M.J.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Miller</surname>
            ,
            <given-names>V.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Foley</surname>
            ,
            <given-names>H.I.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Petry</surname>
            ,
            <given-names>F.E.</given-names>
          </string-name>
          , and
          <string-name>
            <surname>Shaw</surname>
            ,
            <given-names>K.B.</given-names>
          </string-name>
          ,
          <article-title>A Rule-Based Approach for the Conflation of Attributed Vector Data</article-title>
          .
          <source>GeoInformatica</source>
          ,
          <year>1998</year>
          .
          <volume>2</volume>
          (
          <issue>1</issue>
          ): p.
          <fpage>7</fpage>
          -
          <lpage>35</lpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref6">
        <mixed-citation>
          6.
          <string-name>
            <surname>Saalfeld</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          , Conflation: Automated Map Compilation.
          <source>International Journal of Geographic Information Sciences</source>
          ,
          <year>1988</year>
          .
          <volume>2</volume>
          (
          <issue>3</issue>
          ): p.
          <fpage>217</fpage>
          -
          <lpage>228</lpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref7">
        <mixed-citation>
          7.
          <string-name>
            <surname>Chen</surname>
          </string-name>
          , C.-C.,
          <string-name>
            <surname>Shahabi</surname>
            ,
            <given-names>C.</given-names>
          </string-name>
          , and
          <string-name>
            <surname>Knoblock</surname>
          </string-name>
          ,
          <string-name>
            <surname>C.</surname>
          </string-name>
          <article-title>A. Utilizing Road Network Data for Automatic Identification of Road Intersections from High Resolution Color Orthoimagery</article-title>
          . in the Second Workshop on Spatio-Temporal Database Management,
          <source>colocated with VLDB</source>
          .
          <year>2004</year>
          . Toronto, Canada.
        </mixed-citation>
      </ref>
      <ref id="ref8">
        <mixed-citation>
          8.
          <string-name>
            <surname>Chen</surname>
          </string-name>
          , C.-C.,
          <string-name>
            <surname>Thakkar</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Knoblok</surname>
            ,
            <given-names>C.A.</given-names>
          </string-name>
          , and
          <string-name>
            <surname>Shahabi</surname>
            ,
            <given-names>C.</given-names>
          </string-name>
          <article-title>Automatically Annotating and Integrating Spatial Datasets</article-title>
          .
          <source>in the 8th International Symposium on Spatial and Temporal Databases (SSTD'03)</source>
          .
          <year>2003</year>
          . Santorini Island, Greece.
        </mixed-citation>
      </ref>
      <ref id="ref9">
        <mixed-citation>
          9.
          <string-name>
            <surname>Habib</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Uebbing</surname>
            ,
            <given-names>R.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Asmamaw</surname>
            ,
            <given-names>A</given-names>
          </string-name>
          ,
          <source>Automatic Extraction of Primitives for Conflation of Raster Maps</source>
          .
          <year>1999</year>
          , The Center for Mapping, The Ohio State University.
        </mixed-citation>
      </ref>
      <ref id="ref10">
        <mixed-citation>
          10.
          <string-name>
            <surname>Flavie</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Fortier</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Ziou</surname>
            ,
            <given-names>D.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Armenakis</surname>
            ,
            <given-names>C.</given-names>
          </string-name>
          , and
          <string-name>
            <surname>Wang</surname>
          </string-name>
          , S.
          <source>Automated Updating of Road Information from Aerial Images. in the American Society Photogrammetry and Remote Sensing Conference</source>
          .
          <year>2000</year>
          . Amsterdam, Holland.
        </mixed-citation>
      </ref>
      <ref id="ref11">
        <mixed-citation>
          11.
          <string-name>
            <surname>Guttman</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          <article-title>R-trees: a dynamic index structure for spatial searching</article-title>
          .
          <source>in the SIGMOD Conference</source>
          .
          <year>1984</year>
          . Boston, MA.
        </mixed-citation>
      </ref>
      <ref id="ref12">
        <mixed-citation>
          12.
          <string-name>
            <surname>Chew</surname>
            ,
            <given-names>L.P.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Goodrich</surname>
            ,
            <given-names>M.T.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Huttenlocher</surname>
            ,
            <given-names>D.P.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Kedem</surname>
            ,
            <given-names>K.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Kleinberg</surname>
            ,
            <given-names>J.M.</given-names>
          </string-name>
          , and
          <string-name>
            <surname>Kravets</surname>
            ,
            <given-names>D.</given-names>
          </string-name>
          <article-title>Geometric pattern matching under Euclidean motion</article-title>
          .
          <source>in the Fifth Canadian Conference on Computational Geometry</source>
          .
          <year>1993</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref13">
        <mixed-citation>
          13.
          <string-name>
            <surname>Cardoze</surname>
            ,
            <given-names>D.E.</given-names>
          </string-name>
          and
          <string-name>
            <surname>Schulman</surname>
            ,
            <given-names>L.J.</given-names>
          </string-name>
          <string-name>
            <surname>Pattern</surname>
          </string-name>
          <article-title>Matching for Spatial Point Sets</article-title>
          . in
          <source>the IEEE Symposium on Foundations of Computer Science</source>
          .
          <year>1998</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref14">
        <mixed-citation>
          14.
          <string-name>
            <surname>Irani</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          and
          <string-name>
            <surname>Raghavan</surname>
            ,
            <given-names>P.</given-names>
          </string-name>
          ,
          <article-title>Combinatorial and experimental results for randomized point matching algorithms</article-title>
          .
          <source>Computational Geometry</source>
          ,
          <year>1999</year>
          .
          <volume>12</volume>
          (
          <issue>1-2</issue>
          ): p.
          <fpage>17</fpage>
          -
          <lpage>31</lpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref15">
        <mixed-citation>
          15.
          <string-name>
            <surname>Chen</surname>
          </string-name>
          , C.-C.,
          <string-name>
            <surname>Knoblock</surname>
            ,
            <given-names>C.A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Shahabi</surname>
            ,
            <given-names>C.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Chiang</surname>
          </string-name>
          , Y.-Y., and
          <string-name>
            <surname>Thakkar</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          <article-title>Automatically and Accurately Conflating Orthoimagery and Street Maps</article-title>
          .
          <source>in the 12th ACM International Symposium on Advances in Geographic Information Systems (ACM-GIS'04)</source>
          .
          <year>2004</year>
          . Washington, D.C: ACM Press.
        </mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>