[gdal-dev] gdal, netCDF and projection
Roger André
randre at gmail.com
Mon Mar 16 14:05:30 EDT 2009
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 <warmerdam at 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,
> warmerdam at pobox.com
> light and sound - activate the windows | http://pobox.com/~warmerdam
> and watch the world go round - Rush | Geospatial Programmer for Rent
>
>
More information about the gdal-dev
mailing list