Hi John, all,
Is there anything we need to do in the WMS or Godiva code here? Why does the
tiling algorithm make this problem appear more?
Cheers,
Jon
----------
Hi all:
ok, i have found the problem and will get a fix out in the next few days. its
in the netcdf-java hd5 chunked data reader, but mostly manifests in godiva
because of their tiling algorithm. symptom is that missing data is returned for
some chunks of the data. non-missing data is correct.
John
On 2/13/2014 3:15 PM, John Maurer wrote:
> OK, when I convert our files from NetCDF-4 (Classic) to NetCDF-3, the
> problem goes away. Could this be a bug in TDS/FMRC? Is there some
> additional TDS configuration I can try to keep our files in NetCDF-4?
> We are running TDS 4.3.20 - 20131125.1409.
> Thanks,
> John
>
>
> On Thu, Feb 13, 2014 at 10:36 AM, John Maurer <jmaurer@xxxxxxxxxx
> <mailto:jmaurer@xxxxxxxxxx>> wrote:
>
> Hi TDS folks,
> I'm seeing a strange problem with some of our new regridded ROMS
> ocean forecast models that I'm hoping somebody can help me with. At
> certain time steps, some regions are displaying values of
> 9.96921E36. From my understanding, this is the value assigned (by
> NetCDF?, OPeNDAP?, TDS?) when there was no data value. However, I
> can confirm in each of my NetCDF files that the same slices contain
> valid data values. So the problem seems to stem from the TDS side of
> things, where I am serving these as a Forecast Model Run Collection
> (FMRC). Furthermore, I have already assigned a _FillValue and
> missing_value of NaN, so the 9.96921E36 issue is something else.
> More pieces to the puzzle are: (1.) no matter what file I test with,
> it always occurs at the same time steps and regions; (2.) it shows
> up in all variables (temp, salt, u, v); (3.) you can see this in
> Godiva2/ncWMS, NetCDF Subset Service, and OPeNDAP. Ideas?? I'm stumped.
>
> Here is my TDS testbed for this; I have been focusing specifically
> on the Best Time Series:
>
>
> http://oos.soest.hawaii.edu/thredds-test/catalog/hioos/roms_forec/hiig
> /catalog.html
>
> Godiva2 will show you an example of the problem if you navigate to
> sea_water_potential_temperature on Feb 19 2014 at 18:00 at 0.25
> meters depth. As shown in the example image attached, there is a
> black rectangle in the southeast corner where the values are all
> 9.96921E36. You can click there to confirm this value is returned.
> (Strangely the "test image" for the same day does not have this
> problem...)
>
> Here is an OPeNDAP call within that same time/lat/lon/depth which
> shows the 9.96921E36 values:
>
>
> http://oos.soest.hawaii.edu/thredds-test/dodsC/hioos/roms_forec/hiig/R
> OMS_Hawaii_Regional_Ocean_Model_best.ncd.ascii?temp[14][0][0:1:10][284
> :1:294]
>
> I have staged a gzipped NetCDF file (1.4 GB) and TDS catalog via ftp
> for you to test with:
>
> ftp.soest.hawaii.edu <http://ftp.soest.hawaii.edu>
> user: anonymous
> pass: <your e-mail address>
> cd jmaurer/unidata/
> get ocn_mod_hiig.xml
> get hiig_forec_20140208.nc.gz
>
> Thanks in advance for your time on this!
> Cheers,
> John Maurer
> Pacific Islands Ocean Observing System (PacIOOS)
> University of Hawaii at Manoa
>
>
>
>
> _______________________________________________
> thredds mailing list
> thredds@xxxxxxxxxxxxxxxx
> For list information or to unsubscribe, visit:
> http://www.unidata.ucar.edu/mailing_lists/
>
End of thredds Digest, Vol 61, Issue 6
**************************************
