Public Sector ITS Datum Requirements Workshop

Knoxville TN, March 16-17, 1998

Proceedings of the Breakout Group on Technical Issues

Val Noronha, March 19 1998


Members of the Technical breakout group were: Other breakout groups — Public Safety Highway Incidents, GIS-T/Planning and Transit — focused on Datum issues relevant to specific application areas.  The task of the Technical group was to examine issues across the three application categories.  Historically there have been divergences, or perceived divergences, between the viewpoints of GIS-T, NSDI and ITS.  The group decided that it would be useful to attempt to unify these viewpoints, particularly with regard to the following issues:
  1. Structure/Definitions
  2. Node placement
  3. Datum development and maintenance

1.  Structure and Definitions

GIS-T  The principal GIS-T requirement is that the Datum support linear referencing.  It is not concerned with topological functionality, and does not require shape points. GIS-T does require that the Datum support linear measurement, i.e. driven-distance offset measured from a defined starting point.  Accuracy requirements are not well understood, because error tolerance is unclear, and there are no documented evaluations of measurement devices (Distance Measuring Instruments, DMIs).  Accuracy in the 2–5 metre range would probably be considered exceptionally good.

NSDI is concerned with data exchange between digital map bases developed at different scales, e.g. 1:24,000 versus 1:100,000.  The Datum must enable a user to reference the same “chunk” of road in two databases, so that attribute information relating to that chunk can be exchanged.  The chunk must be stable over time, independent of cartographic or topological representation.  It is defined not by street name (which may vary in time and space and is difficult to reference across vendors) but in physical terms, i.e. (a) the road of which the chunk is a part, and (b) extremities of the chunk.  Extremities must be physically identifiable points on the ground, usually intersections.  The appropriate Datum structure is:

  1. anchor point, consisting of
  2. anchor section, consisting of
Coordinates and driven length are attributes of their respective objects, and may be updated as superior measurement technologies emerge.  Other field values are permanently tied to their records.
 
NOTE: Anchor points have historically been termed “nodes,” and anchor sections “links,” in ITS Datum documents, because they are topological nodes and links in the Datum network; however, not all street intersections are ITS Datum-nodes and vice versa.  The ambiguity in terminology has caused some readers to misunderstand the ITS Datum documents.
 

ITS  From the ITS point of view, the Datum must support location referencing between digital databases.  Referencing must be unambiguous.  Error tolerance is currently 10-20 metres in urban areas, but this may get more exacting in the future as ITS resolution evolves from carriageway to lane-level applications.  Locations are typically passed as electronically encoded messages using some communications protocol.

Location referencing relies on the ability to identify common objects between databases; this is also the basis of data exchange as defined above by NSDI.  ITS and NSDI positions are therefore essentially similar, with slightly different emphases on terminology and attributes.

Consensus?  The group agreed that the above structure was largely or exactly similar to the “divergent” positions with which individuals came in.  The following table summarizes minor residual differences.  Pending resolution of terminology and to take a neutral position in this report, basic Datum entities are termed tie-points and tie-lines.  Legend:   • = Required   ? = Optional
 

 
GIS-T
NSDI
ITS
Structure
  Tie-point/Tie-line IDs
•
•
•
  Tie-point Coordinates
?
?
•
  Tie-line Length
•
?
•
Quality
  Error Tolerance
Unknown
N/A
10-25 (urban)
 

A more fundamental point of contention is whether the Datum should be a topological network.  As far as NSDI and GIS-T are concerned, topology is not necessary — and from a strictly technical standpoint it could be argued that topology is not an essential property of the Datum for ITS applications either.  Accordingly it should be permissible to insert a tie-point into a tie-line without breaking the tie-line.  In Figure 1, tie-line 20-24 is introduced into the Datum network, interrupting tie-line 12-16.  In the topological tradition (Figure 1a), this breaks 12-16 into 12-20 and 20-16.  Due to computational imprecision, 12-16 may develop a few-microns-wide kink, but this is inconsequential because 12-16 ceases to exist as a bonafide object.  In Figure 1b, 12-16 stays unbroken, even though though tie-point 20 may lie very close to or exactly on it.
 

