A modest proposal for VOEvent

[Petr Kubánek]

Arnold,

I will happily avoid reinventing wheel and fully support its adoption in
VOEvent, if the wheel:

- has supported library I can use to do calculation for me
- or if it does not, is simply enough that I can create a library which
will do calculations from me

Unfortunately STC does not in my (and hopefully others) view meets any
of previous two requirements for standart wheel.

Regards from Blenheim, New Zealand, commissioning Yock-Allen 0.60cm -
with CAHA 1.23 on TODO list for this summer.

Petr

Arnold Rots píše v Čt 05. 03. 2009 v 18:18 -0500:
> Still reinventing the wheel, uh?
> 
>   <AstroCoords coord_system_id="TDB-ECLIPTIC-BARY" >
>     <Orbit>
>       <a unit="AU">1.5610990</a>
>       <e>0.4412673</e>
>       <i unit="deg">7.21282</i>
>       <Node unit="deg">353.14214</Node>
>       <Aop unit="deg">265.00121</Aop>
>       <M unit="deg">319.73232</M>
>       <T><ISOTime>1998-03-08T00:00:00</ISOTime></T>
>     </Orbit>
>   </AstroCoords>
> 
> 
> Rob Seaman wrote:
> > 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