Regarding the map projection & registration, for rover ops, I learned some things when mcaplinger pointed out this MSL document a little while back: https://pds-imaging.jpl.nasa.gov/data/msl/M...CES_PDS_SIS.PDF

For Curiosity, there were some deliberate simplifying assumptions made regarding position plotting on the mission-specific image mosaic. I wonder what the status is for Perseverence... the orthoimages and DEMs at the USGS site (e.g. here) are much larger and more comprehensive from what I can tell, but they may not be exactly what the operations team is using.

Thanks, that is a very helpful document. I learned that the rover positions are with respect to the center between the center wheels, that RMC means Rover Motion Counter, that the onboard positioning can get refined, and how the stacked system of reference frames is defined. Given this, it seems to me that the coordinates provided in the geojson data are directly from the PDS PLACES (or successor) database. Unfortunately, I could not find direct access to the PDS PLACES database for the Mars2020 (M20?) mission, only previous missions, for a more robustly defined source. For example, it is unclear if the geojson provided latitudes are planetocentric or planetodetic as both are described. But choosing the wrong interpretation for projecting back into the equirectangular projection used for the base map would lead to an obvious mismatch I think.

I am using that USGS mosaic and here is the geotiff CRS:

PROJCRS["Equirectangular Mars 2000 Sphere IAU",BASEGEOGCRS["D_Mars_2000_Sphere",DATUM["Mars_2000_(Sphere)",ELLIPSOID["Mars_2000_Sphere_IAU",3396190,0,LENGTHUNIT["metre",1]],ID["ESRI",106971]],PRIMEM["Reference_Meridian",0,ANGLEUNIT["degree",0.0174532925199433,ID["EPSG",9122]]]],CONVERSION["Equidistant Cylindrical",METHOD["Equidistant Cylindrical",ID["EPSG",1028]],PARAMETER["Latitude of 1st standard parallel",0,ANGLEUNIT["degree",0.0174532925199433],ID["EPSG",8823]],PARAMETER["Longitude of natural origin",0,ANGLEUNIT["degree",0.0174532925199433],ID["EPSG",8802]],PARAMETER["False easting",0,LENGTHUNIT["metre",1],ID["EPSG",8806]],PARAMETER["False northing",0,LENGTHUNIT["metre",1],ID["EPSG",8807]]],CS[Cartesian,2],AXIS["easting",east,ORDER[1],LENGTHUNIT["metre",1,ID["EPSG",9001]]],AXIS["northing",north,ORDER[2],LENGTHUNIT["metre",1,ID["EPSG",9001]]]] - Projected

I think it is exactly the projection described in the PDS pdf, including the sphere radius of 3396190m.

The Where is the rover ? online map uses leaflet and proj4leaflet plugin which indicates that it uses a custom map projection, likely the equirectangular projection, for the tiled base map. The traverse data on the other hand had a crs field indicating potentially use of a terrestrial crs.

I am relying on QGIS/GDAL to convert between CRSs which should be better than trying to do it myself although the conversion is straightforward for this projection.

On a side note, I saw in the MSL PDS archives that there are site specific mesh reconstructions of local topography, presumably based on stereo imagery. It would be cool if Mars2020 could make those available. They are probably generated currently.

I also saw in the configuration data for the online map that there is an option for "site experiences", and that THREE.js is being loaded, a popular web 3d rendering library, presumably in anticipation of such experiences once they are ready for consumption. Something to look forward to.

Great, I'm glad you were able to make some use of it. I'm a GIS neophyte so appreciate you posting the details.

In terms of other potential resources - this SPICE topocentric kernel was made pre-landing, but other than exact coords of actual landing has useful detail:
https://naif.jpl.nasa.gov/pub/naif/MARS2020...z_iau2000_v4.tf (it in turn leads to many rabbit holes, but I think the upshot is that "IAU" + "east-positive longitude" seems to indicate planet'ocentric).

The above kernel provides the local definition that connects to the rover kernel, which fully defines all the other transformations. Note that the one in the main folder doesn't seem to be quite as complete as this one, which has more instruments:
https://naif.jpl.nasa.gov/pub/naif/MARS2020...ee/m2020_v03.tf

