Link shape, lateral offset, and node geometry
mike-mahut opened this issue · 2 comments
This may be more of a question rather than an issue as its about clarifying specific requirements. I haven’t found any discussion on this question in the documentation so thought I should bring it up.
There are 2 distinct approaches for link shape and each has implications for the spatial information associated with nodes. In the higher level, i.e. somewhat simplified approach, link shape is defined as a center line that connects 2 nodes and nodes are represented as points. In this approach its typical for 2 opposing links to share the same shape points. Road width is not explicit in the shape data (though it could be an attribute of a link), and exact road location is collapsed laterally to an idealized center line. This is convenient for visualizing the network and has enough information for static assignment and some meso models.
The other representation, which is required for micro modelling and some meso models, requires explicit road width and the actual alignment of the road, i.e. offset from the idealized center line (in fact there is no idealized center line, just the exact location of each directional roadway). In this case the link shape no longer aligns with a single idealized center point of the node (and nodes do not generally need an idealized center point). Network representation in navigational data sets (TomTom, HERE) have this level of detail. In this approach, an intersection “node” in the usual sense is a group of intersection points since these offset links will intersect at distinct points inside the intersection area.
With this level of information, traffic simulation software can derive distinct physical geometry for individual lanes and is also able to identify the relative positions of roads that arrive to a node parallel to each other (but with different lateral offset); e.g. freeway ramps vs. mainline freeway lanes. Complex intersections have similar cases. This also touches on the question of whether turn “channels” at intersections are represented explicitly as links or implicitly as attributes.
So the question is whether link shape data in GNMS is intended to reflect an idealized centerline that connects idealized center points of nodes, or whether it represents the actual position of the roadway (and thus a node represents a group of intersection points). In the former case, the simplification would make it logical to allow for multiple links to share the same shape data – e.g. opposing links, and also parallel links, though in the latter case some indication of lateral offset would be necessary. The chosen approach will also impact what levels of modeling (macro/meso/micro) the specification is currently able to support.
GMNS can handle several representations: it is implementation specific.
Case 1: the shapepoints are a idealized centerline for a pair of directional links: link 1 and link 2. There are three ways to handle this:
1.1 Shapepoints are a record in the (optional) geometry file. Both links 1 and 2 refer to that record.
1.2. Shapepoints are stored on link 1, and link 2 refers to link 1 as a parent link
1.3 Shapepoints are stored (duplicated) on both links 1 and 2
Case 2: the shapepoints follow a specific location (e.g., the center of the inside lane) on the directional carriageway. In this case, links 1 and 2 will have separate sets of shapepoints. Ways to handle:
2.1 Shapepoints are two records in the geometry file, one for each link.
2.2 Shapepoints are stored on the link records.
resolved by #40