I have submitted a trac ticket to deal with the
definition/documentation issues mentioned in this thread:
https://cf-pcmdi.llnl.gov/trac/ticket/75
regards,
Etienne
On Wed, Dec 21, 2011 at 7:12 PM, Etienne Tourigny
<etourigny.dev at gmail.com> wrote:
> 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 Jan 25 2012 - 06:35:13 GMT
