[PROPOSAL] Adding advisory speeds and redesigning speed_limits with typed speed

[Roel Bollens (RoelBollens-TomTom)]

Motivation

We want to express advisory speeds (also known as recommended safe speed, e.g. before sharp curves or on ramps) in Overture. Today speed_limits only models regulatory limits:

speed_limits:
  - max_speed: {value: 100, unit: km/h}
    is_max_speed_variable: true

Advisory speeds don't fit this shape. We could add them through an extension, but that would replicate most of the speed limit structure (speed value, unit, scoping) outside the core schema for something that is conceptually the same.

Proposed change

Each rule gets a required type and a single required speed:

speed_limits:
  - type: maximum        # maximum | minimum | advisory
    speed: {value: 100, unit: km/h}

• maximum / minimum replace max_speed / min_speed. A speed limit that previously carried both becomes two.
• advisory is new: a recommended safe speed.

Dynamic speeds are a property of the road rather than a kind of speed limit, so is_max_speed_variable moves to road_flags as a new dynamic_speed flag:

road_flags:
  - values: [dynamic_speed]
speed_limits:
  - type: maximum
    speed: {value: 100, unit: km/h}

Alongside it we add an unlimited_speed flag for roads where no regulatory maximum applies (e.g. parts of the German Autobahn), which is currently not expressible at all. Since road flags support geometric scoping, both flags can be limited to a sub-range of the segment. The road flags description is loosened slightly, since flags now cover more than physical characteristics.

Scoping of speed limits (when, geometric ranges) is unchanged. Future kinds of speed limits only need a new enum value rather than a new field.

An aside on flag naming

The new flags are called dynamic_speed and unlimited_speed, not has_dynamic_speed, which does leave them sitting a bit oddly next to is_bridge and friends.

The is_ prefixes don't feel quite right. A flag isn't a boolean, it's true simply by being in the values list so is_bridge reads like a boolean field that's wandered into a set. The flag should name the thing (bridge, tunnel), not the question.

Renaming the existing flags is a further breaking change I didn't fancy smuggling into this PR, so I've left them out of scope in this proposal.

Compatibility

This is a breaking change to the segment schema. Consumers reading speed_limits from GeoParquet will see a different struct layout and need a one-time migration. The two new road_flags values are additive.

Alternative considered: additive advisory_speed

Keep min_speed / max_speed / is_max_speed_variable as they are and add an optional advisory_speed next to them.

[Victor Schappert (vcschapp)]

I like this proposal - it seems like a natural evolution of the schema and the enumerated type has the benefit of further extensibility if needed.

Three questions:

1. Is there buy-in from the rest of the transportation group?
2. Are you able to make whatever changes are needed to the transportation combobulator (or whatever successor system is generating the transpo data in the Pipeline)?
3. This would technically be a major change, are you able to guide it through the major change process?