PUBLIC SECTOR ITS DATUM REQUIREMENTS WORKSHOP

Knoxville - - March 15-17, 1998 - - Sponsored by Oak Ridge National Lab

BACKGROUND -

I represented USGS at a two-day ITS datum workshop in Knoxville, Tennessee, March 15 - 17. ?ITS? is ?Intelligent Transportation Systems? and was formerly known as ?IVHS? for Intelligent Vehicle Highway Systems. ITS includes advanced transportation research and development for a variety of government and commercial applications such as in-car navigation, collision avoidance, non-stop toll booth scanning of UPC-type stickers, real time bus arrival information, regional commuter traffic flow management, commercial fleet tracking, hazardous cargo incident response, route optimization, and advanced E-911 response and guidance. Many ITS components need accurate and current digital geospatial data for transportation networks and facilities.

The proposed ITS datum supports accurate methods of linear location determination and communication. This is similar to the function of a geodetic datum to support accurate 2-D and 3-D location referencing. Although referred to as an ?ITS datum,? the linear datum is important for transportation groups beyond ITS, such as the National Spatial Data Infrastructure (NSDI) ?Framework? transportation community. For an overview of ?The ITS Datum? see

http://itsdeployment.ed.ornl.gov/spatial/files/datumovr.htm

PARTICIPANTS -

The workshop organizers were from Oak Ridge National Lab (ORNL) and Viggen Corporation and are under contract to the ITS group at the Federal Highway Administration (FHWA). Other participants were from the Knoxville Police Department; Knoxville City Engineering Department; Knox County MPC; King County Transit Agency; Tennessee DOT; Vermont Center of Geographic Information; University of Tennessee; Vanderbilt University; University of California at Santa Barbara - National Center for Geographic Information and Analysis (NCGIA) - Vehicle Intelligence Testing and Analysis Lab (VITAL); Digital Geographic Research Corporation (DGRC) in Toronto; University of Wisconsin at Madison; National Cooperative Highway Research Program (NCHRP); various ITS contractors including NASA-JPL, GIS/Trans, and Mitretek; US Bureau of Transportation Statistics (BTS); GIS Committee of the Transportation Research Board (TRB); FGDC Ground Transportation Subcommittee; USGS; and FHWA. Contact me if you would like a complete list of the 26 participants and their organizations.

PLENARY PRESENTATIONS -

* Steve Gordon (ORNL) began the workshop with an overview of Oak Ridge involvement with ITS spatial data research. This workshop focused on (1) the ITS referencing datum, but ORNL and Viggen activities also include (2) development of a Location Referencing Message Specification for real-time communication with in-vehicle systems from different manufactures, (3) work on spatial data exchange and content standards such as GDF and SDTS through ISO TC 204, ISO TC 211, SAE, and FGDC, and (4) study of object-oriented approaches and Open GIS developments for ITS interoperability.

The ITS datum should meet requirements from several transportation groups. It is needed to allow interoperability between and within ITS applications. For example, the location of an incident that is reported relative to a commercial spatial database should be understood accurately relative to a public E-911 database so that fire crews can be sent to the correct location and to the correct side of a divided highway or interchange. More information on ?ITS and the Interoperability Problem? is available at

http://www.ncgia.ucsb.edu/vital/whatis.html

The datum may also be needed for interoperability among ITS, GIS-T, and NSDI framework data sets. Anchor points and anchor sections were important elements from the recent FGDC Wrightsville Beach framework transportation meeting

