[Geoserver-users] GeoServer 2.3-RC1 breaks WCS with TIME support

GeoServer GeoServer User
1

List,

I've been tinkering with raster datasets through WCS with TIME support on GeoServer 2.2.x and everything worked fine. After upgrading to GeoServer 2.3-RC1, however, it somehow fails to properly handle TIME parameter.

For example, WCS would be accessed like below:

http://localhost:8080/geoserver/wcs?crs=EPSG%3A4326&service=WCS&format=GeoTIFF&request=GetCoverage&height=338&width=248&version=1.0.0&BBox=127.67888233703871,35.12473682400443,127.74997856195601,35.22163409828688&Coverage=ksafm:T14&time=2010-09-30T00:00Z

Then, GeoServer would print out error messages about date type casting.

12 Mar 18:33:12 ERROR [geoserver.ows] -
java.lang.ClassCastException: org.geotools.util.DateRange cannot be cast to java.util.Date
  at org.geoserver.wcs.kvp.Wcs10GetCoverageRequestReader.parseDomainSubset(Wcs10GetCoverageRequestReader.java:172)
  at org.geoserver.wcs.kvp.Wcs10GetCoverageRequestReader.read(Wcs10GetCoverageRequestReader.java:105)
  at org.geoserver.ows.Dispatcher.parseRequestKVP(Dispatcher.java:1412)
  at org.geoserver.ows.Dispatcher.dispatch(Dispatcher.java:622)
  at org.geoserver.ows.Dispatcher.handleRequestInternal(Dispatcher.java:263)
…

According to TimeKvpParser.java, It seems that TIME parameter is parsed into either java.util.DateRange or java.util.Date object, depending on whether it is time range or timestamp. (eg. "2013-03-10/2013-03-13" vs. "2013-03-13") Though I couldn't figure out how it's broken as the code itself has no modification for a quite long time. There might be side effect from other changes in 2.3. Interesting is that similar access via WMS with TIME parameter (on layer preview) still works fine.

Maybe it would be related to GEOS-5701 which states about time interval via DateRange for ImageMosaic.
https://jira.codehaus.org/browse/GEOS-5701

I'm running GeoServer WAR on Mac OS X 10.8.2 with Tomcat 7.0.37 installed by Homebrew.

Hope this issue could be rectified before officially release of 2.3. Until then I would stick to 2.2.5.
Thanks in advance.

Regards,
Kyungdahm

2

On Tue, Mar 12, 2013 at 11:14 AM, Kyungdahm Yun <tomyun@anonymised.com> wrote:

List,

I’ve been tinkering with raster datasets through WCS with TIME support on GeoServer 2.2.x and everything worked fine. After upgrading to GeoServer 2.3-RC1, however, it somehow fails to properly handle TIME parameter.

For example, WCS would be accessed like below:

http://localhost:8080/geoserver/wcs?crs=EPSG%3A4326&service=WCS&format=GeoTIFF&request=GetCoverage&height=338&width=248&version=1.0.0&BBox=127.67888233703871,35.12473682400443,127.74997856195601,35.22163409828688&Coverage=ksafm:T14&time=2010-09-30T00:00Z

Then, GeoServer would print out error messages about date type casting.

12 Mar 18:33:12 ERROR [geoserver.ows] -
java.lang.ClassCastException: org.geotools.util.DateRange cannot be cast to java.util.Date
at org.geoserver.wcs.kvp.Wcs10GetCoverageRequestReader.parseDomainSubset(Wcs10GetCoverageRequestReader.java:172)
at org.geoserver.wcs.kvp.Wcs10GetCoverageRequestReader.read(Wcs10GetCoverageRequestReader.java:105)
at org.geoserver.ows.Dispatcher.parseRequestKVP(Dispatcher.java:1412)
at org.geoserver.ows.Dispatcher.dispatch(Dispatcher.java:622)
at org.geoserver.ows.Dispatcher.handleRequestInternal(Dispatcher.java:263)
…

According to TimeKvpParser.java, It seems that TIME parameter is parsed into either java.util.DateRange or java.util.Date object, depending on whether it is time range or timestamp. (eg. “2013-03-10/2013-03-13” vs. “2013-03-13”) Though I couldn’t figure out how it’s broken as the code itself has no modification for a quite long time. There might be side effect from other changes in 2.3. Interesting is that similar access via WMS with TIME parameter (on layer preview) still works fine.

