Hi Idan, Idan Shatz wrote: > Hello Ethan, > > Thank you for the information. the previous questions where indeed related > to issues come from WCS 1.1. However, I have some questions on WCS 1.0, > that currently prevent me from making a successful integration between our > client and your servers. > > we are using the following dataset as been provided in the Geoss data > provider table > http://motherlode.ucar.edu:8080/thredds/catalog/fmrc/NCEP/DGEX/Alaska_12km/catalog.html?dataset=fmrc/NCEP/DGEX/Alaska_12km/NCEP-DGEX-Alaska_12km_best.ncd > > And this is the dataset we are trying to access: (Ben- you might want to > change the version appear on the Geoss web-site, its version 1.1.1) > http://motherlode.ucar.edu:8080/thredds/wcs/fmrc/NCEP/DGEX/Alaska_12km/NCEP-DGEX-Alaska_12km_best.ncd?service=WCS&request=DescribeCoverage&version=1.0.0&coverage=Maximum_temperature > > I have several issues with the coverage description that prevent my WCS > reader to work. > > this is the RectifiedGrid definition: > > <gml:RectifiedGrid srsName="EPSG:-3 [Stereographic]" dimension="3"> > <gml:limits> > <gml:GridEnvelope> > <gml:low>0 0 0</gml:low> > <gml:high>376 236 0</gml:high> > </gml:GridEnvelope> > </gml:limits> > <gml:axisName>x</gml:axisName> > <gml:axisName>y</gml:axisName> > <gml:axisName>z</gml:axisName> > <gml:origin> > <gml:pos>-2376.5749046373835 -4424.688308005453 0.0</gml:pos> > </gml:origin> > <gml:offsetVector>11.944999999999999 0.0 0.0</gml:offsetVector> > <gml:offsetVector>0.0 11.945 0.0</gml:offsetVector> > <gml:offsetVector>0.0 0.0 0.0</gml:offsetVector> > </gml:RectifiedGrid> > > 1. does the "EPSG:-3 [Stereographic]" is a standard definition of a SRS? > our GDAL doesn't support this SRS I'm afraid the "EPSG:-3 [Stereographic]" srsName is not a standard definition. It is really just a placeholder we stuck in there. The native CRSs for most, if not all, of the datasets we serve do not have an EPSG code. We have the various parameters for the projections. However, a standard way to encode these CRS and how to reference them in the GetCapabilities document still seems up for debate in the OGC. > 2. why there are 3 axis in your grid where z value must be zero? The "Maximum_Temperature" variable is stored as a 4-D array (time, height, y, x). Currently, we list all spatial dimensions in the grid description even when the height dimension is size 1. That the variable has a height dimension indicates that it is at a particular height (in this case, 2 meters above ground). Variables that do not have a height dimension are not defined at a particular height, e.g, total precipitation. At the time we implemented our WCS, this seemed like the best way to communicate that the data is for a height 2 meters above ground. If you have any thoughts on a better way to do that, please let me know. On the other hand, I'm not sure why the height value is listed as 0.0 when it should be 2.0. I'll add this to our list of things to dig into. > <supportedCRSs> > <requestCRSs>OGC:CRS84</requestCRSs> > <responseCRSs>EPSG:-3 [Stereographic]</responseCRSs> > </supportedCRSs> > > Our client doesn't support requests with one SRS and results in another. > the reason for that we have to validate if the response we get match the > request we send (it seems many servers play with different rules). > Moreover, in case where both SRS doesn't align well, it is random how > the server may decided to fix this issue. > > my request for you is: > can you support requests in EPSG:-3? if so, can you add it to the > description (supportedCRSs.requestResponseCRSs). the reason for that is > that your RectifitedGrid is defined above this SRS - and our server uses > this information to generate valid requests. We do not currently support requests in the "EPSG:-3" CRS. However, it is already on our list of desired enhancements to our WCS implementation. > if this is not the case, then my request is can you support response in > CRS84? I'm afraid our WCS implementation does not currently support any remapping of the data. This was an intentional choice some time back for a few reasons. It is a decision we have reconsidered off and on but have never had the resources to add this capability. Hope this helps, Ethan > Thank you, > Idan Ticket Details =================== Ticket ID: IDF-300421 Department: Support THREDDS Priority: Critical 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.