Hi Frank, Sorry for being unclear about the projection stuff. I guess what I was asking was how to go about defining the "South-up" nature of the data. But I guess it doesn't matter, so long as the corner coords and pixel dimensions are correct. I used "gdal_translate -a_srs "EPSG:4326"" on the GeoTIFF I created earlier, and it seems to have assigned the SRS properly and kept a positive Y axis pixel size. This "South-Up" stuff is just weird to me, I guess.
$ gdalinfo wgs84_fwdir_bas.tif Driver: GTiff/GeoTIFF Files: wgs84_fwdir_bas.tif Size is 42000, 42000 Coordinate System is: GEOGCS["WGS 84", DATUM["WGS_1984", SPHEROID["WGS 84",6378137,298.2572235629972, AUTHORITY["EPSG","7030"]], AUTHORITY["EPSG","6326"]], PRIMEM["Greenwich",0], UNIT["degree",0.0174532925199433], AUTHORITY["EPSG","4326"]] Origin = (65.000000000000000,5.000000000028436) Pixel Size = (0.000833333333333,0.000833333333333) Metadata: <snip> Thanks for confirming that there is a bug in reading coordinate system info from netCDF files. We're trying to make sure that some of our netCDF's in Lambert projection are correctly written - specifically so I can read them with gdal, and could not figure out what values to assign them. I think you're very close to having the netCDF driver working well enough to be used for serving and consuming WCS, but there are still a few issues to work out. What can I do to help? Setup sample problems, test, write use-cases? I'm trying to get a MapServer-based WCS system up at work that uses tiled netCDF's with time series data, so I think I've hit most of the remaining issues along the way. Roger -- On Mon, Mar 16, 2009 at 9:51 AM, Frank Warmerdam <warmer...@pobox.com> wrote: > 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