I think the source of the problem in ticket #2492 is not a GDAL defect, but that the variable in the connection string is "u.u". The .operator is used to refer to members of a structure (see http://opendap.org/user/guide-html/guide_61.html), but the variables in this dataset are grouped by grids (see http://apdrc.soest.hawaii.edu/dods/public_data/SODA/soda_pop2.0.4.dds). It may be that using the .operator to access members of grids was allowed in older versions of libdap. As it is, replacing "u.u" with "u" eliminates the problem for me on machines with libdap-3.8.2/gdal-svn15148 and libdap-3.7.10/gdal-gdal-1.4.2, respectively.
Steve Gaffigan gdalinfo -mm "http://apdrc.soest.hawaii.edu/dods/public_data/SODA/soda_pop2.0.4?u[0][0][y][x]"; Driver: DODS/DAP 3.x servers Files: none associated Size is 720, 330 Coordinate System is `' Origin = (0.000000000000000,-75.500000000000000) Pixel Size = (0.500000000000000,0.500000000000000) Corner Coordinates: Upper Left ( 0.0000000, -75.5000000) Lower Left ( 0.0000000, 89.5000000) Upper Right ( 360.000, -75.500) Lower Right ( 360.000, 89.500) Center ( 180.0000000, 7.0000000) Band 1 Block=720x128 Type=Float32, ColorInterp=Undefined Computed Min/Max=-9989999710577420651746759362478080.000,1.407 NoData Value=-9.9899999999999995e+33 Overviews: 360x165, 180x82 > Hi Denis- > > I put this patch in a few months ago addressing this libdap 3.8 issue: > > http://trac.osgeo.org/gdal/ticket/2404 > > This will get the code to build against libdap3.8 (primarily a namespace > problem), but there are still issues accessing DODS datasources: > > http://trac.osgeo.org/gdal/ticket/2492 > > > > If you get some time to look into this it would be great... > > > > Thanks, > > -Chris > > > > > > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Denis Nadeau > Sent: Thursday, August 21, 2008 10:53 AM > To: [email protected] > Subject: [gdal-dev] netcdf driver > > > > Hi, > > I will being doing some new development on netCDF driver to make it more > CF-1 Compliant. > > Note: when I compiled the netCDF 3.6.2 with HDF4.2r3 (with the flag > --disable-netcdf) I had to change all macros such as "MAX_NC_NAME" to > "H4_MAX_NC_NAME" and many other similar macros. Need to do some testing > on this. > > I also noticed that DODS (dodsdataset2.cpp) does not seem to compile > with libdap3.8.2. There are some major changes in the library for C++. > > I will take a look into this as well, but do not promess anything... > > If you have suggestion of improvements for DODS, HDF4 and netCDF > drivers, let me know, I have a little bit of time this coming month. > > Regards, > Denis > > _______________________________________________ > gdal-dev mailing list > [email protected] > http://lists.osgeo.org/mailman/listinfo/gdal-dev _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
