A modest proposal for VOEvent

[Rob Seaman]

Hi Bob,

I'm all for promoting adoption of prevetted standards.  MPC 1-line  
format represents a C-like struct datatype.  Maybe this is something  
to support, or maybe the XML-ness of breaking it out into explicit  
variables should win out.  Arguments from both sides?

Rob
----

On Feb 22, 2009, at 5:42 PM, Bob Denny wrote:

> Rick Hessman:
>> I believe the thing to avoid is
>>
>> 	<orbitalElements q="1.2345" P="9.54321" Punits="days" ...   />
>>
>> as too compact and illegible...
>
> and the values cannot be validated by a schema-driven parser. I  
> agree that this
> is the wrong way to go!
>
>> ... and
>> 	<orbitalElements>
>> 		<q>
>> 			<units>none</units>
>> 			<value>1.2345</value>
>> 			...
>> 		</q>
>> 		...
>> 	</orbitalElements>
>>
>> as too verbose and cumbersome to parse.
>
> Also agreed. It's the opposite end of the spectrum and just as bad.
>
>> The only reasonable system
>> is to use attributes for secondary information, e.g.
>>
>> 	<orbitalElements>
>> 		<q units="none">1.2345</q>
>> 		<P units="days">9.54321</P>
>> 	</orbitalElements>
>>
>> but then, everyone has their own tastes (and those tastes even  
>> change).
>
> I'm a KISS Principle guy. The MPC has standard formats for numbered  
> asteroid and
> cometary elements already, the so-called "1-line" format(s).  
> Everyone knows what
> these are, how they are formatted, and what units they are in.  
> They've been
> around for many years. MP versus cometary can be determined by  
> inspection. So
> something as simple as
>
>   <orbitalElements>K01FI5V  7.7   0.15 K014L   0.10308 ...</ 
> orbitalElements>
>   <orbitalElements>    PJ97T030  1998 03  9.3751  ...</ 
> orbitalElements>
>
> would carry everything there is to know about the elements. If only  
> the number
> or designator is given, that could automatically reference the MPC's  
> orbital
> elements database. That would provide the "latest" elements if that  
> were
> preferable (maybe you want to specify the elements that WERE used  
> and not the
> elements TO use). So
>
>   <orbitalElements>K01FI5V</orbitalElements>
>   <orbitalElements>0029P</orbitalElements>
>
> Now what about NEOs which have only a rough short-arc orbit, and for  
> which there
> are no elements available? I've successfully used the MPC's "NEOCP  
> Ephemeris"
> format. Needless to say, the position of an NEO is not well known  
> very far
> ahead, so this would apply only to timely observations in response  
> to a VOEvent.
> In that case, some ephemeris lines covering the expected validity  
> period of the
> event, spaced an hour or two apart, should be "good enough". One can  
> do
> something like a Lagrange interpolation over that data and get a  
> pretty good
> position. So something like
>
>   <ephemeris name="A123456789">
>      <pos>2004 10 27 02    01.6915    -40.095</pos>
>      <pos>2004 10 27 03    01.6834    -40.167</pos>
>      ...
>   <ephemeris>
>
>  -- Bob
>