[Geoserver-users] FW: Missing grib and geotiffformats in WCS 1.1.1 Describe Coverage

Bessette-Halsema_Dom · June 16, 2014, 4:10pm

Hi

I was wondering if anyone could give some insight to our issue. See below. Thanks!

Dominique Bessette

-----Original Message-----
From: Frew, Brian
Sent: Friday, June 13, 2014 3:52 PM
To: Bessette-Halsema, Dominique E
Cc: Leung, Kristine; Mellick, Daniel L
Subject: FW: Missing grib and geotiffformats in WCS 1.1.1 Describe Coverage

dom, do you understand how geoserver gets the list of supported formats for the situation described below?

it appears that the formats that our plugins support aren't showing up in the DescribeCoverage request for WCS 1.1.1 ... however they are showing up for WCS 1.0.0 and also showing up on beta (which means the old geoserver).

we suspect that the plugins register their capability with geoserver, but we are not clear on why this might change from WCS version to version. we are hoping that you have some experience that might help here.

also, we are wondering what you might know about versions of WCS that clients are currently using.

any help will be greatly appreciated. thanks!
b

________________________________________
From: Sojka, Danny CIV 63134 [danny.sojka@anonymised.com]
Sent: Friday, June 13, 2014 12:37 PM
To: Mellick, Daniel L; Leung, Kristine; Frew, Brian; Brister, Robert L
Subject: Missing grib and geotiffformats in WCS 1.1.1 Describe Coverage

Requests to alpha for DescribeCoverage 1.1.1 do not show the grib formats. This is causing some JMeter tests to fail and will likely affect the DOC or external clients.

e.g. http://a4au-a010.fnmoc.navy.mil/geoserver/COAMPS-ALASKA/ows?service=wcs&version=1.1.1&request=DescribeCoverage&identifiers=ALASKA-n2-a2.air_temp.ht_sfc

<wcs:SupportedFormat>image/png</wcs:SupportedFormat>
<wcs:SupportedFormat>image/jpeg</wcs:SupportedFormat>
<wcs:SupportedFormat>image/tiff</wcs:SupportedFormat>

Reqeusts to beta do show grib:

e.g. http://a4bu-a001.fnmoc.navy.mil/geoserver/COAMPS-ALASKA/ows?service=wcs&version=1.1.1&request=DescribeCoverage&identifiers=ALASKA-n2-a2.air_temp.ht_sfc

<wcs:SupportedFormat>image/gif</wcs:SupportedFormat>
<wcs:SupportedFormat>image/png</wcs:SupportedFormat>
<wcs:SupportedFormat>image/jpeg</wcs:SupportedFormat>
<wcs:SupportedFormat>image/tiff</wcs:SupportedFormat>
<wcs:SupportedFormat>image/tiff;subtype="geotiff"</wcs:SupportedFormat>
<wcs:SupportedFormat>image/grib</wcs:SupportedFormat>
<wcs:SupportedFormat>image/grib2</wcs:SupportedFormat>

Dan Sojka
Fleet Numerical Meteorology and Oceanography Center
7 Grace Hopper Ave., Stop #1
Monterey, CA 93943
Office: 831-656-4232

Andrea_Aime4 · June 16, 2014, 8:12pm

On Mon, Jun 16, 2014 at 6:10 PM, Bessette-Halsema, Dominique E <
Dominique.Bessette@anonymised.com> wrote:

Hi

I was wondering if anyone could give some insight to our issue. See
below. Thanks!

The current version of GeoServer (2.5.x) searches the application context
for CoverageResponseDelegate implementations,
and then uses them.
Grib is not an officially supported format, but maybe you created your own
delegate?

Complex situation there, grib is, as far as I remember, a multidimensional
output format, which can be generated
as such only by WCS 2.0, and for which there is a single example, not yet
available in supported land:
https://github.com/geoserver/geoserver/tree/master/src/community/netcdf-out/src/main/java/org/geoserver/wcs/responses

I have the impression you're pretty much on the bleeding edge?

Cheers
Andrea

--

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-------------------------------------------------------

Bessette-Halsema_Dom · June 17, 2014, 8:54pm

Thanks for the reply. We recently upgraded from geoserver 2.2.4 to 2.5 and noticed that the custom delegates are registered differently, and ours was not getting picked up. Is there any other changes to custom delegates you know about? We are looking into it.

Also do you know if the WFS getFeature call was modified for the time domain? We are seeing issues for this too, although it may be on our end.

18:56:24,256 WARN [mil.navy.fnmoc.gis.doc.dataordering.retrieval.RetrieverRunner] (pool-28-thread-1) Exception encountered while running retriever; will retry the item later.: java.io.IOException: Bad HTTP response: url=https://imetoc.nps.edu/geoserver/wfs?service=WFS&version=1.0.0&request=GetFeature&typeName=gis:amdars&cql_filter=BBOX(location,-180.0,-90.0,-157.5,90.0,‘EPSG:4326’) AND uploadtime DURING 2014-06-17T19:05:02Z/2014-06-17T18:46:13Z&outputFormat=json, code=‘200’, msg=‘OK’, type=text/xml;charset=“UTF-8”, response='<?xml version="1.0" ?>

