Transportation Networks in ArcGIS: An Alternative to Geometric Networks

<P>地址：</P>
<P><a href="http://gis.esri.com/library/userconf/proc02/pap0437/p0437.htm" target="_blank" >http://gis.esri.com/library/userconf/proc02/pap0437/p0437.htm</A></P>

<P>Al Butler
</P>
<P>This paper offers insight into how a geographic information system (GIS) can be created to serve transportation applications using ArcGIS and the Geodatabase. The use of object technology to create these products has a dramatic effect on how GIS applications and databases are constructed and used. The paper explores the creation of simple features that represent the logical and physical elements of a network and shows how they may be used to implement transportation data models. Several such models have been developed due to the present lack of an industry-standard approach. There are two "advertised" ways to model networks in ArcGIS. The first is to draw the map using simple features as a somewhat static representation of the network elements. The second is to take these simple features and construct a geometric network, one that includes topology derived from the position of its component features stored in a logical network. The production of the geometric network requires a "clean and build" process that must be done by a single user. There is a third way, one that uses simple features-or none at all-and the direct manipulation of non-cartographic logical networks. This network may include simple features and can be maintained by many users. No clean and build process is required, as the topology is not derived from cartography. Instead, it is stored as an attribute of each network element. New elements may be added by any user to explore alternatives to the base network. This approach allows simple graphical and non-graphical selection tools to be applied to the network dataset to extract subsets of the base network.</P>
<HR>

<H2>Introduction</H2>
<P>This paper offers insight into how a geographic information system (GIS) can be created to serve transportation applications using ArcGIS and the Geodatabase. The Geodatabase is a set of ArcGIS objects that store information within a relational database management system (RDBMS), including raster and vector map layer data traditionally stored in ARC/INFO coverages and computer-aided drafting (CAD) files. Geodatabase data objects are created and accessed through ArcCatalog and other tools, such as those in ArcMap. The use of object technology to create these products has a dramatic effect on how GIS applications and databases are constructed and used. </P>
<P>This paper focuses on network systems, particularly those presented by transportation infrastructures and services. It explores the creation of simple features that represent the logical and physical elements of a network and shows how they may be used to implement transportation data models. Several such models have been developed due to the present lack of an industry-standard approach. Indeed, some designers have concluded that the specific transportation model implemented depends on the view of transportation held by a particular user. For example, shipping companies, with a strong interest in pathfinding applications, may have different models from those of governmental transportation agencies, which may emphasize facilities management applications. </P>
<P>There are two "advertised" ways to model networks in ArcGIS. The first is to draw the map using simple features as a somewhat static representation of the network elements. The second is to take these simple features and construct a geometric network, one that includes topology derived from the position of its component features stored in a logical network. The production of the geometric network requires a "clean and build" process that must be done by a single user. </P>
<P>There is a third way, one that uses simple features-or none at all-and the direct manipulation of non-cartographic logical networks. This network can be maintained by many users and may include simple features. No clean and build process is required, as the topology is not derived from cartography. Instead, it is stored as an attribute of each network element. New elements may be added by any user to explore alternatives to the base network. This approach allows simple graphical and non-graphical selection tools to be applied to the network dataset to extract subsets of the base network. For example, a user may select only those roadways meeting a certain specification, such as facility type, number of lanes, or location. </P>
<P>It should be made clear that some of the contents of this paper are opinion and supposition based on published technical information, ESRI-issued guidance, and informal reports from early adopters. At this point, as initial deployments of a still-evolving product line are occurring, published user experience is scarce, which is a main reason for this paper's creation. </P>
<P>There are three basic object class types presented in ArcGIS documentation: class, coclass, and abstract. A coclass type can create new objects; e.g., records in a data table. A class type cannot directly create new objects but other classes can. Abstract class types are the source of class and coclass specifications. (Yes, the terminology is confusing. It gets worse; e.g., Object is an ArcGIS class and a general ESRI term for all classes that do not include cartographic data.) In this paper, coclasses and classes are shown as three-dimension rectangles, and abstract class are shown as flat rectangles, which is the same approach used by ESRI in its documentation. Differentiation between coclasses and classes is accomplished in this paper's figures by using an explicit instantiation relationship (dashed line with arrowhead). Object class names may be hyphenated or shown using a smaller font in order to fit the available space; these changes serve no other functions. Colors and shading used in ESRI publications have not been used here due to reproduction limitations. </P>