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

[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


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.