Notes on Importing ArcView data (shapefiles)
About Shape Files
Missing; please add a description of shape files
Importing the Road Network
NETCONVERT is able to directly read binary ArcView databases. To convert such databases, you need at least three files: a file with the extension ".dbf", one with the extension ".shp" and one with the extension ".shx". Additionally, having a projection file with the extension ".proj" is of benefit. The option to load a shape-file into NETCONVERT in order to convert it into a SUMO-network is named arcview. Because shape-file description use more than a single file, one has to supply the file name without extension, only. So, the following call to NETCONVERT should be used to import the road network stored in "my_shape_files.shp", "my_shape_files.shx", "my_shape_files.proj", and "my_shape_files.dbf":
netconvert --arcview my_shape_files
Unfortunately, shape files describe how information is stored, but neither which is stored nor how the entries of the according database (*.dbf) are named. Due to this, one has to examine how a given road network is stored within the database file and give this information to NETCONVERT; a plain call almost always fails.
The table below shows which information NETCONVERT is trying to read from the given input files, how the standard values are, and how they can be changed. Also, it shows whether the information is mandatory - must be given - and which is optional.
Table 1.1 Information NETCONVERT reads from shape-files
|Information||Mandatory?||Default field name||Option|
|The id of an edge||y||LINK_ID||--arcview.street-id <FIELD_NAME>|
|The name of an edge (not really used)||n||ST_NAME|
|The name of the node the edge starts at||y||REF_IN_ID||--arcview.from-id <FIELD_NAME>|
|The name of the node the edge ends at||y||NREF_IN_ID||--arcview.to-id <FIELD_NAME>|
|The type of the street||n||ST_TYP_AFT||--arcview.type-id <FIELD_NAME>|
|Speed category||n (see below)||SPEED_CAT|
|Lane category||n (see below)||LANE_CAT|
|Road class, used to determine the priority||n (see below)||FUNC_CLASS|
|Allowed speed on a road||n (see below)||SPEED|
|Number of lanes a road has||n (see below)||NOLANES or rnol|
If being familiar with NavTeq, you may have noticed that the defaults are the ones that are used by NavTeq.
Some shape file databases do not contain explicite information about the edges' attributes (number of lanes, priority, allowed speed) at all. Since version 0.9.4 you can use road types to describe your edges' attributes. You have to name the column to retrieve the information about a street's type from using --arcview.type-id <TYPE_ID_COLUMN_NAME>. Of course, you have then to supply a type-file using --xml-type-files <TYPES_FILE> (or --types or -t). If something fails with the types or the explicite values, you can catch it using --arcview.use-defaults-on-failure. Besides this, you can specify your own connection descriptions.
ArcView-networks are encoded using geocoordinates which have to be converted to the cartesian coordinates system used by SUMO. To describe how to convert the coordinates, you should know in which UTM-zone your network is located. Pass this to NETCONVERT using --arcview.utm <ORIGINAL_UTM_ZONE>. If the conversion can not be initialised, you may additionally use --arcview.guess-projection to let NETCONVERT guess the conversion by him own.
NETCONVERT is able to guess some information which is sometimes missing in imported networks. Below, you may find links to further information of interest.
- Most ArcView networks do not contain definitions of traffic lights positions; Still, NETCONVERT is able to guess tls positions and to guess tls programs.
- Also, we have not seen a ArcView network where on- and off-ramps were available for highways. NETCONVERT is able to guess on- and off-ramps.
- In addition to the network, further descriptions of lane-to-lane or edge-to-edge connections may be read.
- As set above, if no per-edge edge attributes are given within the database, one can specify and use edge types for setting them.
- There should also be more information about transferring geo-coordinates to cartesian coordinates available.
'Frida' network (city of Osnabrück)
The network is available at the Frida-homepage and is licensed under the GPL.
Our main interest is of course the street network. The following files describe this: strassen.dbf, strassen.shp, strassen.shx ("strassen" is the german word for "streets"). When opening "strassen.dbf" we have to realize that there is only a few information stored herein - neither the node names are given nor the street attributes. Instead, the street attributes seem to be stored in an additional database and are references by type names (column "strTypID" - strassen_typ_id = street_type_id). Also, the names of this database's columns have other names than expected.
Ok, let's solve these problems one after another.
- Different field naming
- The only problem with this is that we can not extract street names properly. Still, within FRIDA, the edges are numbered, and we may use the street id as name.
- The call has to be extended by: --arcview.street-id strShapeID
- Missing node names
- NETCONVERT can deal with networks which do not have node names (since version 0.9.4).
- Parsing street attributes from a type file
- The possibility to describe edges using attributes was already available in NETCONVERT and may be used in combination with ArcView files since version 0.9.4. Still, the types have to be translated into XML. The generated file (frida.typ.xml) looks like this:
<types> <type id="0" priority="1" nolanes="1" speed="13.89"/> <type id="1" priority="5" nolanes="3" speed="41.67"/> <type id="2" priority="4" nolanes="1" speed="22.22"/> <type id="3" priority="3" nolanes="2" speed="13.89"/> <type id="4" priority="2" nolanes="1" speed="13.89"/> <type id="5" priority="1" nolanes="1" speed="5"/> <type id="6" priority="2" nolanes="1" speed="8.33"/> <type id="7" priority="1" nolanes="1" speed="1.39"/> <type id="8" priority="0" nolanes="1" speed="0.1"/> <type id="9" priority="0" nolanes="1" speed="0.1"/> <type id="10" priority="0" nolanes="1" speed="0.1"/> <type id="11" priority="0" nolanes="1" speed="0.1"/> </types>
The call has to be extended by: -t frida.typ.xml --arcview.type-id strTypID
After having applied all those changes, the network was buildable, but looked quite messy. After having played with geocoordinate projections, this was fixed. So the call (so far) looks like this:
netconvert --arcview strassen -o frida.net.xml \ --arcview.street-id strShapeID -t frida.typ.xml \ --arcview.type-id strTypID --use-projection
The network looks as shown below:
Figure 1.1. The converted Frida-network of Osnabrück (using allowed speed for coloring)
Looking a bit deeper at the network, we had to realise two further problems. At first, highway on- and off-ramps are marked as "highway". this yields in a network where on- and offramps have the same number of lanes as the highways themselves. And it's definitely not fitting to reality, as the next picture shows:
Figure 1.2. Detail view showing problems with (unidirectional) highway on-/off-ramps
Furthermore, all streets are unidirectional - even highways. This makes the network not usable for traffic simulations when left in the orignal state. Trying to convert the network with --arcview.all-bidi, that means trying to insert edges bidirectional, makes the city usable, but the highways are even worse, now, because also the on-/off-ramps are bidirectional, then...
Figure 1.3. Detail view showing problems with (bidirectional) highway on-/off-ramps
There is no demand available for Osnabrück - at least none we know about.
Using the current features we are able to parse the network from the Frida-project but we can not state it is completely usable for traffic simulations. At least areas around highways are not realistic, because on-/offramps lack an explicite declaration and are due to this as wide as the highways themselves. Furthermore, all streets within the network are coded in just one direction. Extending them to be bidirectional solves the problem in inner-city areas, but yields in an unacceptable result for highways.