[gdal-dev] netcdf driver

[Denis Nadeau]

Hi Steve,

Thanks I'll look into this.

I think that   if you replace "u.u" with "u"  libdap will look into the
entire file to find a variable called "u" regardless of the structure.

Denis

2008/8/21 <gaffigan at sfos.uaf.edu>

> 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]<http://apdrc.soest.hawaii.edu/dods/public_data/SODA/soda_pop2.0.4?u%5B0%5D%5B0%5D%5By%5D%5Bx%5D>
> "
> 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20080822/60226ded/attachment.html