So far as I know (which isn't that far) PLACES is internal to JPL. But the data does get published with the periodic PDS releases. I think the .geojson is a great asset that gets most of what we'd want from there in terms of near-real-time location data.

Wow, another document covering similar topics.

Some notes:

https://naif.jpl.nasa.gov/pub/naif/MARS2020...z_iau2000_v4.tf

"The landing site Gaussian longitude and latitude upon which the definition is built are:

Lon = 77.429800 degrees East
Lat = 18.670633 degrees North
"

This is far from the actual landing site.


https://naif.jpl.nasa.gov/pub/naif/MARS2020...ck/pck00010.tpc

"Mars

Old values:

Values are from the 2006 IAU report.
body499_radii = ( 3397. 3397. 3375. )

Current values:

The 2009 IAU report gives separate values for the north and
south polar radii:

north: 3373.19
south: 3379.21

The report provides the average of these values as well,
which we use as the polar radius for the triaxial model.

BODY499_RADII = ( 3396.19 3396.19 3376.20 )"

It appears earlier USGS products used this (averaged) ellipsoid but I think now use a spheroid with 3396.19km radius.

https://naif.jpl.nasa.gov/pub/naif/MARS2020...ee/m2020_v03.tf

"Local Level Frame
-------------------------------------------------

M2020 local level frame, M2020_LOCAL_LEVEL, is defined as follows:

- +Z axis is along the downward normal at the landing site
("nadir");

- +X axis is along the local north direction ("north");

- +Y axis completes the right hand frame ("east");

- the origin of this frame is located between the rover's middle
wheels and moves with the rover.

Since this frame is essentially the M2020_TOPO frame flipped by 180
degrees about +X ("north") to point +Z down, this frame is defined
as a fixed offset frame with respect to the M2020_TOPO frame."

This is consistent with the PLACES document. So these documents seem to be developed together, and do not compete with each other (luckily).

There are cool ascii drawings of rover reference frames and mentioning of sclk which shows up as field in the geojson.

There are cool ascii drawings of camera reference frames. The MASTCAM frames includes toe in angles of -1.25 deg. and +1.25 deg. for right and left.

There are cool ascii drawings of arm axes frames.

Everything is referenced by id with value mappings somewhere else.

SCLK means SPICE spacecraft clock (SCLK) kernel.

It turns out that the PLACES document pdf for MSL lives along with the database archive, last updated in December: https://pds-imaging.jpl.nasa.gov/data/msl/MSLPLC_1XXX/

But there is no PDS archive for Mars2020 yet, it appears. There is a review. But it mentions that PLACES is not included to be picked up later.

Sorry if I was unclear. The file was made as a placeholder until actual landing. The M2020 team will be using an updated version by now, but everything except the coords will be identical. (We know those from other sources. Posting operational SPICE kernels on public-facing side is probably not a priority.)

On the subject of Percy's geoJSON precision. I've noticed that since the sol 20 update they started using 9 decimal places coordinates. This presupposes mm level positional accuracy.
The track line itself still uses 6 decimal places precision, or 0.1 m accuracy, which seems much more realistic. I guess mm "accuracy" comes from GIS data manipulation that uses
9 digit precison by default.

The yaw_deg property is also changed to just yaw.

Here is my updated map animation:

https://bit.ly/PercyMAP

I noticed that the provided elevation is about 1m higher than the MOLA DEM elevation at the current waypoint. Perhaps it marks the rover body but the rover reference frame is supposed to originate at ground level.
[CORRECTION] I may have mixed up the way points. The MOLA and reported elevation are actually very close, at -2568.9m

Thanks for finding and posting this direct JSON link.
For those like me who like the data but aren't used to the tools for this format, I recently had the brilliant, if belated, idea to search for "JSON-to-CSV converter," and sure enough there are several easy ones (e.g.). Stuff like thisis just easier for me to understand in a table (before it's plotted):

CODE

