Hi,
I use a client which by default submit the TIME parameter (for example
TIME=2007-09-19T09:34:05Z) in the getMap URL.
Geoserver (1.5.0) ignored the parameter.
Upgrading to 1.5.3 I get the error:
<ServiceExceptionReport version="1.1.1">
−
<ServiceException>
For input string: "2007-09-19T09:19:09Z"
For input string: "2007-09-19T09:19:09Z"
</ServiceException>
</ServiceExceptionReport>
Guess it no longer ignores it. I can not make any changes on the
client side, and don't know where to for the geoserver
installation....
HI Petter:
Which client is that?
thanks,
Alex
On 9/19/07, petter lorry hansen <petter.lorry.hansen@...84...> wrote:
Hi,
I use a client which by default submit the TIME parameter (for example
TIME=2007-09-19T09:34:05Z) in the getMap URL.
Geoserver (1.5.0) ignored the parameter.
Upgrading to 1.5.3 I get the error:
<ServiceExceptionReport version="1.1.1">
－
<ServiceException>
For input string: "2007-09-19T09:19:09Z"
For input string: "2007-09-19T09:19:09Z"
</ServiceException>
</ServiceExceptionReport>
Guess it no longer ignores it. I can not make any changes on the
client side, and don't know where to for the geoserver
installation....
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users
Looks like a bug to me. The TIME parsing code just passes the TIME value
straight through to Integer.parseInt(..). Is the value supposed to be an
integer? I am not that familiar with how wms time works.
It would probably be easy enough to parse it as a date when parsing it
as an int fails.
Alex: what do you think?
-Justin
Alexander Petkov wrote:
HI Petter:
Which client is that?
thanks,
Alex
On 9/19/07, petter lorry hansen <petter.lorry.hansen@anonymised.com> wrote:
Hi,
I use a client which by default submit the TIME parameter (for example
TIME=2007-09-19T09:34:05Z) in the getMap URL.
Geoserver (1.5.0) ignored the parameter.
Upgrading to 1.5.3 I get the error:
<ServiceExceptionReport version="1.1.1">
－
<ServiceException>
For input string: "2007-09-19T09:19:09Z"
For input string: "2007-09-19T09:19:09Z"
</ServiceException>
</ServiceExceptionReport>
Guess it no longer ignores it. I can not make any changes on the
client side, and don't know where to for the geoserver
installation....
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users
!DSPAM:4007,46f1342427012085621377!
--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org
Is the value supposed to be an
integer?
Not according to the WMS spec. It needs to be a date or a time period.
I used integer-based indexing since the temporal schema code isn't a
part of geotools yet, and I needed to get TIME and ELEVATION working.
But I am surprised to see that an error is thrown, since the TIME
parameter only works with the netcdf plugin and is otherwise ignored
as far as i remember...
Cedric has been working on WMS spec-compliant handling of TIME. If he
has it ready, we can just replace time and elevation with his code.
It would probably be easy enough to parse it as a date when parsing it
as an int fails.
Alex: what do you think?
It should be reworked to accept a date anyway.
Petter: I am still interested to hear about the particular frontend
client that allows the specification of the TIME parameter in a GetMap
request.
Alex
-Justin
Alexander Petkov wrote:
> HI Petter:
>
> Which client is that?
>
> thanks,
> Alex
>
> On 9/19/07, petter lorry hansen <petter.lorry.hansen@...84...> wrote:
>> Hi,
>>
>> I use a client which by default submit the TIME parameter (for example
>> TIME=2007-09-19T09:34:05Z) in the getMap URL.
>> Geoserver (1.5.0) ignored the parameter.
>>
>> Upgrading to 1.5.3 I get the error:
>>
>> <ServiceExceptionReport version="1.1.1">
>> －
>> <ServiceException>
>> For input string: "2007-09-19T09:19:09Z"
>> For input string: "2007-09-19T09:19:09Z"
>> </ServiceException>
>> </ServiceExceptionReport>
>>
>> Guess it no longer ignores it. I can not make any changes on the
>> client side, and don't know where to for the geoserver
>> installation....
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2005.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> _______________________________________________
>> Geoserver-users mailing list
>> Geoserver-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geoserver-users
>>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Geoserver-users mailing list
> Geoserver-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-users
>
> !DSPAM:4007,46f1342427012085621377!
>
--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org
Hi Alex,
The client I use is a WMS client modul in MARIA
http://www.teleplanglobe.com/templates/AboutProductPage.aspx?id=193&featid=320
The primary use of the the client so far is to provide meteorological
information from for example:
http://openmetoc.met.no:8080/metoc/metocwms?request=getCapabilities
where the TIME parameter of course is very important.
I do not know the rule here, but I was hoping that the time parameter would
be ignored if the
server didn't need it..
-P
Alexander Petkov wrote:
Is the value supposed to be an
integer?
Not according to the WMS spec. It needs to be a date or a time period.
I used integer-based indexing since the temporal schema code isn't a
part of geotools yet, and I needed to get TIME and ELEVATION working.
But I am surprised to see that an error is thrown, since the TIME
parameter only works with the netcdf plugin and is otherwise ignored
as far as i remember...
Cedric has been working on WMS spec-compliant handling of TIME. If he
has it ready, we can just replace time and elevation with his code.
It would probably be easy enough to parse it as a date when parsing it
as an int fails.
Alex: what do you think?
It should be reworked to accept a date anyway.
Petter: I am still interested to hear about the particular frontend
client that allows the specification of the TIME parameter in a GetMap
request.
Alex
-Justin
Alexander Petkov wrote:
> HI Petter:
>
> Which client is that?
>
> thanks,
> Alex
>
> On 9/19/07, petter lorry hansen <petter.lorry.hansen@anonymised.com> wrote:
>> Hi,
>>
>> I use a client which by default submit the TIME parameter (for example
>> TIME=2007-09-19T09:34:05Z) in the getMap URL.
>> Geoserver (1.5.0) ignored the parameter.
>>
>> Upgrading to 1.5.3 I get the error:
>>
>> <ServiceExceptionReport version="1.1.1">
>> －
>> <ServiceException>
>> For input string: "2007-09-19T09:19:09Z"
>> For input string: "2007-09-19T09:19:09Z"
>> </ServiceException>
>> </ServiceExceptionReport>
>>
>> Guess it no longer ignores it. I can not make any changes on the
>> client side, and don't know where to for the geoserver
>> installation....
>>
>>
-------------------------------------------------------------------------
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2005.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> _______________________________________________
>> Geoserver-users mailing list
>> Geoserver-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geoserver-users
>>
>
-------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Geoserver-users mailing list
> Geoserver-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-users
>
> !DSPAM:4007,46f1342427012085621377!
>
--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users
--
View this message in context: http://www.nabble.com/Use-of-TIME%2C-WMS-geoserver-tf4480833.html#a12791872
Sent from the GeoServer - User mailing list archive at Nabble.com.
petter lorry hansen ha scritto:
Hi Alex,
The client I use is a WMS client modul in MARIA
http://www.teleplanglobe.com/templates/AboutProductPage.aspx?id=193&featid=320
The primary use of the the client so far is to provide meteorological
information from for example:
http://openmetoc.met.no:8080/metoc/metocwms?request=getCapabilities
where the TIME parameter of course is very important.
I do not know the rule here, but I was hoping that the time parameter would
be ignored if the server didn't need it..
Hum, I guess it's my fault if we're in this situation.
Some time ago Geomatys offered a good parser, and I replied that I would
have loved to centralize date/time parsing in a single place instead
of having it duplicated in 3 places.
I still stand by the idea that we should not have three of those, yet
the net result is that the contribution did not go forward...
Cedric, for what is worth, the contribution is welcomed (it has always
been btw), I guess we can keep the third parsing dupe for some time,
and I'll find a way to merge them somehow...
Cheers
Andrea
petter lorry hansen ha scritto:
Hi Alex,
The client I use is a WMS client modul in MARIA
http://www.teleplanglobe.com/templates/AboutProductPage.aspx?id=193&featid=320
The primary use of the the client so far is to provide meteorological
information from for example:
http://openmetoc.met.no:8080/metoc/metocwms?request=getCapabilities
where the TIME parameter of course is very important.
I do not know the rule here, but I was hoping that the time parameter would
be ignored if the server didn't need it..
It's not about need. An optional parameter can be ignored if the server
does not recognize it. Unfortunately the currently hacked version of
the time parser does recognize it, but expects an integer (out of spec,
but satisfied netcdf extraction needs for Alexander).
I hope we can fix this one soon. Alexander, should the parser keep
working on integers as well, or can we make it strict?
I also opened a jira issue about this one:
http://jira.codehaus.org/browse/GEOS-1351
Cheers
Andrea
I hope we can fix this one soon. Alexander, should the parser keep
working on integers as well, or can we make it strict?
It should be strict and reflect the specification in the WMS docs.
I'll deal with it when I have to 
I also opened a jira issue about this one:
http://jira.codehaus.org/browse/GEOS-1351
Thanks Andrea, I will look into it.
Alex
P.S. In fact, i do have a geotools prototype module that handles time,
but it never got committed.