7. Bridging GIS (GTF_GIS)

7.2. Bridges translators to GIS formats
7.2.1. Translator to DXF (Standard CAD from AutoDesk Inc.)
7.2.2. Translator to DGN (from Bentley Inc. Microstation SE)
7.2.3. Translator to MIF/MID (from MapInfo Inc.)
7.2.4. Translator to SHAPE (SHP from ESRI Inc. ArcView)
7.2.5. Translator to GEO (from US National Transport Administration)
7.2.6. MGS: Bridges internal binary format

7.3. Command links based on COM/OLE for GIS
7.3.1. COM/OLE for MapInfo
7.3.2. Use of MapObjects components to support ES/DSS and ARC/INFO translators

7.4. Linking GIS and Traffic models
7.4.1. Scope
7.4.2. Different types of software - advantages and drawbacks
7.4.3. Similarities and differences between CAD, GIS and Transport models
7.4.4. Why integrate GIS and traffic model packages?
7.4.5. Translation between traffic models databases and graphs
7.4.6. Translation from GIS to traffic models
7.4.7. Translation from CAD to GIS

7.5. Practicalities of linking GIS and traffic model packages
7.5.1. Basic Physical Networks
7.5.2. Simple Link-Node Networks
7.5.3. Link-Node Networks, With Two Directional Links
7.5.4. Milepost Dependent Data
7.5.5. Link-Node-Turn Network
7.5.6. Interchanges
7.5.7. Public Transport Networks
7.5.8. Fundamental network topology
7.5.9. Work-arounds to describe Public Transport Networks in GIS

The objective of "bridging" GIS applications is to integrate specialised tools into transport support systems which can provide both clear graphic viewing of transport databases and spatial analysis.

There is a conceptual gap, however, between the data models used in GIS and Transport databases: Even the network modules of most advanced GIS present incompatibilities and inefficiency in relation to the ideal data structure required by transport databases.

Three work areas to "bridge" GIS applications and database formats were adopted as starting points:

• Developing translators for GIS data formats (such as DXF, DGN, SHP, MIF etc.)
• Developing command exchange links though COM/OLE using BRIDGES/CS
• Developing a new GIS format (GTF_GIS), based on the GTF data model, and its translator to/from ArcInfo .

Of these areas of work, great emphasis was laid on the first and third. Command exchange formats have proved not as efficient as expected because commercial GIS software providers do not support sufficiently powerful COM/OLE functions. Only with Microsoft Office 97 applications (WORD, EXCEL, ACCESS, PowerPoint) and to some extent with Mapinfo also have COM/OLE links (a Microsoft technology) proved to be effective.
GIS formats and conventional capabilities do not completely cover Transport information and modelling requirements (e.g. in terms of network topology). Therefore, a special effort to bridge more advanced GIS formats and applications (e.g. ArcInfo coverages) and Transport modelling formats has been made. This effort involves more than a data format translation process: it requires consideration of a transport compatible data model (GTF) and development of mechanisms to implement it -although only partially- in GIS formats. As a result, translators for the import/export of data to/from the most relevant public CAD and GIS formats were developed. The usefulness of these translators and GTF_GIS is not in the actual data translation they provide , it is rather in the link they offer between transport and GIS topologies (GTF_GIS) and maximum flexibility and independence from commercial applications for Bridges NIS Core Utilities.

Bridges translators include a set of C++ routines programmed to import/export databases stored in any public CAD and GIS format (all of them based on ASCII). Translators to the following formats have been developed: DXF, DGN, SHP, MIF, GEO, MGS (and ArcInfo Coverages through MapObjects libraries).

A DXF can be binary or ASCII but more usually it is generated and exchanged as an ASCII file. It is structured in five sections:

• 5 HEADER provides general information related to the drawing; each parameter has a variable name and an associated value,
• 6 TABLES defines the elements listed: types of lines (LTYPE), table of levels, table of styles (STYLE), table of views, personal coordinates SCP (UCS), windows configurations (VPORT), dimension style (ACOEST) and identification of applications (APPID),
• 7 BLOCKS contains the definitions of blocks (set of linked elements) in the drawing,
• 8 ENTITIES contains all entities in the drawing, including blocks and
• 9 END OF FILE.