RMC   site drive sol  dist_km dist_mi easting      northing     elev_geoid  elev_radii  radius       lon          lat          roll    pitch   yaw      tilt    Note
3_0     3   0     0   0.000   0.000   4354494.086  1093299.695  -2569.910   -4253.470   3391936.530  77.45088572  18.44462715  -1.182  -0.025  130.882  0.000   Site increment, no motion.
3_110   3   110   14  0.006   0.004   4354497.517  1093294.730  -2569.862   -4253.417   3391936.583  77.45094676  18.44454339   0.971  -0.267  -15.112  0.000   First localization!
3_386   3   386   15  0.043   0.027   4354502.424  1093329.801  -2569.935   -4253.583   3391936.417  77.45103403  18.44513505   1.683  -1.700   88.565  2.392   Used Mobility Report WID: 40151
3_578   3   578   16  0.070   0.044   4354528.468  1093338.387  -2569.287   -4252.973   3391937.027  77.45149727  18.44527990  -0.299   1.950   71.211  1.973   Used Mobility Report WID: 40161
3_770   3   770   20  0.091   0.057   4354548.640  1093330.590  -2568.930   -4252.597   3391937.403  77.45185605  18.44514836   0.966   0.966  127.838  1.165   Used Mobility Report WID: 40201

...I was thinking of asking if anyone could program this for the raw image metadata too... but now I can just get it on my own with a few clicks.

I am trying to figure out the easting and northing values.

The landing site in the geojson is at

4354494.086 1093299.695

The USGS 25cm HiRISE mosaic and 1m DEM geotiffs and metadata use this equirectangular projection:

PROJCRS["Equirectangular Mars 2000 Sphere IAU",BASEGEOGCRS["D_Mars_2000_Sphere",DATUM["Mars_2000_(Sphere)",ELLIPSOID["Mars_2000_Sphere_IAU",3396190,0,LENGTHUNIT["metre",1]],ID["ESRI",106971]],PRIMEM["Reference_Meridian",0,ANGLEUNIT["degree",0.0174532925199433,ID["EPSG",9122]]]],CONVERSION["Equidistant Cylindrical",METHOD["Equidistant Cylindrical",ID["EPSG",1028]],PARAMETER["Latitude of 1st standard parallel",0,ANGLEUNIT["degree",0.0174532925199433],ID["EPSG",8823]],PARAMETER["Longitude of natural origin",0,ANGLEUNIT["degree",0.0174532925199433],ID["EPSG",8802]],PARAMETER["False easting",0,LENGTHUNIT["metre",1],ID["EPSG",8806]],PARAMETER["False northing",0,LENGTHUNIT["metre",1],ID["EPSG",8807]]],CS[Cartesian,2],AXIS["easting",east,ORDER[1],LENGTHUNIT["metre",1,ID["EPSG",9001]]],AXIS["northing",north,ORDER[2],LENGTHUNIT["metre",1,ID["EPSG",9001]]]] - Projected

When I project the provided latitude/longitude coordinates with this equirectangular projection with QGIS/gdal I get:

4590877.824 1093299.695

The projected northing matches exactly the northing in the geojson but the easting is off by ca. 236 km.

My first idea would be that perhaps the provided easting is computed from a reference meridian other than 0 degrees.

Does anybody have an idea what the projection is that the provided easting refers to ?

[ 3396190 * PI * 2 / 360 * 4 = 237098.8

So a reference meridian at 4 degrees E would give easting numbers closer to the provided numbers. But that seems rather arbitrary. ]

https://pds-imaging.jpl.nasa.gov/data/msl/M...CES_PDS_SIS.PDF

section 3.9.2 has a discussion on easting which I think provides a start of an explanation:

" These “easting” meters at a given latitude are related to true meters at the equator by the simple formula:

map_meters = true_meters / cos(φ)

where φ is the planetocentric latitude. "