( http://www.fgdc.gov/Framework/page04.html ).

The datum should serve as the backbone of a common linear referencing system. It may also be used to improve the accuracy of public-sector data sets.

Current ITS datum activities include (1) identifying and evaluating requirements for ITS datum deployment, both locally and nationally, (2) determining costs and benefits, (3) developing a recommendation and an implementation plan. The datum requirements, especially the accuracy requirements for linear locations from a variety of transportation applications need to be identified. Other affected groups should be identified and included in the discussions. Rules for anchor section placement (when not monumented) need to be developed.

A second ITS datum workshop is planned for June 29-30, 1998 in Santa Barbara to resolve issues raised in the Knoxville workshop and to specify roles and issues for implementation. Commercial vendors will be included in the second workshop. A third workshop may occur in September, 1998.

Following Mr. Gordon?s opening remarks, there was some discussion about the need to use precise language and standard terms. Wende O?Neill noticed that there is some confusion between the linear datum and a database representing the navigable roadway network when we use the terms node and link. The ITS linear datum is not intended to represent a navigable network. The preferred terms seem to be anchor point and anchor section. Alternatives include ITS datum node, ITS datum link, tie-point, tie-line, linear datum point, linear datum section, and Vonder point.

* Cecil Goodwin (Viggen) discussed ?Referencing Datums for ITS.? Location referencing, in general, depends on context and a common set of known things, such as landmarks, ID?s, or coordinate systems. A datum is a common set of known things used for location referencing. A common datum allows location references to be understood between groups, and thus allows data sharing. Linear location referencing is a uniform, continuous measurement along linear features. Addresses are, at best, quasi-uniform and quasi-continuous.

An ITS datum includes a set of anchor points which are accurately georeferenced, a set of anchor sections with accurate distances between anchor points, and a specified geodetic datum(s) for horizontal and vertical measurements. The ITS datum will be a national set of ground control points that will anchor spatial references between databases of different kinds. This datum should be in the public domain. It should not jeopardize the proprietary nature of commercial databases. It should allow ITS database interoperability.

ITS datum densification will be a tiered process with a hierarchy of responsibility. The sparse national-level ITS datum should support database interoperability for inter-state and inter-regional applications. The national level datum can be appended and densified by state and local groups using ITS datum standards or recommended practices. There have also been a few local, more dense, ITS datum experiments, including the Santa Barbara ITS test bed.

In addition to (1) the commercial and governmental ITS perspective, Dr. Goodwin mentioned the similar linear datum requirements of (2) the GIS-T linear referencing community (mostly state DOT?s) through the NCHRP, and (3) the NSDI framework transportation activity through the FGDC. The use of a linear datum for the NSDI transportation framework may be less oriented to linear referencing and more toward database updating and attribute sharing. According to the NCHRP, the datum relates the database to the real world and supports transformations among different linear referencing systems and among different geographic representations. A standard ITS datum could be the basis for a common, unified linear referencing data model.

There are differences in the linear datum perspectives for ITS, GIS-T, and NSDI framework. For ITS the requirement is real-time interoperability between different databases. For GIS-T and framework, the requirements relate to data integration, sharing, analysis, and linear referencing. Framework and GIS-T users are mainly public sector. ITS users include the public sector, but are mostly private sector. ITS deployment is bottom-up, beginning with congestion in cities. GIS-T data sharing and framework deployment may occur top down (federal or state first, than regional and local).

* Fred Latham (Viggen) discussed ?ITS Datum Progress and Issues.? Oak Ridge and Viggen have produced a prototype national (48 state) ITS datum on CD-ROM dated 3/16/98 using the 50,000 nodes of the National Highway Planning Network (NHPN) as anchor points. This ITS Datum Prototype, Version 1.0 is in a flat ASCII file format. The anchor point placement is based on centerline intersections from NHPN, with an accuracy of + or - 85 meters at a nominal scale of 1:100,000. See me if you wish to borrow the CD.

Characteristics of the ITS datum that have been identified so far include the following.

( http://www.fgdc.gov/Framework/rdmw/199712Workshop.pdf pages 35-36 ).

Level 0 seems to correspond with the Version 1.0 of the ITS Datum Prototype (on CD).

Several technical issues were discussed including anchor section virtual monuments, physical monuments, and placement rules. Should anchor points always be in the centerline of the right-hand lanes, should they be at intermodal transfer points, what is the standard location for an anchor point at a cloverleaf interchange, should we follow rules from ERTICO (Intelligent Transport Systems - Europe)?

* John Lau (Viggen) provided some ?Scenarios of ITS Datum Use? in the areas of (1) public safety highway incident management, (2) transit operation and transit analysis, and (3) GIS-T and planning. Prior to a bridge replacement, the state engineering department may need to share locational data with local fire departments in case a temporary fire station must be established during bridge construction.

* Val Noronha (UCSB - NCGIA & DGRC) discussed ITS datum technical issues from his perspective at UCSB?s Vehicle Intelligence Testing and Analysis Lab (VITAL) using examples from the Santa Barbara ITS test bed. The six road databases used in a recent Goleta (just north of Santa Barbara) interoperability study were the following.

http://www.ncgia.ucsb.edu/vital/poserror.html

An ITS datum that is common to two databases can help with interoperability by allowing the rubbersheeting (or conflation) of data from one database based on the anchor section coordinates from the other database. Noronha, Goodchild, and others have suggested using accurate anchor points to identify local error clustering and to make positional corrections.

Dr. Noronha discussed placement rules for anchor points at city intersections, freeway interchanges, and ?non right angle? intersections (gore points) based on 4 stages of ITS datum densification and accuracy (similar to the Dan Walters 5 levels discussed by Mr. Latham). Stage 1 is the current Version 1.0 of the ITS Datum Prototype on CD with 80 meter accuracy. Stage 2 for 1998-2002 may have 3 meter accuracy. Stage 3 for 2005-2010 may have 30 centimeter accuracy, and stage 4 may allow referencing of individual lanes.

Please see me for copies of slides from the plenary presentations.

BREAKOUT GROUPS -

The four breakout groups were the following.

1) Public Safety Highway Incidents

2) GIS-T and Planning

