"ctr" for "Location" group

[matthewjohnpayne]

As far as I can tell from the xmltompc80col.py code, it doesn't use the ctr variable, and just directly reformats the data from the pos1, pos2 and pos3 variables into the obs80-string.

• I.e. it is implicitly assuming that the input XML file contains geocentric coordinates, as the obs80-spec assumes geocentric coordinates (see SatelliteObs.html).

Previous typical submissions have used ctr = 399 (geocentric) within the Location group, and as such, this has not been a problem.

However, the NEO-Surveyor team have started producing simulation data that uses heliocentric coordinates for ctr, which breaks the above assumption, and hence the obs80 data produced by xmltompc80col.py is incorrect.

Various courses of action seem possible:

• Change the ADES spec to disallow heliocentric coords and/or force geocentric coords. In the specific case of NEO-Surveyor that seems reasonable, as the actual observable will indeed be the geocentric posn, so to report heliocentric will require them to introduce an ephem-based transformation. However if we disallowed ALL ctr's other than geocenter, that seems too restrictive. Perhaps just ban heliocenter and all barycenter coords?
• Change the ADES repo to continue supporting arbitrary ctr, but change the xmltompc80col.py code to allow the correct transformation from the supplied ctr to the geocentric coords required by obs80. This would presumably require introduce some direct dependency on ephemeris code / SPICE kernels / similar in order to perform said transformation, which is obviously highly non-trivial.
• Change the definition of the obs80 format to allow the integer in the 33rd position (see SatelliteObs.html) to take values beyond 1 & 2. E.g. posn33 = 3 could be used for heliocentric coords in units of AU. This would require only some small changes to the xmltompc80col.py code, but would implicitly require various orbit-computation and/or ephemeris codes be updated to correctly interpret positions from obs80 strings.

Discuss!

[Bill-Gray]

Discuss!

You're a bold man!

Gaia observations of solar system objects come with the satellite position relative to the solar system barycenter (in, for example, the .csv files from the most recent FPR release.) On conversion to ADES, my code therefore puts in <ctr>0</ctr>.

It occurs to me that (as with NEO-Surveyor) the actual observable probably isn't an SSB offset. However, I've had to handle Mars Express observations that were quite definitely relative to Mars. And I'm pretty sure there is Cassini astrometry where the observed spacecraft location is relative to Saturn, Dawn data relative to Ceres and Vesta (I was asked by the Dawn folks about orbit determination should they spot satellites around those two), and so forth.

Columns 70-77 of the second record for spacecraft observations are currently blank. Perhaps we could shove the SPICE code for the center in there (which would be 399=geocenter, 10=sun, 0=SSB). The maximum field width for ctr is a nine character integer plus optional sign, so that wouldn't work for everything... but we could encode such cases as sign plus ~ plus base-62 if (saints preserve us) we really run into that.

For your second choice (transform everything to the geocenter), you'd also have to transform the covariance for the position, which means you exchange a (say) well-determined Saturn-centric position for a miserably-determined geocentric one. Yuck.

[dfarnocchia]

I think that the only real problem is with barycentric coordinates, they are simply not well defined because different projects will use different solar system models. In my opinion that should not be allowed.

Other than that, I think that projects should be reporting what makes most sense. Tracking is Earth-based so I would imagine that geocentric will be the most common. But you could have observations from a Mars orbiter for which Doppler measures the Mars-centric position. In that case Mars-centric will make more sense and should be allowed.

[stevechesley]

Looks like general agreement here. But we should keep in mind that obs80 is obsolescent and slated for deprecation. There is no requirement that XML always be exportable to obs80, and there are already cases with significant loss in precision in obs80. Still, it seems reasonable for obs80 to continue to be supported for a very long time, but only on a "best-effort" basis.

I propose the following steps:

• [ ] (@stevechesley ) ADES documentation currently states, "To avoid model dependencies, the use of barycentric positions for ctr are to be avoided. Use public SPICE codes, e.g., 399 is geocenter, 10 is Sun center." This should be changed to say barycenters are explicitly prohibited and that 399 is the expected value for ctr. Any other value can be accepted only after prior coordination with the MPC. Enforcement of non-geocentric rules would be handled by the MPC rather than XSD.

• [ ] (@matthewjohnpayne ) NEO Surveyor will be requested/urged/implored/required to report geocentric s/c positions (and velocities). This is in principle better anyway and will allow continued routine processing of associated obs80 data from NEO Surveyor.

• [ ] (@stevenstetzler ) Train xmltompc80col to do the Right Thing. That means one of two options:

1. put the value of ctr in columns 70-77 of the 2nd record if and only if it is different from 399. The value can be truncated if it doesn't fit in 8 characters, which is not out of the question for a mission orbiting an asteroid. This allows the information to at least be communicated to obs80 users, most of whom will probably choose to ignore non-geocentric observations anyway.
2. or just have xmltompc80col skip non-geocentric observations and issue a warning. This would have the benefit of not requiring changes to the obs80 documentation. If this seems unkind refer to preamble above while contemplating how often this will be a real problem.

If we don't hear any objection we will move ahead with option 2

