[THREDDS #IDF-300421]: Fwd: WCS Implementations

Hello Idan,

Our THREDDS Data Server (TDS) software only supports WCS 1.0. We have not yet 
worked on implementing 1.1 or 2.0.

Our instance of a TDS is located at 
http://motherlode.ucar.edu:8080/thredds/catalog.html
Are you trying the WCS on one of the datasets available there?

It sounds like you are focused on WCS 1.1. Let me know if you are interested in 
answers to your questions below about our WCS 1.0 implementation.

Ethan

> I am forwarding this message with questions about our TDS WCS behavior to
> the Unidata THREDDS support team where the requisite expertise lies.
> 
> -- Ben
> 
> ---------- Forwarded message ----------
> From: Idan Shatz <address@hidden>
> Date: Wed, Oct 12, 2011 at 12:20 PM
> Subject: WCS Implementations
> address@hidden>
> address@hidden>, George Percivall <address@hidden
> >
> 
> 
> To GEOSS WCS Data Providers:
> 
> 
> 
> PYXIS has been exercising our SDI Client WorldView on WCS data as a part of
> OWS-8 where we worked with the new WCS 2.0 for Earth Observations, and now
> as a part of GEOSS AIP-4.  We believe there is inconsistency in how a WCS
> 1.1 server responds to GetCoverage request.  We need your help confirming
> how the standard is implemented on your server so that we might better
> develop conformance.  We have observed two main issues:
> 
> 
> 
> *First Issue: How is your BOUNDINGBOX parameter is used?*
> 
> 
> 
> Let’s assume that your server has a coverage with the following bbox [0,0] x
> [50,50] (long/lat) and that a pixel size is 1x1 long/lat - a 50x50 pixels
> image that is aligned with the long/lat grid.  When making a request for WCS
> version 1.0 (the first version), the bounding box parameter should be at the
> edges of the pixels.
> 
> 
> 
> For example:
> 
> 
> 
> BoundingBox=0,0,2,2,CRS - will return an image of size 2x2 pixels.
> 
> BoundingBox=6,6,7,7,CRS - will return an image of size 1x1 pixels.
> 
> 
> 
> I have found that WCS version 1.1+ servers have two kind of behaviours when
> parsing the BoundingBox parameter.
> 
> 
> 
> 1.    Pixel Edge - Same as WCS 1.0 version - when the bound box is the outer
> edges of the pixels.
> 
> 2.    Pixel Center - BoundingBox is aligned as the center of pixels (as
> found in GDAL WCS implementation)
> 
> 
> 
> Assuming we have server that is expecting a bounding box aligned to the
> center of pixels then the following request should return the same results:
> 
> 
> 
> version=1.0.0&BoundingBox=0,0,2,2,CRS
> 
> version=1.1.0&BoundingBox=0.5,0.5,1.5,1.5,CRS
> 
> 
> 
> We have found that some servers return 1x1 image and some return 2x2 image.
> * *
> 
> **
> 
> 
> 
> Note that this issue is also apparent when defining the GridCRS element at
> the DescribeCoverage response.  I have found that there are two definitions:
> 
> 
> 
> 1.    Pixel Edge - the gird is originated at the edge of the bounding box
> (pixel corner).
> 
> 2.    Pixel Center - the gird is originated at the center of the pixel.
> 
> 
> 
> For example. Pixel Edge would look something like::
> 
> <wcs:GridCRS>
> 
> <wcs:GridBaseCRS>CRS</wcs:GridBaseCRS>
> 
> <wcs:GridType>urn:ogc:def:method:WCS:1.1:2dGridIn2dCrs</wcs:GridType>
> 
> <wcs:GridOrigin>0 50</wcs:GridOrigin>
> 
> <wcs:GridOffsets>1 0.0 0.0 -1</wcs:GridOffsets>
> 
> <wcs:GridCS>urn:ogc:def:cs:OGC:0.0:Grid2dSquareCS</wcs:GridCS>
> 
> </wcs:GridCRS>
> 
> 
> 
> while Pixel center would look something like that:
> 
> <wcs:GridCRS>
> 
> <wcs:GridBaseCRS>CRS</wcs:GridBaseCRS>
> 
> <wcs:GridType>urn:ogc:def:method:WCS:1.1:2dGridIn2dCrs</wcs:GridType>
> 
> <wcs:GridOrigin>0.5 49.5</wcs:GridOrigin>
> 
> <wcs:GridOffsets>1 0.0 0.0 -1</wcs:GridOffsets>
> 
> <wcs:GridCS>urn:ogc:def:cs:OGC:0.0:Grid2dSquareCS</wcs:GridCS>
> 
> </wcs:GridCRS>
> 
> 
> 
> *Please confirm how your server responds to the BoundingBox parameter (pixel
> edge or pixel center) and how your server is defining the GridCRS parameter .
> *
> 
> 
> 
> *Second Issue: How is your server handle urn:ogc:def:crs:EPSG::4326 vs
> EPSG:4326?  *
> 
> 
> 
> We are observing that the urn:ogc:def:crs:EPSG::4326 and EPSG:4326 are
> handled as two distinct CRSs.  If a request is sent using
> CRS="urn:ogc:def:crs:EPSG::4326", then we are observing the coordinates of
> the BoundingBox is lat/long while with the "EPSG:4326", the coordinates of
> BoundingBox is reversed to long/lat.  Which means, the following request are
> requesting the same area on earth:
> 
> 
> 
> version=1.1.0&boundingbox=0,10,20,50,EPSG:4326
> 
> version=1.1.0&boundingbox=10,0,50,20,urn:ogc:def:crs:EPSG::4326
> 
> 
> 
> We have found that this issue affects the response of the GetCoverage (aka:
> results in a flipped image).  Some WCS implementation returns the same tiff
> 20x40 pixels for both requests while other WCS implementations returns
> different tiffs:
> 
> 
> 
> version=1.1.0&boundingbox=0,10,20,50,EPSG:4326 - 20x40 pixel image
> 
> version=1.1.0&boundingbox=10,0,50,20,urn:ogc:def:crs:EPSG::4326 - 40x20
> pixels image
> 
> 
> 
> *Please confirm how your server is dealing with these two lat/long
> orderings. Is your server returning the same size image for these requests
> or is the image flipped?  *
> 
> **
> 
> Your attention to this issue will allow us to better prepare demonstration
> of your data at the GEOSS Plenary meeting next month and help refine
> conformance.
> 
> 
> 
> Thank you,
> 
> Idan Shatz
> 
> 
> 
> Senior Architect
> 
> the PYXIS innovation
> 
> 


Ticket Details
===================
Ticket ID: IDF-300421
Department: Support THREDDS
Priority: Critical
Status: Open