Feature request: MOLA/DTM dataset support

[0xCoto]

I'm not sure if this has been requested before, but it would be super useful if the Open Topo Data API server was extended to include elevation data from Mars. The two datasets I'm aware are described in this SE answer:

• MOLA laser altimetry (http://tharsis.gsfc.nasa.gov/mapping_data.html) with the actual data available from MEGDR (Mission Experiment Gridded Data Records) at http://pds-geosciences.wustl.edu/missions/mgs/megdr.html (the closest analog to SRTM you can get, but at a higher fidelity level).
• and DTM (digital terrain models from stereo pairs) (http://www.uahirise.org/dtm/).

DTM coverage is small, but the resulting topo models are awesomely detailed - they are good for assessing landing sites and building hi-fi virtual terrains at great locations (Marineris, Olympus etc.)

For the things I'm working on, the MOLA dataset would suffice to support my experiments, as it covers the entire Martian surface. Perhaps this might help others working in fields like astrogeology, space exploration and more!

---

How challenging would you say it would be to integrate this dataset to the current API? Do you think the available dataset format varies significantly from Earth-based data, or is it just as easy to implement?

Cheers!

[ajnisbet]

This is great thanks for bringing this up! It's something I would love to support: I looked at adding a lunar at one point.

From memory, technically non-earth datasets would work: gdal doesn't recognise the MOLA data you linked but I think the projection information could be added like in this SE question.

The main issue I had was with the API: users give lat,lon WGS84 coordinates, which don't make sense not on earth, and I'm not sure if gdal can translate between datums on different planets.

Some potential solutions:

• Allow users to pass y,x coordinates and a crs like ?locations=9329005,166022&epsg:32618.
• Allow users to specify which datum/geoid to use with their lat/lon locations.
• Just ignore the datum difference, it might not make much of a difference with the coarse full-planet dataset.

If you're familiar with non-earth datasets I have a couple of questions:

• Is there a standard coordinate system used on the moon and on mars? I've found this for the moon.
• Do you have any experiences or resources using non-earth data in gdal/qgis/rasterio?

[0xCoto]

• I don't have a lot of experience on coordinate systems for mars myself, but here's something I found: https://planetarynames.wr.usgs.gov/Page/MARS/system - apparently the main systems being commly used appear to be "planetographic latitude with longitude increasing to the west" and "planetocentric latitude with longitude increasing to the east".
• Something I had found earlier today was JMARS. I haven't used it myself, but judging by a few screenshots and video tutorials, it can do exactly what the Open Topo Data provides for Earth data. I'm not sure if this helps at all, but perhaps it could give some inspiration/insight as to what the current 'formats' of inputting/processing/outputting look like?

Edit: also found this post on working with mars data using QGIS - again, not sure if it helps.

[ajnisbet]

Thanks! I'll look through this, figure out what exactly would be needed, then make a call on if it's worth the changes!

[0xCoto]

@ajnisbet Hi Andrew, just wanted to follow up in case you'vr found anything interesting or determined the difficulty of implementing something like this? Hopefully I'm not disturbing too much :)

[ajnisbet]

I had a look at this today.

Because Open Topo Data treats input coordinates as WGS-84, pyproj can't convert those coordinates to lunar/martian ones. You get the error

Error creating Transformer from CRS.: (Internal Proj Error: proj_create_operations: Source and target ellipsoid do not belong to the same celestial body)

The best way to handle this would be to add some parameters like xy_locations and locations_srs to let you specify coordinates that aren't wgs84 latlons. I will add this at some point, but it's non-trivial so I'm not sure when I'll be able to get round to it.

I'd accept a PR though! The steps needed are

• Parse and validate the new query parameters in api.py.
• Pass the params through to backend.get_elevation
• I currently store a WGS-84 bounding box for each Dataset to validate coordinates. I need to remember why this is done, then to modified it to store the bounds in the Dataset crs
• Pass the locations_srs to utils.reproject_latlons, rename that function, and probably update the cached projection transforms to use both the source and destination coordinate systems as keys.
• Do a grep for anywhere else that I assume some wgs84 stuff.