Skip to content

[Feature]: Planetary (non-Earth) coordinate reference systems, e.g. Mars and the Moon #223

Open
Open
[Feature]: Planetary (non-Earth) coordinate reference systems, e.g. Mars and the Moon#223

Description

@binlongye
binlongye
opened on Oct 14, 2026

Before you start

What problem does this solve?

Planetary scientists work with Mars and Moon data (HiRISE/CTX DTMs, MOLA, LOLA…) in body-specific CRSs. Reading the source at 3c9d65d, part of this already works: a WKT1 or GeoTIFF user-defined CRS with a Mars spheroid becomes +a=3396190 …, and because such definitions carry no datum, proj4rs skips the datum shift, so lon/lat survive the WGS 84 pivot unchanged.

What does not work:

  1. Measurements assume Earth. haversine_m, geodesic_length_m and geodesic_ring_area_m2 use EARTH_RADIUS_M (geom/src/lib.rs#L12), so on Mars lengths come out ~1.88× and areas ~3.5× too large; the scale bar has the same problem.
  2. WKT2 is not read. GDAL 3 writes IAU_2015 CRSs as WKT2 (GEOGCRS/PROJCRS), which read_wkt rejects (wkt.rs#L216). There are no IAU_2015 or ESRI 1049xx codes either.
  3. Some common planetary projections are missing from the WKT/GeoKey lists, e.g. sinusoidal and orthographic.

Proposed solution

I'd like to know whether this is in scope, and how you'd prefer it designed:

  1. Would you accept planetary CRS support?
  2. Where should the body's size live? One option: Crs exposes its ellipsoid (a, b), and the geodesic functions take it instead of a constant. This matches ArcGIS Pro, which measures geodesically on the spheroid of the data's or map's GCS.
  3. Codes: a small built-in table of common IAU_2015 codes (Mars, Moon, maybe Mercury/Venus), or WKT only?
  4. Is a minimal WKT2 reader welcome (GEOGCRS/PROJCRS with ELLIPSOID + CONVERSION)?
  5. When layers from different bodies share a map, should RustGIS warn or refuse? Today the WGS 84 pivot would silently overlay them.

If it helps, this could land in small, independent steps: (a) WKT2 + sinusoidal/orthographic, (b) per-CRS ellipsoid for measurements and the scale bar, (c) an IAU code table.

Estimated scope

Medium: a broader feature that is feasible in a reasonable timeframe

Alternatives considered

Converting data to WKT1 with GDAL (gdalsrsinfo -o wkt1) before loading, and doing measurements in QGIS or ArcGIS Pro.

Activity

  1. thareUSGS commented on Oct 15, 2026

    @thareUSGS
    thareUSGS
    on Oct 15, 2026

    Thanks for opening this issue. I would like to also vote for planetary CRS support. While proper planetary support is ideal, there are work-around methods to support planetary measures (if RustGIS understands that a different radius is being used). See: opengeos/GeoLibre#1128

    1. I will note RustGIS happily loads most GeoTIFFs from planetary bodies (e.g., like the Moon or Mars).
    2. It appears the planetary projection is correctly interpreted in the file and map projected (on-the-fly) to the RustGIS defined map projection (which is locked to WGS 84).
    3. While the data looks to be displayed correctly (even as projected to Earth), any measurements are incorrect (which is to be expected since the data is projected to an Earth radius). But even if the RustGIS Map frame supported the Moon or Mars, measurements are also locked to Earth. You can see this lock-in here.

    Thus, for a full CRS support, not only would the radius need to supported in the CRS (map projection), but tools which also have Earth radius lock-in (like the measure tool) would need to support the defined radius.

    For planetary CRS (and map projections), SpatialReference.org supports "IAU_2015" planetary codes. Note these codes are based on what has been loaded into the PROJ library (the official IAU_2015 code site is here). But, I will also note that ESRI codes have many defined planetary bodies also. I see you often reference https://epsg.io/ which also has these planetary ESRI codes (e.g., see Mars).

    So, I'm not sure how much I can help -- but I'm happy to try. To start, I would initially tackle these 2 items:

    1. I would recommend allowing ESRI, or better yet IAU_2015 codes for planetary CRS support (via PROJ look-ups or see SpatialReference.org). You could also implement an ellipsoids configuration file like GeoLibre (see below).
    2. If planetary CRS support is enabled, it would be great to see that radius used in measurement tools that are not locked to Earth (see mu number 3. above as an example).

    How does GeoLibre currently support planetary bodies (I may not have this all correct):

    1. Geolibre has a built-in listing for body sizes (ellipsoids.ts)
    2. Many planetary web services support base map images in degrees and EPSG:4321 (WGS84) -- just so it can support multiple web mapping tools. Note that only some planetary WMS services support "IAU" planetary codes.
    3. Like RustGIS, Geolibre can load planetary vector and raster data sets (Shapefiles, GeoTIFFs, etc.), even it if they may map project the planetary data to a map projection defined using an Earth radius.

  2. giswqs commented on Oct 15, 2026

    @giswqs
    giswqs
    on Oct 15, 2026
    Member

    @binlongye @thareUSGS Thank you both for your feedback. We definitely want to support planetary CRS. I don't have answers to all your questions yet. Let me look into this more closely.

  3. giswqs commented on Oct 18, 2026

    @giswqs
    giswqs
    on Oct 18, 2026
    Member

    Support for Esri codes has been added in #494

  4. giswqs
    added 9 commits that reference this issue on Oct 18, 2026

    Maps: draw tiles across the antimeridian; no Earth basemap off Earth

    353089a

    Globe: draw tiles behind a pole and over the polar caps

    0528ffe

    Globe: work out the mosaic's edges once per warp (review)

    f712265

    Maps: extrusion heights and glTF scenes in the body's metres (review)

    3884e72

    Globe: no atmosphere off the Earth

    1b42dcb

    Maps: review round (volumes on the body, pole lines, mosaic zoom)

    cf013a5

    Merge origin/main; terrain heights in the body's metres

    f04bab0

    Globe: use HALF directly (review)

    9c631c1

    Maps: switch the map between celestial bodies, with planetary basemaps (

    67c8cb8

  5. giswqs commented on Oct 19, 2026

    @giswqs
    giswqs
    on Oct 19, 2026
    Member

    Support for 11 non-Earth celestial bodies have been added.

    Image
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions