NOTE: The galeon mailing list is no longer active. The list archives are made available for historical reasons.
Frank Warmerdam wrote:
On 8/25/05, John Caron <caron@xxxxxxxxxxxxxxxx> wrote:Actually the above is correct for the CF conventions, see Appendix F (the projection parameters were originally taken from FGDC).John / Yang Liu,I stand corrected. Denis and I will review the document and workon implementing it in GDAL.The xdim and ydim coordinates specify the coordinates in projection space, this is more general than a projected origin and offset vector, allowing non-uniform spacing. For this data, the coordinates are uniformly spaced (.6 km), and the projected origin and bounds are easy to compute if you know how to construct the projection function. If not, then you have to fall back on using the lat,lon coordinates which are very often curvilinear. I guess the point is that the above is how we are used to seeing coordinate systems represented in these kinds of datasets. To summarize, from my experiencce anyway: 1. The x,y coordinates are orthogonal, but not necessarily uniformly spaced, in some projection. Typically the units are "km on the projection plane".Understood. It sort of sucks that we have to parse through the xdims and ydims and figure out that the spacing is uniform, but that isa small price to pay.
true
2. The projection function is typically parameterized, rather than being a predefined "well-known" EPSG. In practice, there are a dozen or so projections that are used. Standards like CF specify the names and meanings of the projection and its parameters.Understood. Much like in WKT. We can deal with that.
we should perhaps revive our CF-to-WKT translation project. I'll write the Java if youll write the C code ;^)
3. Knowing the projection and the coordinates fully specifies the georeferencing. I personally prefer this to having the 2D lat,lon coordinates.Certainly from my point of view knowing the underlying projectionparameters is far preferable to just having the lat/lon arrays.In fact, I would also mention that roughly 16/17ths of the resulting netCDF file is geolocation information. For each pixel there are two double precision location values ( lat and lon) for 1 byte of actual image payload. Is there any way of requesting the image data from the server without the geolocation lat/lonarrays?
as i told Yang Liu, the lat/lon is required if you need CF compliance. I agree they should be optional for these cases to save bandwidth. A weakness of the WCS is that theres no real mechanism to specify variations in how you want the data returned, just the "Format Type".
galeon archives: