Registration export datum other than WGS 84

My images are referenced to seleographic (Moon) control points and I am trying to export planetocentric camera poses using Export > Registration in RealityScan 2.0.1. I have tried XYZ heading/pitch/roll (although Colmap format has the same issue). I was careful to choose Coordinate System: Project output.

I have specified the following custom coordinate systems in a local.xml file and changed my project coordinate system to MOON_LONGLAT and output coordinate system to MOON_CENTERED:

But exported camera XYZ coordinates always appear as if the WGS 84 coordinate system is used. For example, here is one of my GCPs after alignment that is displayed correctly in the Moon longlat system:

As can be seen from the GCP, the survey target is roughly at 44.1 degrees north, 19.5 degrees west, altitude -2631 m. Plugging these figures into gdaltransform gives:

$ echo “-19.5 44.1 -2631” |gdaltransform -s_srs ‘+proj=longlat +a=1737400 +b=1737400 +no_defs +type=crs’ -t_srs ‘+proj=geocent +a=1737400 +b=1737400 +no_defs +type=crs’
1174326.97040747 -415850.990444991 1207247.94623165

These XYZ values are roughly what I would expect.

However, in my registration export csv I get incorrect values such as the following:

4331592.902058617,-1534367.917683161,4415285.569108639,-69.11530513829301,56.46322609507894,4.160717252731851

4331413.96503805,-1534320.795447757,4415295.486985723,-69.10845355903031,56.36617659848122,4.108447263335862

These values roughly correspond to what you would get if we assume that RealityScan was converting coordinates using a WGS 84 datum. To confirm, I tried gdaltransform again:

$ echo “-19.5 44.1 -2631” |gdaltransform -s_srs ‘+proj=longlat +datum=WGS84 +no_defs’ -t_srs ‘+proj=geocent +datum=WGS84 +no_defs’
4322823.24826449 -1530791.99797794 4414246.74210373

How can I make RealityScan respect my custom datum when exporting?

Hi @dirkp3001

This is an interesting use case. How do your definitions look? Is there also defined the used ellipsoid? Can you try to use only MOON_CENTERED system?

Here is my local.xml:

<CoordinateSystems authority="Local">
    <cs id="1" desc="MOON_LONGLAT" params="+proj=longlat +a=1737400 +b=1737400 +no_defs +type=crs" />
    <cs id="2" desc="MOON_CENTERED" params="+proj=geocent +a=1737400 +b=1737400 +no_defs +type=crs" />
</CoordinateSystems>

I also tried various combinations of project and output coordinate systems (e.g., MOON_LONGLAT/MOON_LONGLAT, MOON_CENTERED/MOON_CENTERED) and the results are not correct either.

Note that for the combination MOON_CENTERED/MOON_CENTERED, the converted position shown for one of my MOON_LONGLAT GCPs also looks like it is assuming WGS 84:

Hi, I tested this on my data (but I don’t have moon’s one) and for me the exported coordinates were in the same system as I used. Would it be possible to share your data for a proper testing? If so, I’ll send you the invitation for the data upload.

The values are off the moon, but in the expected range for me:

I noticed that your GCP seems to be assuming X, Y, alt which is not a geocentric coordinate system. MOON_CENTERED is a geocentric system.

I will try to convert everything to a lunar geodetic system to see if that works (e.g., ‘+proj=eqc +lat_0=0 +lon_0=180 +x_0=0 +y_0=0 +R=1737400 +units=m +no_defs +type=crs’).

In the mean time, I’m fine with sharing as it is public scientific data (there are about 170 1024x1024 8-bit images). Please send me a data upload invitation.

Yes, I was just trying to provide a quick test with the data I have.

The invitation was sent, it can be in your spam folder.

Actually, changing everything to eqc cartesian (‘+proj=eqc …’) seems to have worked! I changed project, output coordinate systems, and converted GCPs to eqc and the values in the exported registration are now very plausible.

Added the following to local.xml:

    <cs id="3" desc="MOON_EQC" params="+proj=eqc +lat_0=0 +lon_0=180 +x_0=0 +y_0=0 +R=1737400 +units=m +no_defs +type=crs"/>

Sample GCP:

1 4866660.23363903 1337735.94062529 -2631.39038085938

Registration export:

4866555.834480618,1337895.964133604,-2587.604306787252

4866555.796092062,1337895.894561155,-2594.03595831804

1 Like

It’s good to hear that! Thank you for sharing your solution with us.