Geocoding and linear referencing
Notes on the Breakout Group
Val Noronha
Address ranges vs address points
-
Addresses are usually (not universally) in monotonic sequence. They
are rarely perfectly linear. There is a need for rules that guarantee
geocoding accuracy, e.g. supposing the requirement is that geocoding be
accurate within 50m (longitudinally, along the street), then selected address
points would have to be stored explicitly as required to achieve this,
supplementing address ranges. There is a straightforward algorithmic
solution to find the minimum set of points, given a geocoding tolerance.
-
In some jurisdictions addresses may be alphabetic rather than numerical,
e.g. “Beach Manor.” This must be accommodated.
-
In other jurisdictions (e.g. parts of the Middle East), conventional street
addresses may not exist at all, and people rely on directions, landmarks
or other descriptors of location. Even in North America, rural locations
may have rural route numbers or lot and township address formats that do
not lend themselves to linear address structures and methods. Models
cannot be expected to accommodate all these practices; it is reasonable
to expect jurisdictions to implement conventional civic addressing, and
many are already doing so in the interests of public safety.
-
Multiple addressing methods may co-exist on the same stretch of road, particularly
where the road separates or cuts through different municipalities.
Addresses may be linear over some sections, non-monotonic in others, or
random in parts.
-
Jonathan pointed out that ESRI “locators” are able to deal interchangeably
with many forms of address expression. The UNETRANS team will review
these and examine the need for modification to handle the special cases
identified.
Multiple street names
-
A street may have several different names that apply over different sections,
e.g. I-90 is New York State Thruway in one section, Mass Pike in another.
Each should be associated with a naming authority:
{Name, Authority, Start offset, End offset}
-
Again, the group felt that some exceptional cases should be addressed by
the model, while others that are unresolvable should be fixed by the municipal
action. For example, if there are several instances of “Main Street”
in a state, the county name or postal code can be used to distinguish between
them. On the other hand, if there are multiple instances of “Main
Street” that share the same county and postal district, it is up to the
municipality, not a model, to resolve the duplication.
Linear Issues
-
Linear addresses such as “mile 23.75” are not always accurate. They
are implemented more as labels that remain stable through time (as sections
are lengthened and shortened) rather than statements of exact distance,
although exact distance may be recorded as an attribute of the section
(see measures, below).
-
There must be a provision for lateral offsets (including elevation) associated
with linearly addressed objects, and means for translating between offsets
and coordinates.
-
“Measures” are records of linear distance associated with a road section.
Multiple measures must be accommodated, e.g. calculated x-y length, calculated
x-y-z length, calculated x-y/x-y-z length from a different database, DMI
distance, GPS distance.
-
Feature level metadata, categorical and/or interval, may be associated
with linear measures. For most purposes a linear measure should carry
categorical method-of-measurement metadata (e.g. “DMI”). Sometimes
a numerical estimate of error may be associated with the measurement.
Scale — Carriageways and Lanes
-
The carriageway vs lane question attracted lively debate at both the breakout
session and the plenary that followed. There is overwhelming consensus
on the need to accommodate data at the lane level, e.g. lanewise loop detector
data, HOV usage, navigational instructions. But there are different
opinions on how lanes should be implemented. There is general agreement
that the carriageway, not the lane, may be the appropriate level of resolution
for the present, but that we should be thinking ahead to a future where
lanes are the fundamental objects.
-
The general principles for dealing with lanes are quite clear: there is
a hierarchy of objects from thoroughfare to lane, e.g.
-
Interstate 5 is a thoroughfare
-
I-5 is usually instantiated in two directional carriageways, I-5 North
and I-5 South, which inherit properties from the parent object as appropriate
-
In some areas I-5 North may split into physically separate carriageways,
e.g. express/collector lanes or HOV/regular lanes
-
Lanes may inherit properties of the parent carriageway.
-
One view of implementation is that all lane data (including geometry) should
be stored as attributes associated with carriageways, using start and end
offsets.
-
The other view is that using attribution in this way is a contortion of
the carriageway model, reminiscent of recent experience where turntables
stored data (esp. infinite impedance to prohibit turns between roads that
were not physically connected) that rightfully should have been stored
using non-planar and carriageway models.
-
A difficulty with the lane-level model is that it does not lend itself
to current routing algorithms — an infinite or very large number of links
between
lanes would need to be defined or generated, or algorithms would need
to be redesigned.
Data dictionary/glossary
-
The case was made that the data model should carry a data dictionary and
glossary.