Weird… you specified a single time, so a DateRange should not have been generated.

Maybe it would be related to GEOS-5701 which states about time interval via DateRange for ImageMosaic.
https://jira.codehaus.org/browse/GEOS-5701

The support for time ranges has been committed only on trunk, and I’m working on GeoServer support for it
right now (still uncommitted), so it should not be the case

I’m running GeoServer WAR on Mac OS X 10.8.2 with Tomcat 7.0.37 installed by Homebrew.

Hope this issue could be rectified before officially release of 2.3. Until then I would stick to 2.2.5.

Not sure we’ll manage, 2.3.0 was due out last week, we delayed it a bit but in the next few days
it has to be out (we follow a time boxed release model)

Cheers
Andrea

–

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it 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

3

It’s been pretty dated, but for others who may struggle with a similar issue.

I thought the time parameter ‘2010-09-30T00:00Z’ to be treated as a single point of time, but it was actually not. Without seconds/microseconds offered explicitly, it expands to time ranges like ‘2010-09-30T00:00:00.0Z/2010-09-30T00:00:59.999Z’. This is what a new manual details with “reduced accuracy times” heading (GEOS-5280).

After properly defining single time position (eg. ‘2010-09-30T00:00:00.0Z’), it should work without any problem.

By the way, current master branch can work even with DateRange, seemingly thanks to GEOS-5701.

Regards,
Kyungdahm

···

On Tue, Mar 12, 2013 at 7:39 PM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Tue, Mar 12, 2013 at 11:14 AM, Kyungdahm Yun <tomyun@anonymised.com.84…> wrote:

List,

I’ve been tinkering with raster datasets through WCS with TIME support on GeoServer 2.2.x and everything worked fine. After upgrading to GeoServer 2.3-RC1, however, it somehow fails to properly handle TIME parameter.

For example, WCS would be accessed like below:

http://localhost:8080/geoserver/wcs?crs=EPSG%3A4326&service=WCS&format=GeoTIFF&request=GetCoverage&height=338&width=248&version=1.0.0&BBox=127.67888233703871,35.12473682400443,127.74997856195601,35.22163409828688&Coverage=ksafm:T14&time=2010-09-30T00:00Z

Then, GeoServer would print out error messages about date type casting.

12 Mar 18:33:12 ERROR [geoserver.ows] -
java.lang.ClassCastException: org.geotools.util.DateRange cannot be cast to java.util.Date
at org.geoserver.wcs.kvp.Wcs10GetCoverageRequestReader.parseDomainSubset(Wcs10GetCoverageRequestReader.java:172)
at org.geoserver.wcs.kvp.Wcs10GetCoverageRequestReader.read(Wcs10GetCoverageRequestReader.java:105)
at org.geoserver.ows.Dispatcher.parseRequestKVP(Dispatcher.java:1412)
at org.geoserver.ows.Dispatcher.dispatch(Dispatcher.java:622)
at org.geoserver.ows.Dispatcher.handleRequestInternal(Dispatcher.java:263)
…

According to TimeKvpParser.java, It seems that TIME parameter is parsed into either java.util.DateRange or java.util.Date object, depending on whether it is time range or timestamp. (eg. “2013-03-10/2013-03-13” vs. “2013-03-13”) Though I couldn’t figure out how it’s broken as the code itself has no modification for a quite long time. There might be side effect from other changes in 2.3. Interesting is that similar access via WMS with TIME parameter (on layer preview) still works fine.

Weird… you specified a single time, so a DateRange should not have been generated.

Maybe it would be related to GEOS-5701 which states about time interval via DateRange for ImageMosaic.
https://jira.codehaus.org/browse/GEOS-5701

The support for time ranges has been committed only on trunk, and I’m working on GeoServer support for it
right now (still uncommitted), so it should not be the case

I’m running GeoServer WAR on Mac OS X 10.8.2 with Tomcat 7.0.37 installed by Homebrew.

Hope this issue could be rectified before officially release of 2.3. Until then I would stick to 2.2.5.

Not sure we’ll manage, 2.3.0 was due out last week, we delayed it a bit but in the next few days
it has to be out (we follow a time boxed release model)

Cheers
Andrea

–

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it 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