[ hey, one can use html entities in the forum ♥ https://www.w3schools.com/html/html_symbols.asp ]

It looks like the provided meters are true meters (at the equator) and the projected easting has map meters since:

4590298.31635 = 4354494.086 / cos(18.4446271 degrees)

This is getting closer to 4590877.824, with still ca. 580m of a difference.

The gdal computed easting assumes a sphere with a radius of 3396190 m. Perhaps the reported true meter easting takes into account a local radius because these are also listed in the geojson, in the radius field.

The gdal computed easting and northing is consistent with the simple formulas given in section 4.4.2.4:

" planetocentric_latitude: Latitude of the point, measured using a planetocentric system.
Planetocentric coordinates are measured as angles from the center of the planet. Latitude (φ_pc) is
computed from northing (x) using the formula:
φ_pc = x / Re • 180 / PI
where Re is the ellipsoid radius, or 3396190 meters.

longitude: Longitude of the point. Longitude is computed from easting (y) using the formula:
θ = y / Re • 180 / PI
"

[ This is good and so simple that I can probably directly plot the traverse geojson on my equirectangular basemap ].

Since the northing matches, Re is 3396190 m. In addition to the correction to true meters from map meters easting, something else seems to be done to the easting. But what ?

Solving for the latitude using the target easting we get:

18.46629998 = acos(4354494.086 / 4590877.824) degrees

Curiously, this number shows up as the center latitude of an orthographic projection in this metadata file. The relevant snippet is this:


The TIFF file this refers to is described on this page as the Derived JPL Surface Operations Mosaic:


Thanks for bringing this up because it looks likes this may have solved a problem I've been working on, too.

Mark

Another way to look at it is to assume that the reported easting is from a equirectangular projection with a standard latitude not at the equator but close to the landing site. In fact, one can back out the standard latitude because the easting and the corresponding longitude are given:

arccos(4354494.086 / 4590877.824) is 18.4663 degrees for the standard latitude possibly used.

If this is the case all the waypoints should use the same standard latitude. Here is the table with the standard latitude computed for all waypoints:



And, in fact all waypoints do use the same standard latitude. The only question is why this particular latitude. Perhaps that was the original target. A little farther north, closer to the delta, would make sense.

The center of the landing ellipse seems very close.

The average of the ellipse latitudes is 18.46630439 (after not double counting the repeated start and end).

Close enough for me.

So I think the M20 localization uses an equirectangular projection with a standard latitude at 18.4663 degrees N. The reported easting is based on this projection.

[edit] Ah, thanks, Mark. That completely confirms it.

Glad we arrived at the same conclusion (at the same time !). I am using the TIFF you linked to as my base map. Confusingly, the geotiff embedded projection does have 0 as the Latitude of the 1st standard parallel, somewhat contrary to the description which mentions 'centering' on the landing ellipse:

Unknown CRS: PROJCRS["Equirectangular Mars 2000 Sphere IAU",BASEGEOGCRS["D_Mars_2000_Sphere",DATUM["Mars_2000_(Sphere)",ELLIPSOID["Mars_2000_Sphere_IAU",3396190,0,LENGTHUNIT["metre",1]],ID["ESRI",106971]],PRIMEM["Reference_Meridian",0,ANGLEUNIT["degree",0.0174532925199433,ID["EPSG",9122]]]],CONVERSION["Equidistant Cylindrical",METHOD["Equidistant Cylindrical",ID["EPSG",1028]],PARAMETER["Latitude of 1st standard parallel",0,ANGLEUNIT["degree",0.0174532925199433],ID["EPSG",8823]],PARAMETER["Longitude of natural origin",0,ANGLEUNIT["degree",0.0174532925199433],ID["EPSG",8802]],PARAMETER["False easting",0,LENGTHUNIT["metre",1],ID["EPSG",8806]],PARAMETER["False northing",0,LENGTHUNIT["metre",1],ID["EPSG",8807]]],CS[Cartesian,2],AXIS["easting",east,ORDER[1],LENGTHUNIT["metre",1,ID["EPSG",9001]]],AXIS["northing",north,ORDER[2],LENGTHUNIT["metre",1,ID["EPSG",9001]]]] - Projected

And I do think the image data is supposed to be used with that 0 latitude projection because the ISIS .lbl and PDS .lbl also do not specify a standard parallel away from the equator.

It would be possible to reproject (or gdalwarp) the mosaic to the off-equator equirectangular projection and that would yield a less distorted map more appropriate for the region. In effect, it would mean squeezing the x dimension by about 5.15%. But I do not think I am going to do that because it introduces some data loss compared to the existing mosaic.

There are two images referenced on that page. The primary image and subject of that page is the equirectangular projection prepared by the USGS:

JEZ_hirise_soc_006_orthoMosaic_25cm_Eqc_latTs0_lon0_first.tif

I agree, the metadata seems to indicate that the 0.25 meters/pixel applies to the equator:


The following relations hold:

UpperLeftCornerX = MinimumLongitude * Scale * PixelResolution
UpperLeftCornerY = MaximumLatitude * Scale * PixelResolution
Scale = EquatorialRadius (or PolarRadius or CenterLatitudeRadius) * 2 * Pi / PixelResolution / 360

So, UpperLeftCornerX appears to be an easting based on the equator and not what the JPL operations team is using in the M20_waypoints.json feed. At our latitude of interest (~18.4663 degrees), the horizontal resolution becomes 0.25*cos(18.4663) = 0.237 meters/pixel. So the pixels aren't quite square. It seems desirable to use easting and northing "meters" that are close to equal where you'll be driving your rover so that's where this image comes in:

JEZ_hirise_soc_007_orthoMosaic_25cm_Ortho_blend120.tif

An orthographic projection centered on the target landing site (77.4298 Lon, 18.4663 Lat) where "meters" are nearly equal around the landing site. I suppose they chose orthographic projection (over equirectangular) because any distortion in "meters" as you move from the center of projection will apply to both easting and northing in a symmetrical manner instead of just one dimension as you would have with an equirectangular projection.

The second image seems to be superior from what I've seen, so in order to use it for Google Earth tiles, I'll have to resample it with something like bicubic interpolation to obtain an equirectangular projection with center latitude of 18.4663 degrees.

.
I'm sure there's already been a little squeezing (and stretching) here and there in order to get these projections from the original HiRISE images, so what's a little more?

Mark

There is really no mystery here, only an age old geographical problem. Compromises need to be made in order to render spherical planetary surface onto a 2d surface.

First we need to see how HiRise images are produced. Camera images the surface of Mars while in orbit around the planet looking straight down, so images are really in orthographic (OR) projection. But as images cover very small part of spherical surface of the planet, it is possible to approximate it as a 2d picture in equirectangular (EQ) projection with central longitude and latitude near the center of the imaged area (in essence we treat this area as it would be flat). That's why different HiRise images come all with the same EQ projection, but varying central longitudes and latitudes. EQ projection also has true scale latitude defined, which means only at this latitude scale will be in true meters. On this map straight lines looking to be of the same length but located at different latitudes would have different lengths in reality. Also lines are that are always straight in EQ projection will be curved in reality (except at central long/lat point).

To get straight lines straight in reality as well as on the map you have to choose orthographic projection with central long/lat at the center of the area of interest. That's way Perseverance's HiRise mosaic used for driving comes in
OR projection with central long/lat at 77.4298/18.4663. This particular coordinate is at the center of HiRise mosaic as well as very near to a predicted landing spot. So what you get is a map with approximates very well the spherical surface as
a 2d Cartesian space. In essence you get x/y grid defined with parallel longitudes and latitudes. So when planning rover's traverse you can simply plot a straight line from point A to B and be sure the this line is also straight on the surface of Mars.
Pretty important when navigating a 2.2 billion dollar rover on Mars.

Coming back to geoJSON data and why it uses ER projection coordinates. Well OR projection really doesn't have a true scale, so if you want to measure a distance in meters you have to reproject it into ER with appropriate true scale latitude. Only then will your measurment be in true scale meters. Thats's why easting and northing in geoJSON file are given in ER projection with central long/lat at 77.4298/18.4663.

I hope this helps.

Click to view attachment
Mars in OR projection with central long/lat at 77.4298/18.4663. Note that extent of Perseverance's mosaic (yellow rectangle) is totally rectangular in this projection.

Here are some maps of the Pathfinder site. One overview and three detailing the traverse of Sojourner. Take a look at the maps of Sojourner's travels in any other source - journal articles and the mission website... there's something lacking. The only one that looks good is a big polar projection, but it's simplified. The 'A' boxes are APXS analysis sites.

Phil
Click to view attachment.
Click to view attachment

And 2 more:
Click to view attachment.Click to view attachment


Phil

And a last one - should have been first, really.
Phil
Click to view attachment

Some Phoenix maps.
Phil
Click to view attachment
Click to view attachment


and a third one:
Click to view attachment

Stookes Pathfinder HiRISE/Pano reprojection

Separate images for first two Sojourner path maps.

I have started posting some things on:

https://mastodon.social/@PhilStooke

Almost everything I put there will have been seen here first.

I am starting with a set of maps of Mars landing sites, beginning with Viking 1.

https://mastodon.social/@PhilStooke/111511806000535744


Phil

Click to view attachment

I recently noted that a new Mars Express global color map was made available (download link).
I blended it with THEMIS global map, which resulted in this composite view of the Gale Crater. The contrast between "regular" surface and black sand dunes is really striking.

Click to view attachment

The same for Jezero crater region. Both maps are at the same scale.

It looks weird because Themis is mainly an infrared camera so its like a "multiwavelength" map