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 <[email protected]> wrote: > On Fri, Dec 16, 2011 at 10:11 PM, John Caron <[email protected]> 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 <[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. > > 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 >> [email protected] >> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata >> _______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
