On Fri, Dec 16, 2011 at 10:11 PM, John Caron <caron at unidata.ucar.edu> wrote:
> 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 <caron at unidata.ucar.edu> 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.
All examples I have seen of the 1SP version have
latitude_of_projection_origin==standard_parallel, which is the case
of "unity scale factor on the standard parallel". Have you seen any
examples otherwise?
(The one given in the cf-1.5 page is a clear example)
I would suggest that users should use the 1SP version for the "unity
scale factor on the standard parallel" case, and the 2SP version
otherwise, and the documentation could be updated to reflect that.
This would resolve the confusion once and for all.
>
>
>
>
> 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.
Can we drop from the cf convention the
"scale_factor_at_projection_origin" for CEA then?
>
>
>
>
>
> 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.
Allright, I think I have understood. EPSG (Geomatics Guidance Note
Number 7, part 2) has 2 variants for Polar Stereographic, which are
in line with what you are saying:
A) the latitude of origin is either the north or the south pole, at
which is defined a scale factor at the natural origin ...
B) instead of the scale factor at the pole being defined, the
(non-polar) latitude at which the scale is unity ? the standard
parallel ? is defined.
It seems that GDAL/OGR only supports variant A, and does not enforce
latitude of origin to be +90 or -90 , I will try to have that fixed.
In the mean time I will ensure that OGR WKT-CF interoperability is
correct, at least from a metadata point of view. Thanks!!!
>
> 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
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
Received on Wed Dec 21 2011 - 14:12:17 GMT
