search

metno / fimex

File Interpolation, Manipulation and EXtraction
Other
24 stars 16 forks source link

+no_rot not supported ? #6

Open mraspaud opened 6 years ago

mraspaud commented 6 years ago

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: https://github.com/metno/fimex/blob/0a31b931b0fa7f32eef02e7653d58098ea5de227/src/coordSys/ObliqueMercatorProjection.cc#L84-L85

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 commented 6 years ago

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: https://github.com/OSGeo/proj.4/issues/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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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

The dataset of interest is ct

mraspaud commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 5 years ago

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