Roger André wrote:
Hi all,
Just a couple quick netCDF related questions:
1) Is there any way to include projection information in a netCDF
file so that gdal can properly read it? It appears that
georeferencing is handled correctly, but not projection info. This
causes problems with the whole "north/south origin shift" between the
netCDF and other raster formats when gdal is used to convert the .nc
file into a GeoTIFF. Most notably, I'm not sure how to assign the
data a projection - either for display in MapServer, or to reproject
it to EPSG:4326: See example below.
File created with ArcGIS 9.3:
$ gdalinfo fwdir_bas.nc
Driver: netCDF/Network Common Data Format
Files: fwdir_bas.nc
Size is 42000, 42000
Coordinate System is `'
Origin = (65.000000000000000,5.000000000028436)
Pixel Size = (0.000833333333333,0.000833333333333)
Metadata:
NC_GLOBAL#Conventions=CF-1.0
NC_GLOBAL#Source_Software=ESRI ArcGIS
Fwdir_bas#long_name=Fwdir_bas
Fwdir_bas#esri_pe_string=GEOGCS["GCS_WGS_1984",DATUM["D_WGS_1984",SPHEROID["WGS_1984",6378137.0,298.257223563]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]]
Fwdir_bas#coordinates=lon lat
Fwdir_bas#units=Degree
Fwdir_bas#missing_value=
lon#long_name=longitude coordinate
lon#standard_name=longitude
lon#units=degrees_east
lat#long_name=latitude coordinate
lat#standard_name=latitude
lat#units=degrees_north
Roger,
The above example is not projected as far as I can see. It is
geographic. So I'm not sure what this was intended to be an
example of.
If I use gdal_translate to convert a utm GeoTIFF file to
Netcdf I get a gdalinfo report like below.
Driver: netCDF/Network Common Data Format
Files: out.nc
Size is 512, 512
Coordinate System is:
PROJCS["NAD27 / UTM zone 11N",
GEOGCS["NAD27",
DATUM["North_American_Datum_1927",
SPHEROID["Clarke 1866",6378206.4,294.9786982139006,
AUTHORITY["EPSG","7008"]],
AUTHORITY["EPSG","6267"]],
PRIMEM["Greenwich",0],
UNIT["degree",0.0174532925199433],
AUTHORITY["EPSG","4267"]],
PROJECTION["Transverse_Mercator"],
PARAMETER["latitude_of_origin",0],
PARAMETER["central_meridian",-117],
PARAMETER["scale_factor",0.9996],
PARAMETER["false_easting",500000],
PARAMETER["false_northing",0],
UNIT["metre",1,
AUTHORITY["EPSG","9001"]],
AUTHORITY["EPSG","26711"]]
Origin = (440720.000000000000000,3751320.000000000000000)
Pixel Size = (60.000000000000000,-60.000000000000000)
Metadata:
NC_GLOBAL#Conventions=CF-1.0
NC_GLOBAL#AREA_OR_POINT=Area
Band1#grid_mapping=transverse_mercator
Band1#long_name=GDAL Band Number 1
transverse_mercator#Northernmost_Northing=3.75132e+06
transverse_mercator#Southernmost_Northing=3.7206e+06
transverse_mercator#Easternmost_Easting=471440
transverse_mercator#Westernmost_Easting=440720
transverse_mercator#spatial_ref=PROJCS["NAD27 / UTM zone
11N",GEOGCS["NAD27",DATUM["North_American_Datum_1927",SPHEROID["Clarke
1866",6378206.4,294.9786982139006,AUTHORITY["EPSG","7008"]],AUTHORITY["EPSG","6267"]],PRIMEM["Greenwich",0],UNIT["degree",0.0174532925199433],AUTHORITY["EPSG","4267"]],PROJECTION["Transverse_Mercator"],PARAMETER["latitude_of_origin",0],PARAMETER["central_meridian",-117],PARAMETER["scale_factor",0.9996],PARAMETER["false_easting",500000],PARAMETER["false_northing",0],UNIT["metre",1,AUTHORITY["EPSG","9001"]],AUTHORITY["EPSG","26711"]]
transverse_mercator#GeoTransform=440720 60 0 3.75132e+06 0 -60
transverse_mercator#grid_mapping_name=transverse_mercator
transverse_mercator#latitude_of_projection_origin=0.000000e+00
transverse_mercator#central_meridian=-1.170000e+02
transverse_mercator#scale_factor_at_central_meridian=9.996000e-01
transverse_mercator#false_easting=5.000000e+05
transverse_mercator#false_northing=0.000000e+00
Corner Coordinates:
Upper Left ( 440720.000, 3751320.000) (117d38'28.21"W, 33d54'8.47"N)
Lower Left ( 440720.000, 3720600.000) (117d38'20.79"W, 33d37'31.04"N)
Upper Right ( 471440.000, 3751320.000) (117d18'32.07"W, 33d54'13.08"N)
Lower Right ( 471440.000, 3720600.000) (117d18'28.50"W, 33d37'35.61"N)
Center ( 456080.000, 3735960.000) (117d28'27.39"W, 33d45'52.46"N)
Band 1 Block=512x1 Type=Byte, ColorInterp=Undefined
NoData Value=0
Metadata:
NETCDF_VARNAME=Band1
It is my understanding that with some limitations GDAL
is producing NetCDF files conforming to the CF-1.0
conventions, including those for coordinate systems.
We also insert the spatial_ref item with the GDAL WKT
string for more accurate preservation of the coordinate
system.
I just tried removing the spatial_ref from the netcdf
file and I see that GDAL does *not* successfully read back
the coordinate system definition. Grr. Well, that is
presumably a bug and should be corrected.
I have filed a ticket on this:
http://trac.osgeo.org/gdal/ticket/2893
and assigned it to Chaitanya to work on since Denis does not really
have time to maintain the netcdf driver anymore.
2) Is there any continuing work being done in the gdal community with
regards to the GALEON project? As far as I can see, all gdal posts
related to this are from 2005 - 2006, yet recent articles in some
industry rags suggest that GALEON is still on the OGC's radar. I'd be
interested in working on this with anyone else who already is to help
resolve some of the remaining hiccups that are left in getting netCDF
files to work more easily with gdal. Feel free to contact me off-list
regarding this.
I have not been following the GALEON work much lately though I'm still
on a related mailing list I believe. I am keen on getting our netcdf
support into good enough shape that we can use it for serving and
consuming netcdf over WCS smoothly. I just can't spend much of my
time on it.
Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Programmer for Rent
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