3) Transit

4) Technical Issues

I was assigned to the Technical Issues group.

1) Public Safety Highway Incidents -

John Lau summarized the work of the Public Safety Highway Incidents group. They have requirements to identify point locations for incidents to the actual side of the road, especially for divided highways where a significant response delay can occur if an emergency vehicle arrives on the wrong side. There is also a similar need to locate incidents on interchanges to the correct ramp. Interoperability between databases and in-vehicle systems is needed in mutual aid situations where emergency equipment responds from other jurisdictions. Response delays may also occur if street network connectivity is incorrectly represented in a database using a planar graph that may show allowed turns off the top of an overpass. The database should include all roads, including trails. The ITS datum needs to be densified for local use. For local densification, it should be easy to apply placement rules to add datum points. The format should be flat ASCII. At least one anchor point is needed in each operational area. There was some discussion about the need for a new set of signs to allow the public to more easily and accurately report the linear location of incidents.

2) GIS-T and Planning -

Fred Latham summarized the work of the GIS-T and Planning group. ITS datum densification must be driven by the requirements of the applications. Most GIS-T planning is at the local and regional level rather than at the state level. A good ?cost versus benefits? case must be made for development and inclusion of the ITS datum in existing databases. The concept should not be oversold The model must be simple or it will be rejected.

3) Transit -

Steve Gordon summarized the work of the Transit group. For transit planning and operations, many data sets must be integrated with the roadway database, including Census population statistics, DOQ?s, and parcels. If the bus is late because of traffic congestion, then the ferry should wait.

4) Technical Issues -

Val Noronha (UCSB-NCGIA, DGRC, VITAL) was our convener. Other group members were Mark Bradford (FHWA), Bruce Spear (BTS & FGDC-GTS), Alan Vonderohe (U.W.-Madison & NCHRP 20-27), Bruce Westcott (BTS & Vermont GIS), Demin Xiong (ORNL), and Bobby Haas (Viggen). The Technical Issues group met Monday afternoon and Tuesday morning.

The linear datum can be a common structure that supports multiple higher-level structures. For example, one linear datum can be related to multiple spatial data representations (i.e., multiple base maps from different producers and at different scales), multiple route systems (transit, school bus, snow plow, mail delivery), multiple networks, and multiple linear referencing methods and systems.

We noted that there seem to be three perspectives and three sources of requirements for linear datums based on the following three related and overlapping groups.

1) the ITS community, both commercial and governmental,

2) the GIS-T linear referencing community (mostly state DOT?s) through the NCHRP,

3) the NSDI Framework transportation participants through the FGDC.

A linear datum takes on slightly different roles with respect to these three groups. For ITS, the main roles of the linear datum are to support database interoperability and real-time location message exchange. For GIS-T, the roles may be to support accurate dynamic application of road inventory attributes and linear event management. For NSDI transportation framework, a linear datum may support data improvements through conflation and transactions, and the representation of transportation features at multiple levels of detail.

Our initial documentation of required attributes for anchor points and anchor sections, as shown below, may vary based on role.

Anchor Point

6 accuracy for length (determined by applications needs)

Since the ITS linear datum has the most rigorous requirements, it should also meet the linear datum needs of GIS-T and NSDI framework.

The Technical Issues group considered a number of issues and made several observations. Many of the following were suggestions by a subset of our group and are still open to debate.

