Expose highway rank

[LorenDB]

I'm tinkering around with a custom fork of Sunnypilot but I hope to merge features back upstream. One feature I want to implement is making dynamic experimental control more context-aware so that it can default to ACC on major highways and default to experimental mode on smaller, less major roads.

It appears that the highway rank is currently not being exposed as a parameter that Sunnypilot can access. Could that be added as a feature?

References: https://github.com/pfeiferj/mapd/blob/main/maps/way.go#L25, https://github.com/pfeiferj/mapd/blob/main/maps/way.go#L539

[pfeiferj]

Some unordered thoughts:

• sunnypilot is still working on upgrading to mapd 2.x and many of the currently available data points are not available in mapd 1.x
• The highway rank in mapd will likely be reworked so the rank in it's current state will likely not be something that gets exported
• You can probably use other available data points for what you want to do, likely the roadContext output would be enough
• I will likely add some subset of the osm highway tag values to the maps data, at which point I would expose that value
• I do have some plans to export some signals for helping with dynamic experimental control but haven't fully fleshed out what I want to do

Some unordered links to go along with those unordered thoughts:

• mapd/cereal/custom/custom.capnp

  Line 180 in 7828bba

  roadContext @18 :RoadContext;

• mapd/cereal/custom/custom.capnp

  Line 155 in 7828bba

  enum RoadContext {

• mapd/maps/way.go

  Line 478 in 7828bba

  func (w *Way) _context() RoadContext {

• https://github.com/pfeiferj/mapd/blob/main/docs/outputs.md
• https://wiki.openstreetmap.org/wiki/Key:highway

[LorenDB]

I don't feel like the highway context is quite what I'm looking for. I'd rather use the OSM tags for the best accuracy. If you are going to add them later then I will probably just wait until then to implement my own sunnypilot changes.

In some ways I'd argue that it would make sense to expose the entire OSM tagset for the current way so that *pilot can pull any data necessary instead of having to add functionality in mapd.

[pfeiferj]

In some ways I'd argue that it would make sense to expose the entire OSM tagset for the current way so that *pilot can pull any data necessary instead of having to add functionality in mapd.

So, the issue with this is file sizes. If I added all osm tags to the maps files in a way that can be quickly indexed during runtime then the size of the planet could easily balloon to over a terabyte. Currently the entire planet is stored in about 30-40 GB which is actually smaller than the original highly compressed and un-optimized for indexing planet pbf file. Storage is at a premium for multiple reasons, one, the comma devices don't have a whole lot of storage in the first place. The second reason is my own costs hosting the maps. I've highly optimized my hosting costs to only be around $5/month and increasing the file size very quickly increases that cost. So, all additional data points have to be carefully considered. In the case of the highway tag, I wouldn't directly store the string values, I would instead create an enum for the common values which is why it would be a subset of the tag and not every possible value in osm for the highway tag.