Introduce new archetype for minimal CoordinateReferenceSystem (CRS)

[jleibs]

Context

Rerun points are currently abstract and otherwise dimensionless.

Transforms and camera projections define mathematical relationships between sub-spaces, but they still don't ground the data relative to a meaningful world reference frame, or tell you how to interpret the data itself.

For example:

• Are these points relative to a well-defined real-world origin?
• What do the points represent? A cartesion space? A geographic space?
• What are the units: meters? cm? radians? degrees?

In geographic systems this data is typically captured by a CRS:

• https://docs.ogc.org/is/18-010r11/18-010r11.pdf

Primary driving use-case

• In: Map View and GeoPoints archetype #6561
  One challenge we currently have is that if a user logs lat/lon/alt-based Points3D archetypes, they have no way of indicating that this data actually represents geographic data.

Logging a CRS to the parent space would be one way of providing this context. The implication, much like a transform, is that all data in the subtree beneath the CRS can be interpreted relative to that reference system.

We can then find instances of the CRS archetype with Geospatial values and use those to determine where we spawn MapViews.

Alternatives considered

A different approach is to introduce new archetypes such as GpsCoordinate. This is much easier to implement in the short term, but scales poorly:

• It proliferates Gps variants across other 2D/3D constructs that still make sense in a map. GpsPoints, GpsLines, etc.
• It still doesn't handle the problem of letting a user define which coordinate system their data is in. "GPS" systems still may provide data relative to one of many different coordinate systems.

MVP

Providing a full implementation of an ogc-defined CRS is well out of scope at this point in time and arguably of limited utility (see this old thread from georust project: georust/geo#32)

The main things we specifically care about is indicating whether units in a space are Cartesian (the default) or EPSG4326 (the defacto mapping standard that will cover 95% of our users).

We can document that when using EPSG4326 (WGS84), we assume coordinate axes order of (lat, lon, alt), and units of (degrees, degrees, meters).

Optional low-cost nice-to-haves:

• User-defined label. This can be helpful for indicating known reference points or conventions.
• Units enum for cartesian spaces (ignored for EPSG4326)

[k-bx]

Not to over-complicate the discussion, and I'm not an expert on the geo math, but I want to mention that the representation of the map projection itself might also differ, for example I assume that the one in PR uses a WebMercator projection, which is OK for most use-cases but not good enough for any serious usage where errors are not as tolerable, where regular Mercator (or other projection) might be used.

Not sure if it affects the suggestions outlined here (newbie to the whole rerun arch), but please consider.

[jleibs]

@k-bx yes, arbitrary map projections is something I know we'll eventually want to deal with and I'm hoping to take at least baby steps in that direction.

My understanding at the moment is that the map view in the referenced PR assumes that the source data is in EPSG4326. This assumption goes down through like 3 layers of deps and is fairly baked into much of the georust ecosystem.

The library then does a projection into EPSG3857, which is the common WebMercator projection. This is somewhat implicitly tied to the tile-servers that view provides, which are serving EPSG3857 tiles. Since the view only supports openstreetmap / mapbox, this part really is an implementation detail of the view.

To that end, my first goal is to make it possible to correctly annotate that the source data is represented in EPSG4326, which allows this particular view to know the data is appropriate to use based on its assumptions. Furthermore, if we introduce other CRS values in the future, this would allow the map view to either not work, or, ideally, to implement a correct reprojection from the source data crs into EPSG4326, before it passes it onto the map visualizer.

Farther down the line, it would be nice if our core transform system supported doing arbitrary reprojections between different CRS values much like you can project from 3D views into 2D views via a camera.

[tfoldi]

We may also need to create a separate issue for the Position3D precision: using float to store latitudes and longitudes can only achieve meter-scale precision, whereas modern RTK-corrected positions require accuracy down to centimeters or millimeters.

Jeremy, you mentioned using Vec3_f64 and Position3D_f64 types as temporary solutions until we implement types that are flexible with respect to the underlying primitive.