In October 1990 Intergraph Corporation made its formerly proprietary design file formats common to Microstation and Interactive Graphic Design System (IGDS) available publicly. In particular, the description of binary DGN files was made public. The structure of a DGN is similar to DXF but it is more restricted in the actual organisation of data and therefore simplifies warnings and flags. However, different applications are required for DXF and DGN translators.

This is a rather simple format, so simple that with some previous experience on DXF and DGN, no additional information other than an ASCII file is needed to write the translator. For example, instead of codes describing the type of elements it simply uses the full English word (e.g. POLYLINE). Furthermore, the complexity of many CAD elements (blocks etc.) is avoided, and only basic graphic elements are permitted. Therefore it is an intuitive and easily understandable format.

Shapefiles are also similar to DGN but with some particular features. An ESRI shapefile consists of a main file, an index file, and a dBASE table. The main file is a direct access, variable-record-length file in which each record describes a shape with a list of its vertices. In the index file, each record contains the offset of the corresponding main file record from the beginning of the main file. The dBASE file contains feature attributes with one record per feature. The one-to-one relationship between geometry and attributes is based on a record number. Attribute records in the dBASE file must be in the same order as records in the main file.

The GEO format is a very simple format, organised into different files (for transport networks: Link file, Node file, Geography file; for transportation points: Point file, Area file, Geography file). The position of the field name, type, length, beginning and end position and general comment is clearly stated for each file, and therefore it is relatively easy to write a translator.

In addition to the previous formats, an internal Bridges format (MGS) has been defined as a binary structure providing more efficient on-line interaction for data storage and screen regeneration. MGS format has proved to be very efficient for displaying graphic data on screen, reaching faster speeds than commercial Desktop mapping tools such as MapInfo and ArcView, and even sophisticated CAD tools such as Microstation SE. Much more important than these advantages is the necessity to have more efficient access from transport modelling algorithms to data attached to transport networks. The running times of traffic network assignment algorithms, for example, rises rapidly if access to data is not extremely efficient.

Three different implementations have been developed within Bridges research:

1. Use of COM/OLE to create MapInfo Bridges Command Exchange Translator (MapInfo can be integrated into a Bridges Work Space in the same way as all Microsoft Office 97 applications).
2. Use of MapObjects components for developing ES/DSS own GIS/Mapping capabilities.
3. Use of MapObjects for the translator from ARC/INFO to GTF_GIS).
   However, given the level of development of the internal GIS/NIS core utilities (and the limited support for the COM/OLE functions provided by the commercial software companies), this line of research has been limited to these three cases.

A COM/OLE Container application of MapInfo was developed at early stages of the research (together with EXCEL, WORD and ACCESS) as a part of BRIDGES Communication System.

As a part of model's Expert System graphic interface (see Chapter 8), MapObjects components have been used. They have proved to be very cost effective in bringing mapping capabilities to user friendly interfaces. When the user interface is connected to ESRI applications (specially ArcInfo) MapObjects components become almost indispensable for easy import facilities from Arcinfo converters. This is the main reason why an ArcInfo GTF translator has been programmed using MapObjects components.

The focus of this section is to provide a theoretical discussion of problems and solutions regarding the link between GIS formats and traffic models.
Transport models demand large amounts of data, including:

• Traffic network topology,
• Traffic network data,
• Zone data and
• Trip matrices.

GIS is a natural tool for handling most of these as it can ease processing and improve quality control. However, traffic models demand a complex topology which is not covered well by conventional GIS topology. Thus, in terms of data exchange, there are serious problems when GIS based data are used as input to traffic models and also when trying to use a GIS to illustrate traffic model results.

Despite these difficulties, there are still many advantages from integrating traffic models and GIS, since data handling and the presentation and quality control of results is easier. For this reason, traffic modelling is the field in traffic planning that has made most use of GIS. But, as with data exchange, the poor coverage by GIS of the complex network topology that traffic models demand means that GIS has primarily been used for displaying results from traffic models. As a result, GIS is not used actively as a tool for providing a data foundation for traffic models.

