Due to the current gap in continued funding from the U.S. National Science Foundation (NSF), the NSF Unidata Program Center has temporarily paused most operations. See NSF Unidata Pause in Most Operations for details.
Due to the current gap in continued funding from the U.S. National Science Foundation (NSF), the NSF Unidata Program Center has temporarily paused most operations. See NSF Unidata Pause in Most Operations for details.
Yes, i can imagine that a polar projection will give bad results for the lat/lon BB. We really need to replace that with a bounding polyline. Does WMS/WCS allow other than lat/lon bounding boz? I did check the dataset pointed to by ArcticTEP.ncml, and it had a reasonable bounding box: LLbb= ll: 34.57N 79.65W+ ur: 90.0N 169.6E still not great, but not empty at least. I see that you're using TDS 3.14, im not sure if ive fixed a bug (im testing with 4.0.11 alpha) or we are looking at different datasets.... Ill make a release on monday so that you can check against 4.0, and i'll look at your specific dataset next week. Jon Blower wrote:
Hi John, That's brilliant, thanks very much. Everything (nearly) now appears to work: http://lovejoy.nerc-essc.ac.uk:8080/ncWMS/mersea.html?menu=MERSEA&layer=MERSEA_ARCTIC_TOPAZ/temperature&elevation=-5&time=2008-01-24T00:00:00Z&scale=-3.055269694328308,22.592125034332277&bbox=-65.039062,18.28125,24.960938,88.59375 However, there seems to be a problem with GridCoordSystem.getLatLonBoundingBox() for this dataset (presumably because of the polar stereographic projection). This function returns a zero-sized bounding box (with minLat = maxLat). The longitude range also appears wrong. I would expect this to return a BBOX of the form (-180, minLat, 180, 90), i.e. covering the full longitude range and ranging from some minimum latitude to the North Pole. The ncml file is attached that contains your metadata corrections, in case you want to test getLatLonBoundingBox(). Cheers, Jon On Jan 22, 2008 12:25 AM, John Caron <caron@xxxxxxxxxxxxxxxx> wrote:Hi Jon: 1) y coordinate is missing units attribute 2) latitude unit should be "degrees_north", not "degrees" 3) longitude unit should be "degrees_east", not "degrees" 4) most of the the data variables have "_CoordinateAxes" attributes missing the time coordinate, eg: :_CoordinateAxes = "longitude latitude y x "; should be: :_CoordinateAxes = "longitude latitude y x time "; The rule for "_CoordinateAxes" is that they have to be complete, if you are going to use them. If you left "_CoordinateAxes" off, then the CF-1.0 convention :coordinates = "longitude latitude"; would work, since the coordinate variables (x,y,time) would be automatically added. Jon Blower wrote:Hi all, I'm trying to use the Java NetCDF libraries (2.2.22) to read Arctic ocean data over OPeNDAP. The data are in polar stereographic projection. However, the following short program (which works fine for many other datasets) returns zero Grids: NetcdfDataset nc = NetcdfDataset.openDataset(url, true, null); GridDataset gd = (GridDataset)TypedDatasetFactory.open(DataType.GRID, nc, null, null); System.out.println(gd.getGrids().size()); // prints out "0" The URL to the OPeNDAP site is http://topaz.nersc.no/thredds/dodsC/topaz/mersea-ipv2/arctic/tmipv2a-class1-be. The results of performing an ncdump on this URL (using toolsUI) are attached. toolsUI also fails to recognize any Grids in this dataset. Can anyone advise on what might be the problem here? Is the metadata of the dataset incorrectly specified? Thanks in advance, Jon ------------------------------------------------------------------------ _______________________________________________ netcdf-java mailing list netcdf-java@xxxxxxxxxxxxxxxx For list information or to unsubscribe, visit: http://www.unidata.ucar.edu/mailing_lists/
netcdf-java archives: