2

I'm working on reading in a NetCDF file into GeoServer and GeoServer has no problem reading it in as a data store, but when I go to publish the layer from the data store I get an error that states "Unable to load raster for granuleDescriptor" from org.geotools.imageio.netcdf.NetCDFImageReader.

I've read through the CF Conventions 1.6 Documentation and COARDS documentation to ensure the NetCDF file meets formatting standards. I've been working with the dataset for quite some time and am unable to find out what the issue is.

I'm using GeoServer 2.7.4 which is using GeoTools 13.4. In case you'd like to use the preconfigured environment I'm using, the environment it's configured in is my own GeoServer Docker container. Information on the container can be found on it's GitHub page.

The sample dataset can be found here. The link includes the dataset, projection in WKT, and a text file showing the stack traced that is thrown.

Here is the exact error thrown.

2015-12-18 22:29:32,882 DEBUG [io.netcdf] - Unable to load raster for granuleDescriptor 
org.geotools.coverage.io.netcdf.NetCDFResponse@3c9d1be6 with request NetCDFRequest [
interpolation=javax.media.jai.InterpolationNearest@5420f335, 
source=org.geotools.coverage.io.netcdf.NetCDFSource@6621e90, 
readType=DIRECT_READ, 
spatialRequestHelper=SpatialRequestHelper [
    requestedBBox=ReferencedEnvelope[0.0 : 5.0, 54.0 : 59.0], 
    cropBBox=ReferencedEnvelope[0.0 : 5.0, 54.0 : 59.0], 
    requestedRasterArea=GridEnvelope2D[0..4, 0..4], 
    destinationRasterArea=java.awt.Rectangle[x=1,y=1,width=5,height=5], 
    requestCRS=GEOGCS["WGS 84",
        DATUM["World Geodetic System 1984",
            SPHEROID["WGS 84", 6378137.0, 298.257223563, AUTHORITY["EPSG","7030"]],
            AUTHORITY["EPSG","6326"]],
        PRIMEM["Greenwich", 0.0, AUTHORITY["EPSG","8901"]],
        UNIT["degree", 0.017453292519943295],
        AXIS["Geodetic longitude", EAST],
        AXIS["Geodetic latitude", NORTH],
        AUTHORITY["EPSG","4326"]], 
    requestedGridToWorld=PARAM_MT["Affine",
        PARAMETER["num_row", 3],
        PARAMETER["num_col", 3],
        PARAMETER["elt_1_1", -1.0],
        PARAMETER["elt_1_2", 59.0]], 
    requestedResolution=[1.0, 1.0], 
    requestedBBOXInCoverageGeographicCRS=null, 
    requestCRSToCoverageGeographicCRS2D=null, 
    destinationToSourceTransform=null,        coverageProperties=org.geotools.coverage.io.SpatialRequestHelper$CoverageProperties@6e92b820, 
    empty=false, 
    needsReprojection=true, 
    approximateRequestedBBoInNativeCRS=null], 
originalRequest=org.geotools.coverage.io.CoverageReadRequest@62767596, 
name=soil_moisture] 
Resulting in no granule loaded: Empty result

Here is the projection of the dataset:

PROJCS["Lambert_Conformal_Conic",
GEOGCS["GCS_Sphere",
    DATUM["Not_specified_based_on_Authalic_Sphere",
        SPHEROID["Sphere",6370000.0,0.0]],
    PRIMEM["Greenwich",0.0],
    UNIT["Degree",0.0174532925199433]],
PROJECTION["Lambert_Conformal_Conic_2SP"],
PARAMETER["false_easting",0.0],
PARAMETER["false_northing",0.0],
PARAMETER["central_meridian",-97.0],
PARAMETER["standard_parallel_1",30.0],
PARAMETER["standard_parallel_2",60.0],
PARAMETER["latitude_of_origin",40.0000076294],
UNIT["Meter",1.0]]
AUTHORITY["EPSG", 102009]

One strange observation is that the error seems to state it reprojecting to a projection other then the one that the file is defined as. I've also tried placing the WKT projection string as the crs_wkt attribute of the Lambert_Conformal variable with no dice.

1

I just checked with the developers and in the GeoServer version you are using there is no support for coordinate reference systems other than WGS84.

This has been added on the 2.8.x series along with some other improvements, you can get a decent summary here.

I would suggest to test with a more recent version and let us know.

Regards, Simone.

  • I spun up a docker container based on GeoServer 2.8.1 and it is now reading the NetCDF data and allowing me to publish. It looks like this will be significant evidence to push for a GeoServer upgrade in production. Thank you for the help. – Brian Lee Dec 23 '15 at 18:32
1

Not that it solves your geoserver problem, but I'm seeing a discrepancy in your projection description. Above you say standard parallels are at 30N and 60N, but the projection description in the dataset has a single standard parallel at 25N.

Is the mapped area intended to be in southeast Nebraska?

  • After updating the NetCDF's projection to match that of the source data, it still does not read into GeoServer, but that likely would have been an issue later on during visualization. To better tune the NetCDF to the Lambert Conformal Conic projection used, I added the second standard parallel to the standard_parallel attribute, the false_easting attribute, and the false_northing attribute to my Lambert_Conformal variable. See Standard Horizontal Coordinate Transforms for more info. – Brian Lee Dec 21 '15 at 17:29
  • I didn't answer your question about the dataset's extent. The projection provided was given by UCAR for another dataset I'm working with, but I didn't use it as a sample because it's rather large and hard to work with. The sample dataset was taken from the WRF Output Sample on Unidata's website. It's the wrfout_v2_Lambert.nc. Obviously, I've modified it to conform to CF standards so that GeoServer can recognize the data. I could be having an issue with inconsistencies. – Brian Lee Dec 21 '15 at 17:56
  • I asked about the geographical extent of the data because I had opened up the dataset using the Panoply application. The file generally appeared to use the CF convention correctly in describing the projected coordinate system, but when plotting the data, only a small area in Nebraska was drawn. Taking a closer look now, I see that there is a problem. The latitude and longitude vars suggest a much larger area is intended (66-93W 24N-44N). Examination of the values in the x and y coordinate vars show that they do not have values that extend to match the lon-lat area. – MSD Software Dec 22 '15 at 5:38
  • I've never used Panoply before, so thanks for the reference. It looks a bit more convenient than ncdump. Even when plotting the unmodified sample data in Panopoly, I still get a coverage originating in Nebraska. I guess my issue is that I don't know exactly how the projection coordinates x/y should look. I thought they were just numeric indexes 0-n. Also, it appears the central meridian and possibly the units are incorrect. Could this that be the reason GeoServer is failing to publish the dataset? – Brian Lee Dec 22 '15 at 18:22
  • 1
    The values in the x and y coordinate vars should be the distance from the projected coordinate system's axes in km. In other words, rather than the values of the x variable being 0, 1, 2, 3, etc., as they are now, they more likely should be something like 0, 60, 120, 180, etc. (or other multiples of the distance increment is along the x dimension). – MSD Software Dec 22 '15 at 23:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.