[Feature]: Arbitrary Ellipsoid Support

[Itschotsch]

Before you start

• I searched the existing issues and did not find a duplicate request.

What problem does this solve?

GeoLibre is sadly incapable of working with celestial bodies other than Earth (e.g. Moon, Mars, other planets, asteroids, etc.). This seems like a rather simple change that would enable most of GeoLibre's tools to be used in a much wider range of application.

Proposed solution

Currently, in several places in the code, Earth's dimensions, projections etc. are defined as constants. Instead, they could be set as variables per project.

Estimated scope

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

Alternatives considered

No real workaround possible. Scaling other celestial bodies to Earth's size, using the program, then scaling back is infeasible.

[giswqs]

Thanks for the thoughtful request! I dug into how deep the Earth assumptions run and where the ceiling actually is. Short version: part of this is a very reasonable GeoLibre feature, and part of it is a hard upstream MapLibre limitation. It helps to split "arbitrary ellipsoid support" into two things:

1. Displaying other bodies (Moon, Mars, …) + correct measurements — feasible

This is achievable and roughly matches your "medium scope" estimate, though it's a bit more than swapping constants:

• Basemaps mostly just work today. MapLibre doesn't care which body its lon/lat tiles represent — it renders them in a normalized tile space and the globe view even shows them as a sphere. Planetary data is routinely published in a Web-Mercator-equivalent scheme (USGS Astrogeology, OpenPlanetaryMap, Solar System OSM), so a Mars/Moon basemap can be added with existing tile sources.
• The real breakage is measurement, and it's fixable. Distance/area assume Earth's radius, so on Mars you'd be off by ~1.88× (6371 km → 3389.5 km). That radius is hardcoded in ~5 places (Web-Mercator meters, meter-based stroke widths, haversine for spatial stats, scale-bar, and georeferencing residuals). These can be parameterized from a single per-project ellipsoid definition.
• The project format has no CRS/ellipsoid concept at all today — only a "globe" | "mercator" projection enum. So step one is adding a celestialBody/ellipsoid field to the .geolibre.json schema and threading it through.

2. A true arbitrary ellipsoid / custom CRS — blocked upstream

The parts that make it "not just a find-and-replace":

• MapLibre GL JS only renders Web Mercator (EPSG:3857). There's no way to set a custom ellipsoid, flattening, or a non-Mercator CRS (e.g. polar stereographic for lunar poles). The globe view treats the planet as a unit sphere — its size is purely cosmetic. Custom CRS is maplibre-gl-js#168, open since 2021 with no milestone, so genuine ellipsoid-accurate rendering isn't in our hands.
• Turf.js (all client-side vector ops — buffer, distance, area, circle) bakes in Earth's radius internally with no per-call override, so those would need a patched/replaced Turf to be body-correct.
• The Python sidecar's estimate_utm_crs() (used for metric buffer/centroid math) is Earth-only — UTM zones don't exist off-Earth, so that path needs a body-specific metric-CRS strategy.
• 3D-tiles / deck.gl overlays are anchored to the WGS84 ellipsoid and out of scope for other bodies.

Where this leaves us

I think there's a genuinely useful, self-contained feature here: a per-project celestial-body setting that (a) offers Mars/Moon basemaps and (b) parameterizes the hardcoded radii so distances, areas, and the scale bar are correct — delivering most of the practical value ("use GeoLibre on the Moon"). What it can't deliver, until MapLibre grows custom-CRS support, is ellipsoid-accurate rendering and non-Mercator projections.

I'll scope the per-project ellipsoid + planetary basemaps work. If you have specific bodies/basemap sources you care about most, let me know and I'll prioritize those.

[giswqs]

This has been implemented. Now you can render the Moon the Mars. Note that some data sources are a bit slow to render. If you have better data sources, let me know.

[giswqs]

Added support for nine more celestial bodies. See #1197

