GMNS v0.85

[ianberg-volpe]

This pull request proposes changes to the specification based on several issues raised by @e-lo and @xzhou99, and discussed at PMC meetings in March and May, 2020.

Major changes

Combining link_geometry, road_link, and offroad_link tables (#3, #7)

We propose combining these tables into a single link table.

• road_link table is renamed link; road_link_id field becomes link_id
• The link_geometry table is removed and link_geometry_id is removed from the link table. Geometry information can now be stored in two different ways:
  • by directly storing the geometry information (e.g., with WKT) in the geometry field
  • by referencing a separate, optional geometry table with the geometry_id field. Unlike the link_geometry table, this geometry table does not contain fields for additional characteristics – these are all stored on the link table.
• offroad_link table is removed
  • a new directed field on the link table indicates whether the link is directed or undirected
  • the dir_flag field can now have value 0 (representing an undirected link or a link without geometry information) in addition to 1 (travel with shapepoint direction) and -1 (travel against shapepoints)

Inheritance: parent fields and segment_lane table (#7, #14)

It can be useful to define a parent from which a link or node can inherit characteristics – for example, a crosswalk entrance node on a pedestrian network is the child of the intersection node at the road network, so they can be signalized together. Or, to conserve disk space, one may wish to provide characteristics for a two-way road on only one of the directed links that makes up that road.

Therefore, parent_link and parent_node fields are added to the link and node tables, respectively. If this field is filled, then blank fields on the child will inherit values from the parent.

Similarly, when a link is divided into segments or lanes, these also can inherit values from the link. The segment_lane table allows for lanes to change characteristics along a segment (as well as adding or dropping lanes). This table contains a parent_lane field, to key a changed lane to its usual characteristics along the rest of the link.

Splitting time-of-day tables (#14, #5)

Rather than allow for link, lane, and segment time of day changes to occur on a single Link_TOD table (meaning that multiple foreign keys have to be checked), we propose defining separate link_tod, link_lane_tod, segment_tod, and segment_lane_tod tables. Similar to how geometries are handled, there is now also an optional time_set_definitions file to allow for time-of-day sets to be defined on a separate table instead of the XXXXXXXX_HHMM_HHMM format.

Minor changes

Several cleanup edits and clarifications to documentation were also made, including:

• moving the specification tables to the "code" section of the GitHub site instead of the wiki (Move schema to 'code' #6)
• recommended preferred units (Specify default units #13)
• recommended using OSM map feature names for loc_type (Use OSM standards for location type #10)
• clarified that ad-hoc fields are allowed; there is no field named "other fields" (Allow ad-hoc additional fields rather then explicitly setting a field name as "additional_fields" #15)
• specified that the capacity field is per-lane (capacity - should we make it per lane? #16)
• consistency edit on zone_id, plus creation of a basic zone table (Be consistent between zone and zone_id #11)
• specified priority for using x_coord and y_coord fields for visualization over linear reference on the location table (x_coord, y_coord in locations provides duplicative (potentially conflicting) information #9)

Example network

One small example has been drafted to show these changes as implemented: Cambridge_v085. The other examples, along with the conversion and validation tools, have not yet been updated to reflect these changes, but will be upon approval of these changes.

[ianberg-volpe]

Lazy approval received; merging (see issue #18 for PMC vote).