Difference between revisions of "Networks/Import/ArcView"

From Sumo
Jump to navigation Jump to search
(New page: =Notes on Importing ArcView data (shapefiles)= ==About Shape Files== '''<font color="red">Missing; please add a description of shape files</font>''' ==Importing the Road Network== [[NETCO...)
 
(custom name field)
 
(34 intermediate revisions by 4 users not shown)
Line 1: Line 1:
=Notes on Importing ArcView data (shapefiles)=
+
[[NETCONVERT]] is able to directly read binary ArcView databases ("shapefiles"). To convert such databases, at least three files are needed: 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 {{Option|--shapefile-prefix {{DT_FILE}}}}. Because shape-file descriptions 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":
==About Shape Files==
+
netconvert --shapefile-prefix my_shape_files
'''<font color="red">Missing; please add a description of shape files</font>'''
 
  
==Importing the Road Network==
+
Unfortunately, shape files describe how information is stored physically, 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.
[[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.
+
=Defining the Input=
 +
The table below shows which information [[NETCONVERT]] is trying to read from the given input files, what the standard values are, and how they can be changed. Also, it shows whether the information is mandatory - must be given - or optional.
  
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.
+
<center>'''Table: Information [[NETCONVERT]] reads from shape-files'''</center>
 
+
{| cellspacing="0" border="1" width="90%" align="center"
 
 
'''Table 1.1 Information [[NETCONVERT]] reads from shape-files'''
 
{| cellspacing="0" border="1"
 
 
|-
 
|-
 
! style="background:#ffdead;" | Information
 
! style="background:#ffdead;" | Information
! style="background:#ffdead;" | Mandatory?
+
! style="background:#ffdead;" | Mandatory
 
! style="background:#ffdead;" | Default field name
 
! style="background:#ffdead;" | Default field name
 
! style="background:#ffdead;" | Option
 
! style="background:#ffdead;" | Option
Line 23: Line 18:
 
| y
 
| y
 
| '''LINK_ID'''
 
| '''LINK_ID'''
| '''--arcview.street-id ''<FIELD_NAME>'''''
+
| {{Option|--shapefile.street-id ''<FIELD_NAME>''}}
 
|-
 
|-
| The name of an edge (not really used)
+
| The street name of an edge (need not be unique, for displaying)
 
| n
 
| n
 
| '''ST_NAME'''
 
| '''ST_NAME'''
|  
+
| {{Option|--shapefile.name ''<FIELD_NAME>''}}
 
|-
 
|-
 
| The name of the node the edge starts at
 
| The name of the node the edge starts at
 
| y
 
| y
 
| '''REF_IN_ID'''
 
| '''REF_IN_ID'''
| '''--arcview.from-id ''<FIELD_NAME>'''''
+
| {{Option|--shapefile.from-id ''<FIELD_NAME>''}}
 
|-
 
|-
 
| The name of the node the edge ends at
 
| The name of the node the edge ends at
 
| y
 
| y
 
| '''NREF_IN_ID'''
 
| '''NREF_IN_ID'''
| '''--arcview.to-id ''<FIELD_NAME>'''''
+
| {{Option|--shapefile.to-id ''<FIELD_NAME>''}}
 
|-
 
|-
 
| The type of the street
 
| The type of the street
 
| n
 
| n
 
| '''ST_TYP_AFT'''
 
| '''ST_TYP_AFT'''
| '''--arcview.type-id ''<FIELD_NAME>'''''
+
| {{Option|--shapefile.type-id ''<FIELD_NAME>''}}
 
|-
 
|-
 
| Speed category
 
| Speed category
Line 62: Line 57:
 
| Allowed speed on a road
 
| Allowed speed on a road
 
| n (see below)
 
| n (see below)
| '''SPEED'''
+
| '''SPEED''' or '''speed'''
|  
+
| {{Option|--shapefile.speed ''<FIELD_NAME>''}}
 
|-
 
|-
 
| Number of lanes a road has
 
| Number of lanes a road has
 
| n (see below)
 
| n (see below)
| '''NOLANES''' or '''rnol'''
+
| '''NOLANES''', '''nolanes''' or '''rnol'''
 +
| {{Option|--shapefile.laneNumber ''<FIELD_NAME>''}}
 +
|-
 +
| Direction of travel ("B": both, "F": forward, "T": backward)
 +
| n
 +
| '''DIR_TRAVEL'''
 
|  
 
|  
 
|}
 
|}
Line 73: Line 73:
 
If being familiar with NavTeq, you may have noticed that the defaults are the ones that are used by NavTeq.
 
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.
+
Some shape file databases do not contain explicit information about the edges' attributes (number of lanes, priority, allowed speed) at all. It is possible use [[SUMO edge type file]] for describing the edges' attributes. In this case, the column to retrieve an according street's type name from must be named using {{Option|--shapefile.type-id {{DT_ID}}}} and a [[SUMO edge type file]] must be given to [[NETCONVERT]] using {{Option|--type-files {{DT_FILE}}}}. If something fails with the types or the explicit values, it can be catched using {{Option|--shapefile.use-defaults-on-failure}}. In these cases, the default [[NETCONVERT]] values are used. Besides this, it is possible to load own [[Networks/Building Networks from own XML-descriptions#Connection Descriptions|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.
+
{{Note|One can insert own attributes into the database using a GIS. This means, one can also insert own fields for the number of lanes, priority, or allowed speed, naming them as described above.}}
  
 +
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, one should know in which UTM-zone your network is located. Use [[projection options]] to set the correct one.
  
===See also===
+
{{Caution|Road geometries must be encoded with type 'linestring'}}
[[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 [[NETCONVERT_GuessingTlsPositions|guess tls positions]] and to [[TCONVERT_GuessingTlsPrograms|guess tls programs]].
 
* Also, we have not seen a ArcView network where on- and off-ramps were available for highways. [[NETCONVERT]] is able to [[NETCONVERT_GuessingRamps|guess on- and off-ramps]].
 
* In addition to the network, further descriptions of [[NETCONVERT_SettingConnections|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 [[NETCONVERT_EdgeTypes|specify and use edge types]] for setting them.
 
* There should also be more information about [[NETCONVERT_GeoCoordinates|transferring geo-coordinates to cartesian coordinates]] available.
 
  
 +
=ArcView Import Options=
 +
The complete list of options used for reading shapefiles is given in the table below. You may find further options which control the import behaviour on [[NETCONVERT]].
  
==Examples==
+
{| cellspacing="0" border="1" width="90%" align="center"
==='Frida' network (city of Osnabrück)===
+
|-
 +
! style="background:#ddffdd;" valign="top" width="350" | Option
 +
! style="background:#ddffdd;" valign="top" | Description
 +
|-
 +
| valign="top" | {{Option|--shapefile-prefix {{DT_FILE}}}}
 +
| valign="top" | Read shapefiles (ArcView, Tiger, ...) from files starting with 'FILE'
 +
|-
 +
| valign="top" | {{Option|--shapefile.street-id {{DT_STR}}}}
 +
| valign="top" | Read edge ids from column STR
 +
|-
 +
| valign="top" | {{Option|--shapefile.from-id {{DT_STR}}}}
 +
| valign="top" | Read from-node ids from column STR
 +
|-
 +
| valign="top" | {{Option|--shapefile.to-id {{DT_STR}}}}
 +
| valign="top" | Read to-node ids from column STR
 +
|-
 +
| valign="top" | {{Option|--shapefile.type-id {{DT_STR}}}}
 +
| valign="top" | Read type ids from column STR
 +
|-
 +
| valign="top" | {{Option|--shapefile.use-defaults-on-failure}}
 +
| valign="top" | Uses edge type defaults on problems; ''default: '''false'''''
 +
|-
 +
| valign="top" | {{Option|--shapefile.all-bidirectional}}
 +
| valign="top" | Insert edges in both directions; ''default: '''false'''''
 +
|-
 +
| valign="top" | {{Option|--shapefile.guess-projection}}
 +
| valign="top" | Guess the proper projection; ''default: '''false'''''
 +
|}
 +
 
 +
 
 +
=Examples=
 +
=='36_NEW_YORK' from TIGER database==
 +
The network is available at the [ftp://ftp2.census.gov/geo/tiger/TIGER2008/36_NEW_YORK/36061_New_York_County/ TIGER2008 ftp server (?)]. '''<font color="red">Missing copyright information; please add</font>'''.
 +
 
 +
Opening the edges-dbf (''tl_2008_36061_edges.dbf'') of which we hope that it contains information about roads shows us, that:
 +
* the from- and the to-nodes of the streets are described in fields named '''TNIDF''' and '''TNIDT''', respectively.
 +
* the field '''tlid''' may be stored as the one to name the edges by
 +
* there is a further information about the type (mtfcc)
 +
 
 +
As a begin, we try to import the road graph. We use the information we have found and apply a projection:
 +
netconvert -v --shapefile-prefix tl_2008_36061_edges -o net.net.xml \
 +
    --shapefile.from-id TNIDF --shapefile.to-id TNIDT --arcview.street-id tlid \
 +
    --shapefile.use-defaults-on-failure
 +
 
 +
As a result, we obtain the network shown below.
 +
 
 +
[[Image:tl_2008_36061_edges.gif|400px]]
 +
 
 +
'''Figure 1.1. The converted network of New York'''
 +
 
 +
There are several issues one should note:
 +
* The types were not used - no information about their meanings was investigated
 +
* All roads are unidirectional
 +
* The projection has not been verified (though it should be valid)
 +
* Maybe the further files which are included in the zip contain additional information. This has not been investigated.
 +
 
 +
=='Frida' network (city of Osnabrück)==
 
The network is available at the [http://frida.intevation.org/ Frida-homepage] and is licensed under the GPL.
 
The network is available at the [http://frida.intevation.org/ Frida-homepage] and is licensed under the GPL.
  
Line 96: Line 149:
 
* Different field naming
 
* Different field naming
 
:The only problem with this is that we can not extract street names properly. Still, within [http://frida.intevation.org/ FRIDA], the edges are numbered, and we may use the street id as name.
 
:The only problem with this is that we can not extract street names properly. Still, within [http://frida.intevation.org/ 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
+
:The call has to be extended by: {{Option|--arcview.street-id strShapeID}}
 
* Missing node names
 
* Missing node names
 
:[[NETCONVERT]] can deal with networks which do not have node names (since version 0.9.4).
 
:[[NETCONVERT]] can deal with networks which do not have node names (since version 0.9.4).
* Parsing street attributes from a type file
+
* Parsing street attributes from a [[SUMO edge 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:
 
: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>
+
<pre class="xml">
    <!-- "noch nicht attributiert" (= not yet attributed) -->
+
<types>
    <type id="0"  priority="1" nolanes="1" speed="13.89"/>
+
    <!-- "noch nicht attributiert" (= not yet attributed) -->
    <!-- "Autobahn" (highway) -->
+
    <type id="0"  priority="1" numLanes="1" speed="13.89"/>
    <type id="1"  priority="5" nolanes="3" speed="41.67"/>
+
    <!-- "Autobahn" (highway) -->
    <!-- "Bundesstrasse" (motorway) -->
+
    <type id="1"  priority="5" numLanes="3" speed="41.67"/>
    <type id="2"  priority="4" nolanes="1" speed="22.22"/>
+
    <!-- "Bundesstrasse" (motorway) -->
    <!-- "Hauptstrasse" (main (city) road) -->
+
    <type id="2"  priority="4" numLanes="1" speed="22.22"/>
    <type id="3"  priority="3" nolanes="2" speed="13.89"/>
+
    <!-- "Hauptstrasse" (main (city) road) -->
    <!-- "Nebenstrasse" (lower priorised (city) road) -->
+
    <type id="3"  priority="3" numLanes="2" speed="13.89"/>
    <type id="4"  priority="2" nolanes="1" speed="13.89"/>
+
    <!-- "Nebenstrasse" (lower priorised (city) road) -->
    <!-- "Weg" (path) -->
+
    <type id="4"  priority="2" numLanes="1" speed="13.89"/>
    <type id="5"  priority="1" nolanes="1" speed="5"/>
+
    <!-- "Weg" (path) -->
    <!-- "Zone 30" (lower street with a speed limit of 30km/h) -->
+
    <type id="5"  priority="1" numLanes="1" speed="5"/>
    <type id="6"  priority="2" nolanes="1" speed="8.33"/>
+
    <!-- "Zone 30" (lower street with a speed limit of 30km/h) -->
    <!-- "Spielstrasse" (a street where children may play (10km/h)) -->
+
    <type id="6"  priority="2" numLanes="1" speed="8.33"/>
    <type id="7"  priority="1" nolanes="1" speed="1.39"/>
+
    <!-- "Spielstrasse" (a street where children may play (10km/h)) -->
    <!-- "Fussgaengerzone" (pedestrains zone) -->
+
    <type id="7"  priority="1" numLanes="1" speed="1.39"/>
    <type id="8"  priority="0" nolanes="1" speed="0.1"/>
+
    <!-- "Fussgaengerzone" (pedestrains zone) -->
    <!-- "gesperrte Strasse" (closed street) -->
+
    <type id="8"  priority="0" numLanes="1" speed="0.1"/>
    <type id="9"  priority="0" nolanes="1" speed="0.1"/>
+
    <!-- "gesperrte Strasse" (closed street) -->
    <!-- "sonstige Strasse" (something else) -->
+
    <type id="9"  priority="0" numLanes="1" speed="0.1"/>
    <type id="10" priority="0" nolanes="1" speed="0.1"/>
+
    <!-- "sonstige Strasse" (something else) -->
    <!-- "Fussweg" (way for pedestrians) -->
+
    <type id="10" priority="0" numLanes="1" speed="0.1"/>
    <type id="11" priority="0" nolanes="1" speed="0.1"/>
+
    <!-- "Fussweg" (way for pedestrians) -->
</types>
+
    <type id="11" priority="0" numLanes="1" speed="0.1"/>
 +
</types>
 +
</pre>
  
The call has to be extended by: -t frida.typ.xml --arcview.type-id strTypID
+
The call has to be extended by: {{Option|-t frida.typ.xml}} {{Option|--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:
 
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:
Line 136: Line 191:
 
   --arcview.type-id strTypID --use-projection
 
   --arcview.type-id strTypID --use-projection
  
The network looks as shown below:
+
===Data Quality===
 +
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:
  
[[Image:frida_by_speed.png]]  
+
[[Image:frida_uni_highway_ramp.png|400px]]  
 
 
'''Figure 1.1. The converted Frida-network of Osnabrück (using allowed speed for coloring)'''
 
 
 
 
 
====Data Quality====
 
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:
 
  
[[Image:frida_uni_highway_ramp.png]]
+
'''Figure 2.2. Detail view showing problems with (unidirectional) highway on-/off-ramps'''
  
'''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 {{Option|--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...
  
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...
+
[[Image:frida_bidi_highway_ramp.png|400px]]
  
[[Image:frida_bidi_highway_ramp.png]]
+
'''Figure 2.3. Detail view showing problems with (bidirectional) highway on-/off-ramps'''
  
'''Figure 1.3. Detail view showing problems with (bidirectional) highway on-/off-ramps'''
+
===Demand===
 +
There is no demand available for Frida - at least none we know about.
  
====Demand====
+
===Conlusion===
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 explicit 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.
  
====Conlusion====
+
{{License CC BY-SA}}
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.
 

Latest revision as of 13:29, 17 March 2018

NETCONVERT is able to directly read binary ArcView databases ("shapefiles"). To convert such databases, at least three files are needed: 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 --shapefile-prefix <FILE>. Because shape-file descriptions 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 --shapefile-prefix my_shape_files 

Unfortunately, shape files describe how information is stored physically, 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.

Defining the Input

The table below shows which information NETCONVERT is trying to read from the given input files, what the standard values are, and how they can be changed. Also, it shows whether the information is mandatory - must be given - or optional.

Table: Information NETCONVERT reads from shape-files
Information Mandatory Default field name Option
The id of an edge y LINK_ID --shapefile.street-id <FIELD_NAME>
The street name of an edge (need not be unique, for displaying) n ST_NAME --shapefile.name <FIELD_NAME>
The name of the node the edge starts at y REF_IN_ID --shapefile.from-id <FIELD_NAME>
The name of the node the edge ends at y NREF_IN_ID --shapefile.to-id <FIELD_NAME>
The type of the street n ST_TYP_AFT --shapefile.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 or speed --shapefile.speed <FIELD_NAME>
Number of lanes a road has n (see below) NOLANES, nolanes or rnol --shapefile.laneNumber <FIELD_NAME>
Direction of travel ("B": both, "F": forward, "T": backward) n DIR_TRAVEL

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 explicit information about the edges' attributes (number of lanes, priority, allowed speed) at all. It is possible use SUMO edge type file for describing the edges' attributes. In this case, the column to retrieve an according street's type name from must be named using --shapefile.type-id <ID> and a SUMO edge type file must be given to NETCONVERT using --type-files <FILE>. If something fails with the types or the explicit values, it can be catched using --shapefile.use-defaults-on-failure. In these cases, the default NETCONVERT values are used. Besides this, it is possible to load own connection descriptions.

Note:
One can insert own attributes into the database using a GIS. This means, one can also insert own fields for the number of lanes, priority, or allowed speed, naming them as described above.

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, one should know in which UTM-zone your network is located. Use projection options to set the correct one.

Caution:
Road geometries must be encoded with type 'linestring'

ArcView Import Options

The complete list of options used for reading shapefiles is given in the table below. You may find further options which control the import behaviour on NETCONVERT.

Option Description
--shapefile-prefix <FILE> Read shapefiles (ArcView, Tiger, ...) from files starting with 'FILE'
--shapefile.street-id <STRING> Read edge ids from column STR
--shapefile.from-id <STRING> Read from-node ids from column STR
--shapefile.to-id <STRING> Read to-node ids from column STR
--shapefile.type-id <STRING> Read type ids from column STR
--shapefile.use-defaults-on-failure Uses edge type defaults on problems; default: false
--shapefile.all-bidirectional Insert edges in both directions; default: false
--shapefile.guess-projection Guess the proper projection; default: false


Examples

'36_NEW_YORK' from TIGER database

The network is available at the TIGER2008 ftp server (?). Missing copyright information; please add.

Opening the edges-dbf (tl_2008_36061_edges.dbf) of which we hope that it contains information about roads shows us, that:

  • the from- and the to-nodes of the streets are described in fields named TNIDF and TNIDT, respectively.
  • the field tlid may be stored as the one to name the edges by
  • there is a further information about the type (mtfcc)

As a begin, we try to import the road graph. We use the information we have found and apply a projection:

netconvert -v --shapefile-prefix tl_2008_36061_edges -o net.net.xml \
   --shapefile.from-id TNIDF --shapefile.to-id TNIDT --arcview.street-id tlid \
   --shapefile.use-defaults-on-failure

As a result, we obtain the network shown below.

Tl 2008 36061 edges.gif

Figure 1.1. The converted network of New York

There are several issues one should note:

  • The types were not used - no information about their meanings was investigated
  • All roads are unidirectional
  • The projection has not been verified (though it should be valid)
  • Maybe the further files which are included in the zip contain additional information. This has not been investigated.

'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).
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>
    <!-- "noch nicht attributiert" (= not yet attributed) -->
    <type id="0"  priority="1" numLanes="1" speed="13.89"/>
    <!-- "Autobahn" (highway) -->
    <type id="1"  priority="5" numLanes="3" speed="41.67"/>
    <!-- "Bundesstrasse" (motorway) -->
    <type id="2"  priority="4" numLanes="1" speed="22.22"/>
    <!-- "Hauptstrasse" (main (city) road) -->
    <type id="3"  priority="3" numLanes="2" speed="13.89"/>
    <!-- "Nebenstrasse" (lower priorised (city) road) -->
    <type id="4"  priority="2" numLanes="1" speed="13.89"/>
    <!-- "Weg" (path) -->
    <type id="5"  priority="1" numLanes="1" speed="5"/>
    <!-- "Zone 30" (lower street with a speed limit of 30km/h) -->
    <type id="6"  priority="2" numLanes="1" speed="8.33"/>
    <!-- "Spielstrasse" (a street where children may play (10km/h)) -->
    <type id="7"  priority="1" numLanes="1" speed="1.39"/>
    <!-- "Fussgaengerzone" (pedestrains zone) -->
    <type id="8"  priority="0" numLanes="1" speed="0.1"/>
    <!-- "gesperrte Strasse" (closed street) -->
    <type id="9"  priority="0" numLanes="1" speed="0.1"/>
    <!-- "sonstige Strasse" (something else) -->
    <type id="10" priority="0" numLanes="1" speed="0.1"/>
    <!-- "Fussweg" (way for pedestrians) -->
    <type id="11" priority="0" numLanes="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

Data Quality

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:

Frida uni highway ramp.png

Figure 2.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...

Frida bidi highway ramp.png

Figure 2.3. Detail view showing problems with (bidirectional) highway on-/off-ramps

Demand

There is no demand available for Frida - at least none we know about.

Conlusion

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 explicit 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.

Creative Commons License This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License. The authors are listed in the history.