id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc
465	Increase centre of curvature range limits	Ian Culverwell	Ian Culverwell	"Christian Marquardt (EUM) reports a problem from a user:
{{{
Dear Josep,

I’ve added Ian and Kent (for the ROPP) as well as Harald to the 
list (as I think he’s the IROWG bufr guru).

Some background: the test data streams on the ftp server 
(GRAS_Geometrical_Optics and GRAS_Wave_Optics) are fed by our 
prototype system. The GRAS_NRT data stream on the ftp server is fed 
by the operational software in our validation ground segment. 
Scientifically and with respect to the bending angle profiles, the 
prototype and operational code provide the same results (when using 
equivalent versions); but there are some technical differences. One 
is the generation of bufr; we use the ROPP in the prototype setup, 
but an internal solution in the operational code. In this case, I 
believe the problem is in the ROPP

You are right that the bufr files has missing components in r_coc; 
values are:

   r_coc =  20459.17, -9.9999e+07, 12089.03 ;

The original  level 1b product however has 

     r_curve_centre_fixed = 20459.1650542901, 82510.4888887256, 
        12089.0251200038 ;

so the bufr version has the correct numbers, but the second 
coordinate must have been set to missing in the conversion process. 
The ROPP we use appears to use a valid_range for the CoC 
coordinates of [-50000, 50000] meters, but the coordinate affected 
has 82500 meters – that is why it was set to invalid I presume.

@Ian, @Kent: Is there a reason for the range limitation in ROPP? 
Should we update the valid_range in the next ROPP release? If you 
could suggest a better choice we would update our ROPP installation 
accordingly.

@Harald: I haven’t found any reference to valid ranges for the CoC 
in the bufr specification, but I tend to overlook such subtleties. 
Do you think there is a limitation? Should there be one?

We will check what the operational code does; my assumption is that 
it copies values correctly into the bufr, but postprocessing with 
the ROPP tools might again re-introduce the missing data values. 
And right now, we don’t have a bufr reader other then the ROPP. 
I’ll let you know about the outcome.

@Josep, thanks again for making us aware of this bug, and please go 
on doing that!

   Chris.
}}}"	defect	closed	normal	9.0	ROPP (all)	8.0	wontfix	bufr, ropp_io