Re: [thredds] Providing data access to GIS users

Hi Roy,

I believe both THREDDS and MapServer correctly follow the WCS 1.0 standard. Unfortunately, the ArcMap client appears to make an assumption related to the location of the origin and directionality of the offset vector (this corresponds with MapServer's implementation).

An incident was opened with ESRI related to this issue, but so far it has not been resolved.

-Dave


On 3/22/2011 8:29 AM, Roy Mendelssohn wrote:
ArcGIS and Mapserver both make heavy use of GDAL, and the fact that they work 
together is probably more a reflection of the shared code base than that they 
necessarily do something correctly.  While GDAL is a great library,  I have had 
similar problems in how it handles OPeNDAP and netCDF files  (it flips the 
images), in cases where the grids etc were clearly specified in CF conventions 
- they were just being ignored and GDAL was imposing its own interpretations.

The question is not whether ArcGIS works with MapServer, but whether the WCS 
service implemented in THREDDS correctly follows the standard, and  provides 
enough information for a client to interpret what it receives correctly. If the 
answer is yes, then we should be talking to ESRI et al. about implementing 
their client correctly to follow the standard.  The equivalent would be saying 
I should change my CF compliant netCDF files to suit GDAL, rather than have 
GDAL learn the standard.

My $0.02.

-Roy

On Mar 21, 2011, at 3:21 PM, David Neufeld wrote:

Hi Ethan, Jay,

Below are my notes about problems with THREDDS WCS and ArcGIS when I last 
looked at the issue (about 6 mos ago).  I'm not sure if there have been any 
recent changes in THREDDS or ArcGIS that may have addressed the problem yet.  
The link to a PDF at the bottom includes some screen snap shots from ESRI's 
ArcCatalog and ArcMap.

-Dave








-------- Original Message --------
  ArcMap is not correctly displaying coverages from a THREDDS WCS.  The
problem appears to be with differences in the DescribeCoverage response
in THREDDS compared to MapServer (ArcMap does display WCS coverages from
UMN MapServer).  Specifically the problem appears to be related to the
way the origin and offset vector are reported.

ArcMap appears to expect the origin of the Grid to be described in terms
of its upperleft corner with the offset vector described accordingly.

This is a DescribeCoverage response coming from MapServer (note origin
is upperleft corner; offset vector for y is negative):

<gml:RectifiedGrid dimension="2">
<gml:limits>
<gml:GridEnvelope>
<gml:low>0 0</gml:low>
<gml:high>21600 10800</gml:high>
</gml:GridEnvelope>
</gml:limits>
<gml:axisName>x</gml:axisName>
<gml:axisName>y</gml:axisName>
<gml:origin>
<gml:pos>-180.008333333335 90.008333369335</gml:pos>
</gml:origin>
<gml:offsetVector>0.01666666667 0</gml:offsetVector>
<gml:offsetVector>0 -0.01666666667</gml:offsetVector>
</gml:RectifiedGrid>

Currently the DescribeCoverage response from THREDDS contains the
following for the gml:RectifiedGrid (note origin is lowerleft corner;
offset vector for y is positive).

<gml:RectifiedGrid srsName="OGC:CRS84" dimension="2">
<gml:limits>
<gml:GridEnvelope>
<gml:low>0 0</gml:low>
<gml:high>21600 10800</gml:high>
</gml:GridEnvelope>
</gml:limits>
<gml:axisName>x</gml:axisName>
<gml:axisName>y</gml:axisName>
<gml:origin>
<gml:pos>-180.0 -90.0</gml:pos>
</gml:origin>
<gml:offsetVector>0.016666666666666666 0.0</gml:offsetVector>
<gml:offsetVector>0.0 0.016666666666666666</gml:offsetVector>
</gml:RectifiedGrid>
</spatialDomain>

This appears to cause ArcMap to formulate the following GetCoverage
request to THREDDS after parsing the DescribeCoverage response (as noted
by Kevin Sampson):

127.0.0.1 - - [12/Oct/2010:14:53:53 -0600] "GET
/thredds/wcs/test/ETOPO1_Ice_g_gmt4.nc?SERVICE=WCS&VERSION=1.0.0&REQUEST=GetCoverage&COVERAGE=z&FORMAT=GeoTIFF&BBOX=-180.008333333333,-89.975,-179.975,-90.0083333333333&WIDTH=2&HEIGHT=2&CRS=&INTERPOLATION=nearest%20neighbor
HTTP/1.1" 400 331

At which point THREDDS reports an exception:

<?xml version="1.0" encoding="UTF-8"?>
<ServiceExceptionReport xmlns=
"http://www.opengis.net/ogc";
  version="1.2.0">
<ServiceException code="InvalidParameterValue" locator="BBOX">BBOX
[-180.008333333333,-89.975,-179.975,-90.0083333333333] minimum point
larger than maximum point.</ServiceException>
</ServiceExceptionReport>


Full report is available here:

https://sites.google.com/site/geointeropdemos/home/issues-with-thredds-wcs/WCS_Comments_NGDC_v1.1.pdf
_______________________________________________
thredds mailing list
thredds@xxxxxxxxxxxxxxxx
For list information or to unsubscribe,  visit: 
http://www.unidata.ucar.edu/mailing_lists/
**********************
"The contents of this message do not reflect any position of the U.S. Government or 
NOAA."
**********************
Roy Mendelssohn
Supervisory Operations Research Analyst
NOAA/NMFS
Environmental Research Division
Southwest Fisheries Science Center
1352 Lighthouse Avenue
Pacific Grove, CA 93950-2097

e-mail: Roy.Mendelssohn@xxxxxxxx (Note new e-mail address)
voice: (831)-648-9029
fax: (831)-648-8440
www: http://www.pfeg.noaa.gov/

"Old age and treachery will overcome youth and skill."
"From those who have been given much, much will be expected"