On 12/15/2011 8:03 AM, Etienne Tourigny wrote:
John, thanks for your answers.
Would anyone be kind enough to point me to real files that use the
projections mentioned in this thread?
Answers below, but here is a quick summary of my recommendations
1) LCC: calculate the missing scale_factor from other parameters (no
changes to CF)
2) CEA: drop the scale_factor_at_projection_origin variant all
together, or add a scale_factor parameter to that variant.
3) PS: add an optional parameter (Scale factor at natural origin) that
defaults to 1 if absent
On Wed, Dec 14, 2011 at 2:21 PM, John Caron<[email protected]> wrote:
Hi Etienne:
Generally, CF has followed proj4 conventions as much as we could, and John
Snyder's reference book is often underneath:
http://pubs.usgs.gov/pp/1395/report.pdf
OGC specs tended to come from experts using the EPSG, and generally we are
less familiar with that.
some specific comments below, based on my own understandings.
On 12/13/2011 2:21 PM, Etienne Tourigny wrote:
Hi all,
I am opening a seperate thread at this deals merely with the problems
encountered in translating projection parameters to/from OGC WKT and
CF-1.5.
I would appreciate any guidance in resolving these issues.
In summary:
1) LCC (Lambert conformal): should include a scale_factor parameter in
the 1 standard parallel case
2) CEA (Lambert Cylindrical Equal Area): how to convert the
'scale_factor_at_projection_origin' alternative to standard parallel
to OGC WKT?
3) PS (Polar stereographic):This projection's parameters in CF-1 are
significantly different from OGC/PROJ.4 , CF-1 standard parameters
'Either standard_parallel or scale_factor_at_projection_origin' is
incompatible with OGC WKT, which requires both
More detailed information (reproduced here) can be found at
http://trac.osgeo.org/gdal/wiki/NetCDF_ProjectionTestingStatus
1) LCC 1SP (Lambert conformal)
The OGC WKT 'Lambert_Conformal_Conic_2SP' maps clearly to LCC in CF-1
with 2 std parallels.
The CF-1 spec claims that a 1SP version can be used, but it doesn't
include a 'scale_factor' as does the OGC WKT
'Lambert_Conformal_Conic_1SP'.
For import: Given discussion and example on #3324, and also support
from NARCCAP project: it seems the CF-1 LCC 1SP projection is a
'degenerate' LCC-2SP with both SP's at the same location. Thus seems
we can read with both 'std_parallel' (1 value) and
'latitude_of_projection_origin' mapping to latitude_of_origin (WKT)
and setting scale_factor=1? This is the code's current behaviour
(though perhaps could do more error-checking).
yes, we handle both 1 and 2 standard parallels in the same projection. the
1 parallel can be thought of as a degenerate case of the 2 parellels.
AFAIU, the scale factor is determined by the standard parallels, so is
reduntant to specify, see Snyder, equation 15-4.
As you follow proj4 closely, it could make more sense to use the proj4
string for LCC1SP, as described in [1]
+proj=lcc +lat_1=Latitude of natural origin
+lon_0=Longitude of natural origin
+k_0=Scale factor at natural origin
+x_0=False Origin Easting
+y_0=False Origin Northing
But this is another issue, I think that we can manage the CF-WKT conversion.
i agree that the CF parameters are misnamed
Given the way CF stores LCC1-SP parameters, I see how to calculate k_0
(scale factor at natural origin), using eq. 15-4 with CF
standard_parallel1 and latitude_of_projection_origin .
However, when converting a OGC WKT to CF grid_mapping, I don't see
how to do the inverse calculation , which requires to obtain
latitude_of_projection_origin from proj4 parameters above.
The example given in
http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.5/cf-conventions.html#lambert-conformal-projection
is trivial, as standard_parallel1=latitude_of_projection_origin=25.0 ,
therefore k_0 is 1, and the inverse is trivial
It is my understanding from [1] that the 1SP is usually considered to
have a scale factor of 1, and when it is not the 2SP form is preferred
(with a scale factor of 1 for each SP) .
Therefore, would it make sense to do the following?
1)
CF->WKT : calculate scale_factor using eq. 15-4 and use the 1SP form
WKT->CF : set standard_parallel1=latitude_of_projection_origin, but
return an error if scale_factor != 1
2)
Another option would be that, if a CF definition contains 1SP and the
computed scale_factor is not 1 (because standard_parallel1 !=
latitude_of_projection_origin), then use the 2SP form in WKT.
A conversion back to CF would then work (in a 2SP form), although the
SP would probably not have integer values of degrees or degrees and
minutes (see [1]).
I prefer the second option as it closes the loop. Any examples of 1SP
with standard_parallel1 != latitude_of_projection_origin out there?
[1]
http://www.remotesensing.org/geotiff/proj_list/lambert_conic_conformal_1sp.html
its possible that the more general case is to use another constant to
multiply the one given in 15-4, but i have never seen that.
hmm which constant do you refer to?
see below
Im not sure what #3324 refers to.
sorry, this refers to gdal trac #3324 at http://trac.osgeo.org/gdal/ticket/3324
For export: given the LCC-1SP can specifically include a scale_factor
to control the projection (see
http://www.remotesensing.org/geotiff/proj_list/lambert_conic_conformal_1sp.html),
it seems this can't be directly exported to NetCDF without throwing
away the scale factor.
Perhaps the reasonable thing for now is to export the scale_factor to
NetCDF, so it can at least be read back in. Otherwise, we'd have to
try to translate the LCC-1SP to a LCC-2SP on the fly.
Ok, so according to this note from
http://www.remotesensing.org/geotiff/proj_list/lambert_conic_conformal_2sp.html:
Sometimes however, although a one standard parallel Lambert is
normally considered to have unity scale factor on the standard
parallel, a scale factor of slightly less than unity is introduced
on this parallel. This is a regular feature of the mapping of some
former French territories and has the effect of making the scale
factor unity on two other parallels either side of the standard
parallel. The projection thus, strictly speaking, becomes a Lambert
Conic Conformal projection with two standard parallels. From the one
standard parallel and its scale factor it is possible to derive the
equivalent two standard parallels and then treat the projection as a
two standard parallel Lambert conical conformal, but this procedure
is seldom adopted.
It does seem that there is an additional scale factor that CF doesnt
have, with the effect as as stated. however, it appears that it is
equivilent to specifying the standard parellels. I understand there is
no obvious formula for this.
2) CEA (Lambert Cylindrical Equal Area):
The CF-1 conventions claim this can be encoded with a
'scale_factor_at_projection_origin' alternative to standard parallel -
how would this conversion be done from/to OGC WKT (which requires
central_meridian and standard_parallel_1)?
It does appear at first glance that there should be a seperate scale factor.
I am less familiar since I havent coded this one.
> From 10-2b and 10-2a it seems that scale_factor_at_projection_origin
(k0) is a simple function of standard_parallel1 and
latitude_of_projection_origin.
However, latitude_of_projection_origin is not part of that
projections' parameters, so there is no way to convert that variant to
proj4 and WKT.
Also the proj4 string does not include the scale factor.
+proj=cea +lon_0=Central Meridian
+lat_ts=Standard Parallel
+x_0=False Easting
+y_0=False Northing
Any examples using the scale_factor_at_projection_origin?
If not I would propose to drop that variant all together, or add the
scale_factor to that variant.
i dont have any example of this at all.
Frankly, Im not sure why this was added to CF. I do not add a projection
until I have a real example of a dataset that uses it.
3) PS (Polar stereographic)
This projection's parameters in CF-1 are significantly different from
http://www.remotesensing.org/geotiff/proj_list/polar_stereographic.html.
In particular the CF-1 equivalent for 'latitude of natural origin'
seems to be 'standard_parallel'.
i agree, i dont know where these CF names came from.
That doesn't really matter as long as we know what the mapping is.
Reading [2] more attentively, it seems that scale factor is normally
1, so it would be ideal to add an optional parameter (Scale factor at
natural origin) that defaults to 1 if absent.
[2] http://www.remotesensing.org/geotiff/proj_list/polar_stereographic.html
CF-1 defines either standard_parallel or
scale_factor_at_projection_origin, which is incompatible with OGC WKT
(and OGR) that requires both. Note: we have verified the current
approach we take to mapping is the same used by at least one other
NetCDF CF-1 user in the UCAR NARCCAP project.
snyder 21-7 gives the formula for the scale factor, which can easily be
inverted to derive the "standard_parallel" which i think just means the
latitude at which the scale factor = 1. Thats why in CF you give one or
the other. so my guess is that the OGC is specifying redundant info.
GRIB-1 has "Grid lengths are in units of metres, at the 60-degree
parallel nearest to the pole on the projection plane." If one uses 21-7
to compute the scale factor at the pole that makes scale factor = 1 at
60 degress, one gets 0.9330127018922193. use this for GRIB-1 GDS=5, and
lo! the pictures look correct. GRIB-2 allows the user to specify and
wowwa! they often have 0.933.
"straight_vertical_longitude_from_pole" just gives the longitude at
which x = 0, as you have figured out. dunno where these names came from,
no doubt historical accidents.
Current implementation (as of Dec. 13) uses the following rules:
- WKT scale_factor maps to CF scale_factor_at_projection_origin
- WKT central_meridian maps to CF straight_vertical_longitude_from_pole
- WKT latitude_of_origin maps to WKT standard_parallel
- WKT to CF: if WKT latitude_of_origin is positive then CF
latitude_of_projection_origin is +90, else it is -90 (North vs. South
Pole)
- CF to WKT: unsupported if standard_parallel is not defined, as
OGRSpatialReference::SetPS() requires both CF
scale_factor_at_projection_origin
Im guessing these rules may have to be specific to a projection, rather than
assuming you can do a global mapping of the attribute names.
They are indeed. Currently we use a set or predefined mappings (for
any projection which is not in CF), but each CF projection has its set
of mappings and there is a specific algorithm for Polar Stereographic
(described above).
It is not formally documented but the header file for GDAL's netcdf
driver is pretty explicit:
http://trac.osgeo.org/gdal/browser/trunk/gdal/frmts/netcdf/netcdfdataset.h?format=txt
Also the page mentioned earlier outlines the problems I am discussing here:
http://trac.osgeo.org/gdal/wiki/NetCDF_ProjectionTestingStatus
Now that you mention this, it would be nice to extend the wiki at
https://cf-pcmdi.llnl.gov/trac/wiki/Cf2CrsWkt , but with
per-projection mappings.
I would like to incorporate your findings into the CDM library when I can.
can you point me to more information on this?
http://www.unidata.ucar.edu/software/netcdf-java/reference/StandardCoordinateTransforms.html
regards,
John
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
