[Geoserver-devel] Submitting code for Time parameter in WMS request

Dear geoserver list,

I'm working on the multidimensional WMS and the handling of the TIME and ELEVATION parameters.
For this work, Martin Desruisseaux and I have designed a class to get the value of the TIME parameter in a WMS request and to parse it as in the standard.
This parameter can take :
- a date, as in ISO-8601:2000 standard. For example : TIME=2007-08-08T12:00:00Z
- a comma-separated list of dates. For example : TIME=2007-08-08T12:00:00Z,2007-08-09T12:00:00Z,2007-08-10T12:00:00Z
- a period. For example : TIME=2007-01-01T12:00:00Z/2007-02-01T12:00:00Z/P1D (which means every day between the first of January 2007 to the first of February 2007).
This class TimeKvpParser is owned by the package org.geoserver.ows.kvp.
It provides some methods that parse dates as in the ISO-8601 standard, and parse the increment part of a period.

I would be glad if you could consider this code for an hypothetic inclusion in Geoserver code base, and corrects it if you see some mistakes.
I've put the same header copyright in my classes since it seems to be what you use in the source code of Geoserver.

Best regards,
Cédric Briançon.

(attachments)

TimeKvpParser.java (7.62 KB)
TimeKvpParserTest.java (2.58 KB)

Cédric Briançon ha scritto:

Dear geoserver list,

I'm working on the multidimensional WMS and the handling of the TIME and ELEVATION parameters.
For this work, Martin Desruisseaux and I have designed a class to get the value of the TIME parameter in a WMS request and to parse it as in the standard.
This parameter can take :
- a date, as in ISO-8601:2000 standard. For example : TIME=2007-08-08T12:00:00Z
- a comma-separated list of dates. For example : TIME=2007-08-08T12:00:00Z,2007-08-09T12:00:00Z,2007-08-10T12:00:00Z
- a period. For example : TIME=2007-01-01T12:00:00Z/2007-02-01T12:00:00Z/P1D (which means every day between the first of January 2007 to the first of February 2007).
This class TimeKvpParser is owned by the package org.geoserver.ows.kvp.
It provides some methods that parse dates as in the ISO-8601 standard, and parse the increment part of a period.

Sigh, the third way to parse ISO dates in our codebase. We already have
the jaxb library and a class in geotools doing so (the latter does not
work very well in fact).

I would be glad if you could consider this code for an hypothetic inclusion in Geoserver code base, and corrects it if you see some mistakes.
I've put the same header copyright in my classes since it seems to be what you use in the source code of Geoserver.

Code looks good as far as I can see, I have no particular objection,
besides the fact that I would love to see the iso date handling
centralized somehow. But I guess that could come later, when we decide
wheter to ship with a shrinked down version of jaxb (we don't use any
of its xml capabilities, only its date parsing/encoding code), to
ship will full jaxb and use it everywhere, or to roll our own.

Cheers
Andrea

Andrea Aime a écrit :

Cédric Briançon ha scritto:

Dear geoserver list,

I'm working on the multidimensional WMS and the handling of the TIME and ELEVATION parameters.
For this work, Martin Desruisseaux and I have designed a class to get the value of the TIME parameter in a WMS request and to parse it as in the standard.
This parameter can take :
- a date, as in ISO-8601:2000 standard. For example : TIME=2007-08-08T12:00:00Z
- a comma-separated list of dates. For example : TIME=2007-08-08T12:00:00Z,2007-08-09T12:00:00Z,2007-08-10T12:00:00Z
- a period. For example : TIME=2007-01-01T12:00:00Z/2007-02-01T12:00:00Z/P1D (which means every day between the first of January 2007 to the first of February 2007).
This class TimeKvpParser is owned by the package org.geoserver.ows.kvp.
It provides some methods that parse dates as in the ISO-8601 standard, and parse the increment part of a period.

Sigh, the third way to parse ISO dates in our codebase. We already have
the jaxb library and a class in geotools doing so (the latter does not
work very well in fact).

The class you mentionned doesn't seem to handle the period part. I didn't think that you could use the jaxb jars only for parsing dates, because the 3 jars weights more than 2 Mb together, and I thought jaxb was designed to handle XML bindings. Using it only to parse dates may be a redundancy with the geotools class.
Martin told me that the right place for this kind of method should be in the org.opengis.temporal package.

I would be glad if you could consider this code for an hypothetic inclusion in Geoserver code base, and corrects it if you see some mistakes.
I've put the same header copyright in my classes since it seems to be what you use in the source code of Geoserver.

Code looks good as far as I can see, I have no particular objection,
besides the fact that I would love to see the iso date handling
centralized somehow. But I guess that could come later, when we decide
wheter to ship with a shrinked down version of jaxb (we don't use any
of its xml capabilities, only its date parsing/encoding code), to
ship will full jaxb and use it everywhere, or to roll our own.

Cheers
Andrea

http://www.labo-sun.com/resource-FR-articles-606-0-java-autre-jaxb-le

Cédric Briançon ha scritto:

Andrea Aime a écrit :

Cédric Briançon ha scritto:

Dear geoserver list,

I'm working on the multidimensional WMS and the handling of the TIME and ELEVATION parameters.
For this work, Martin Desruisseaux and I have designed a class to get the value of the TIME parameter in a WMS request and to parse it as in the standard.
This parameter can take :
- a date, as in ISO-8601:2000 standard. For example : TIME=2007-08-08T12:00:00Z
- a comma-separated list of dates. For example : TIME=2007-08-08T12:00:00Z,2007-08-09T12:00:00Z,2007-08-10T12:00:00Z
- a period. For example : TIME=2007-01-01T12:00:00Z/2007-02-01T12:00:00Z/P1D (which means every day between the first of January 2007 to the first of February 2007).
This class TimeKvpParser is owned by the package org.geoserver.ows.kvp.
It provides some methods that parse dates as in the ISO-8601 standard, and parse the increment part of a period.

Sigh, the third way to parse ISO dates in our codebase. We already have
the jaxb library and a class in geotools doing so (the latter does not
work very well in fact).

The class you mentionned doesn't seem to handle the period part.

Indeed it does not. It also has other troubles, and I wanted to throw it
away in fact.

I didn't think that you could use the jaxb jars only for parsing dates, because the 3 jars weights more than 2 Mb together, and I thought jaxb was designed to handle XML bindings. Using it only to parse dates may be a redundancy with the geotools class.

Yet that's what the new XML modules are doing. I suggested to create a
trimmed down version of JAXME (a jaxb open source compatible library from apach) with only the classes that we use, but
that did not get much traction because we would end up maintaining our
own fork. Which is still easier, imho, than having 3 copies around imho...

Martin told me that the right place for this kind of method should be in the org.opengis.temporal package.

I don't mind the place, the trouble is really that we need a good parser/encoder for all xs:date, xs:time and xs:datetime, and possibly just one.

Cheers
Andrea