netconvert 能够直接读取二进制的 ArcView 数据库（"shapefiles"）。要转换此类数据库，至少需要三个文件：扩展名为 ".dbf" 的文件、扩展名为 ".shp" 的文件以及扩展名为 ".shx" 的文件。此外，拥有扩展名为 ".proj" 的投影文件会很有帮助。将 shape-file 加载到 netconvert 中以将其转换为 SUMO 网络的选项名为 --shapefile-prefix <FILE>。由于 shape-file 描述使用多个文件，因此必须仅提供不带扩展名的文件名。因此，应使用以下对 netconvert 的调用来导入存储在 "my_shape_files.shp"、"my_shape_files.shx"、"my_shape_files.proj" 和 "my_shape_files.dbf" 中的道路网络：
netconvert --shapefile-prefix my_shape_files
netconvert 在导入 shape 文件时支持虚拟文件系统。因此，如果您的形状位于 myshapes.zip 中，且主文件名为 arcview.shp，您可以通过 netconvert --shapefile /vsizip/myshapes.zip/arcview 导入它们（--shapefile 是 --shapefile-prefix 的别名）。
不幸的是，shape 文件描述了信息的物理存储方式，但既没有描述存储了什么，也没有描述相应数据库（*.dbf）中的条目是如何命名的。因此，必须检查给定的道路网络在数据库文件中的存储方式，并将此信息提供给 netconvert；直接调用几乎总是会失败。
定义输入#
下表显示了 netconvert 尝试从给定输入文件中读取哪些信息、标准值是什么以及如何更改它们。此外，它还显示了信息是强制性的（必须提供）还是可选的。
| 信息 | 强制性 | 默认字段名 | 选项 |
|---|---|---|---|
| 边的 id | y | LINK_ID | --shapefile.street-id <FIELD_NAME> |
| 边的街道名称（不需要唯一，用于显示） | n | ST_NAME | --shapefile.name <FIELD_NAME> |
| 边起始节点的名称 | y | REF_IN_ID | --shapefile.from-id <FIELD_NAME> |
| 边结束节点的名称 | y | NREF_IN_ID | --shapefile.to-id <FIELD_NAME> |
| 街道类型 | n | ST_TYP_AFT | --shapefile.type-id <FIELD_NAME> |
| 速度类别 | n（见下文） | SPEED_CAT | |
| 车道类别 | n（见下文） | LANE_CAT | |
| 道路等级，用于确定优先级 | n（见下文） | FUNC_CLASS | |
| 道路上的允许速度 | n（见下文） | SPEED 或 speed | --shapefile.speed <FIELD_NAME> |
| 道路的车道数 | n（见下文） | NOLANES、nolanes 或 rnol | --shapefile.laneNumber <FIELD_NAME> |
| 总方向性道路宽度 | n | --shapefile.width <FIELD_NAME> | |
| 道路长度 | n（见下文） | --shapefile.length <FIELD_NAME> | |
| 行驶方向（"B"：双向，"F"：正向，"T"：反向） | n | DIR_TRAVEL |
如果您熟悉 NavTeq，您可能已经注意到默认值是 NavTeq 使用的值。
某些 shape 文件数据库根本不包含有关边属性（车道数、优先级、允许速度）的显式信息。可以使用 SUMO 边类型文件 来描述边的属性。在这种情况下，必须使用 --shapefile.type-id <ID> 命名检索相应街道类型名称的列，并且必须使用 --type-files <FILE> 将 SUMO 边类型文件 提供给 netconvert。如果类型或显式值出现问题，可以使用 --shapefile.use-defaults-on-failure 来捕获。在这些情况下，将使用默认的 netconvert 值。除此之外，还可以加载自己的连接描述。
如果未指定边长度，则将根据提供的几何形状计算长度。
Note
可以使用 GIS 将自己的属性插入数据库中。这意味着也可以插入自己的字段用于车道数、优先级或允许速度，并按照上述描述命名它们。
ArcView 网络使用地理坐标进行编码，这些坐标必须转换为 SUMO 使用的笛卡尔坐标系。要描述如何转换坐标，应该知道您的网络位于哪个 UTM 区域。使用投影选项来设置正确的区域。
Caution
道路几何形状必须使用 'linestring' 类型进行编码
ArcView 导入选项#
用于读取 shapefiles 的完整选项列表如下表所示。您可以在 netconvert 上找到更多控制导入行为的选项。
| 选项 | 描述 |
|---|---|
| --shapefile-prefix <FILE> | 从以 'FILE' 开头的文件中读取 shapefiles（ArcView、Tiger 等） |
| --shapefile.street-id <STRING> | 从列 STR 中读取边 id |
| --shapefile.from-id <STRING> | 从列 STR 中读取起始节点 id |
| --shapefile.to-id <STRING> | 从列 STR 中读取结束节点 id |
| --shapefile.type-id <STRING> | 从列 STR 中读取类型 id |
| --shapefile.use-defaults-on-failure | 在出现问题时使用边类型默认值；默认值：false** |
| --shapefile.all-bidirectional | 插入双向边；默认值：false** |
| --shapefile.guess-projection | 猜测正确的投影；默认值：false** |
| --shapefile.node-join-dist | 如果未找到节点 id 且其几何端点在 FLOAT 米范围内，则假定边共享一个节点（默认 0） |
示例#
TIGER 数据库中的 '36_NEW_YORK'#
该网络可从美国人口普查局 ftp 服务器获取。TIGER 数据是免费提供的，因为美国政府出版物必须发布到公共领域。
打开我们希望包含道路信息的边 dbf 文件（tl_2008_36061_edges.dbf）显示：
- 街道的起始和结束节点分别在名为 TNIDF 和 TNIDT 的字段中描述。
- tlid 字段可以存储为命名边的字段。
- 还有关于类型（mtfcc）的进一步信息。
首先，我们尝试导入道路图。我们使用已找到的信息并应用投影：
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
结果，我们获得了如下所示的网络。
图 1.1. 转换后的纽约网络
有几个问题需要注意：
- 类型未被使用 - 未研究其含义的信息。
- 所有道路都是单向的。
- 投影未经验证（尽管它应该是有效的）。
- 也许 zip 中包含的其他文件包含更多信息。这尚未研究。
'Frida' 网络（奥斯纳布吕克市）#
该网络可在 Frida 主页 上获取，并根据 GPL 许可。
我们的主要兴趣当然是街道网络。以下文件描述了这一点：strassen.dbf、strassen.shp、strassen.shx（"strassen" 是德语的 "streets"）。打开 "strassen.dbf" 时，我们必须意识到其中存储的信息很少 - 既没有给出节点名称，也没有给出街道属性。相反，街道属性似乎存储在附加数据库中，并通过类型名称（列 "strTypID" - strassen_typ_id = street_type_id）引用。此外，此数据库的列名与预期名称不同。
好吧，让我们逐一解决这些问题。
-
不同的字段命名
唯一的问题是我们无法正确提取街道名称。尽管如此，在 FRIDA 中，边是编号的，我们可以将街道 id 用作名称。 调用必须扩展为：--arcview.street-id strShapeID
-
缺少节点名称
netconvert 可以处理没有节点名称的网络（自 0.9.4 版起）。
-
从 SUMO 边类型文件 解析街道属性
使用属性描述边的可能性在 netconvert 中已经可用，并且自 0.9.4 版起可以与 ArcView 文件结合使用。尽管如此，类型必须转换为 XML。生成的文件（frida.typ.xml）如下所示：
<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>
调用必须扩展为：-t frida.typ.xml --arcview.type-id strTypID
在应用了所有这些更改后，网络可以构建了，但看起来相当混乱。在尝试了地理坐标投影后，这个问题得到了解决。因此调用（目前）如下所示：
netconvert --arcview strassen -o frida.net.xml \
--arcview.street-id strShapeID -t frida.typ.xml \
--arcview.type-id strTypID --use-projection
数据质量#
更深入地研究网络后，我们不得不意识到另外两个问题。首先，高速公路的入口和出口匝道被标记为 "highway"。这导致匝道的车道数与高速公路本身相同。这绝对不符合现实，如下图所示：
图 2.2. 显示（单向）高速公路入口/出口匝道问题的详细视图
此外，所有街道都是单向的 - 甚至高速公路也是如此。这使得网络在保持原始状态时无法用于交通仿真。尝试使用 --arcview.all-bidi 转换网络，即尝试插入双向边，这使得城市变得可用，但高速公路的情况更糟，因为入口/出口匝道也变成了双向的...
图 2.3. 显示（双向）高速公路入口/出口匝道问题的详细视图
需求#
Frida 没有可用的需求 - 至少我们不知道有任何需求。
结论#
使用当前功能，我们能够解析来自 Frida 项目的网络，但我们不能说它完全可用于交通仿真。至少高速公路周围的区域是不现实的，因为入口/出口匝道缺乏明确的声明，因此与高速公路本身一样宽。此外，网络中的所有街道都只编码为一个方向。将它们扩展为双向可以解决内城区域的问题，但对于高速公路来说会产生不可接受的结果。
本作品采用 知识共享署名-相同方式共享 3.0 未本地化版本许可协议 授权。作者列于历史记录中。