Figure 1a: Topology enforced
Figure 1b: Topology not enforced
Arguments in favour of the topology-unenforced structure are:
  1. 12-20 is not a legal link.  Measurements along the 12-20 section must still be expressed with reference to 12-16.  Therefore periodic maintenance does not require re-labelling of tie-points or tie-lines.  A user's Datum file may be out of date, yet references based on older IDs remain valid.
Counter-arguments are:
  1. This non-topological structure is not currently accommodated by GIS software.  Software vendors will have to comply with this new requirement, else specialized software will have to be developed.
  2. One possible Datum development strategy may be that it evolves into a skeletal national road network database, upon which private vendors may add value by attaching shape points and attributes.  A non-topological structure may make this course difficult.
Converse positive and negative arguments can be advanced with regard to a topological structure.
 
Post-workshop note  

A compromise position, that preserves topology-dependent ambitions for the Datum and avoids re-labelling, is achievable.  Bear in mind that the internal Datum maintenance process and the public Datum access mechanism are two separate systems. 

  • Although tie-lines such as 12-16 are technically retired when split by intervening tie-points, and new tie-lines created, these changes are made transparent to the end-user.  References to the original tie-line are still permitted, and in fact required.
  • “Component links” created by fragmentation of older tie-lines (e.g. 12-20 and 20-16) are specially flagged in their internal attribute table, at the time of fragmentation.  While they are valid objects in the internal maintenance of the database, they are concealed from the public.  Separation between the internal and public facets of the Datum is inevitable.  Because custodianship and maintenance of the Datum are hierarchically decentralized, insertions will usually be performed by agencies other than the highest-level custodian.  The lower-level creator of 12-20's takes steps as above to hide these links created as a result of its own actions, while the upper-level agency need do nothing to ensure continued survival of the original 12-16's.
This compromise structure is maintainable using standard current software, yet a fully-topological national database may easily be created downstream by merging the databases of each custodian.  Merging is most easily accomplished if lower-level custodians maintain a record of (a) higher-level links that they have split, and (b) suppressed component links.
 

2.  Node Placement

Other breakout groups required that the Datum not be restricted to be a subset of the road network.  Tie-points and tie-lines may be associated with off-road paths such as driveways, hiking trails and transit termini, and significant landmarks or structures of particular interest such as hospitals, bridges, lighthouses, etc.

It is impossible to agree on accuracy requirements until error tolerances are fully defined at the application end.  Density is dependent on rectification (rubber-sheeting) algorithms and error tolerance, and micro-level placement rules depend on the accuracy specification.  Appropriate subjects for research are:

 

3.  Datum Development and Maintenance

Administration

Datum development will involve federal, state and local government, and perhaps private parties.  Development, maintenance and labelling procedures must be developed to allow these players to contribute to the Datum in an orderly but flexible fashion.  Tie-points are labelled using Internet-style partitioned numbers, that include (a) basic geography — county identifier, (b) administrative body responsible for the number, (c) serial identifier.
 
Figure 2: Hierarchical Development.  Black superstructure is responsibility of highest level, e.g. federal.  State administers red tie-lines, counties define green, etc.  Greatest accuracy is found at the lowest level. 
An example is 50019.013.394837, where 50019 is the county FIPS code, 013 is a code representing the responsible state authority, and 394837 is the serial number assigned by that authority.  A hierarchical domain permission system gives agencies at each level the authority to sub-assign numbering and maintenance rights to lower-level bodies which take responsibility for sub-domain administration.  Public access to the Datum may be through a central server or distributed servers; either option is feasible in the age of the Internet.

Budgeting

Two budgeting scenarios were discussed: Costs and benefits of each approach need to be assessed.

Edits

Datum edits may take the form of additions, deletions and changes.  Additions are straightforward.  Change may take two forms: All data edits must have time stamps and metadata regarding reasons, data sources and quality.  Historical files must be maintained for reference and correction of legacy data.

Quality Hierarchy

Federal data requirements will probably call for analysis at smaller scales (i.e. wider geographic areas, with greater error tolerance) than will municipal needs.  As the Datum is locally densified, accuracy will improve.  Lower-level organizations are free to upgrade accuracy by re-measurement within their geographic area.  When re-measured objects fall under the jurisdiction of higher-level authorities, the new data must be submitted to the higher authority.

Comments to Val Noronha