@matthewjohnpayne If we get a thumbs up from the MPC then we can proceed.

@Bill-Gray It is my understanding that Gaia astrometry is now available with geocentric states, which is significantly superior to barycentric states. And so there is so far still no need to be able to handle non-geocentric data in MPC exports.

[dfarnocchia]

About Gaia: yes, they do provide geocentric states in their latest data release. However, they use the TCB time scale which means that positions (whether barycentric or heliocentric) need to be scaled by (1−LB), where LB = 1.550519768e−8 to be used with a TDB time scale. It is my understanding that this will be fixed in future data releases or at least for MPC submission.

[federicaspoto]

About Gaia, I just wanted to confirm that they do provide geocentric states in the FPR and as Davide said, the positions need to be rescaled. We are working on creating the ADES format for Gaia observations and the Gaia positions will be geocentric and already rescaled, which means ready to use.

[Bill-Gray]

@stevechesley @dfarnocchia @federicaspoto Thank you for pointing all this out. I'd completely missed the addition of geocentric states in the FPR. Modifying my code to use them was straightforward.

I don't have those values multiplied by (1-LB) at present, but can do so readily enough. I assume that only the positions should be multiplied by that factor? Seems to me that for the velocities, it ought to cancel out. Of course, with the use of geocentric states, the difference in position is about 20 meters instead of 2.3 km...

[dfarnocchia]

Another good reasons for using geocentric... even if users forget to scale the error is much smaller. Velocities don't need to be scaled, as you say

[joemasiero]

Hi all, just to clarify, NEO Surveyor will not be submitting any obs80 data. Everything we send in will be in ADES. Re: helio- vs geocentric, I believe our NAV team is fitting and reporting the spacecraft orbit in the heliocentric frame. DSN geocentric range and rate are used for updates, but geocentric is not the native orbit fit as far as I know. It's possible for us to convert position before submission, but that introduces the possibility of information loss potentially.

[dfarnocchia]

Hi @joemasiero,

Yes, the Nav team can certainly use the heliocentric state of the spacecraft as the estimated state in the fit. That is just a choice on how the orbit determination filter is set up. But the tracking will be from the ground and so the geocentric state of the S/C is really what is being measured and best constrained. It would be different for an orbiter of a planet, but not at a Lagrangian point.

Gaia had a similar issue: they were using the barycentric state internally. But the real measured state was relative to Earth. Barycentric is worse than heliocentric because much more model dependent: the relative position between Earth and Sun doesn't change much with different planetary ephemerides, the barycenter can change in a significant way.

Anyway, it should be easy for NEO Surveyor to convert to the geocentric state in an internally consistent way and report it. If not, we can probably work with heliocentric. But that doesn't seem to be the optimal choice

[joemasiero]

Hi @dfarnocchia, one wrinkle is that we will not be reporting reconstructed positions, but rather forward predicts of the best-fit state. We don't have time in the data processing stream to rectify the positions prior to submission to the MPC (this is similar to what we do for NEOWISE). I've put a Q into our Nav team about what they recommend we report, and will let you know.

[Bill-Gray]

@joemasiero - I suspect you've plenty of company in submitting a predicted (or approximate) state. It's common for me to see that current spacecraft offsets from Horizons have some deviation from what was reported in the astrometry. So I think this is a general (not NEO Surveyor) specific issue. I don't know how often it makes a noticeable difference.

My initial thought was to provide a note to distinguish "approximate" from "final" state vectors. But perhaps better is to use the existing spacecraft position covariance (posCovnn) in ADES. Even if you don't have a real covariance matrix for the state vector, you can at least say "the position is known to within 100 km" when submitting the observations, and then later submit updated observations with a tighter uncertainty and more reality-based covariance.

I'd bet a beer that for both your predicts and reconstructed state vectors, the uncertainty in the geocentric state will be significantly less than that for the heliocentric state. It's hard for me to imagine how it could be otherwise; I'm fairly sure I'd win that beer. But I don't know enough about how you're navigating to bet much more than that.

It might help in all this if Horizons reported a spacecraft state vector covariance matrix. As best I can tell, it does so, but only at the epoch of the elements; you can't get an ephemeris of covariances.

[joemasiero]

Feedback from the Surveyor Nav folks at JPL also supports reporting geocentric instead of heliocentric as being the most well constrained. I'll talk with the NSDC folks at IPAC about getting this change implemented. Thanks for all the discussion on this.

[stevechesley]

After much further discussion among MPC, JPL and @Bill-Gray , the ADES standard will restrict the value of ctr to allow only geocentric spacecraft positions for the foreseeable future. This has the side benefit of not changing the obs80 standard. And no changes are required for xmltompc80col.py. PR #55 will be revised to take this approach.

If a future (or past) space mission does produce astrometry for which the geocenter is not an appropriate origin then a new value for ctr can readily be added to the enumerated list. The most obvious such scenario would be for a spacecraft orbiting a planet and observing a satellite of the same planet. Another case would be of a spacecraft orbiting/stationkeeping near a small body and reporting observations of a satellite of that small body.

[stevechesley]

Resolved with PR #55.