'General' vs. 'submit' ADES, and names

[Bill-Gray]

Today, I started work on having my code output ADES data with residual group data in it. I think it'll be useful to be able to provide astrometry and say "here are the sigmas I actually used in fitting an orbit, the debiasing I applied, and whether or not this observation was actually included in the fit, and here are its residuals", all conveniently stored in ADES in a format that can be exchanged. (*)

I've never actually tried to validate a file against general.xsd, only the submit.xsd schema. I was dismayed to see that the submitter and observer names and telescope details are required, even with general.xsd. I don't usually really have those details. ADES files from MPC lack them.

I suppose I could add a bunch of <name>A. Nonymous</name>s (in fact, I've done that just to get past this particular stumbling block), but it would be nice not to have to do that for verification against general.xsd.

(*) When ADES was originally proposed, I was not a fan. Actually, I was quite horrified. However, the flexibility it provides to do things like this is pretty impressive; I've come around.

[federicaspoto]

Hi Bill,

I am not sure I completely understand. Are you using the general.xsd file to validate the observation file or the residual file? Because we (MPC) use the general.xsd all the time to validate the observations and we don't need to add the obscontext part to the XML. (Also the submit part for submissions) This is an example of how we use it the general one: python3 <your-ades-name-repo>/Python/bin/valgeneral.py <xmlfile>

Also, submit.xsd does not require observer names anymore.

Thanks, Federica

[Bill-Gray]

Hi Federica,

I think I've puzzled my way around this, by means of looking at the ADES data for NEOCP objects on the MPC site and imitating it. So I think we can close this.

By default, my XML output includes an <obsBlock>, followed by an <obsContext> listing submitters, measurers, observers, and telescopes, followed by an <obsData> with the observations from that MPC code. If there's an <obsContext> block, it has to have at least one submitter, one observer or measurer, and telescope data. Without those, it fails.

I can do what you've done for the NEOCP data : one line gives the ADES version, and then there's just a series of <optical> blocks. So the data is an all-or-nothing affair. If I know, say, the telescope and observer/measurer, but not the submitter, I either have to fake the submitter or just omit the block. (Which I can live with. And, of course, the result will be suitable for general.xsd and not for submit.xsd.)

Ideally, you'd be required to provide the submitter/observer/measurer/telescope data in full for a submission, but could include only the parts you actually know when validating against general.xsd. This may be an edge case not worth revising the standard for, though.

Background : most of my efforts here are to convert 80-column sungrazing comet astrometry, sent to me by Karl Battams, into submission-format ADES. I think I have all the pieces needed for that, because in that case, I do know the submitter (it is I) and who the observers and measurers are, and which telescopes were used. In other cases, of course, I may have only some of that information.

Thanks! -- Bill