id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc
524	unit_conversion problems on longitudes and latitudes	Ian Culverwell	Ian Culverwell	"The transcription of the MT-IO-02 test from the test folder to a new suite has revealed that the ROPP unit conversion utilities are failing on latitudes and longitudes.  For example, if we take the input file '''MT-IO-02.nc''', which has
{{{
		lat:long_name = ""Reference latitude for the occultation"" ;
		lat:units = ""degrees_north"" ;
		lat:valid_range = -90., 90. ;
 lat = 67.0613, 67.0613 ;
}}}
then manually amend this (with NC operators) so that '''MT-IO-02.3.nc''' holds 
{{{
		lat:long_name = ""Reference latitude for the occultation"" ;
		lat:units = ""radians"" ;
		lat:valid_range = -1.5707963267949, 1.5707963267949 ;
 lat = 1.170441, 1.170441 ;
}}}
and then pass the latter through '''ropp2ropp''', we find that the resulting file '''MT-IO-02.4.nc''' has
{{{
		lat:long_name = ""Reference latitude for the occultation"" ;
		lat:units = ""degrees_north"" ;
		lat:valid_range = -1.5707963267949, 1.5707963267949 ;
 lat = 1.170441, 1.170441 ;
}}}

The units have been correctly renamed, but the data and valid_ranges have not been rescaled.  

Ditto for lat_tp.

If I try to do a similar thing with longitude, by converting
{{{
		lon:long_name = ""Reference longitude for the occultation"" ;
		lon:units = ""degrees_east"" ;
		lon:valid_range = -180., 180. ;
 lon = 39.74173, 39.74173 ;
}}}
to
{{{
		lon:long_name = ""Reference longitude for the occultation"" ;
		lon:units = ""degrees_west"" ;
		lon:valid_range = 180., -180. ;
 lon = -39.74173, -39.74173 ;
}}}
and passing the latter through '''ropp2ropp''', I find
{{{
		lon:long_name = ""Reference longitude for the occultation"" ;
		lon:units = ""degrees_east"" ;
		lon:valid_range = -180., 180. ;
 lon = -39.74173, -39.74173 ;
}}}
This time the valid_range has been correctly scaled (flipped), but the data values still haven't.

Ditto for lon_tp.

As far as I can see these are the only issues with the MT-IO-02 tests.  All the other sclaings and unscalings (descalings?) match within numerical precision.  Azimuth{_tp}, which might be expected to get messed up, looks OK, even if the numbers in the input file are inconsistent:
{{{
	float azimuth(dim_unlim) ;
		azimuth:long_name = ""GNSS->LEO line of sight angle (from True North) for the reference coordinate"" ;
		azimuth:units = ""degrees_T"" ;
		azimuth:valid_range = 0., 359.9 ;
azimuth = 0.433944, 0.433944 ;
}}}
and
{{{
	float azimuth_tp(dim_unlim, dim_lev1b) ;
		azimuth_tp:long_name = ""GNSS->LEO line of sight angles (from True North) for tangent points"" ;
		azimuth_tp:units = ""degrees"" ;
		azimuth_tp:valid_range = 0., 20620.7510467583 ;
azimuth_tp =
  114.5916, 114.5916, ...
}}}
This should be fixed while we're at it."	defect	new	normal	Whenever	ropp_io	9.0