- If we do not have the length of an anchor section, we may still be able to locate items along it using a percentage. This percentage will we independent of spatial representations and scales. Several GIS-T vendors support this concept. However, if I am in the field and am 100 meters down the road from a monumented anchor point, I may not know my location by percentage unless the length of the anchor section is available.

- Anchor sections have a direction. For each anchor section we identify a starting anchor point and an ending anchor point, not just two bounding anchor points.

- Some, but not all, anchor points will occur at intersections, and not all intersections will be anchor points. The linear datum should not be considered a navigable network. Anchor sections are not equivalent to links. The linear datum is independent of network link arrangement which is related to scale and application.

- GIS tools may not yet exist that can accommodate and take advantage of a linear datum. We may need to push the GIS-T vendor community a bit to develop methods to use a linear datum to support multiple linear referencing methods and multiple spatial representations.

- To measure an event on a ramp, there must be an anchor section under the ramp.

- The rules or guidelines for anchor point placement and anchor section delineation must be flexible to accommodate the needs of different area integrators and regional transportation groups.

- Anchor sections are just as important and as stable as anchor points in the linear datum. I initially thought that we might get by with just the anchor point set for some applications (e.g., rubber sheeting to improve the accuracy of some spatial datasets).

- Local and regional groups can improve the linear datum in several ways. They can provide more accurate coordinate values and descriptions for the national level anchor points and more accurate anchor section lengths to replace current coordinate values, descriptions, and lengths. They can also densify the linear datum by adding new anchor points and anchor sections.

- Given that anchor coordinate values, descriptions, and anchor section lengths may be improved and updated over time, we talked about how this information could be tracked so that we could obtain earlier versions when needed. One suggestion was to carry multiple coordinate values, each with a date stamp and other metadata. We seemed to reject this and settle on simply keeping a log of changes (or transactions) that could be used to produce an earlier version when needed.

- In addition to including better measurements for current values, the linear datum can be updated when there is a physical change such as a realignment that actually changes the real-world length of an anchor section. In this case we should retire the old anchor section and its ID number and replace it with a new anchor section and new unique ID.

- The linear datum may also be updated by adding to the national-level linear datum a more dense set of anchor sections and anchor points to accommodate local roads and detailed interchanges. When this occurs there may be a new anchor point in the middle of an existing national-level anchor section. If the linear datum were required to conform to a planar graph, then we would need to break up the national-level anchor section into two anchor sections between adjacent anchor points. This may conflict with our need to keep a stable set of anchor segments. We can certainly reference the new anchor point by some distance or percentage along the existing anchor segment, but we may not want to impose a planar graph requirement on the linear datum. We referred to this as a topological issue during the workshop, but it may be more a planar issue. This has not yet been resolved, and Dr. Noronha has more information and diagrams of this situation on a web page at

http://www.ncgia.ucsb.edu/vital/tys9803.html

- We should only split an existing anchor section if we have agreement by all participants. When we do this, we will retire the current ID number and use two new ID?s.

- One idea was to name or identify the anchor sections by using the two ID?s of the starting and ending anchor points. This might allow us to use a planar graph linear datum and still reference longer, national anchor segments by specifying two anchor points that are no longer directly adjacent. We may not want to allow the possibility of having overlapping anchor sections.

- A national registry of identified anchor sections was suggested.

- The density and accuracy of anchor points and anchor sections will be based on the accuracy needs of applications. We need better information on the accuracy requirements of ITS, GIS-T, and framework applications before we make final decisions of linear datum density. Some of this information may come from the NCHRP 20-47 project.

- Dr. Spear noted that Michigan uses some very long anchor sections, even across multiple counties for the entire length of the state. There are reference points along these long anchor sections.

- The ultimate development of a usable linear datum may be from the bottom up, but with national guidelines to provide some consistency.

- Prof. Vonderohe noticed some major differences in how the linear datum will be densified as compared to how the geodetic datum has been densified. The initial Federal set of geodetic control points were sparse but very accurate, with additional control being more dense but less accurate. The initial national ITS datum is sparse but not very accurate, and the densified linear datum will be more accurate.

- We considered liability if an emergency response is delayed due to components of a linear datum that do not conform to national guidelines. This could be similar to emergency response delays due to spatial database problems. Appropriate disclaimers may be enough to avoid liability concerns.