A major element of Bridges is the integration of the different types of software package used in transport planning and analysis into an open system framework. This section describes the theoretical contributions of ScanRail Consult and the Technical University of Denmark to the integration of GIS with both the Bridges Communication System and to models directly. This is all outlined in Figure 6. Because of its widespread use in the transport field in the Commission and more broadly elsewhere, there is most interest in developing tools for ARC/INFO. Instead of just creating some binary exchange routines between ARC/INFO and the core utilities, a more open exchange format, focusing on the public transport aspects of GIS and transport models has been created. This facilitates easier exchange with other software packages and other types of software.
Apart from the ARC/INFO translators, a set of translators for TPSchedule has been created. This has been done in order to demonstrate the potential for exchanging data between traffic models and GIS as well as to test and validate the implemented exchange routines.

Different software products for geographic data have different strengths and weaknesses as illustrated in Figure 3. While CAD is excellent for editing geographic data (e.g. for digitising a map), it can only handle very simple topologic relationships. At the other end of the scale, the graph topologies used within calculation algorithms are often so complicated, that it is almost impossible to maintain them manually. Thus, they are normally built automatically as part of modelling packages.

Graph theory represents traffic networks as graphs in order to feature an optimal implementation of the all-or-nothing algorithm. However, a similar structure is seldom used in commercial GIS packages. In some GIS and most CAD systems, nodes and links are not connected at all in a topologic sense as outlined in graph theory. In these cases, it is very difficult to implement an efficient all-or-nothing algorithm, since it would demand a new algorithm to interpret the topological relationships from the co-ordinates of the links and nodes. Other GIS maintain a link-node topology (like Arc/Info and TransCAD). Some GIS include procedures to translate the topology to a Forward Star Vector or separate tools to build graph topologies externally to the GIS (such as ESRI's NetEngine). Some GIS or programming tools even include path-finding algorithms as part of their development languages (e.g., Calliper's GISDK or ESRI's Arc/Info and ArcView). However, none of them seem to maintain a full traffic network topology directly as a graph.

Most GIS include some path-finding algorithms and must therefore include functions for translation to graphs internally. However, this translation tends to be carried out every time the algorithm is run and it is usually implemented in a non-efficient way for traffic modelling purposes. Consequently, traffic modelling algorithms implemented by GIS macro programming tools usually result in lengthy calculation times. Thus, the easiest approach to using GIS data for traffic modelling is to transmit the network to an external modelling package for the calculations, rather than programming the algorithm with the GIS' own macro tools.

Data exchange causes several problems due to the differences between CAD, GIS and traffic modelling packages storage formats and the mathematical graphs used for the calculations.

The translation between the network representations of traffic modelling packages and graphs are usually carried out automatically when requested. As an example, Trans-CAD can store the network as an efficient graph - a so-called forward star vector file - in order to avoid translation each time the algorithm is run. This file must be rebuilt when the network database is changed within the GIS.

When using GIS for network maintenance and transport models for calculation, it is often necessary to build a public transport topology in the GIS. In most projects, modellers choose to maintain this topology directly in traffic models or external databases. As traffic-modelling packages have a less user friendly interface, this complicates the process of quality control. The physical network and the organisational network being maintained in different software products is also a potential source of errors. To avoid this some modellers have recently begun work on a way to maintain the entire topology in a GIS

Finally, one might consider importing data created in CAD systems (e.g. Microstation and AutoCAD) into GIS in order to use such data for traffic modelling purposes. However, as a CAD system does not normally maintain topologic relationships, it demands substantial effort to translate from the CAD format to the GIS format. Although the more advanced GIS such as ARC/INFO and MGE include many functions to assist topology building there is a problem, because some of the attribute data in CAD are often stored as part of the graphics (e.g. layers, colours and line styles reflecting information on road types). Such data are lost in the conversion.

7.5.1. Basic Physical Networks

The basic 'building block' in all GIS representations of traffic networks should be the physical network. If this network is not present in the model, the model does not represent geographic information in a GIS sense.
Non-physical objects, such as routes, should be maintained by database tables - not as digitised objects.

A traffic network representation must at the very least include links and nodes. The links only contain information about "totals" e.g. total capacity, both directions included but no information about each individual direction. In the graph, each link should contain information about its ID, the from- and to-nodes, and of course data on the link. Each node should contain information about its ID and data on the node.

A network without link information for each direction is sometimes used in traffic models. This should be avoided in local and regional traffic models, due to the limitations regarding many types of traffic (e.g. traffic in the rush hour and trip-chains) and link attributes (e.g. a different number of lanes in each direction). However, network models that only describe information in each direction do not allow for a modelling of the interaction of the two directions (such as overtaking). Thus, the network should both allow for information on each direction individually and for both together. The topology needed for a traffic network containing two-directional links is identical to the one for one-directional links. The two structures differ only in the associated data. This data should contain separate columns for the forward and backward directions.

Data on the traffic network are often stored by mileposts (e.g. an accident at milepost 6,456 or 4-lanes until milepost 14,234 then 2-lanes). This type of data is handled by Dynamic Segmentation in GIS. However, in traffic models such data are usually described by splitting the links at the mileposts concerned. This reflects more closely the structure of the final calculation graph. In order not to make the exchange between GIS and traffic models too complicated, it may be better not to use dynamic segmentation to store link based data in projects that involve traffic modelling.
However, it is noted that dynamic segmentation only containing a sequence of links (no segmentation within a link) can be used as a work-around to describe public transport routes as described in a later section in this chapter. Such a use of dynamic segmentation can also be used to store link data more efficiently and thus to store traffic modelling networks.

A more complete model of physical networks contains an extra topologic element: The Turn. In urban areas, the inclusion of turns is recommended when modelling traffic at an operational or tactical level. Even at the strategic level, it can be necessary to model turns. This is especially the case in networks with congestion problems. In Copenhagen up to 30% of the travel time is spent at intersections. This includes both geometrical delays (deceleration, turn, acceleration) and delays caused by waiting to give way or in queues. At a regional level it is usually not necessary to model turn delays. However, some models describe the time used in passing a city by 'pseudo turns'. This might be more properly described by interchanges.

Figure 8 illustrates the topologic relationships for a traffic network with turns. The turn structure (TURNS) should contain information on which link the turn comes from (FROM-LINK), which it is going to (TO-LINK) and at which node the turn is located (AT-NODE).

Turns are quite easy to describe in a GIS, since they relate to the already described links and nodes. These relations can be described directly in many GIS by using a feature known as 'turntables'.

Some traffic models use more complicated queue models to describe delays at intersections. In this context, it is necessary to have information on the priority of different turn-movements and based on this calculate all points of conflicts between turns. It is noted that this more complicated topology can be interpreted from the simpler data structure above.

In some circumstances, one might want to generalise the topologic element 'turn' to an 'interchange'. The interchange can for example be the movements between different link types, such as from road to rail. Interchanges can in principle be handled in two ways:

1. The interchange is described by turns.
2. The interchange is described as a 'hub' of 'pseudo links and nodes'. Each of the NODES and LINKS can be described as these topologic archetypes..

The first definition is very common for intersections in most GIS and many traffic models but is also used as a work-around to describe stations and airports for example in some GIS representations. 'Turntables' are a simplified version of this definition.

The second definition might be better in cases where the interchanges actually have a physical extent, such as several bus stops within walking distance, or transfers at stations, airports and other big terminals. If the interchanges do not have a substantial physical dimension (compared with the scale of the model), the use of pseudo links and nodes to describe the interchanges is not recommended. If these are used in traffic models, they should be translated into the first definition when imported to a GIS.

A special data type is the transfer table in TransCAD. This describes transfers from one bus stop to another. Each of the bus stops can be defined for different links as events along different routes (similar to the dynamic segmentation by mainstream GIS). Stops are grouped together by assigning them to a network node. The transfer table topology is similar to the 'interchange as hub' type, where the links have been simplified to a transfer and the network node to the interchange ID.

This section deals with public transport networks, which describe the organisation of vehicles and passenger flows. Describing public transport networks by 'pseudo links' a and 'pseudo nodes' as in some traffic models is not recommended, because it demands

Figure 4 Topologic relationships in a network of links, nodes and turns
a substantial effort to update even small changes in routes or the physical network. Thus, in the following we discuss the organisational topology for the public transport network as described by tables relating to the physical network. As public transport sometimes use the car-network with links, turns and nodes, it needs these topologic data types. Similarly, rail switches might be interpreted as nodes and turns.

Between two bus stops or between two stations, passengers have no points of access to the bus or train. Such a route segment might consist of many links, nodes and turns in the physical network (in contrast to the organisational network, where it is one segment). Public transport might interact with the other modes of traffic at each link along the route segment. Some data might be represented at the link level but not at the route segment level, e.g. travel speeds, capacities and lengths as attributes to the many links along one route segment.

However, from the passengers' point of view there will be an organisational network of route segments, terminals and changes. A change in the topologic sense might be to remain in the bus or train at a bus stop or railway station. Thus, both data on the physical network and on the organisational network are needed.

It is noted, that not all the recommended network descriptions can be implemented in the major GIS'. Thus, work-arounds to reduce this problem are given.

A public transport network topology is best described by ROUTES, CHANGES and TERMINALS referring to the physical network consisting of LINKS, TURNS and NODES. Figure 10 gives an example of the underlying topology.

Figure 10 Topologic relationships in a public transport network (b)
The LINKS, TURNS and NODES are organised in the same way as in the car-network. The ROUTE-SEGMENT describes the path going from one terminal to another. Each route segment should contain a ROUTE-ID as well as a ROUTE-SEGMENT-ID. Each link can contain several routes and each terminal can contain several CHANGES between routes. The from-route segment (FROM-SEGMENT), the to-route segment (TO-SEGMENT) and the terminal (AT-TERMINAL) define the changes.

There are two main types of CHANGES: To continue at the same route or to change to another route. To continue will typically need information on the waiting time at the terminal. To change to another route will need information on waiting time for the next mode of transport, including walking time within the terminal, discomfort caused by changing etc.
Each TERMINAL is located at a node (AT-NODE). A node can be a terminal for some routes and an ordinary node for others (e.g. through trains, express busses not stopping at local bus stops).

For assignment models, route segments simplify the network as they can be considered to be a link by the all-or-nothing algorithm. However, in large public transport networks with many routes and terminals, the calculation network is often much larger than the car-network for the same area of analysis. It is noted that route segments terminals and changes can be used as a tool for aggregating a traffic network as they also can be interpreted as links, nodes and turns. This can be used to utilise the results from a national traffic model in a regional model. If proper tools are developed (e.g. to thin out the number of shape points), this approach could be an excellent tool for the integration of models at different levels of aggregation. Zone data can similarly be aggregated by using the concept of regions (e.g. as in ARC/INFO).

As mentioned, the ideal public transport network topology as discussed earlier cannot be maintained by mainstream GIS (although TransCAD is a big step forward in that direction). Therefore, different work-arounds are needed to describe public transport networks in GIS.

The simplest approach is to describe the topology by pseudo links and nodes. This approach is very similar to early traffic models, and is straightforward to implement. However, in practice it demands a substantial work effort to enter and maintain the network by 'multiple digitisation' of links. Thus, tools need to be implemented to enter, maintain, aggregate and disaggregate data. Another approach is to describe the routes by digitising each route and describe transfers by turntables. This eases the handling of transfers, since tools are available in most GIS to maintain turntables. For routes, this approach has the same disadvantages as the first.

Describing the network by dynamic segmentation and transfer tables make it easy to aggregate and disaggregate data and easier to exchange the data between GIS and traffic models. Routes are also more easily maintained than by the other two approaches. However, there is no automatic method in mainstream GIS to relate transfer tables to routes. Thus, this relationship must be maintained by some rather complex GIS application work or by importing and exporting the whole network to an external application.

info@mcrit.com