id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc
452	Hold 'reference' POD values away from level1a	Ian Culverwell	Ian Culverwell	"This is the issue that has been referred to in #431 and #433. 

The basic point is that
{{{
ncks -H -v/data/occultation/position_rec_fixed eum_test.n4         
/data/occultation/position_rec_fixed
xyz[0] position_rec_fixed[0]=-4576838.62065 
xyz[1] position_rec_fixed[1]=4230563.95258 
xyz[2] position_rec_fixed[2]=-3612829.96993 
}}}
but
{{{
ncks -H -dt,0 -v/data/level_1a/closed_loop/r_receiver eum_test.n4  
/data/level_1a/closed_loop/r_receiver
t[0] xyz[0] r_receiver[0]=-3648067.50063 
t[0] xyz[1] r_receiver[1]=5056884.48351 
t[0] xyz[2] r_receiver[2]=-3607933.47362 
}}}

These are very different because the first are in ECF coordinates and the second are in ECI (J2000).

If we ask for some lev1a data, then {{{data%lev1a%r_leo(:,1:3)}}} becomes populated with the latter values, which is OK except when it comes to BUFR encoding, because this assumes ECF coords.  On the other hand, if we don't want any lev1a data but we do ask for BUFR data, then the first variables are read into {{{data%lev1a%r_leo(1,1:3)}}} - ie, a lev1a substructure of length 1.  This at least is in the right frame. 

There are two inconsistencies in the BUFR files produced by the two methods.  The first, which arises from the use of different frames of reference, could be fixed relatively easily by a call to {{{eci2ecf}}}. But the second, which arises from the fact that the prefered reference value is ''not'' equal to the first recorded satellite position, in any frame.  (It's the satellite positions at SLTA=0, for the EUM-data.)

A better solution would be to hold the reference values away from the level1a data, so that we can keep both in the same file.  Stig suggests the {{{data%georef}}} substructure, which seems sensible.

There may be lots of changes throughout ROPP (eg to copy/assign the new variables, and to not change existing behaviour or ucar2ropp and gfz2ropp), so it might be better to do this development in a branch.
"	enhancement	closed	normal	9.0	ropp_io	8.0	fixed	EUM data