<ServiceExceptionReport

version=“1.2.0”

xmlns=“http://www.opengis.net/ogc”

xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance”

xsi:schemaLocation=“http://www.opengis.net/ogc http://schemas.opengis.net/wfs/1.0.0/OGC-exception.xsd”>

java.lang.IllegalArgumentException: The temporal position of the beginning of the period must be less than (i.e. earlier than) the temporal position of the end of the period

The temporal position of the beginning of the period must be less than (i.e. earlier than) the temporal position of the end of the period

’

at mil.navy.fnmoc.gis.doc.dataordering.WFSClient.getJSONStream(WFSClient.java:330) [classes:]

at mil.navy.fnmoc.gis.doc.dataordering.WFSClient.getAndStoreFeatures(WFSClient.java:169) [classes:]

at mil.navy.fnmoc.gis.doc.dataordering.ob.ObRetriever.retrieve(ObRetriever.java:46) [classes:]

at mil.navy.fnmoc.gis.doc.dataordering.retrieval.RetrieverRunner.run(RetrieverRunner.java:211) [classes:]

at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_51]

at java.util.concurrent.FutureTask.run(FutureTask.java:262) [rt.jar:1.7.0_51]

at mil.navy.fnmoc.gis.doc.dataordering.retrieval.RetrieverQueue$FutureWrapper.run(RetrieverQueue.java:470) [classes:]

at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]

at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]

Dominique Bessette

Engineer, Software

General Dynamics Information Technology

Supporting Fleet Numerical Meteorology and Oceanography Center (FNMOC)

Office: 619-881-2748

···

On Mon, Jun 16, 2014 at 6:10 PM, Bessette-Halsema, Dominique E <Dominique.Bessette@…1196…> wrote:

Hi

I was wondering if anyone could give some insight to our issue. See below. Thanks!

The current version of GeoServer (2.5.x) searches the application context for CoverageResponseDelegate implementations,

and then uses them.

Grib is not an officially supported format, but maybe you created your own delegate?

Complex situation there, grib is, as far as I remember, a multidimensional output format, which can be generated

as such only by WCS 2.0, and for which there is a single example, not yet available in supported land:

https://github.com/geoserver/geoserver/tree/master/src/community/netcdf-out/src/main/java/org/geoserver/wcs/responses

I have the impression you’re pretty much on the bleeding edge?

Cheers

Andrea

–

==

GeoServer Professional Services from the experts! Visit

http://goo.gl/NWWaa2 for more information.

==

Ing. Andrea Aime

@geowolf

Technical Lead

GeoSolutions S.A.S.

Via Poggio alle Viti 1187

55054 Massarosa (LU)

Italy

phone: +39 0584 962313

fax: +39 0584 1660272

mob: +39 339 8844549

http://www.geo-solutions.it

http://twitter.com/geosolutions_it

Andrea_Aime4 · June 17, 2014, 9:10pm

On Tue, Jun 17, 2014 at 10:54 PM, Bessette-Halsema, Dominique E <
Dominique.Bessette@anonymised.com> wrote:

Thanks for the reply. We recently upgraded from geoserver 2.2.4 to 2.5
and noticed that the custom delegates are registered differently, and ours
was not getting picked up. Is there any other changes to custom delegates
you know about? We are looking into it.

Hmm... I did not even think that in 2.2.x the delegates were pluggable
already... but I may be wrong. Yes, several changes occurred as WCS 2.0 was
introduced,
but I don't remember exactly what, it all happened several months ago (git
diff/git log are your friend).

Also do you know if the WFS getFeature call was modified for the time
domain? We are seeing issues for this too, although it may be on our end.

18:56:24,256 WARN
[mil.navy.fnmoc.gis.doc.dataordering.retrieval.RetrieverRunner]
(pool-28-thread-1) Exception encountered while running retriever; will
retry the item later.: java.io.IOException: Bad HTTP response: url=
https://imetoc.nps.edu/geoserver/wfs?service=WFS&version=1.0.0&request=GetFeature&typeName=gis:amdars&cql_filter=BBOX(location,-180.0,-90.0,-157.5,90.0,‘EPSG:4326’)
AND uploadtime DURING
2014-06-17T19:05:02Z/2014-06-17T18:46:13Z&outputFormat=json, code='200',
msg='OK', type=text/xml;charset="UTF-8", response='<?xml version="1.0" ?>

<ServiceExceptionReport

   version="1.2.0"

   xmlns="http://www.opengis.net/ogc"

   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

   xsi:schemaLocation="http://www.opengis.net/ogc
http://schemas.opengis.net/wfs/1.0.0/OGC-exception.xsd
<http://www.opengis.net/ogc%20http:/schemas.opengis.net/wfs/1.0.0/OGC-exception.xsd>
">

   <ServiceException>

      java.lang.IllegalArgumentException: The temporal position of the
beginning of the period must be less than (i.e. earlier than) the temporal
position of the end of the period

The temporal position of the beginning of the period must be less than
(i.e. earlier than) the temporal position of the end of the period

Looks like more correct validation of inputs, look:
2014-06-17T19:05:02Z/2014-06-17T18:46:13Z
The interval is invalid, the begin time is more recent than the end one