Route Relations

[msbarry]

Highways often go back and forth between motorway/trunk or trunk/primary, so if you use class to decide which zoom to show them in leads to broken road segments:

https://msbarry.github.io/planetiler-overture-demo/#4.99/37.15/-83.06

OpenStreetMap has a concept of route relations that connect long continuous roads composed of many segments that go back and forth between classes so you can more easily decide to show them at lower zooms on a map. Is there any plan to add something similar in Overture?

[vcschapp]

Thanks for raising this Michael. (And by the way, that planetiler demo with the Overture roads is very cool.)

This seems to be an open question right now.

• Under the initial schema release, we are limited by the fact that road.class cannot be linearly referenced, which means every class change produces a segment cut. If we dropped or eased this approach...
  • It would reduce the number of segment cuts imposed by the schema, making the schema more flexible and eliminating a source of cutting...
  • But it wouldn't eliminate segment cuts because we are also making an algorithmic choice to cut at certain types of junctions. So while a schema-imposed source of cutting would go down, our segmentation algorithm imposed cuts would remain. Let's say the change would be a 20%-50% reduction in cuts.
• Apart from the segmentation discussion we do have an open question about whether, and when, we would want to construct some kind of aggregate entity out of many road segments. We don't have the bandwidth to answer that right now but I am curious on your opinion.

Could you go into a bit more detail about the technical difficulty you're facing? Is the issue that for a "logical road" (i.e. the thing that a person would recognize as being a road), you want to show it on the map at a particular zoom level if any sub-segment of that road rates at or above a certain road class?

[msbarry]

Thanks for getting back! The technical problem I'm trying to solve is how to programmatically identify important long continuous road segments that should be displayed at low zoom levels. OSM gives enough hints with route relations, but I don't think overture has enough to determine this on its own.

It seems like for the linearly-referenced attributes to be useful there needs to be some convention around how meaningful the merged segment is, otherwise it would be easier to just work with an exploded segment with simple attributes that apply to the entire length. Merging up to the level of important relations like I-90 Eastbound would certainly be useful. But I understand it gets complicated when segments of a road might belong to different aggregate entities.

[vcschapp]

Separately, I'm curious about your opinion on using an ordinal system of road class numbers versus an enumeration of strings....

[msbarry]

How would the current string values map to the ordinal levels? Would it introduce new levels that don't exist in the string enumeration? I like the idea of being able to filter where class < 5 instead of listing out the classes. Assuming this wouldn't add any new information to the data though I don't have a strong opinion since to write code against it I'd likely map both to an enumeration.

[msbarry]

Also (and this might be a separate issue) for fields that linearly-referenced it would be a lot more convenient to work with them if they always had a consistent structure, like:

{
  "at": [0, 0.5],
  "values": ["a", "b"]
}

for a partial-length attribute, or

{
  "at": null,
  "values": ["a"]
}

instead of just "a" for a full-length attribute

[vcschapp]

Thanks Michael. This is good feedback also. I at a fundamental, I know you're right and to some degree I've been pushing the opposite based on the aesthetic appeal of "simple data looks simple", but I think we need to think more carefully about tooling complexity.