[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[THREDDS #UIE-535383]: Questions re THREDDS and GOES-R ABI L1B products


Thanks for contacting us. See replies inline below:

> GOES-R ABI L1b/L2 full disk and CONUS products are on the ABI fixed grid
> projection. It is my understanding that Unidata has added support for
> this projection (i.e. a Java library), at least to convert a point on
> the fixed grid to a lat/lon and visa-versa. What I would like to find
> out is whether THREDDS can:
> 1)  Subset/sectorize these products based on lat/lon corner points.

THREDDS has the NetCDF Subset Service (NCSS, see: 
 which allows subsetting a dataset using lon/lat and time coordinates, as well
as only asking for specific variables.

> 2)  Change the projection of these products on the full disk projection
> to tropical mercator, lambert conformal, or polar stereographic.

This is not supported on the thredds server--it only provides services in the 
data's native coordinates, lon/lat, or index-based subset. Reprojection is 
currently a task left to the client.
We are investigating adding some generic server-side processing capabilities, 
of which this is a classic example, but this is very early investigations, and 
there is no timeline on when such features might appear in a release.

> 3)  Down-sample these products.

NCSS supports specifying a stride for both horizontal spatial dimensions and 
time. This means you can get, for example, every 3rd point.

> 4)  Change the bit depth of the products' pixels.

THREDDS does not do this, nor is it currently planned.

> 5)  The products contain data quality flag "images" that mirror the fixed
> grid data arrays. Will the functions for 1) and 2) be available for
> these data quality flag images?

Assuming the data quality flag images are NetCDF4 variables, then NCSS will 
work on these as well.

> 6)  Will the CF-compliant geolocation metadata be modified appropriately
> when functions 1) or 2) above are performed ?

Yes, NCSS writes out CF-compliant files in general.

> 7)  Will the product level metadata fields (i.e. scalar variables, such
> as number of good pixels in the image, be updated when functions for
> 1) an d 2) above are performed?

If I understand correctly, this metadata is not part of CF and is specific to 
the GOES-R ABI formatted files. As such, THREDDS would not currently handle 
this, nor is this currently on the roadmap.

> 8)  The standard names used for the coordinate variables in the native
> GOES-R ABI L1b/L2 products are "projection_x_coordinate" and
> "projection_y_coordinate". The units are supposed to be meters, but
> the GOES-R product designers "cheated" and is using these standard
> names with units of "radians".  Is this going to cause a problem?

I'm not sure. My gut says no, but that it will be straightforward to make it 
work. Such a problem is likely to be addressed once we start working with some 
real data.

> 9)  The other question I have is whether IDV has been revised to support
> displaying GOES-R ABI L1b/L2 on the ABI fixed grid projection.

For data accessed from THREDDS, the IDV will rely on the same netcdf-java code 
that power THREDDS.

> 10) Lastly, if THREDDS is not currently capable of any of the functionality
> described above, do you have plans to develop such functionality, and,
> if so, when?

All I can add is that we have plans to have a GOES-R receiver here. I'm sure 
once we have the data flowing we'll be smoothing the process of serving and 
processing the GOES-R data using THREDDS. This is especially true of problems 
that affect our internal clients (like IDV and THREDDS).
I can't promise, however, that all of the issues discussed above will be solved.


Ticket Details
Ticket ID: UIE-535383
Department: Support THREDDS
Priority: Normal
Status: Closed

NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.