[gdal-dev] netcdf driver

[Christopher Condit]

Thanks, Steve. I see that it's working now.
It should be noted that the same call (with the u.u) worked in libdap
3.6.2.
I went ahead and closed this ticket.

-Chris

> -----Original Message-----
> From: gaffigan at sfos.uaf.edu [mailto:gaffigan at sfos.uaf.edu]
> Sent: Thursday, August 21, 2008 7:13 PM
> To: Christopher Condit
> Cc: Denis Nadeau; gdal-dev at lists.osgeo.org
> Subject: RE: [gdal-dev] netcdf driver
> 
> 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: gdal-dev-bounces at lists.osgeo.org
> > [mailto:gdal-dev-bounces at lists.osgeo.org] On Behalf Of Denis Nadeau
> > Sent: Thursday, August 21, 2008 10:53 AM
> > To: gdal-dev at lists.osgeo.org
> > 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
> > gdal-dev at lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/gdal-dev
>