• Mercury
• Venus
• Io, Europa, Ganymede, and Callisto (Jupiter's Galilean moons)
• Titan (Saturn's largest moon)
• Pluto and Charon

[thareUSGS]

@giswqs First, let me say I am very impressed GeoLibre. I also very much appreciate the detailed response to this issue.

I am from Astrogeology and do currently support the (slow) Mapserver layers for our web sites (like our Nomenclature site) and it is great to see them used here. We always had plans to convert to faster tiled-services, but just haven't had the bandwidth. We have worked with others to help (like OPM, Esri, LROC Team, NASA Treks [e.g., Mars, Moon] and others). We also have a STAC API which is ready to be used. Sorry for all the self promotion.

So as you noted above (RE: earth-lock-in), I have been fighting this type of lock-in across applications, standards, and engines for essentially my whole career :-). We actually just helped push for a major planetary update in QGIS 4.2+. But this has been a multi-decade effort supporting GDAL, PROJ, Mapserver, Geoserver, STAC API, CSM API, etc.

I'm here to offer some potential options (work-arounds) for GeoLibre and planetary support.

1. First, it sounds like the true fix would be to find support for planetary updates in MapLibre and Turf (and then GeoLibre). GDAL/PROJ are already planetary savvy as is Proj.js I believe.... If those could be used to support those updates.

2. But there are some potential work-arounds you might be able to easily implement to help planetary users. Not ideal, but common for us. This why we still often support degrees (EPSG:4326) within our WMSs (or even Web Mercator tiles locked on Earth -- not a fan though. At least degrees is degrees and not Earth meters in Web Mercator...).

   2.1. As you have already done, loading our WMS/tiled layers is the first work-around (thanks for doing that). It is fun to fly around Mars in GeoLibre.

   2.2. In past web map viewers we have implemented this work-around (hack) for better measurements within Earth-locked applications (e.g., OpenLayers, Leaflet, ...). Currently, GeoLibre reports drastically incorrect distances and areas (as you noted above). If you can intercept the measurement reporting or even the scalebar draw, there is a potential update to help. Because you have the planetary bodies defined in packages/core/src/ellipsoids.ts and you know the body you are on, a simple ratio applied to the geodesic returned measure will get us very close. For example, one can apply Mars_distance = (Mars_radius / Earth Radius) * Geodesic_TURF_distance. That workaround can also be applied to the area, scalebar draw, and I believe buffers and circles.

As I have stated this is not ideal, but can help. It is also just an idea for GeoLibre. But I could also envision a measurement warning in GeoLibre for non-Earth measures without the correction (or even with the correction).

thanks for listening and good luck with the project!

[giswqs]

@thareUSGS Thank you for chiming in. It is great to hear from you. I greatly appreciate the planetary basemaps provided by USGS Astrogeology. They have been very useful for expanding GeoLibre beyond Earth.

The main limitation I have run into is that many of the USGS Astrogeology basemap services are provided in an equirectangular projection, while GeoLibre currently relies on MapLibre and Web Mercator for rendering. As a workaround, I deployed a Cloudflare Worker that requests the equirectangular WMS imagery and reprojects each tile on the fly to Web Mercator before sending it to GeoLibre.

GeoLibre/workers/tiles/src/reproject.ts

Lines 1 to 19 in bf91c8d

	// Equirectangular (plate carrée, EPSG:4326) → Web-Mercator (EPSG:3857) tile
	// reprojection for planetary raster mosaics.
	//
	// GeoLibre's Mars and Moon basemaps come from OpenPlanetaryMap, which publishes
	// ready Web-Mercator tiles. The other USGS Astrogeology bodies (Mercury, Venus,
	// the Galilean moons, Titan, Pluto, Charon) are only served as *equirectangular*
	// WMS layers — MapLibre can't render those directly, because it only draws Web
	// Mercator. This module warps a single equirectangular WMS image into the Web-
	// Mercator tile MapLibre asks for.
	//
	// The warp is cheap because both projections are **linear in longitude**: a tile
	// and the WMS window requested for it share the same longitude span, so columns
	// map 1:1 and only the latitude axis is non-linear. We therefore request one WMS
	// GetMap covering exactly the tile's lon/lat bbox and resample it row-by-row
	// (nearest-neighbour) onto the Mercator latitude grid — no per-pixel trig, just
	// `size` latitude evaluations and `size` row copies per tile.
	/** Radians → degrees. */
	const DEG = 180 / Math.PI;

It would be wonderful if, one day, GeoLibre could render the planetary basemaps from USGS Astrogeology directly without needing this intermediate reprojection service.

Thank you as well for suggesting a solution for 2.2. I will look into that.