- Mr. Westcott mentioned that we could use jurisdiction information (e.g., state and county FIPS codes) for initially assigning parts of the unique internet-style ID numbers for anchor points and anchor segments, but after ID assignment is complete, we should consider these to be ?dumb? numbers and not try to use any information imbedded in the ID?s. This may have been from lessons learned in Vermont. New ID assignment will likely be decentralized and be the responsibility of groups at the local or regional level.

- Some possible next steps include (1) develop guidelines to be used locally to densify the linear datum with more anchor points and sections, (2) encourage the ITS Joint Program Office or the FGDC to begin a monumentation program for some of the national linear datum points, (3) begin improving the coordinate values and distances in Version 1.0 of the ITS Datum Prototype (on CD) based on NHPN by using the best available data. These ideas and others will be discussed at the next ITS datum meeting in Santa Barbara.

On Tuesday afternoon, Prof. Vonderohe summarized the work of our Technical Issues group for the entire workshop.

CLOSING DISCUSSIONS -

Steve Gordon led the entire group in a closing summary.

We identified a number of questions. Should a public-domain ITS datum be developed? What are the requirements for a more dense, next generation datum? Will it be densified by federal agencies or by local agencies? How can linear datum requirements from ITS, NSDI framework, and GIS-T be reconciled? What is the technical design of the datum? What accuracy requirements? What roles for fed, state, regional, local, commercial, academic? Is the combination of national guidelines and local control appropriate for datum densification? What are the physical monumentation requirements? What are the anchor section placement rules? How does the linear datum relate to the common linear referencing data model?

Future work may include the following. Development of a glossary to help avoid confusion in terms (e.g., anchor point, ITS datum node, tie-point, Vonder point). Acquisition of more complete information on linear location accuracy requirements from various applications, that will help determine requirements for linear datum density and measurement accuracy. Current ITS test bed projects and the NCHRP 20-47 project may provide more information on the relationships between datum density, measurement accuracy, and the accuracy requirements from transportation applications. Dr. Spear mentioned that there may be a new proposal to FGDC for an NSDI linear referencing model. AASHTO has a new ITS committee.

There was some discussion on who would lead and fund future efforts in this area. Possibilities include the US DOT?s Joint Program Office for ITS, FGDC, AASHTO. Funding may depend on having a clear and understandable plan, with information on how key groups will benefit. What does this buy us? Why do it? Why is this a higher priority that other possible ITS projects? A non-technical primer may be critical to help acquire funding.

ODDS AND ENDS - ADDITIONAL OBSERVATIONS -

After Dr. Goodwin?s discussion of addresses, someone mentioned that the resource (memory or storage space) requirements to store individual addresses (e.g., for driveway-street intersections) is not much more than storing address ranges. Many of the ITS applications will perform better using individual addresses rather than using address ranges which have lots of problems and inconsistencies. This could also make life easier if we do not have to try to nationally standardize the delineation of a road segment so that it always matches available segments which have address ranges. It also helps when we update data, for example if we add a new road from current DOQ data which causes a new intersection in the middle of an existing segment with an address range, we may try to interpolate the address range and split it at the new intersection, but we cannot be sure about the accuracy of the new address ranges without an expensive site visit. We encounter these same problems with address ranges during conflation but would have an easier time using individual addresses. Dr. Noronha noted that it is best to represent the individual address along the road centerline (e.g., at the intersection of the driveway or property with the road) rather than on the location of the structure or the door, in case we improve the road centerline geometry.

When looking at the data on the new ITS Datum Prototype, Version 1.0 CD-ROM from ORNL and Viggen, I noticed that there are no unique ID?s for anchor sections other than via anchor point ID?s. On the CD, anchor sections are uniquely identified by the combination of starting anchor point ID and ending anchor point ID. For example, in Missouri, along I-29, there is an anchor section from anchor point 295 to anchor point 297 with distance 410 meters. There is a separate anchor section from 297 to 295, also with distance 410 meters (probably a divided highway).

Several people indicated that the format should be flat, comma delimited, ASCII with header information. SDTS and the Point Profile (used by NGS for geodetic control) were mentioned. The SDTS Point Profile will only accommodate point data, so it could be used for anchor points but not anchor sections. The current SDTS Vector Profile is another option, but it may be best to include the ITS datum requirements in the plans for a more complete (and GDF compatible) transportation profile to SDTS and the future object profile to SDTS.

