New message prototype: foxglove_msgs/MapTile and foxglove_msgs/MapTileArray

[jhurliman]

User-Facing Changes

• Adds support for foxglove_msgs/MapTile and foxglove_msgs/MapTileArray message types

Description

This is a sandbox PR for experimenting with a new message type that describes a textured surface oriented in space, with an optional heightmap texture. Currently, the MapTile message looks like this:

{
  header: std_msgs/Header;
  pose: geometry_msgs/Pose;
  resolution: float32;
  width: uint32;
  height: uint32;
  albedo: { format: "png" | "jpeg", data: uint8[] },
  elevation: { format: "png" | "jpeg", data: uint8[] },
  elevation_scale: float32;
}

With a MapTileArray message that is a single array field of MapTiles. Some open questions and notes:

• Should map tiles be more like markers, uniquely identified by ns+id and with ADD/REMOVE/REMOVEALL actions? To give the publisher control of which tiles appear on the screen at which time, we can either use the marker style system or just use MapTileArray and have it replace all of the map tiles (on that topic) each time it is published. Similar to the difference between markers and occupancy grids / pointclouds / laserscans.
• Which image formats should albedo and elevation support? Raw rgb inline, PNG/JPEG inline, url. Do we need separate message types for some or all of these?
• What should be rendered after a message is received but before the images have loaded? A flat grey rectangle? Nothing?
• TODO: How do we make the scene update when a texture has finished asynchronously loading?
• TODO: Make albedo and heightmap optional, handle albedo: [] or elevation: [] (setting both to empty should be a topic error)
• TODO: Fix the caching logic, nothing is purging the cache so this will likely run out of memory quickly
• TODO: Can the error handling be migrated away from sendNotification()?

[defunctzombie]

Could you open an accompanying PR on our website repo documenting this message and its fields similar to how we documented the LocationFix message. We should use this PR and that documentation PR to work through your above questions.

We need to similarly add support for the protobuf message name variants. Going forward I'd like any new message support to always be accompanied by a documentation PR to website and support the protobuf names.

[github-actions[bot]]

This PR has been marked as stale because there has been no activity in the past 3 months. Please add a comment to keep it open.

[amacneil]

What's the plan for this PR? Is it going to land or is it going to get folded into new3d?

[jhurliman]

@amacneil folded into New3D. It would be helpful to keep this branch around though for reference when doing the new implementation.

[jtbandes]

But the plan is to use the new foxglove.Grid type from BYOD, right?

For height data we will still need to resolve this issue: https://github.com/foxglove/studio/pull/2555#discussion_r777622949

[github-actions[bot]]

This PR has been marked as stale because there has been no activity in the past 3 months. Please add a comment to keep it open.

[jtbandes]

Going to say this is closed by #4544. Filed https://github.com/foxglove/studio/issues/4629 to track height support for Grid rendering.