[THREDDS #QGG-522175]: arguments for a jnlp

Hi Yolanda,

> Hi again Ethan,
> 
> Thanks for your reply, the first part of the problem was solved as you
> suggested url={WCS}
> The second part didn't work but Im still doing some tests.

OK. Let me know if you have any other questions
 
> Now I have another problem:
> I tempted to install the version 4 you have in the web and see haw well
> it works with actual data in the catalog. Apparently it soes quiet well
> but found a difference that prevents my WCS client (GVSIG) from getting
> srs info, and thus getting access to coverage:
> 
> In thredds 3.17-
> My srs was defined as:
> 
> lonLatEnvelope srsName="WGS84(DD)">
> <gml:pos>-35.0 20.0</gml:pos>
> <gml:pos>24.98333740234375 69.98333740234375</gml:pos>
> </lonLatEnvelope>
> EPSG:4326
> 
> But in Thredds 4 it is defined as
> - <lonLatEnvelope srsName="urn:ogc:def:crs:OGC:1.3:CRS84">
> <gml:pos>-35.0 20.0</gml:pos>
> <gml:pos>24.98333740234375 69.98333740234375</gml:pos>
> <gml:timePosition>2009-03-09T00:00:00Z</gml:timePosition>
> <gml:timePosition>2009-03-09T00:00:00Z</gml:timePosition>
> </lonLatEnvelope>
> 
> In the nc file the tag is:
> grid_mapping:'Polar_Stereographic_projection_Grid'
> Is there any configuration to make in order to solve this?

Neither of our WCS implementations handle CRS/SRS very well. But the 4.0 
version is a bit of an improvement and more in line with the WCS specification.

The main failing in both is that in the CoverageDescription document the 
information in the 
"CoverageOffering/domainSet/spatialDomain/EnvelopeWithTimePeriod" element is 
simply a repeat of the contents of the "CoverageOffering/lonLatEnvelope" 
element. We should include an alternate "EnvelopeWithTimePeriod" element that 
describes the projection.

As it stands (at least in 4.0) the only indication of the projection is in the 
"CoverageOffering/supportedCRSs" element which contains a "requestCRSs" element 
and a "responseCRSs" element. In 3.17, no matter what projection the dataset is 
in, these will both contain "EPSG:4326". In 4.0 the "requestCRSs" is always 
"OGC:CRS84" but the "responseCRSs" contains information about the projection of 
the actual data (though not in any standard form). For a polar stereographic 
dataset on our server it looks like:

<supportedCRSs>
  <requestCRSs>OGC:CRS84</requestCRSs>
  <responseCRSs>EPSG:-3[Stereographic]</responseCRSs>
</supportedCRSs>

Which indicates that the request BBOX, if specified, must be specified in CRS84 
lat/lon but the response will be in the stereographic projection of the dataset.

Hope that all makes sense, though I'm not sure it will help with your WCS 
client. I will add improving our "spatialDomain/EnvelopeWithTimePeriod" to 
include projection information to our list of improvement. Let me know if I can 
help in any other way as well. 

Ethan

PS The dataset on our server I was looking at:

TDS 4.0, DescribeCoverage request - 
http://motherlode.ucar.edu:9080/thredds/wcs/fmrc/NCEP/GFS/CONUS_191km/files/GFS_CONUS_191km_20090323_1200.grib1?service=WCS&version=1.0.0&request=DescribeCoverage&coverage=Temperature

TDS 3.17, DescribeCoverage request - 
http://motherlode.ucar.edu:8080/thredds/wcs/fmrc/NCEP/GFS/CONUS_191km/files/GFS_CONUS_191km_20090323_1200.grib1?service=WCS&version=1.0.0&request=DescribeCoverage&coverage=Temperature

TDS 4.0, OPeNDAP DAS which includes all the 
"Polar_Stereographic_projection_Grid" attributes -
http://motherlode.ucar.edu:9080/thredds/dodsC/fmrc/NCEP/GFS/CONUS_191km/files/GFS_CONUS_191km_20090323_1200.grib1.das

Ticket Details
===================
Ticket ID: QGG-522175
Department: Support THREDDS
Priority: High
Status: Closed