Consider changing the featureType property value from Segment to Node

[ghobona]

Looking at the example in Annex C of the REM draft on 2022-03-10.

The example contains Feature instances that have a “featureType” property with value “Segment”.

The geometry is presented as a Point. See below.

    {
      "id": 3,
      "type": "Feature",
      "properties": {
        "featureType": "segment",
        "levelOfDetail": "visualization",
        "length_m": 70,
        "duration_s": 46,
        "instructions": "continue",
        "text": "Head north on North Rd. Go for 70 m."
      },
      "geometry": {
        "type": "Point",
        "coordinates": [-77.0721011, 38.9308998]
      }
    }

I realise that the REM is not intended to represent a graph, however I suspect that many implementers of routing applications will have graph databases underneath their applications.

The issue is that in Graph models there are nodes and edges. https://en.wikipedia.org/wiki/Graph_theory

Nodes are typically represented as points.

Edges are typically represented as lines.

The current draft of the REM, however, represents a Segment feature using a POINT geometry. This might confuse implementers.

Please consider changing the featureType property value from Segment to Node.

[cportele]

Changing "Segment" to "Node" would not solve the issue and would be wrong.

The segments are segments and not nodes. They have properties like length, duration, etc. that describe the segment from start to end. It is just that for reasons of compactness and to avoid unnecessary redundancy by repeating many positions in both the overview and the segments, there was a decision to reduce the geometry of the segment to the point at the end of the segment. See the definitions of RouteSegment and its properties including locationAtEnd.

However, I can see that it may be counterintuitive for those that only look at an instance and that are not familiar with the REM. So, what can we do so that the use of terms is not only correct, but also intuitive? I assume that we do not want to reintroduce the redundant coordinates in the segments and that we do not want to rename the feature type to something like "segementWithPathGeometryReducedToTheLocationAtTheEnd".

[lieberjosh]

This actually a problem in 19107, how to be efficient but also include processable geometry in both overall features and the topological elements that they comprise. GML just provides for geometries in the features, which makes it (in my opinion) very hard to do useful things with the topo elements. The present REM version adds an ending point, as well as reusing the "id" property for ordering (in addition to the physical ordering in the JSON document). This corresponds with the idea of segments as lightweight, dependent elements of a route. An application should be able to calculate whatever is needed (e.g. segment geometry, to/from nodes) from this information to create an explicit graph representation. It is definitely terse, though, and not compatible with some applications such as independent exchange of segments between routes (a la Strava and other sport routing apps).

An alternative approach (a la TopoJSON) could be to put full geometries in each segment as a first-class object and then provide the overall route as just a list of the segments. This might be considered in the future but I'm not sure there are compelling reasons to make this change in the core exchange model.

[ghobona]

@cportele How about changing to "SegmentNode"?

'Segment' becomes the adjective and 'Node' becomes the noun.

[skyNacho]

The thing is that it is not a 'Node' but a 'Segment', a directed segment to be more specific. All the properties (such as length_m and duration_s) indicate that it is a segment. In order to avoid redundancy it was agreed to represent its geometry as a point (the last point in the segment).

I have been thinking about this issue for the past few days and I cannot find a proper solution: either we continue representing a segment with a point (generating confusion for newcomers) or modify our previous agreement and represent a segment with a line (repeating the information on a segment's initial point with the previous segment's final point).

[lieberjosh]

It's not actually that bad of an idea to use a 2-point linestring to represent a route segment, as it wouldn't add that much volume and potentially makes it easier to order, find, or exchange individual segments. Significant change, though.

On the other hand, "segment" here is used as a feature type specific to the route model, not a generic topological edge or arc. Could perhaps emphasize this by calling it route_segment (and...route_overview, route_start, route_waypoint...). It also has the benefit of more clearly identifying the FeatureCollection as an integral route.

[cportele]

Meeting 2022-09-20: The feature has a length and duration, it is a segment, not a node. We simply reduce the geometry to a point to avoid repeating coordinates to be more efficient. There will never be a single segment feature, the feature collection always includes all the segments. We will therefore keep the name and definition as it is.