During a side discussion, I mentioned that it would save the government framework transportation players a great deal of effort if we could entice any of the commercial roadway database vendors into giving us a value-reduced version of their data for the NSDI framework. Even a value-reduced version would be more current and more accurate than what is now available in the public domain (with some local E-911 database exceptions). I thought that it might stimulate the overall market for this type of data and actually improve sales of the commercial version of the data, much as free Arc/View version 1 stimulates interest in Arc/View versions 2 and 3. Dr. Goodwin indicated that some database vendors have been approached with this idea, and they currently see no commercial advantage in doing this.

I gave Al Vonderohe some information on the current ANSI (American National Standards Institute) NCITS (National Committee for Information Technology Standards) Technical Committee L1 (Geographic Information Systems) review of SDTS or NCITS 320:199x. Prof. Vonderohe may have a request to change ?altitude? to ?elevation? as the more appropriate technical term for Z values in the geo-positional community. Related information is at

http://www.ncits.org/press/1998/pr98006.htm

ISTEA II passed the Senate and is now in the House. The funding is significantly larger than the original 1992 ISTEA legislation.

During some of the discussions, there seemed to be minor confusion between (1) anchor points and (2) linear reference points (including calibration points, reference posts, mile points, and route origins). My understanding is that anchor points from the linear datum are not necessarily the same as reference points or posts used for linear referencing. Typically there will be lots of reference points used for linear referencing and a smaller number of anchor points.

There also seemed to be different understandings of ?anchor sections.? Are anchor sections equivalent to some proposed standardized road segments (or ?chunks of road?) mentioned in other transportation data model meetings? To be most useful, should the set of anchor sections cover all the roadways represented in a database? Can anchor sections be along just some of the roadways and streets in a database and still be useful as a linear datum?

I was most interested in the relationship between the linear datum and the FGDC?s framework conceptual road data model. We did not talk about this directly, but my assumption is that the framework road data model being developed by Bruce Westcott and Bruce Spear from the work at the Wrightsville Beach meeting will be compatible with the linear datum model.

In regards to the framework road conceptual data model, I mentioned to Bruce Westcott that I had heard good reviews of Visio Professional as a graphics tool for creating a conceptual data model using UML (Unified Modeling Language - best of Rumbaugh, Booch, and Jacobson) rather than Rumbaugh-style OMT (Object Modeling Technique) or Chen-style ERD (Entity Relationship Diagram). Bruce is already using one of the Visio products. I just found that ?ISO/TC 211 resolves to replace the use of OMT by UML for the graphical presentation of conceptual schemas immediately.? (from ISO TC 211 resolutions March 6, 1998, Victoria, BC). We talked briefly about the advantages for the normal reader of showing cardinality using well-known arabic numerals.

I was also interested in the need to include linear datum features (anchor point and anchor section) in the current transportation content specifications that USGS is developing or investigating in partnership with several states (e.g., Georgia, Michigan, West Virginia, Vermont, Kentucky, New Mexico, Texas). My impression is that we should wait for further developments on the national linear datum side before we try to include anchor sections and anchor points in our specifications. However, we should be aware of these developments and have some sense about how they relate to our (USGS) pilot projects and partnerships that are aimed at framework transportation.

In our current USGS transportation pilot projects with various partners we seem to have two kinds of roadway pieces; one is a short piece and the other is a long piece. The short piece is sometimes referred to as a ?road segment? or ?street segment? or ?chunk of road.? The delineation of the short piece varies depending on our partner?s requirements in that area. With Census in New Mexico, the short piece may be very short and delimited by intersections with other roads and linear data from other themes (boundaries, drains, railroads, etc.). With state and regional DOT?s and GIS coordination groups the short piece most often is delineated by real-world planar intersections with other roadways. With partners who use Arc/INFO, the short piece is may even be delineated at overpasses (3-D node in Arc 7.2). The short piece usually matches available address ranges, which also affects delineation. The long piece is most often referred to as a ?route? and may be a publically numbered and posted route or named street, or an internally numbered ?inventory route? (or linear referencing route or GIS route). In the USGS model, a long piece (route) can be composed of one-to-many short pieces, and any one short piece (road segment) can be part of zero-to-many long pieces. My current understanding is that an anchor section is different from either of these two kinds of roadway pieces (road segment and route), but they all may share some of the same representational geometry or spatial primitives.

