+no_rot not supported ?

[mraspaud]

We have implemented the support of the omerc projection a while ago, but are now realising that the +no_rot parameter doesn't seem do be supported in fimex.
The way we implemented it is here:

fimex/src/coordSys/ObliqueMercatorProjection.cc

Lines 84 to 85 in 0a31b93

	if (boost::regex_search(proj4Str, what, boost::regex("\\+no_rot"))) {
	attrs.push_back(CDMAttribute("no_rotation", ""));

I couldn't find any other example of proj4 parameters without a value in fimex, so I'm wondering if what we implemented is actually supported, or if we implemented wrong ?

[heikoklein]

I'm not sure if I understand all this no_rot business, but there are is a discussion in the proj mailing-list about a change in the +no_rot implementation: OSGeo/PROJ#523 Which proj version do you use?

The reason why there are no other proj-parameters which don't map the CF-Convention is that we always tried to extend the convention to our needs before implementing it. When needed, it is usually no problem to get it implemented in CF. In particular, you can always add a projString attribute to the projection in the netcdf-file, and this will supersede all other parameters in the projection variable.

[mraspaud]

I understand the need to have the parameter in the CF-Conventions. However we tried to get projString to work, but the +no_rot parameter was obviously not being taken into account.
Regarding the proj version, I'm using pyproj 1.9.5.1 which embeds proj 4.9.3.

[heikoklein]

projString is used as is. If this is not the case, it might mean a bug in fimex. Can you send me a file (or a ncdump -h) including projString where it wasn't working. Then, I can check.

[mraspaud]

Here comes a netcdf file: https://drive.google.com/open?id=1_bX1sba0gZiYsWYl3J89RlICiQzEL53u

The dataset of interest is ct

[mraspaud]

Just for the record, PR #7 offers a better solution than +no_rot actually, so I'm not going to use this parameter for now.

[heikoklein]

Thanks for the file. Neither ncatted or python netCDF4 were able to read it, so I had to run a
ncks omerc.nc out.nc
to clean som hdf5 stuff?

Anyway, after renaming the grid_mapping_name to: unknown_to_fgdc
ncatted -a grid_mapping_name,omerc,o,c,unknown_to_fgdc out.nc

I get clearly the proj4 string you defined:

fimex --input.file out.nc --input.printCS
input CoordinateSystems: 2: CF-1.X=pal_colors_256:Undefined,pal_rgb:Undefined | CF-1.X=x:GeoX,y:GeoY;unknown_to_fgdc:grid_mapping_name=unknown_to_fgdc;long_name=omerc;false_easting=0;semi_minor_axis=6.35675e+06;false_northing=0;projString=+no_rot +lonc=-2.13356507672 +ellps=WGS84 +proj=omerc +alpha=9.23672932453 +lat_0=-0.269585480385;longitude_of_projection_origin=-2.13357;semi_major_axis=6.37814e+06;reference_ellipsoid_name=WGS84;latitude_of_projection_origin=-0.269585;no_rotation=1;azimuth_of_central_line=9.23673;;simpleSpatialGrid

including the no_rot parameter.

I tried the same also by renaming the grid_mapping_name to mercator, and it worked to. As long as the grid_mapping_name is oblique_mercator, fimex aborts earlier with a unknown projection message.

[mraspaud]

Interesting! what do I need to do to get fimex to accept oblique_mercator? I probably missed something when we made the PR last time

[alexander-buerger-met-no]

Can this been regarded as closed by pull PR #7?