An update on LCC-1SP:
I have modified the GDAL driver to compute scale_factor from CF
parameters ( std_parallel and latitude_of_projection_origin), and keep
the std_parallel1 (which is not OGC WKT for LCC-1SP), so it exports
back to CF without a hitch.
The only exception is translating from WKT to CF, with scale_factor !=
1 and no std_parallel1 (a valid OGC WKT), there is no valid CF
definition (because I can't see how to get std_parallel from
scale_factor and latitude_of_projection_origin). In this case, the 2SP
variant is preferred (but I don't know how to compute it). On the
positive side, at least GDAL is able to read it back so no information
is lost.
For anyone interested here is the trac entry:
http://trac.osgeo.org/gdal/ticket/3324#comment:13
Regards,
Etienne
On Thu, Dec 15, 2011 at 1:03 PM, Etienne Tourigny
<etourigny.dev at gmail.com> 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.
>
> 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.
Here i meant standard_parallel1
>
> 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?
>
>>
>> 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.
>>
>>
>> 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.
>
>>
>>
>>
>> 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.
>>
>> 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?
>
>> Do you have any official documentation describing this mapping?
>>
>>
>> Thanks
>> Etienne
>> _______________________________________________
>>
>>
>> The question for CF is whether we should start to follow the WKT spec
>> closer, and add aliases where needed.? I would prefer this since most of us
>> arent experts in this sort of thing. Which is pretty much the whole argument
>> for adopting WKT as an alternative to what we have done.
>>
>> john
>>
>>
>>
>> _______________________________________________
>> CF-metadata mailing list
>> CF-metadata at cgd.ucar.edu
>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>>
Received on Thu Dec 15 2011 - 15:26:10 GMT
