VEHICLE INTELLIGENCE & TRANSPORTATION ANALYSIS LABORATORY    
    University of California, Santa Barbara 

 

Workshop Outcomes

 
Overview The second User Requirements workshop was held June 29-30 1998 in Santa Barbara.  Predictably, it was difficult to find agreement on every detail among the 40+ participants, on how the Datum should be conceptualized, designed and administered to satisfy the entire range of requirements.  Nevertheless, the workshop achieved its purpose, which was to help crystallize our understanding of what the user requirements were, and it has helped us (at VITAL) to focus our research agenda.
Visions There are three, somewhat divergent views of the Datum. 
  • The ITS viewpoint is primarily to achieve interoperability between map databases in real-time ITS applications.  This requires accurate coordinates (currently ± 10m) and standardized distances correct to 0.5%–1%.
  • GIS-T requirements are currently the subject of an extended error propagation study (NCHRP 20-47), and may not be known for another 18 months.  While some GIS-T requirements can extend to the level of 1:250 engineering drawings (positioning to ±12 cm), these do not fall within the realm of centerline databases, and would require a multi-scale data model.  Other requirements in GIS-T are at the centerline scale, and accuracy requirements are likely to be within the same range as ITS specifications.  GIS-T currently envisages a need for lengths, correct to 0.2%–0.5%, but not coordinates.
  • Finally the NSDI need is data sharing between maps at scales of 1:24,000 to 1:100,000.  The requirement is for standard identifiers on appropriately defined objects (e.g. intersections and road segments), not coordinates, not lengths.
The above is largely a restatement of findings from the Knoxville workshop. 

It could be argued that in a cost- and benefit-sharing environment, the most useful design is one that accommodates the needs of all stakeholders (in algebraic terms, the union of needs).  Since the range of users is wide, this view of the Datum would for practical purposes be an accurate public sector database.  This option requires a large up-front investment.

Alternately it could be argued that the first incremental step should be to build the component that is common to all stakeholders (intersection of needs), and that the components peculiar to one or other interest group should evolve as they are able to justify themselves.  This option may serve nobody's interest in the short term, and leaves open the possibility that the needs of some stakeholders will never be met.
. Clearly, if the Datum is to be a reference framework for centerline databases, at least in the short term, then it would be appropriate to design it with reference to centerline error rectification, with associated assumptions about scale and error tolerance.
Agreement There appears to be agreement on a few core issues: 

Basic Components 

The ITS Datum consists of points and lines. 

The points are variously termed nodes, anchor points, tie-points.  (Proponents of the term “node” see the datum as a navigable network; proponents of the term “anchor point” do not).  “Tie-point” is a neutral term to permit the discussion to proceed without getting bogged down in that controversy. 

Similarly the lines are variously termed links, anchor sections, tie-lines. 

Tie-Points  There seems to be agreement that tie-points must lie at physically recoverable locations on the street network.  What is yet unclear is the resolution to which those points are defined and recovered.  If 3-5 metres is sufficient, then it is adequate to define a point as “intersection of Main and State” (assuming that the center point of the intersection is reasonably well defined).  If sub-metre resolution is required, then the definition may have to rely on a reference marker, a stake in the ground or a brass marker in the vicinity of the intersection, relative to which the tie-point is defined. 
 

needs and concerns, so that future technical directions are rooted in reality and utility.

Disagreement

 There are points of contention even at the highest level of conceptualization of the Datum: 
  1. Is it a framework database, containing basic but accurate backbone data for every street nationwide (e.g. shape point coordinates, name, driven length) ...

    2. or a skeleton of monuments and linkages, highly accurate data on a subset of the national street network, with increasingly comprehensive coverage at lower levels 
     
  2. Is “ITS Datum” (or even “datum”) an appropriate term ...

    3. or is it misleading and causing confusion? 
     
  3. Should development be

    4. Top down (national coverage the most accurate, as in geodetic datums) ...  
    or bottom up (national level the coarsest, increasingly accurate at local levels)
Possible contents 
  • Coordinates
  • Standard identifiers
  • Lengths
  • Road Classification
Design should support 
  • non-planar nodes (e.g. at overpasses)
  • differentiation in vertical dimension (z)
  • side of road (implicit left/right topology)
  • pseudonode (2-valent node, no navigation decision)
Other requirements 
  • Testing of the technical concept
  • Software to facilitate implementation

    • Recommended practice (and testing) of the administrative mechanisms to make it work successfully