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.
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.
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.
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 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.
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.
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.
Object-oriented programs are typically described using a diagram following the principles of the Unified Modeling Language (UML).[1] UML diagrams generally illustrate object classes and their inheritances and relationships. According to the published UML Notation Guide, UML diagrams are "graphs containing nodes connected by paths. The information is mostly in the topology, not in the size or placement of the symbols." [2] In this paper, we will use static structure class diagrams from the UML suite of nine diagram types.
Figure 1 presents iconic notation for UML relationships and compares them to those used in an entity-relationship diagram (ERD). An entity is something about which the users want to retain or process information. An ERD shows entities as rectangular boxes and the multiplicity relationships (how many of this are required for one of that) between them are shown as lines with special terminus icons. An ERD has more of a data focus, while an UML diagram has more of a process focus. Since relationship line terminus icons in UML are used to illustrate many things, like inheritance and similar relationships, icons cannot be used for multiplicity relationships. Instead, multiplicity is illustrated on UML diagrams using numeric notations. Frequently encountered examples include "0..1" to mean one may exist, "1" or no notation to mean one must exist (a default value), "*" to mean any number may exist, and "1..*" to mean one or more must exist. Other symbols and notations may also be present in typical UML diagrams, but they are not needed to understand the Geodatabase diagrams presented in later sections. The multiplicity relationship notation of UML is shown in parentheses at the end of ERD explanations for the equivalents of that model notation.
![Figure 2. Standard UML notation used by Esri for ArcGIS and Geodatabase diagrams.[3]](p04372.gif)
Objects explored in this paper have their data stored in relational tables; therefore, ERDs may also be used to illustrate the Geodatabase structure. Indeed, the simplified UML diagrams used in most Esri publications looks a great deal like an ERD. Figure 2 shows the standard notation used in Esri ArcGIS class diagrams. On the left side of the figure is the standard ArcGIS UML diagram key without interfaces. It shows abstract classes using a flat rectangle, with coclasses and classes shown as 3D rectangles. All the lines and icons are standard UML practice. For example, Class is an instantiation of AbstractClass; i.e., invoking AbstractClass produces a Class object or instance. One or more Class instances must be associated with CompositeClass. (It is Esri practice to omit spaces and underscores from class names.) On the right side of the figure are two sample classes taken from the ArcInfo Coverage section of the Geodatabase model. All the labeled "lollipops" are interfaces. In this example, the normal UML practice of not repeating inherited interfaces in the subclass (FeatureClass) is followed. It is also possible that inheritance will be omitted in some diagrams by removing the included generalization connector. In such cases, the FeatureClass list of interfaces must include those of the parent class, Table.
A table is a collection of rows, each containing a common set of one or more columns. Each row is an object. The intersection of a row and a column is an attribute of the object stored for that column as a value. ArcGIS object class tables have several predefined columns, or fields, depending on the class, such as those needed to hold the primary key and a class subtype field. Users may add other fields when entity-specific object classes are created.
In general, Esri restricts the use of object class to mean a "type of table that stores nonspatial objects." Thus, objects, as defined in ArcGIS, do not directly have a cartographic aspect; i.e., there is no shape stored in the table. In ArcGIS, an object that includes a shape attribute is called a feature; i.e., is a spatial object. In practical terms, a feature requires more complex methods to address the expression of spatial objects on a map layer. More specifically, a feature class is "a table with a geometry column stored as binary long object (BLOB)[4] pages in a relational database." A feature class contains geometric elements (a.k.a., simple features) or network elements (topological features) in a coverage, shapefile, or Geodatabase structure. Geometric elements displayed in ArcGIS are contained in layers, so a feature class may also be called a feature layer when referencing what the user sees in ArcMap or ArcView.[5]
Tables and GeoDatasets are the two types of information that can be stored in a Dataset. A GeoDataset can contain raster and feature datasets, with the latter composed of one or more feature classes. Tables consist of fields, which can be indexed to speed record access. A feature class table will include a field called GeometryDef that describes the type of feature included in the class, and a field that points to the location of the geometric element that represents the class entity.
Like their shapefile counterparts, simple features do not operate under the "cleanliness" rules of coverages. However, an important aspect of the Geodatabase is the use of rule and relationship classes to affect the behavior of object and feature classes. Several types of rules can be defined. These rules can apply to object and feature classes to validate their members. Connectivity rules apply to edges and junctions, the primary objects used to represent network systems, as will be discussed in the next section. Attribute rules ensure that an entered value complies with the defined domain for a table column. Relationship rules may be established to enforce cardinality that implements multiplicity associations between objects and features.
With this brief foundation in the terminology and presentation required to understand the original and alternative ArcGIS structures discussed in this paper, we can now move to a review of current Geodatabase structures.
ArcGIS uses geometric networks consisting of features and their implicit connectivity to create systems with topological aspects. Some topological relationships are stored in the Geodatabase. Other relationships are provided using network feature class methods that allow ArcGIS to derive topological relationships when they are needed rather than store them in a table. This approach means that logical topology still relies substantially on cartographic elements and the implicit topology inferred from their position. For example, two lines terminate at the same cartographic coordinate and implicitly "connect" to each other when incorporated into a geometric network. However, this is only a temporary solution that is being modified in the object framework. Object classes are currently under development at Esri to explicitly store topological relationships in order to eliminate the present reliance on the quality of cartography. This paper will show one way to create such a structure before it is made an "out of the box" function of ArcGIS.
Figure 3 shows the ArcGIS object model for network features. NetworkFeature is an abstract subclass of the Feature class. Simple features are like shapefile records; i.e., they don't have topology. Network features, on the other hand, do have a form of topology based on implied cartographic connectivity. Network features are part of a geometric network, which is a form of a two-dimensional graph; i.e., a set of topologically related network feature classes. Two network feature types, junctions and edges, are provided, each of which comes in two subclass types, simple and complex. Edges are the links in a geometric network; junctions are the nodes. The logical network data model supports turns, which provide the rules for how one may move from edge to edge at a junction. Methods to utilize turns are not presently provided by ArcGIS. They are likely to be supported in a future release that provides explicit support for topological rules.
As Figure 3 shows, four recognized geometric network feature classes are presently provided: SimpleJunctionFeature, ComplexJunctionFeature, SimpleEdgeFeature, and ComplexEdgeFeature. Of these, all but ComplexJunctionFeature have out-of-the-box methods included in the ArcGIS toolbox. SimpleJunctionFeature has a one-to-many relationship with edges, although the data model supports unconnected junctions. An "orphan junction" feature class is used to maintain network integrity in the absence of explicit connectivity. The ancillary role field, a predefined column for both junction classes, stores an indicator as to whether the feature is a source or a sink for network flow. Sources and sinks are special forms of junctions and get an ancillary role field added to their attributes when they are created.
The distinction between simple and complex edges is based on their topological properties, the relationship of geometric features to logical network elements. Simple edges have a one-to-one relationship between feature and element. Complex edges have a one-to-many relationship between feature and element. Midpoint connections on simple edge features split the edge into multiple edges; i.e., they split the geometry and logical records to maintain the one-to-one relationship. This does not happen with complex edges, which split the topological records but not the geometry records.
A geometric network may have multiple feature classes fulfilling the same topological role. For example, signalized intersections and traffic circles serve the same topological role (i.e., connecting roadways) but may be represented by different feature classes. The several network feature classes form a Geodatabase dataset. Each feature class may belong to only one network. Therefore, if a roadway network is used to construct multiple networks-say, one for pavement management and one for bus routes-then the user will need to maintain two copies of the roadway geometry, one for each network. This practice may be necessary even if geometric network structures are not required, as noted in the next section's discussion of dynamic segmentation.
ArcGIS relies on geometric networks and a form of clean and build to construct "perfect" cartography for network operations. The cartographically derived topology is stored in a logical network, which is maintained in an UtilityNetwork or StreetNetwork object class, which is derived from the abstract Network object class through the process of invoking the NetworkLoader class. The logical network data structure stores the topological connections between edges and junctions in BLOB pages and is not directly accessible outside ArcGIS. Path tracing algorithms operate on the logical network with the results illustrated using the geometric network. Figure 4 shows the central logical network classes. A Network is instantiated by the NetworkWorkspace.
The logical network schema of the Geodatabase, shown in Figure 4, is based on a set of identifiers. ElementID (or EID) is a globally unique identifier for each feature instance in the network. UserClassID is an identifier for a feature class. UserID is the unique identifier of a feature instance within its class. UserSubID provides an identifier for the logical elements of a complex feature; a simple feature has a UserSubID value of zero. Logical network BLOB pages are built in chronological sequence, so extensive editing of a network's features over time will scatter them across the logical network dataset. From a performance perspective, these networks should be rebuilt from time to time.
Depending on the type of network being created, either an UtilityNetwork or StreetNetwork class is produced. At this time, only the UtilityNetwork class has additional functionality. The only interface added by the StreetNetwork class to those that exist in the abstract Network class is IStreetNetwork, the sole purpose of which is to denote that the class is not a utility network. According to Esri, a street network differs from a utility network in the nature of flow along edges: a street network has undefined flow while a utility network has directional flow. The interfaces added by the UtilityNetwork class consist of mechanisms to establish flow direction through the entire network, based on sources and sinks, and to set the direction of flow along a single edge member. In the latter case, the flow can be uninitiated, indeterminate, the same as the direction of digitization for the related geometric feature, or the opposite of the digitized direction. The public interfaces of the two Network subclasses may be used directly only to manipulate a logical network for which there are no geometric members. Otherwise, interaction with the logical network must be through the geometric network. This paper will show how to manipulate the logical elements directly without using geometric networks, even when geometric members exist.
The four stand-alone classes on the left side of Figure 4 are used to create a network. The NetworkLoader takes the simple features created as network elements and builds the geometric and logical networks. Building a network from existing cartography (Esri "simple feature classes," or Spatial Data Transfer Standard "elements") changes them to network features. For example, points become junctions and lines become edges. Multipart geometries, which are aspects of several cartographic features, cannot be part of networks in the present release. (Esri plans on supporting what may be a multipart geometry for divided roadways called CarriageWays.) Since multipart elements are not allowed, the network build process splits any that may be found into separate features (one for each path or point). Snapping rules control the construction of networks during the build process through the creation of geometric coincidence of edge endpoints. Complex junctions are not supported by the build process and, if used, must be added to the network using custom scripts after the network is built. Since the logical network is based on all network feature classes in a dataset, the number of classes should be minimized. Subclasses do not impose the same processing performance overhead, so "fat" feature classes are recommended by Esri.
Edge-junction and edge-edge rules may be specified for network creation and editing management; however, once any such class has an expressed connectivity rule, then all must have such rules-including the orphan junction class. Connectivity rules are checked after other rules are applied, like those defining attribute domains. Freestanding junctions are not presently supported in the connectivity rule tools. Connectivity rules do not survive dropping a network, and so must be re-specified each time. (Making a "save rules and restore" tool could be useful.)
Weights may be established at the time a network is built to store information that can be used in network tracing analyses. Weights are used to denote the cost of traversing an edge or going through a junction. Weights cannot be added after the network is created. Attributes from which weights will be constructed must exist as feature attributes before the network is constructed. The NetWeight class stores the actual weight data while the NetWeightAssociation class stores the application of weights to object classes. The NetElementDescription class creates network elements in the logical network that do not have geometric equivalents. This class provides read-only access to the properties of a network element. The related NetElementClass object provides access to the identifiers of objects participating in a network. Features may be removed from the network without being eliminated from the class by using weights and barriers, or by calling upon the DisabledState property. Weights are stored in the edge logical element and can be bitgate, integer, single, or double data types. A weight value of -1 means that an edge is impassible.
NetFlag and NetSolver subclasses are used during flow tracing operations and utilize the logical network and weight data. The primary data store for flow analyses is the EnumNetEIDArray. The TraceFlowSolver is a group of network analysis methods provided by Esri; users may create others. NetSolver allows classes to be disabled, flow barriers to be established, and filters and weights to be set prior to analysis. The TraceFlowSolver lets the user declare the origin and destination for path analysis, or declare an origin and then find all reachable edges and junctions.
The logical network stores connectivity data based on the adjacency and concurrence of geometric features, and may, in some applications, be used to store purely logical networks without geometric feature equivalents. Thus, the logical network stores a form of topology; i.e., element connectivity. Topology, however, as Esri refers to it in the context of the Geodatabase structure, doesn't yet exist. It is planned in the future to be a data construct that manages simple feature classes that share geometry. The approach will be similar in function to the coverage model, but will be more flexible. For instance, a feature dataset will be able to have more than one topology, which will be a set of integrity rules for one class or between classes. The planned topology relationships will be stored in the logical network. Two-dimension topology will be supported in what is expected to be an ArcGIS extension. Topology will continue to be stored in BLOB pages and will be accessible only through ArcObject interfaces.
Work is continuing as of this writing on the full definition of topology, integrity rules and flags, support for spaghetti digitizing, logical network structures, and enhanced network editing tools. This paper uses topology in a more traditional way; i.e., to mean the connectivity relationships between features. This kind of topology is implemented in the Geodatabase using geometric coincidence and adjacency, which is an expanded form of the explicit topology of coverages. Topology is used here in a purely logical sense and not a physical planar graph manner.
At this point, we know how geometric networks are constructed in the Geodatabase using out of the box ArcGIS tools. In the next chapter, we will cover the traditional structure of transportation network data.
The form of transportation data is determined by a sequence of federal data reporting requirements that resulted in the creation in the 1970s and subsequent years of a number of fairly standard data sets. The 1972 act reauthorizing federal aid for highways established a requirement for state reporting of highway data through the Highway Performance Monitoring System (HPMS). This system is based on unique roadway identifiers and one-dimension measurement mechanisms to locate major roadway attributes and minor roadway sample sections where data are collected. A later act established a related requirement for data from the states to create a National Highway Planning Network map using a defined data structure and roadway identifiers that are unique within each state. HPMS sample sections are to be identified within the new network structure.[6]
The one-dimension locations of roadway characteristics and elements are called field measures, which are typically stated in units of 0.01 or 0.001 mile. Some field measures may also be in meters, kilometers, or feet, depending on the application, and a typical transportation agency may have multiple field measure methods. Field measures are generally related to routes, which are roadway segments that typically extend across a county or a state, with measures starting at zero at one terminus and extending sequentially to the other terminus. Field measures usually increase numerically from west to east and south to north. These methods are generally called linear location referencing methods (linear LRMs) due to the linear nature of the real-world roadway and railroad features they represent. The most common form of linear LRM is called route-milepoint. The things located using milepoint measures are called events, and are either point events, which have one milepoint location reference, or linear events, which have two milepoint location references. Milepoint locations are frequently called event points.
An advantage to using the route-milelog approach is that reference posts or signs do not have to be maintained in the field. However, the "no posts" approach requires that the person in the field go back to the beginning of the route or to a known reference object to start measuring distance. The person in the field must also know where the route begins (e.g., state or county line) and the primary direction of the milepoint measures. A disadvantage of the route-milelog method is the burden of maintaining a historical record of changes to the roadway. If a roadway is realigned, all of the roadway beyond that point may suddenly have different milelog measures. As an alternative, any new alignment may be given its own route identifier and field measures.
Figure 5 shows how field measures and routes are typically used. The bottom section shows a roadway as it may appear on a map; in this case it is State Road 8. The top section shows the roadway as it appears in the transportation database. This is more than just a symbolic representation. It is also the traditional way in which state departments of transportation (DOTs) graphically represent roadways; i.e., as a straight-line diagram (SLD). The origin for milepoint measures on this example roadway is at the left end, as denoted by a black star. Intersections along this roadway are shown using white stars. The milepoint measures are shown next to each intersection on the SLD and are in units of 0.01 mile. The route identifier for the example roadway is RD3302.
Figure 6 shows a less common structure called link-node, with distances being specified as an offset from the origin node. Links may be combined to form routes or traversals, which may themselves utilize the route-milelog linear LRM. In the illustrated example, Road RD3302 in Figure 5 has changed to Traversal 3302, which has its own milepoint measures. The traversal is formed of three links, the endpoints of which are created from four nodes. Black stars represent intersections that were selected to serve as node locations, while white stars are other intersections. Beneath each traversal milepoint is an alternative linear LRM based on node-offset distances. The origin node number is combined with the distance of that event point from the node shown as a plus measure. Some states may also use minus measures. In all cases, some route or traversal designation must be recorded for link-offset measures as many nodes represent the intersection of more than one state road and users need to know which route/traversal the event point is located.
The node and link numbering systems shown in Figure 6 are illustrative of the common practice of link identifiers being a concatenation of terminal node identifiers. In this example, "33" is the numeric designation of the county. All nodes and traversals are numbered sequentially and uniquely within the county. By adding the county designation, these identifiers are also unique statewide. Virtual links may be established to bridge from the terminal node in one county with its logical equivalent in the next. This approach is especially useful when individual county maps are maintained. Alternatively, the coincident nodes may be combined into a single node with its identifier being the combined county numbers plus a sequence number.
The route-milepoint approach can result in a data structure with a separate logical table for each attribute. For example, one could be created for speed limits, another for number of lanes, etc. In order to find all the attributes for a section of roadway, something like a relational join must be performed. The use of links is generally motivated by a desire to provide atomic attribute values for block-length roadway segments, thereby eliminating this step. HPMS sample sections are a form of link node structure in that only one value. GIS, particularly the topological vector design of coverages, are well suited to the link-node data structure and to other applications that work at the street block level. With a link-node structure, a user can, for example, simply select a block-long polyline in ArcView and see all the attributes. However, the link-node structure often imposes its own restrictions, such as the inability to properly reflect the multiple values that may exist for such things as number of lanes, speed limit, and parking restrictions along the link (block). Because of its inherently denormalized data structure, link-node files are typically much larger than those associated with route-milelog methods, which is more amenable to normalized data forms. Both link-node and route-milelog methods will commonly exist in a single transportation agency. For example, route-milelog may be utilized for highway inventories and project management applications, while link-node is frequently used for traffic flow models.
A common measurement tool is the distance measuring instrument (DMI), which is a highly accurate odometer attached to a vehicle. Field measures are often derived by traversing the route in the proper direction with the user pressing a button as the vehicle passes a feature element of interest, such as the end of a guardrail, the location of a sign, or the midpoint of an intersection. Field measures for such attributes as functional class and speed limit are frequently derived from maps in the office.
Some agencies have sought to increase the accuracy of their measures by using survey instruments using the Global Positioning System (GPS) to collect field data directly in Earth coordinates. A typical application is to take continuous GPS readings as a vehicle drives along the roadway, with the centerline's location calculated as a lateral offset from the tracked path. While GPS has its place in defining the location of fixed works, it also suffers from a number of limitations that preclude its general replacement of DMIs and linear LRM field methods.
Because of the likely difference between derived offsets from a map feature and the real-world locations determined in the field using a DMI and other methods, GIS software vendors have developed data structures that store the field measures. Esri, for example, developed the PolylineM shapefile format for this purpose. A linear datum can be established to increase the accuracy of field measures. Taking the logical form of a link-node structure, a linear datum uses anchor points as nodes and anchor sections as links, as shown in Figure 7. This figure looks very similar to the link-node approach of Figure 6.
Anchor points have a unique identifier, a location description, and some type of Earth coordinate location as their only mandatory attributes. Anchor sections have mandatory attributes of a unique identifier, designation of terminal anchor points, and length. The anchor section follows the logical centerline of the roadway, with anchor points being located along that centerline. Anchor section length serves as a quality control check for the accuracy of linear LRM field measurements. The terminal anchor points may be supplemented by an intermediate anchor point in order to uniquely describe one of several possible paths between the two termini. The example anchor point and anchor section identifiers used in the figure are derived similarly to those for nodes and links in Figure 6. The density of anchor points is determined by the degree of positional accuracy desired; the greater the desired accuracy, the greater the number of anchor points needed. The ability to detect and correct measurement errors varies directly with the number of anchor points and inversely with the average anchor section length.
Anchor points, though, may be difficult locations to precisely identify and capture in the field as they are usually located on an abstraction of the road; i.e., the roadway centerline. Anchor points need to be tied to reference objects, which are physical locations a user can easily find in the field and on maps.[7] Reference objects could be anything that is not readily movable, such as a curb intersection, bridge end, traffic signal pole, or survey marker. This practice is illustrated in Figure 8.
To be valid, a datum must be tied to physical, real world locations that are unambiguously defined. This would seem to eliminate such field references as county lines and other jurisdictional boundaries since county line and city limit signs may not be properly and/or consistently placed. However, several state DOTs, for example, frequently require the origin of a roadway's linear measures to be at the beginning point of the road in the county. The reconciliation of these two needs is to tie the jurisdictional boundary to a reference object that is unambiguously defined; i.e., locate the boundary (and origin) as an offset from a reference point. The roadway is thus unambiguously tied to a datum-compatible location.
One or more anchor sections must be created to provide a geographic network reference for each roadway. Vonderohe and Hepworth (1998) provide a way to calculate existing measurement accuracy and how to determine the number of anchor points needed to reach a given level of accuracy.[8] It is important to note the difference between accuracy, precision, and resolution. Resolution is the closest proximity of objects that can be represented as being at different locations. For example, the Tennessee DOT roadway inventory uses a resolution of 0.01 mile (52.8 feet), which means that two objects must be at least half that far apart for measurement rounding to place them at different locations. Thus, this linear LRS has a resolution of 26.4 feet if one accounts for rounding to the nearest milepoint unit. Accuracy refers to the closeness with which a set of measurements approximates the true value, which cannot be absolutely known. Anchor points and anchor sections provide a way to reach a specified level of accuracy by controlling systematic error, but accuracy is ultimately determined by measurement methods. Precision refers to the repeatability of these methods. High precision means that all measurements for the location of a feature are numerically similar. Errors in measurement when precision is high can be corrected through a uniform adjustment that compensates for the method's systematic error. Errors when precision is low cannot be readily corrected by adjustment because random error is much larger than systematic error.
An increase in the density and location precision of anchor points results in an increase in linear LRS measurement accuracy. The overall accuracy of the linear LRS is limited by the precision of linear offset measurements from anchor points to locations of interest along a transportation feature. Measurements made with distance measuring instruments have errors that increase with distance; i.e., are said to propagate. Anchor point accuracy requirements should be determined by looking at both the needs of users and the ability of available field procedures. A multimodal linear LRM datum must meet the highest accuracy, precision, and resolution requirements of any modal database and application it is intended to support. Applications requiring lower levels of spatial and temporal accuracy and precision can utilize resolutions expressed with fewer degrees of certainty. For example, if the production of county highway maps is the desired "highest use" of the data, then the largest scale at which roadway features may be mapped is perhaps one inch to one-half mile and working positional accuracy is, say, plus or minus 66 feet.[9]
Of course, one primary objective of transportation GIS is to put data in the proper location on a map. For this to happen, a means must be provided for GIS software to traverse a polyline or similar linear feature and properly locate point and linear events. This means is commonly called dynamic segmentation (dynseg). Dynseg operations utilize field measures to subdivide linear geometric objects representing roadways, waterways, or railroad tracks to produce thematic maps. Dynseg works by straight-line interpolation and compensates for some mapping "errors," such as those induced by elevation or inaccurate base map geometry. Maintaining the principle that one geometry record must relate to one attribute record, dynseg software cuts the base geometry of the route into segments that correspond to the field measure extents of each applicable event record. The attribute records must typically be scrubbed in advance of dynseg in order to identify and correct unintended gaps and overlaps in continuous attributes; e.g., speed limits, pavement type, and functional class, for which there should be only one value on each segment of roadway. Thus, the practice of "clean and build" applies both to the geometric network and the attributes stored in external legacy data systems.
Dynseg subdivides a line to create segments defined by attribute table records, or to place points along the line that correspond to a specified location in the attribute table. Dynseg is analogous to a spatial join between the original cartography and the attribute table. Whether the data structure is that of a coverage, shapefile, or Geodatabase, the basic operation is similar. In addition to storing vertices as x, y, and possibly z values, the base geometry must also store vertex field measure values (m). The measure values are determined by field methods normally involving an automobile outfitted with a distance-measuring instrument (DMI). Measures relate positions on the cartography with relative positions found in the real world.
Initially, there are likely several attribute table records for each linear feature. Dynseg software traverses the geometry, inserting new vertices where required, to construct the features that correspond to the attribute table linear event extents, or to place point event symbols at the proper locations on the roadway centerline. When the dynseg process is completed, the one-to-one relationship required for attributes and representative geometric features is established. As shown in Figure 9, it is possible to join the multiple route-milepoint attribute tables to create a result set that corresponds to the roadway segments that atomic values across all attributes. In the end, then, a normalized route-milepoint data structure can ultimately look like the link-node structure for mapping applications.
Figure 9 also implicitly introduces the concept of left- and right-side attributes. Like the complete chain of the SDTS topological vector profile and the structure of arcs in coverage files, roadway centerlines may also have left- and right-side attributes, particularly where it is a divided roadway with a median. The approach for recording left- and right-side attributes shown in the figure is atypical but representative. More typically, a database will be designed to either contain two columns for all attributes, with the single value for an undivided roadway segment being always placed in one column. Alternatively, a separate column is used to state whether a value is for the right side, left side, or both. In both cases, data integrity rules are typically implemented to force all attributes that are side-dependent, such as pavement type, roadway width, and speed limit, to be recorded consistently. Other integrity rules may enforce a requirement for a median value to exist for all roadway segments with attributes recorded as right and left values.
The implementation of dynseg in the ArcGIS product is purely geometric, as would be expected. The network features that may be used to represent transportation facilities do not add anything to the operation of dynseg functions. Thus, ArcGIS dynseg methods do not require geometric networks as they operate on one feature instance. Figure 10 shows the ArcGIS objects involved in dynseg.
The first aspect of the ArcGIS dynseg model that should be logical and expected is the derivation of the RouteEventSource from the FeatureClass object. The objective of dynseg is to create features that correspond to attribute record extents based on the route-milepoint measure system. RouteEventSource is the feature version of an event table that drives the process. Events are the characteristics and elements of the linear transportation facility being processed. A characteristic is some aspect of the facility itself, such as how wide the pavement is at that point and what the speed limit may be. An element of the facility is a physical thing itself, such as a sign, guardrail, or a bridge. An event table is one that includes a route identifier column and at least one measure column for a point event table, two for a linear event table. The route identifiers must match those in the dataset and the measures must fall within the defined domain for each route. An event is stored as a row in the event table. A RouteEventSource instance is created by the RouteEventSourceName object. The RouteMeasureLocation classes provide a means for the user to describe the position of a point or linear event.
The contents of each event table are described in the RouteMeasurePointProperties and RouteMeasureLineProperties object classes, as appropriate for the type of event(s) included. The IrouteEventProperties interface provides the tools to define the route identifier field and the measure units used. The interface also allows a lateral offset field to be identified that can be used to position events to the side of and parallel to the route. A basic requirement is to set a flag field that says whether the event is point or linear in nature. Once this has been done and the appropriate object instantiated, either the "from" and "to" measure fields (for a linear event) or an "at" measure (for a point event) must be defined.
While the results of dynseg are the RouteEventSource features, Locator objects actually do the dynseg work. The RouteMeasureLocatorName object instantiates the RouteMeasureLocator object required to perform dynseg. To instantiate the object, RouteMeasureLocatorName must know the polyline feature class that will be used (it must have measures), the route identifier field name, and measure units. Two useful options are available. First, if the values in the route identifier field are unique (i.e., there are no duplicates), then the RouteIDIsUnique flag can be set to True to speed processing. Second, an SQL where clause can be defined as a string of characters for use in selecting features to process; e.g., a clause like, "WHERE routeID = 143," would select only those records for the indicated route.
The source feature dataset can be a coverage, a PolylineM shapefile, or a Geodatabase polyline feature class with measures. To support dynseg in a Geodatabase dataset, the Workspace-Factory will need to have GeometryType = EsriGeometryPolyline, HasM = True, and a spatial domain for the m values (overall maximum and minimum values for the SpatialReference property). The measurement units (map units, meters, miles, etc.) are defined separately. The geometry starts with segments, which are either straight or one of various mathematically constructed line types. Each segment has two defined end points stored as a set of four fields in a shapefile structure (x, y, z, m) or five fields in a Geodatabase structure (x, y, z, m, ID). (The Surveyor Analyst extension is reported to require the additional point ID field.) Segments are combined to create paths and one or more paths form a polyline. Geometric network edges may only have one path for each polyline. (The same is true for polylines used in dynseg.)
Figure 11 shows the basics of dynseg operation. The upper shape is a polyline consisting of one path composed of 10 segments defined by 11 endpoints that represents Route 1037. The table to the right shows the measure values stored for each vertex (the values for the other 3-4 fields have been omitted). The bottom two shapes are the result of applying the event table for number of lanes, which produces two event polylines presented as instances of RouteEventSource. The two resulting features were created by RouteMeasureLocator, which interpolated the new vertices needed to represent the end of the first event and the start of the second. The created features are part of a new feature layer; the original polyline is unchanged.
Although measures are stored at the segment level in the polyline structure, the primary means of interacting with them are through three higher-level interfaces, IMAware, IMCollection, and IMSegmentation2. (IMSegmentation still exists following Esri practice to support earlier object versions, but it has been effectively replaced by IMSegmentation2, which provides more methods.) IMAware essentially provides a flag that tells ArcGIS that the geometry elements include measures. In such cases, set MAware = True. IMCollection performs such functions as identifying the minimum and maximum measure values and performing some mathematical operations on measure values. IMSegmentation2 provides numerous ways to edit polyline measures. ArcGIS wizards are available to aid the user in utilizing these objects.
There is no requirement for measure values to increase across a polyline element. Until a polyline element has stored field measure values, each m value will be set to NaN (an Esri abbreviation for "not a number"). Although topology is not stored in polyline files, they must be internally consistent as to the topology of vertices within the line. Esri says that "a topologically correct polyline is known as 'simple'."[10] Polylines that will be used for dynseg work must be "network simple." The IPolyline::SimplifyNetwork method makes polyline files suitable for dynseg by:
1. Removing zero-length segment and empty path records;
2. Ensuring adjacent segments are properly oriented end-to-end geometrically (ToPoint of one is connected to the FromPoint of the next);
3. Creating a new path for any discontinuous segments or segments with different attributes (each path can be composed of only continuous segments);
4. Merging parts where two paths share an endpoint (producing a longer path and reducing the number of path records); and
5. Correcting obvious spatial data gaps; i.e., where one of the two coincident endpoints of adjacent segments lacks a data value, it will be copied from the other endpoint).
The Add Route Events dialog is provided in ArcGIS to create geometric elements corresponding to attribute table records (events) on polyline features, thereby creating a new feature layer. Multiple event-based feature layers may be created and then operated upon to conduct spatial analyses. For example, a feature layer constructed from a table of speed limits can be unioned with another feature layer constructed from a table of pavement types using a line-on-line overlay to produce a third feature layer containing the spatial join of both inputs. Alternatively, these tables could have been joined external to the ArcGIS environment then the result used to build a single event-based feature layer.
With the addition of a lateral offset column, elements like guardrail and signs may be shown off to the side of the roadway polyline. In fact, it wouldn't take too much programming to use the presence of left- and right-side values and the lateral offset function to produce parallel polylines to illustrate divided roads more realistically.
The RouteMeasureGeoprocessor supports the actions of dissolve (removes overlaps), concatenate (leaves overlaps), overlay, union (OR), and intersection (AND) on polyline elements. This is an alternative to doing the joins first, then running dynseg on the resulting multi-attribute table. However, it is really a more versatile tool than that use would imply. RouteMeasureGeoprocessor is much like the polygon overlay tools in that it allows spatial operations, such as line-on-point and point-on-point operations. The example in Figure 18 shows coincident vertices for the ToPoint of Event 1 and the FromPoint of Event 2, but there is no requirement in ArcGIS for this to be the case. The events may produce gaps and overlaps, either through design or data error. RouteMeasureGeoprocessor could be used to look for line-on-line overlaps in the event feature layer that represent data errors where what should be two spatially unique events include part of the same roadway section. Similarly, RouteMeasureGeoprocessor could be used to compare the original polylines to the event feature layer to find gaps in the data; i.e., where no overlap existed. The available concatenate and dissolve methods may be useful in repairing dynseg features produced by event tables with gap and overlap errors.
For ArcGIS to work with legacy Route System coverages in performing dynseg operations, their contents must first be converted to a suitable polyline features. This is done by using the coverage's Route System feature attribute tables to construct an equivalent polyline for each Route Attribute Table record. Only the attributes stored in this table are attached to the resulting polyline feature; the attributes in the Section Attribute Table are lost.
The next service pack for ArcGIS reportedly will include dynseg operators for polygon elements, probably using something similar to the PolygonM shapefile structure. Additional information regarding dynseg operation in ArcGIS can be found in the referenced sources listed in footnotes, such as Linear Referencing and Dynamic Segmentation in ArcGIS 8.1, May 2001, and in the Geodatabase Supplemental Diagram.
GIS software vendors recognized the difficulty of relying solely on third-party file format translators and public file transfer profiles like those offered by the Spatial Data Transfer Standard (SDTS). As an alternative, they began to offer native integration of competitor's file formats. For example, an ArcView extension was provided by Esri to read AutoCAD and MicroStation file formats as a means of allowing cartographic data sharing. Several GIS researchers recognized the need to also exchange non-cartographic data. The proposed National Spatial Data Infrastructure (NSDI) transportation feature identification standard is intended, in substantial part, to meet this need. [11] However, more work was needed since uncoordinated GIS-T development efforts typically occur in multiple divisions of federal, state, and local transportation agencies. The only realistic solution is to adopt an enterprise approach to system development, particularly with regard to database design. Such an approach is facilitated in transportation agencies that have adopted a standard linear location referencing system, thereby providing a spatial foundation for combining data stored as network events using identically measured linear LRM locations.
The object models developed in NCHRP 20-27(2) [12] and 20-27(3) [13] were efforts to create a broader foundation for GIS-T. A user can certainly utilize the models as a guide, but it will be necessary to make a set of process choices and do lower level database design work using ERDs and similar tools to design the desired system. James Greetham of Bentley Systems, Inc., demonstrated this requirement at the 2001 GIS-T conference in Session 7.1.2, Distributed Object Model and Its Relational Storage Model for Transportation System Features (unpublished). The situation is analogous to building kitchen cabinets during new house construction. The architect draws a basic outline on the floor plans to show where the cabinets go. Later, the cabinetmaker prepares the more detailed drawings necessary to actually build the kitchen cabinets. In the same way, the Enterprise GIS-T data model [14] was developed to convert the other, more abstract models, to a form that could be directly implemented.
In a structure similar to that of the 20-27(2) model's Linear Referencing Method, the Enterprise GIS-T data model says that events occur on transportation features, adopting the original meaning of the two terms. A transportation feature is an element of the transportation network and may be in the form of a point, line, or area. An event is a characteristic or element of a transportation feature. The location of events is defined by one or two event points, which store the field measure determined by applying the appropriate LRM. Figure 12 shows this portion of the Enterprise GIS-T data model using an ERD.
The Enterprise GIS-T data model was designed for practitioners building real systems. Since the theoretical structure of a relational table to store activities, experiences, and attributes of transportation features is identical in a normalized schema, the Enterprise GIS-T data model puts them all together in a single Event entity. An Event happens at one place ("here" or "along here") on one or more Transportation Features (Intersection is the only event type that happens on more than one transportation feature). In all the published sample implementations, each included attribute, characteristic, event, or experience is separately stored in a common table.[15]
An important consideration is what defines a transportation feature. In all the examples discussed thus far, it was always assumed that the transportation features were linear in nature; e.g., roadways, waterways, and railroads. For instance, the NSDI proposal suggests:
"The appropriate FTSeg length represents a tradeoff between maintaining information on a large number of short segments, and potential errors introduced by measurements over a long linear segment. This standard prohibits segments which span boundary lines of states, territories, or equivalent jurisdictions. Transportation data authorities within a particular geography will need to assess whether more restrictive guidelines regarding FTSeg length are needed to support common applications among various transportation database users within that geography."[16]
The Enterprise GIS-T data model also recognizes the importance of point-like features that represent the crossing or intersection of two or more linear features, plus other point and area configurations. Extensions of the basic model accommodate point, line, and area features that are not part of the transportation network. However, since the subject of this paper is the construction of linear networks in ArcGIS, these elements of the Enterprise GIS-T data model will not be covered here. That is not to say that area features are unimportant to constructing linear networks. In practice, many area features are converted to point and linear equivalents by linear location referencing system practices, as shown in Figure 13. In this case, an area feature representing an urban region is intersected with a linear transportation feature to produce three linear events. The alternative is to utilize four point events to represent the places where the transition occurs between urban and rural characteristics.
Figure 14 illustrates the transportation feature (left half) and topology (right half) components of the Enterprise GIS-T data model for linear features. As in the other models, linear LRM measures are used to locate point and linear events along a transportation feature. An intersection is a point event on each intersecting transportation feature. Area events are expressed as either a linear event for that section inside an area, or as a set of point events where the area boundary crosses the transportation feature.
On the topology side of the figure, segments are attributed links, with the chosen attributes depending on the application. This structure is designed to support pathfinding applications by storing the characteristics and elements of the transportation network as transportation features and their events. The connectivity of these network elements is stored in the topology of links and nodes. In a standard implementation, a node record would include the node identifiers of all adjacent nodes that could be reached by traveling a legitimate link. Various networks could be defined for different vehicle types. For example, buses may be able to make different turns at some intersections than may other vehicles. A traversal is a path through the network. Traversals are called static when based on a feature characteristic and dynamic when based on more complex criteria. A static traversal example is the one formed by all the segments with the same route number. A dynamic traversal example can be constructed by finding a suitable path for an oversized truck. Solving such a problem would require linear events for characteristics-number of lanes, pavement width, and load restrictions, height restrictions, and current construction projects-and roadway elements-overhead signs, bridges, and traffic signals. Traversal Segment is an associative entity since a segment may be part of many traversals and a traversal will likely consist of multiple segments.
Figure 15 shows the addition of cartographic entities and their relationships with the transportation feature entities. Assuming the exclusive use of linear transportation features, a single PolylineM shapefile object, for example, may be used as a base map object to represent each linear transportation feature. Dynseg software would select, stylize, and position the appropriate point symbol for a point event, or cut out the correct line segment for a linear event.
The cartography could instead be related to the topology entities, as some states have done. Such an approach is not generally recommended due to the large number of very short segments that result, assuming most intersections are modeled as nodes. Implementations may also integrate the topological and cartographic aspects of a network into a single entity, such as is the case with the complete chains of the SDTS's topological vector profile and ARC/INFO coverages. This level of integration will also be present in most implementations of networks in ArcGIS. Such integration can exact a significant performance penalty in some situations.
Several illustrative physical data models have been developed to implement the Enterprise GIS-T logical data model based on sets of business rules that are fairly common in state departments of transportation. Figure 16 (next page) shows one example. This approach uses a central Transportation Feature Table for all feature types with links to type-specific event tables. The samples included in Figure 16 are for roadways, rail lines, waterways, bridges, and traffic signals. A single type-specific table covers most transportation features, but roadways need three tables (Roadway, Event, and Event Type).
The externalkey field in the Transportation Feature Table is provided to support the NSDI transportation feature identification standard and is shown as a public key. (Other tables with a similarly named field refer to identifier fields within the figure.)
The Bridge Table has links to several other feature-specific tables to reflect the fact that the Bridge Table stores the identifiers of the features that go over and under the bridge as foreign keys. (It has been assumed that railroads and waterways only go under bridges, with bridges carrying railroads being outside the scope of this database.) Bridges and traffic signals have been treated as intersections, so they do not have a direct tie to the Transportation Feature Table. The Intersection Table uses intersectiontypeID to provide information regarding the feature type table to which the value of externalkeyID applies. This allows one Intersection Table to serve the entire transportation network, thereby supporting multimodal intersections. The Intersection Table includes eventID as a performance improvement mechanism to save a join for locating intersection features on the roadway network.
Each record in the Transportation Feature Table would be linked to one of the subordinate type-specific tables, all of which contain tranfeatureID as a foreign key. In this design, cartographic objects would be related to the feature-specific tables; i.e., Roadway, Airport Runway, Rail Line, Waterway, Bridge, and Signal. The Transportation Feature Table includes information on when the record is valid and who entered it. The table uses a complex primary key consisting of tranfeatureID, starton, and enteredon. This is one way to handle versioning. The starton field says when the feature, as it is presently configured, became valid. A matching retiredon field offers a place to store the date the feature was retired. The enteredon field allows the system to track corrections (starton stays the same but enteredon changes). To help find the most recent record, a latestFLG avoids the need to search through the date fields.
The beginmilelog and endmilelog fields in the Roadway Table apply to the entire length of the facility, with directionID providing a general cardinal direction for increasing milelog values. The only other sample field is roadstatusID, which tells whether the roadway is closed, open, or proposed. This list could be expanded to include other attributes that apply to the entire feature, such as which county in which it is located.
The Event Table contains starton, enteredon, and retiredon fields to record the temporal history of the event value. It also has the latestFLG field to quickly select the current records. The location of the event along the roadway specified by roadwayID is stored in the beginmilelog and endmilelog fields. Point events would have only a beginmilelog value. The sample design includes fields to record the side of road or a lateral offset distance from the road to an element of the roadway, such as a guardrail or a sign. (For a complete sign inventory, it may be better to create a sign table with the attribute identifier as a foreign key. The sign table would provide fields for sign type using the MUTCD code, sign size, color, installation date, and similar attributes of signs. The roadway attribute table would essentially only store the identifier and location of the sign.)
The look-up table Event Type is an example of how other such tables could be structured. It includes information on how to interpret the value field in the Event Table as well as domain information for error checking in data entry and analysis tools. The eventtype field stores a code value or abbreviation that may be used by some users plus the full text description of the type. The alphanumeric listorder field allows the database administrator to control the position of each record in a pick list.
This chapter has shown approaches that either suggested or used for GIS-T applications and data structures. The next section will talk about how Esri has implemented these ideas and others within ArcGIS.
Esri has been developing a set of industry-specific data models that provide additional guidance on developing applications using ArcGIS. These models are being built by special interest groups affiliated with Esri as a means of providing additional elements of an ArcGIS application. One such model is the one for transportation, called UNETRANS (from Unified Network for Transportation) being developed by the University of California at Santa Barbara (UCSB). The UNETRANS model utilizes network geometry and is based on simple junctions and complex edges.[17] Although the UNETRANS model for transportation GIS is expressed using Unified Modeling Language (UML) object-oriented programming notation, it is really a pure data model, not an object model. There are few explicitly defined relationship classes in most of the UNETRANS model, although a Relationships Package has been proposed.
UNETRANS is divided into seven object packages, or thematic groups:
1. Reference Network;
2. Assets;
3. Incidents;
4. Activities;
5. Routes and Location Referencing;
6. Mobile Objects; and
7. Relationships.
Each package includes various feature classes and subclasses; there are generally no described methods at this point in their development. The basic building block of an ArcGIS implementation for transportation, as expressed in the UNETRANS model, is the geometric network consisting of complex edge features and simple junction features, called the Reference Network Package, which is shown in Figure 17.
The basic UNETRANS-recommended approach is to segment linear transportation features at their intersections with each other in a "link-node" fashion, with ComplexEdgeFeature objects representing the links (transport segments) and SimpleJunctionFeature objects representing the nodes (intersections). Note that the network structure of UNETRANS is distinct from the use of dynseg functions, which may utilize the simple Polyline feature class with measures.
TransportEdge is an abstract class that inherits from ComplexEdgeFeature. RoutableEdge is an abstract subclass of TransportEdge. WaterEdge, Rail, BicyclePath, WalkingPath, CarriageWay, and Road are the names of included RoutableEdge feature subclasses. Transportation junctions are subclasses of the abstract TransportJunction class, which inherits from the SimpleJunctionFeature class. TransportJunction features must be of either the Station or Intersection class, both of which are further divided into various subtypes.[18] A Station may be a TrainStation, BusStation, or a Port [19] feature. An Intersection may be a Rotary, Cloverleaf, Brunnel, or FourWayStop feature. (The term 'brunnel' is a contraction of 'bridge' and 'tunnel', and means a place where two transportation features cross but do not intersect; they may, however, affect each other in various ways.) Stations represent locations where intermodal exchange occurs. Of all these SimpleJunctionFeature subclasses, only Brunnel represents a situation where true connectivity may not exist in the physical network.
Multiple representation of a transportation feature, such as at various levels of cartographic abstraction, is supported through foreign keys relating various RoutableEdge feature subclasses to each other. Departing from the norm for geometric networks in ArcGIS, the RoutableEdge subclasses include a multipart feature called a CarriageWay, so as to represent the two parallel paths of a divided roadway. Current UNETRANS documentation is silent on how to deal with the cross-median connections required for carriageway representations; conceivably, these would be SimpleJunctionFeature instances as if they were intersections. A lane-by-lane structure is supported logically in the Geodatabase but not cartographically. Because of the constraints posed by ArcGIS network geometry rules, there can be only one linear LRM for each feature class. Therefore, multiple linear LRMs on a single roadway, for example, will require the construction of multiple feature layers, one for each linear LRM. This will add some complexity to map editing processes due to the need to maintain cartographic concurrency.
The UNETRANS model ties the transportation feature tightly to its cartographic representation; i.e., the classes shown in Figure 17 are all feature classes. Object classes compose most of the remaining model elements. For example, linear LRM requirements are supported by a set of object classes. This appears to mean that the Route and Location Referencing Package is related to dynseg but is not sufficient to perform those functions. The source document states, "While the tables are described in this section [on the Route and Location Referencing Package], much of the analysis that people want to perform will require additional programming and/or software to achieve sophisticated results."[20] This is partly due to the absence of topological structures and linear measures at the route level.
The Routes and Location Referencing Package, illustrated in Figure 18 (next page), is intended to meet the needs of application designers to construct transportation systems over which MobileObjects may move and higher-level transportation features can be constructed, but it does not explicitly provide those features, such as routes and traversals. (The UNETRANS model does provide the RouteFeature subclass of the Feature class as a template for constructing feature subclasses for linear location referencing. RouteID, an attribute of the RouteFeature subclass, or TransportEdgeID can be utilized as a foreign key to provide a means of displaying the result of dynseg operations. Otherwise, dynseg presently appears to be outside the scope of the UNETRANS data model and its related object packages.) Within the Routes and Location Referencing Package, the TransportRoute object can relate route identifiers to the Road feature class (RoutableEdge subclass) through a RoutesHaveEdges relationship class provided in the Relationships Package. (See separate discussion, below.) A TransportRoute could be equivalent to a transportation feature and/or a traversal in the 20-27(2) and Enterprise GIS-T data models. An alternative is to create a relationship between the TransportRoute object class and a Polyline feature class. AnchorPoint and AnchorSection subclasses of the RouteFeature class are part of the Routes and Location Referencing Package.[21] These feature classes appear to provide the functions of their similarly named linear LRM datum elements.
Other objects provided by the Routes and Location Referencing Package include Stop, StopGroup, Turn, TransportSchedule, TransportModeRestriction, and ODMatrix (OD is short for Origin-Destination), all of which are nonspatial. A Stop is a location along a TransportEdge defined by a linear measure. A StopGroup is a cluster of nearby stops and may be logically equivalent to a Station. A Turn instance describes a movement at a designated TransportJunction, as defined by a paired relationship stated as movement from one TransportEdge to another TransportEdge, with attributes to store day of week and time of day for application. A single intersection is likely to require many Turn instances. (There is no functionality within ArcGIS at present to utilize turns as pathfinding is not an inherent capability of the product out of the box.) A TransportSchedule provides a chronological ordering of Stops into a path, such as to represent the stops along a bus route. A TransportModeRestriction provides an additional way to weight movements along specified TransportEdges for particular MobileObject types, such as to prohibit all but transit vehicles. (TransportEdge already includes a general weight in its RouteableEdge subclass.) An ODMatrix stores the group of origins and destinations across a network for pathfinding and traffic modeling. All are point or linear events that may be positioned along TransportEdges or at a TransportJunction using linear measures defined within the relevant RouteFeature.
Four of the five remaining defined packages-Assets, Activities, Incidents, and Mobile Objects-are also collections of linear and point event objects referenced to locations on TransportEdges or at TransportJunctions. Assets, Activities, and Incidents may relate to points, lines, and polygons, with polygonal features requiring the construction of separate elements as they cannot be directly related to TransportEdges and TransportJunctions. Since these are all objects classes, the described subclasses do not include geometric elements even though they are called by such names as AssetPoint and ActivityLine. Relationship classes would have to be constructed to actually link these objects to their corresponding Reference Network and/or simple PolylineM feature classes. The Activity and Incident packages do include feature classes to illustrate polygonal instances. (Polygons are not included in the basic Reference Network package at this time.) Although it is logical to expect some applications to require the physical display of MobileObjects using a tracking object feature, this approach is not explicitly addressed in the UNETRANS model.
It is important to understand the structure of data within UNETRANS objects compared to their structure within typical legacy route-milepoint and link-node databases. A typical route-milepoint data structure will have one table for all feature characteristics and elements, whether they are point events or linear events. In general, the first step required to utilize these data is to sort out the various data by type. For example, the user may first select all records that include values for speed limit, pavement type, and number of lanes, placing them into three separate files or tables. The next step might be to join them together to produce a set of roadway segments with speed limit, pavement type, and number of lane as three attributes in a single table. (See Figure 23, p. 37 for an illustration of this process.) A legacy link-node data structure also often has a single table for attribute data, but the network is divided into numerous small pieces, frequently just the links, which have one or more fields for each defined characteristic and element attribute. Occasionally, a link-node structure will provide a route-milepoint appearance in that it is normalized within each link, but this approach is rare.
The Assets Package serves as a good example to show how ArcGIS and UNETRANS are used to do the same operation. This package consists of only four object classes, but these few classes are the heart of the UNETRANS data storage mechanism for roadway elements. These elements are physical components of the transportation feature, including such things as pavement, bridges, poles, and traffic signs. The UNETRANS Asset package includes an abstract Asset class and two instantiable subclasses, AssetPoint and AssetLine. The choice of which subclass to utilize is based on the representative form selected for the asset. Some assets may have more than one form. For instance, bridges may be represented by points (AssetPoint) or lines (AssetLine) located along a linear feature using measures, or as a discrete polygon (AssetPolygon, a Feature subclass. (ArcGIS does not presently support measures for polygons.) Potential, all three forms could exist in one agency.
The AssetPoint and AssetLine object classes, plus the AssetPolygon feature class, have a number of defined subtypes. TollBooth is a subtype of AssetPoint, while Sidewalk is a subtype of AssetLine. Airport, RightOfWay, and TrafficAnalysisZone are all subtypes of AssetPolygon. Various attributes may be defined as extensions to these Asset Package objects and features. AssetPoint and AssetLine instances can be used to create events and be run through the dynseg process with the base linear transportation features to generate features that correspond to the extent of the assets.
Characteristics may be added to any feature or object class in UNETRANS and other elements of the Geodatabase. With the implementation of transportation and other network structures within the Geodatabase taking a decidedly link-node form, the typical geometric network will have numerous relatively short segments. Thus, characteristics for route-milepoint legacy databases will have to be applied by joining the extent of ComplexEdgeFeature instances and the transportation feature characteristics, as they are stored in the legacy database. Making the extent of each ComplexEdgeFeature a linear event in the legacy database can do this.
The Relationships Package is introduced in the UNETRANS model and related white paper but is not discussed there.[22] A general review of Geodatabase relationship classes and the UNETRANS model will reveal their general function. This package may eventually include the expected relationship classes and the functions of the planned Topology classes. It presently has one many-to-many relationship class, RoutesHaveEdges. The RoutesHaveEdges relationship class ties TransportRoute objects to their representative features. The Relationships Package model shows StreetName, AddressRange, ActivityPoint, ActivityLine, Road, and TransportRoute objects and the Road feature class. All classes are involved in relationships, such as "Road Has Address Ranges," "Road Has Line Activities," and "StreetName Has Roads." StreetName and AddressRange are not discussed in the documentation except for StreetName to be defined in the glossary as a type of Asset applying to part or all of a TransportEdge.[23]
ArcGIS with UNETRANS offers two approaches to mapping transportation features and their attributes. The inherent ArcGIS dynseg functions provide support for route-milepoint data structures, while the UNETRANS packages offer an alternative link-node structure. There is another significant difference between these two approaches: The routes provided in out-of-the-box ArcGIS do not support any type of network functions. Otherwise, the features themselves vary only in length. In the route-milepoint approach, linear features represent routes that typically extend across counties and states. Routes are then subdivided by dynseg to produce the shorter segments required to illustrate attributes. In the link-node approach of UNETRANS, the basic linear features are more typically one block in length. These short features are combined to produce the longer segments required to illustrate attributes that typically span several blocks, such as pavement type and speed limit, using a simple SQL Select statement. Inherent in the choice of these two approaches is the adoption of a normalized or denormalized basic data structure at the route level.
An obvious third approach is "both." A single agency could use each approach for the applications to which it is best suited. While building on the benefits of each, this alternative also amplifies their negative aspects. For example, Esri strongly advises its users the old approach of storing attributes in an external database is very inefficient with the new Geodatabase structure. Dynseg is, most applications, the process of applying external data to a set of features. It is, therefore, a relatively time-consuming, CPU-intensive process that Esri recommends not be done "on the fly" with large datasets in response to a user request. This leads to a general approach of dynseg pre-processing and storing the results for later use, an approach not altogether different from using the predefined UNETRANS objects and their extensions. Of course, the short features used in UNETRANS can themselves be subjected to dynseg operations using external attribute datasets.
The consideration of these various ArcGIS approaches is significant in the process of designing a GIS-T application. So, too, is the feature-maintenance overhead imposed by multiple cartographic representations. ArcGIS does not presently support the easy decentralization of geometric network construction. The source simple features from which the network is built can be maintained in a decentralized organization where multiple users in potentially different locations may edit the features within their scope of coverage. However, the process of cleaning and building the geometric network must occur in a single operation. There is also the consideration of replicating changes through all the pre-processed dynseg results and UNETRANS objects. Enterprise deployment of ArcGIS in larger agencies will require the balancing of the agency's ability to support the maintenance overhead with the user community's need for cartographic data.
Presenters at the Esri User Conference stated that the company is presently working on accommodating GPS data and distributed layer maintenance for geometric networks, and plan to provide a map symbology template approach for map layer rendering. Where presently time stamp attributes are supplied in several features and objects, complete temporal objects may be available in the future. The UNETRANS model will likely split into a core version and multiple extended versions to address the needs of specific transportation industry segments, like asset management at state departments of transportation, bus routing in transit agencies, and logistics in the shipping industry. The complete UNETRANS model is expected by the end of 2001.
While the previous generation of transportation agency management software was almost always custom built for each agency, the present trend is to adapt commercially available software. It is likely that robust GIS software will remain a toolkit rather than a complete application for a long time. Some level of integration, customization, specification, or extension is always required. This is no different than trying to construct a financial model using spreadsheet software. The software provides the model framework, but there is still a lot of work to do. So, the question may not be how to implement the independent models from scratch but how best to use their concepts within existing commercially available GIS products.
Realistically, the choice of a cartography implementation platform may be limited to one of the few products that support dynseg, such as Esri's ArcGIS. The data components can be either the attributes these products already include, extensions to these standard attributes created using provided tools, or an external database management system that supports spatial operators, such as Oracle or Informix. These are not purely mix-and-match choices as there are limitations. For example, Esri's tools do not natively work with files built using Oracle's LRS Extension to its foundation Spatial Data Option (SDO) as they store the coordinates and measures differently.[24] To use Esri network mapping editors, it is presently necessary to use the compressed binary (BLOB) implementation of SDO, or to batch translate the files from one format to the other. A spatial editor for LRS Extension objects is not presently available.
One currently available approach is to utilize the ArcGIS TransportEdge, TransportJunction, and TransportRoute feature classes, but not the rest of the UNETRANS product line, plus a database design along the lines of that shown in Figures 36-37 that would replace the objects offered by the Assets, Incidents, and Activities packages. Alternatively, it may be preferable today to use the simpler Point, MultiPoint, and PolylineM shapefile structures with ArcView 3.2 or 8.1 serving as the editor and a Transportation Feature database held in Oracle, with or without ArcSDE and/or SDO. Such a system could readily migrate to another product line at a future date-after the technical issues of compatibility have been resolved.
An important element of any implementation is to have knowledgeable people involved who know the product lines being used, understand the various business models implied in the commercial products, grasp the concepts of the various data models, and see how to implement the desired elements of these models within the commercial platforms being used. One way to do this is shown in the next chapter.
All the ArcGIS network data models addressed in the preceding chapters have been geometric networks. This means they involve cartographic features that have associated logical network elements stored in separate objects. In this chapter, another method for dealing with logical networks will be described, one using simple features and direct manipulation of multiple related logical networks. This approach will be especially applicable for agencies that are decentralized, such as state DOTs. The ArcGIS and Geodatabase objects, methods, and properties implemented by Esri through Version 8.1 were designed for utility networks modeled using a geometric network. This chapter will focus on providing an alternative to geometric networks for supporting a number of network modeling applications.
There are several reasons a user might want to build a network-based application that does not include geometric network features:
1. The simple features from which networks might be built may be maintained in an uncoordinated manner, as may be the case with multiple districts in a state DOT maintaining the portions within their jurisdiction. Replication of these features throughout the organization may take some time.
2. The construction of geometric networks is a centralized function; i.e., only one person can construct a geometric network from simple features. In a decentralized organization, there may be a need for many people to construct networks, including various versions of a shared network.
3. Networks may exist at various levels of abstraction. Some networks may include aggregates of multiple physical entities, such as where two adjacent one-way streets are generalized to a single two-way segment in a traffic model. Requiring a cartographic equivalent for every network element creates a significant workload.
4. The basic segmentation of transportation features is often not directly compatible with the block-by-block approach required by ArcGIS and UNETRANS. Some existing products, such Highways by Exor, are not directly transferable to ArcGIS.
5. Statewide summaries are often created in state DOTs that require a "snapshot" view of the transportation network. Versioning of a network may be necessary, but this process is not supported by ArcGIS.
6. Non-cartographic search mechanisms offer performance advantages. According to Esri, logical networks can be processed 200-10,000 times faster than geometric networks.[25]
7. The primary application may be the integration of attributes from non-cartographic data sources. It may not always be possible to find physical equivalents in a geometric network, as may be the case with historical data.
Esri provides a number of objects, interfaces, and associated methods to accommodate many needs for logical networks constructed without requiring geometric network features in the Geodatabase. All of these carry a strong caution in Esri documentation that they should never be used when an equivalent geometric network exists lest the network be corrupted. This caution does not mean that cartography cannot be included as there is no warning regarding the use of simple features. What it does mean is that a carefully constructed application can be used to create and edit logical networks without the overhead of geometric networks and while still preserving the ability to include cartographic representations.
Figure 19 shows the primary network objects provided in ArcGIS to create, edit, and delete logical networks and their member elements. (This figure is an expanded subset of the object classes shown in Figure 4.) The figure follows the established practice of having subtype classes include only the new interfaces they add to those of the parent. Thus, the NetworkWorkspace class implicitly includes all the interfaces of the parent Workspace class, and the StreetNetwork class implicitly includes all the interfaces of the parent Dataset and Network abstract classes. Interfaces listed with the "(optional)" qualifier may be inherited only by specific subtype classes; when they are, the interfaces are explicitly listed for the subclass. Since none of the optional interfaces is listed for the illustrated subtype classes, none is inherited.
Interfaces within an object class may likewise inherit methods and properties from another interface. For example, many "_Edit" methods include the read-only functions of companion methods. Where applicable, this chapter will list the parent method. Unless otherwise stated, all interfaces inherit from the IUnknown interface. The following paragraphs describe the object coclasses in Figure 19 and their important interfaces:
Workspace factories create workspaces within which data may be stored. Figure 19 shows the SdeWorkspaceFactory as instantiating the Workspace object; however, this is just an example. There are presently seven workspace factory types that accommodate the various data storage mechanisms supported by ArcGIS. These factories include those required for file-based systems (e.g., shapefiles and coverages), personal Geodatabases (Access), and multi-user databases accessed through ArcSDE (e.g., Oracle and SQLServer). The interface of interest contained in all these object classes is:
* IWorkspaceFactory - Provides methods that create and open workspace factories that contain data. The most important methods are Create and Open. An ArcGIS Edit session must be active in ArcGIS for logical network to be created or edited. A WorkspaceName object is used to get things going by defining a Workspace path name using the PathName property in the WorkspaceName object's IWorkspaceName interface. If the Workspace already exists, the next step is to open it with the Open function of the WorkspaceName object's IName interface. Alternatively, the IWorkspaceFactory::Open or IWorkspaceFactory::OpenFromFile methods could be used. If the workspace does not exist, it is necessary to invoke the IWorkspaceFactory::Create method to make it. This method returns the properties contained in the IWorkspaceName interface.
* IDataset - The main interface used to manage a dataset contained in the workspace. It can read and edit the browse (public) name of the dataset, delete and copy the dataset, and perform other functions.
* IDatasetContainer - Provides the means to create a dataset through its AddDataset function. (The dataset must first be specified through calls to the ObjectClassName object.)
* IWorkspace - This is the primary interface for getting information about workspaces. The included ExecuteSQL method is a potentially important one for dataset use as it provides the means to execute SQL statements against the workspace members, although result sets cannot be returned. The Datasets method will provide a list of the datasets included in the workspace.
* IWorkspaceEdit - Provides ways to start, stop, undo, and redo changes to the workspace.
Inherits interfaces from Workspace. The NetworkWorkspace object instantiates the Network subclass desired. It adds two interfaces to those offered by its parent class, Workspace. The one most relevant to this chapter is:
* INetworkWorkspace - This interface allows access to methods to create and open logical networks without a geometric network being constructed. The most important methods are CreateNetwork and OpenNetwork. Invoking the CreateNetwork function creates an empty network class. This function requires a network name, a network type, and a Boolean value indicating whether or not the resulting tables should be normalized. For a street network, the network type field (EsriElementType) has a code value of 0. A utility network has a code value of 1. An orphan junction class will be created by default. Once a network is created, the OpenNetwork interface is used to open the network with read-only or read-and-write access permission.
Inherit interfaces from Network and mandatory interfaces from its parent abstract class Dataset. ArcGIS supports two basic network types, utility and street. The difference between these, as noted in Esri publications, is that utility networks may have a defined flow direction while street networks may not.[26] Both the UtilityNetwork and StreetNetwork object classes are instantiable subtypes of the abstract Network object class. They add just one interface each to those supplied by the parent Network object class. Adding, editing, or deleting network elements is done using this object. The relevant interfaces are:
* IDataset - Same as for Workspace.
* IDatasetEdit - A Boolean property that indicates whether the dataset is being edited.
* IDatasetEditInfo - Contains three Boolean properties indicating whether the dataset supports undo and redo, and whether edits can be discarded when the dataset is saved. Called before an editing session begins.
* INetAttributes - Provides methods used to read a Boolean field indicating whether the specified network element is disabled and the value of a specified weight field.
* INetAttributesEdit - Inherits from INetAttributes. Offers methods for setting the disabled state (SetDisabledState) and storing a weight (SetWeightValue).
* INetElements - Supports methods that convert between user-defined element identifiers and element identifiers assigned by ArcGIS. It is the assigned element identifier (EID) that will be required for several interfaces, including the one that actually adds the new element to the network. The class identifier, the user-defined identifier, and the element type determine the EID. EIDs are stored in BLOB pages and are spatially clustered when created during the geometric network building process; they are otherwise ordered by creation time. The EID for a network element can be found using the GetEID method and specifying the element type and two-part, user-defined identifier. (It may be necessary to first get a count of EIDs by invoking the GetEIDCount method. If the answer is greater than one, then use the GetEIDs method instead of GetEID.)
* INetSchema - Offers a number of functions and properties that provides information about the network structure. This information includes the number of element classes, weights and weight associations, ancillary role types and the fields in which the data are stored, and name of the table field associated with disabled/enabled state values. The class identifiers for participating network elements is found by invoking the INetElementClass interface of the NetElementClass object, which can be obtained by using the INetSchema interface and its ElementClass or ElementClassbyUserID method. Most properties are actually provided by interfaces included in other object classes.
* INetSchemaEdit - Inherits from INetSchema. Provides methods that modify the present schema of a network. The AddElementClass method has the means to introduce a new element class to the network. Other methods set the properties that can be retrieved using the INetSchema interface.
* INetTopology - Offers the means of discovering adjacent network elements for an element specified by EID. GetFromToJunctions will retrieve the terminal junction EIDs for a specified edge; there are always two. A junction may terminate multiple edges, so three functions are required to retrieve equivalent adjacency information for junction elements. The GetAdjacentEdgeCount function returns the number of terminating edges. Depending on the result, either the GetAdjacentEdge or GetAdjacentEdges function is used to retrieve all relevant edge EID values.
* INetTopologyEdit - Inherits from INetTopology. Provides the means to add and delete network elements. It is necessary to first instantiate a NetElementDescription object as they are required as inputs for the AddEdgeByEndEID and AddJunction methods of this interface.
* INetwork - Includes properties describing the network, such as the number of edges and junctions it includes. The Status property can return one of nine possible values for EsriNetworkStatus. For example, if EsriNetworkStatus is equal to 1, then the network already exists and need not be created. Two properties apply only to street networks: MaxTurn is the number of turns associated with a junction; TurnCount is the number of turns in the entire network. [Note: These methods have not been implemented because ArcGIS Version 8.1 does not support turns.] The CreateForwardStar function creates a cursor that can move through the network elements using the network index. (See ForwardStar object class. The NetWeight object must be used first as weights are required as an input to this function even if they do not exist in the network.) The CreateNetBrowser procedure returns the IEnumNetEID interface, which is a browser for the network that lists all the elements in the network and allows access to them. (See EnumNetEIDArray object. This procedure is generally used to apply values to all elements in a network.
* INetworkUpdate - Editing sessions are started and ended using methods provided in this interface, which also include properties that report the present status. Network element attributes, network schema, and network topology can be separately edited, so there are three sets of properties and start/stop editing procedures. For example, before starting to edit attributes, first check the IsAttributesBeingUpdated property of this interface to see if editing has been initiated. If it has not, then invoke the StartAttributesEditing to start the editing process and invoke StopAttributesEditing when finished. If IsAttributesBeingUpdated is True, then the initiating process should be the one to later stop editing.
* IStreetNetwork - This interface has no methods or properties. According to at least one Esri document, "future releases of ArcGIS will include additional interfaces implemented on the [StreetNetwork] class to provide street-specific types of operations" (Zeiler, 2001, p. 1174). Thus, at the present release of ArcGIS (8.1), there are no specific transportation (street) properties or methods in the basic product.
* IUtilityNetwork - Provides the means to deal with flow direction in a utility network. It has three methods: EstablishFlowDirection sets a network flow direction based on the location of sinks and sources; GetFlowDirection retrieves the direction of flow for a specified edge; SetFlowDirection sets the flow direction for a single edge.
* IVersionedObject2 - Since versioning cannot be used for logical networks for which there are no corresponding geometric networks, according to published Esri guidance, this interface is not applicable here.[27]
As noted above, this object must be instantiated to create a new network element as NetElementDescription provides the information needed to reference the object from the user's perspective. The two included interfaces are:
* INetElementDescriptionEdit - Inherits from INetElementDescription. Provides the means of populating the inputs required to derive the EID of the newly created element generated by the INetTopologyEdit interface's methods. To add a new element, four input values must be provided: the type of element; the user class identifier; and a two-part, user-defined identifier for the element. The support element types are coded as: (0) None, or Deleted; (1) Junction; (2) Edge; and (3) Turn.[28] ArcGIS will assign an element identifier to each new element.
* INetElementDescription - The results supplied by this function are the property values previously put there using the INetElementDescriptionEdit interface. These properties are element type, user class identifier, user-specified identifier for the NetElementDescription object, and the user-specified sub-identifier for the object.
This object class has a single purpose: to return the user class identifier of specified class in a logical network. Its one interface is:
* INetElementClass - Supplies the property of user class identifier for a network element class. This property is not directly accessed but is the result of invoking various methods in the INetSchema interface. (See the street and utility network objects listed above.)
Trace solvers use network weights to control path selection. Higher weights mean more difficulty in traversing the edge or junction. For example, a street pathfinder could use traffic volume density as a weight. A weight of -1 removes an element from a trace operation and functions similarly to a disabled state. All network elements must have a defined weight, even if it is zero. ArcGIS geometric networks must have all weights defined before the network is constructed. The value of the weight may change, but the weight and its associations may not. The NetWeight class stores the type of weight applied, not the actual value. The value is stored in an external object class tied to the network element through a NetWeightAssociation instance. A single defined NetWeight object may be applied to multiple network element classes and derive its values through multiple NetWeightAssociation objects that may vary depending on the network element class. The two NetWeight interfaces are:
* INetWeight - Provides four weight properties: bit gate size of the NetWeight object (accessible only if the weight type is BitGate); the internal identifier of the NetWeight object; the name of the network weight being described; and the weight type. There are five weight types: Null, BitGate, Integer, Single, and Double.
* INetWeightEdit - Inherits from INetWeight. The editing interface used to set NetWeight properties except for WeightID, which is determined by the application.
Table fields used as network element weights are associated with network elements through instances of the NetWeightAssociation class. The NetWeight object and the table from which weight values will be retrieved must exist before an association can be established. The association is live; i.e., any changes to the values in the source table will be reflected in the next use of weights in a trace-solving procedure. The two interfaces for this class are:
* INetWeightAssociation - This interface provides read-only access to three properties: the name of the field that contains weight values for this association; the name of the table in which the field exists; and the weight identifier.
* INetWeightAssociationEdit - Inherits from INetWeightAssociation. This interface provides read and write capabilities to create and alter the three weight association property values.
As mentioned above, this object class supports interfaces that work with sets of element identifiers present in the network. It is instantiated by the Network subclasses (UtilityNetwork or StreetNetwork) and the TraceFlowSolver object discussed below. The two interfaces are:
* IEnumNetEIDArray - Methods in the Network and TraceFlowSolver object classes, such INetwork::CreateNetBrowser, return instances of this interface. It includes properties, like Count (the number of elements in the array), and methods that move a table cursor through the array.
* IEnumNetArrayBuilder - As implied by the name, this interface includes the Add method that is used to construct an array of EIDs and properties used to manage the array.
The ForwardStar object is created through the INetwork interface provided by the appropriate network object (either StreetNetwork or UtilityNetwork). This object cannot be created directly. Its name is derived from the theory of computer science network searches; the potential arrangement of edges around a junction look like the rays of a star. The ForwardStar object allows incremental movement through a network by finding adjacent edges and junctions from a selected starting location. As the ForwardStar object's methods are used to discover paths through the network, the found elements may be placed in an EnumNetEIDArray object. ForwardStar has seven functions, one that finds the number of adjacent edges connected to a specified junction and six that use this information to look at the connected elements through a set of queries:
* FindAdjacent - Returns the number of adjacent edges connected to the specified junction of a given edge. This count (adjacentEdgeCount) is then used to construct a loop counter and index to move among the connected edges. This function always counts in the same sequence; e.g., the third edge examined FindAdjacent will be third edge in every function.
* QueryAdjacentEdge - Gets information about the specified edge within the index range of 0 to the value of adjacentEdgeCount.
* QueryAdjacentEdges - Retrieves information about all adjacent edges and places the data into a specified array.
* QueryAdjacentJunction - Returns data describing the opposite terminal junction for the specified adjacent edge.
* QueryAdjacentJunctions - Gets information about all opposite terminal junctions for all adjacent edges and places the data into a specified array.
* QueryAdjacentTurn - Turns control how the network may be logically traversed. Edges that logically connect to a given junction may be prohibited as path elements leading from that junction based on the stored turn information. This function returns the data stored for the turn that allows movement from the current junction to the specified edge using the index value determined by first running FindAdjacent. The functions of ForwardStar will not find an adjacent edge for which movement is prohibited by a turn. [Note: This method has not been implemented because ArcGIS Version 8.1 does not support turns.]
* QueryAdjacentTurns - A parallel multi-element method that returns data on all turns through which passage is permitted to adjacent edges. [Note: This method has not been implemented because ArcGIS Version 8.1 does not support turns.]
The object classes defined in the preceding section provide the means necessary to construct a logical network without associated geometry. These are the same classes used by ArcGIS to construct the logical network portion of geometric networks. Normally, geometric network features control the instantiation and use of logical network classes as the features are constructed and manipulated. However, it is possible to create and use purely logical networks in a carefully controlled application. In this alternative approach, cartography is not required and topological connections between transportation features are explicitly stored as attributes of those features.
One problem, of course, is that when cartography is absent, the user interface becomes problematic. How will the user be able to define a logical network with nothing to manipulate visually? There are two basic choices. For both choices, topological information for constructing logical networks from these features would be retrieved from feature attributes. The user would select and/or eliminate transportation feature segments then utilize a NetworkWorkspace object to create a purely logical network that would be populated using the appropriate object classes listed above. The input mechanism could be a set of simple feature classes as visual representations of logical network elements or various user-defined criteria that would be applied against an attribute database. Conceivably, both could be utilized, with an attribute query used to select the candidate graphical features for graphical fine-tuning of the network.
Figure 20 shows the present network object model utilizing geometric networks. Figure 21 shows the alternative proposed in this chapter. The alternative suggested in this chapter is substantially less complicated, yet more flexible.
![Figure 20. The current ArcGIS 8.1 network object model.[29]](p043720.gif)
Figure 22 illustrates one way to provide the required functionality of decentralized transportation network editing and manipulation in ArcGIS as it is presently offered. This alternative uses Object rather than Feature as the parent coclass for the Routes and Location Referencing Package. (As with the UNETRANS model, Figure 22 shows a logical data model since it lacks interfaces. The actual design of the software to use these interfaces, which would be invoked in other object classes, is outside the scope of this paper.)
Why is this better than building a geometric network? The answer is a combination of higher execution speed and support for using multiple cartographic representations. As noted earlier, logical network functions operate hundreds and thousands of times faster than those using geometric features. By breaking the one-to-one relationship between geometric networks and logical networks, it is possible to tie one logical network to many cartographic representations-or vice versus-through the use of foreign keys defined by the user.
There is also the benefit of faster network construction. With explicit topology stored in the simple feature classes, there is no requirement for the cartography to be perfect since the connectivity of network elements will not be inferred from feature coincidence. In other words, there will be no requirement to clean the cartography before building the network. This means that users can sketch new simple features and define their connections to other features without worrying whether they did the job neatly. (It would be fairly straightforward to construct a tool that snaps a new linear segment to the defined junction locations as a means of displaying the stated connectivity as a sort of verification mechanism.)
There is, of course, the overhead of maintaining the explicit topology data, but this type of information is typically already present in transportation databases, particularly where dynamic segmentation (dynseg) operations are anticipated. For example, the location of intersections (junctions) can be found by searching for cross-street names on linear transportation features (edges), or explicit points of intersection may be created using anchor points, with anchor sections being subsequently defined with equivalency to physical features.
Simple SQL statements and the dynseg function could be used to construct features for building networks by using multiple selection criteria that could be applied to produce linear segments and their points of intersection. For example, functional class or number of lanes could be used to thin the features to a base set that could be further reduced by applying other selection criteria, such as population, traffic volume, allowable bridge load, and maintenance activities. Dynseg or line overlay functions could than be applied to subdivide the transportation features into polyline features that span intersection to intersection, with those intersections being converted to point features. The explicit topology data can be collected during this process and stored in the resulting features. Feature identifiers created during this process would be employed as the external identifiers that are stored as attributes of logical network elements (UserClassID, UserID, and UserSubID) to serve as a complex foreign key for relating them to their representative features.
The proposed UNETRANS object classes, which do not yet exist, could be constructed in such a way as to function with simple features and the logical network since most of them are object, not feature, classes. Indeed, several classes, such as those defining anchor points and anchor sections, already relate to simple feature classes, while most others are object classes that could be related to simple features. Essentially, the only change proposed here for UNETRANS implementation is to replace the Reference Network Package with one not based on geometric network feature classes. All other packages work equally well with simple features or require no features at all. It is also useful to note that UNETRANS is a data model, not a true object model; i.e., it has no defined methods.
An alternative approach is to have a single, comprehensive logical network, then alter the disabled/enabled state and/or weights of network elements. While possible to implement, this alternative suffers from the shortcomings resulting from its greater processing overhead, both for the user and the software.
Whether to use the out of the box functionality of ArcGIS or to be more creative-and flexible-by deploying a simpler data structure that requires some programming is a question that must be answered by each user.
1 UML was created by Grady Booch, Ivar Jacobson, and Jim Rumbaugh at Rational Software Corporation. It has since become the property of the Object Management Group, an open membership, not for profit consortium.
2 From UML Notation Guide, available at http://www.platinum.com/corp/uml/nota_11.pdf, p. 3.
3 From ArcGIS 8.1 Object Model, Diagram Key, included in Zeiler, 2001.
4 Some authors use the term 'binary large object'.
5 These quoted definitions from Esri's published Geodatabase model show that Esri itself is sometimes inconsistent in the use of "object" as a formally defined term (Zeiler, Michael, Modeling Our World: The Esri Guide to Geodatabase Design. Redlands, CA: Esri Press, 1999, pp. 81 and 98-99).
6 More information on these reporting requirements can be found at sites accessed through http://www.lib.ncsu.edu/stacks/gis/nhpn.html#hpms.
7 Vonderohe, A., & T. Hepworth (1998). "A Methodology for Design of Measurement Systems for Linear Referencing," Journal of the Urban and Regional Information Systems Association. 10, 1, pp. 48-56.
8 Ibid.
9 This figure is calculated using a map scale of 1:31,680 (number of inches in half a mile) and the map accuracy standard of error being no greater than 1 in 40: 31,680 ÷ 40 = 792 inches; 792 ÷ 12 = 66 feet.
10 From page 21 of Linear Referencing and Dynamic Segmentation in ArcGIS 8.1, May 2001, available from Esri at http://www.Esri.com/library/whitepapers/pdfs/lrds_arcgis.pdf.
11 Federal Geographic Data Committee, Ground Transportation Subcommittee (2000). NSDI Framework Transportation Identification Standard-Public Review Draft. Washington, DC: US DOT Bureau of Transportation Statistics. http://www.bts.gov/gis/fgdc/web_intr.html
12 Described, for example, in Opiela, K.S. Research Results Digest 218: A Generic Data Model for Linear Referencing Systems. Washington, DC: National Academy Press, September 1997.
13 Adams, T., N. Koncz, and A. Vonderohe. NCHRP Report 460: Guidelines for the Implementation of Multimodal Transportation Location Referencing Systems. Washington, DC: National Academies Press. 2001. This paper relies on the Web-published version offered for comments (no longer available) plus known changes by the authors.
14 Major publications related to this model are: Dueker, K.J., and J.A. Butler, "GIS-T Enterprise Data Model with Suggested Implementation Choices," Journal of the Urban and Regional Information Systems Association (a.k.a. "URISA Journal"), Vol. 10, No. 1, Spring 1998, pp. 12-36; and Butler, J.A., and K.J. Dueker, "Implementing the Enterprise GIS in Transportation Database Design," URISA Journal, Vol. 13, No. 1, Winter 2001, pp. 17-28. Related publications can be found at the Portland State University's Center for Urban Studies Web site at http://www.upa.pdx.edu/CUS/PUBS/contents.html.
15 See, for example, Butler, J.A., and K.J. Dueker, "Implementing the Enterprise GIS in Transportation Database Design," URISA Journal, Vol. 13, No. 1, Winter 2001, pp. 17-28.
16 FGDC (2001) Part III, p. C-12.
17 Many reference books and articles use an example of a limited-access highway interchange being represented by a complex junction. While complex junctions are an implicit part of ArcGIS, they are not implemented in the product at present and such features must be custom coded. This may be why they are not included in the UNETRANS model.
18 This paper shows the Station class as instantiable, as it is in the published UNETRANS ArcGIS data model. The paper by Curtin, et. al (2001), ArcGIS Transportation Data Model (Draft), shows it as an abstract class. These documents are available at http://support.Esri.com/index.cfm?fa=downloads.dataModels.filteredGateway&dmid=14.
19 As of this writing, the UNETRANS glossary defines a Port to be a polygonal object, not a type of Station, in Curtin, et. al (2001).
20 Ibid. p. 12
21 Ibid, p. 19.
22 Ibid, p. 5.
23 Ibid, p. 25.
24 Esri's file format follows the design of shapefiles, where the planar coordinates are listed first followed by the elevations and measures; i.e., x, y, x, y, x, y, ...; m, m, m, .... Oracle's LRS file format is x, y, m; x, y, m; x, y, m; ....
25 From Essential Network: Developer Details of the Logical Network, a presentation by Doug Sterling at the 21st Annual Esri User Conference, San Diego, CA, July 2001.
26 Zeiler, op cit., p. 1162.
27 From Modeling, Managing, and Editing Geometric Networks, a presentation by Erik Hoel & Craig Gillgrass at the 21st Annual Esri User Conference, San Diego, CA, July 2001.
28 A presentation at the 2001 Esri User Conference indicated that another type, Maneuver, is forthcoming. It also noted that both Turn and Maneuver are post-8.1 types.
29 From Hoel and Gillgrass (2001), op cit.
Al Butler
GIS Director
Orange County, Florida
Al.Butler@ocfl.net
407-836-5514