Another area of interest is the relationship of the linear datum and the FGDC content standard for transportation suggested by Kevin Backe of the Corps of Engineers and the FGDC Facilities Working Group.

During our Technical Group discussions of making transactions to update linear datum coordinate values and lengths with better measurements, we made reference to the FGDC?s Feature Maintenance workshop last year in Kansas City. There is not a report from this workshop on the web, however the individuals who attended the Kansas City meeting indicated that there was expectation of an updated report from Hair, Timson, and Martin of USGS on feature maintenance. I will check with George Timson about the status of this report.

RELATED WEB SITES -

Public Sector ITS Datum Requirements Workshop, Knoxville, March 1998

http://itsdeployment.ed.ornl.gov/workshop/ITSDatum.html/

Oak Ridge ITS

http://itsdeployment.ed.ornl.gov/spatial/

ITS Glossary

http://www.ncgia.ucsb.edu/vital/glossary.html
 

FGDC Framework Transportation Workshop at Wrightsville Beach

(including proposed levels of anchor point density on pages 35 & 36)

http://www.fgdc.gov/Framework/page04.html

then select report or summary of Road Data Model Workshop or go directly to

http://www.fgdc.gov/Framework/rdmw/199712Workshop.pdf

Proceedings of the ITS Datum breakout group on Technical Issues from Val Noronha, 3-19-98

(with post workshop information on the linear datum that is or is not planar or topological)

http://www.ncgia.ucsb.edu/vital/tys9803.html

North Carolina DOT linear referencing report from Geo Decisions

(see section 6.3 Common Linear Datum, fig. 19 data model, and fig. 26 LRS anchor section length updating)

http://www.doh.dot.state.nc.us/planning/gis/gis/newlinref/default.html

VITAL - Vehicle Intelligence Testing and Analysis Lab - UCSB

http://www.ncgia.ucsb.edu/vital

ERTICO (Intelligent Transport Systems - Europe)

http://www.ertico.com/index.htm

GDF - Georaphic Data Files (ITS data transfer standard)

(the ISO standard number for GDF is ISO/TR 14825:1996)

http://www.ertico.com/gdf/index.htm (new URL for GDF)

SDTS - Spatial Data Transfer Standard

(also known as FIPS 173, FGDC-STD 002, and soon ANSI NCITS 320:199x)

http://mcmcweb.er.usgs.gov/sdts/

ISO/TC 204

Transport Information And Control Systems

http://www.jhk.com/tc204/

ISO/TC 211

Geographic Information and Informatics

http://www.statkart.no/isotc211/.

SAE ? Society of Automotive Engineers

http://www.sae.org/

SAE ITS division

http://www.sae.org/TECHCMTE/gits.htm

SAE Map Database Committee

http://www.sae.org/TECHCMTE/mapdata.htm

Bureau of Transportation Statistics (BTS) GIS Program -

http://www.bts.gov/programs/gis/

Transportation Research Board (TRB) GIS committee

http://www.bts.gov/programs/gis/trb/

FGDC Ground Transportation Subcommittee (GTS)

http://www.bts.gov/programs/gis/fgdc/

National Cooperative Highway Research Program

NCHRP 20-27(2)

A Generic Model for Linear Referencing Systems

http://www2.nas.edu/trbcrp/2322.html

NCHRP 20-27 (3)

Guidelines for the Implementation of Multimodal Transportation Location Referencing Systems

http://www2.nas.edu/trbcrp/5d22.html

NCHRP 20-47

Quality and Accuracy of Positional Data in Transportation

http://www2.nas.edu/trbcrp/314a.html

US DOT ITS Joint Program Office summary

http://www.its.dot.gov/transi1.htm

Digital Geographic Research Corp. (DGRC)

http://dgrc.ca/

Mitretek

http://www.mitretek.org/business_areas/transportation/

Dueker-Butler GIS-T data model documents including

"A Proposed Method of Transportation Feature Identification."

http://www.upa.pdx.edu/CUS/

ISTEA II (big bucks)

http://www.fhwa.dot.dov/reauthorization/index.htm

CONTACT -

Charley Hickman -- Geographer

U.S. Geological Survey -- Rolla, Missouri

chickman@usgs.gov

http://mapping.usgs.gov/

http://mcmcweb.er.usgs.gov/