[Geoserver-devel] Time dimension for a "instant"

GeoServer GeoServer Developer
1

I'm working on trying to send data to a (closed-source) WMS client that
doesn't like my GeoServer WMS GetCapabilities response.

The data is wave height (from the WaveWatch III model, thanks to all those who
worked on 4D support, and on netCDF and GRIB support). From the logs, the
problem appears to be the time dimension:
<Dimension name="time" default="2015-03-09T00:00:00Z"
units="ISO8601">2015-03-09T00:00:00.000Z/2015-03-09T00:00:00.000Z/PT1S,2015-03-09T03:00:00.000Z/2015-03-09T03:00:00.000Z/PT1S,2015-03-09T06:00:00.000Z/2015-03-09T06:00:00.000Z/PT1S,2015-03-09T09:00:00.000Z/2015-03-09T09:00:00.000Z/PT1S,2015-03-09T12:00:00.000Z/2015-03-09T12:00:00.000Z/PT1S</Dimension>
(it keeps going, I've just trimmed the data here).

Specifically, that client doesn't like the end time not being greater than the
start time. I'm going to have to fix this on the server side (or perhaps via
some XSLT magic on the client side), but I'm wondering if that is really
"legal" per the WMS 1.3.0 spec and OGC 12-111r1 best practice guide.

If the start and end are the same, should we really be doing just a list of
instants:
<Dimension name="time" default="2015-03-09T00:00:00Z"
units="ISO8601">2015-03-09T00:00:00.000Z,2015-03-09T03:00:00.000Z,2015-03-09T06:00:00.000Z,2015-03-09T09:00:00.000Z,2015-03-09T12:00:00.000Z,2015-03-09T15:00:00.000Z</Dimension>

Irrespective of whether it is legal / compliant, are there interoperability
reasons why we need to keep the start/start/PT1S convention anyway?

Basically, I'm trying to figure out if I should try to put this change upstream
or just keep it local.

Brad

2

Hi Brad,
I’m not 100% sure, but believe GeoServer is just re-publishing what it’s getting from the NetCDF driver.
Daniele (cc’ed), do you know why/under which conditions the netcdf reader publishes time periods
instead of simple time intervals?

Cheers
Andrea

···

On Mon, Mar 16, 2015 at 4:07 AM, Brad Hards <bradh@anonymised.com> wrote:

I’m working on trying to send data to a (closed-source) WMS client that
doesn’t like my GeoServer WMS GetCapabilities response.

The data is wave height (from the WaveWatch III model, thanks to all those who
worked on 4D support, and on netCDF and GRIB support). From the logs, the
problem appears to be the time dimension:
2015-03-09T00:00:00.000Z/2015-03-09T00:00:00.000Z/PT1S,2015-03-09T03:00:00.000Z/2015-03-09T03:00:00.000Z/PT1S,2015-03-09T06:00:00.000Z/2015-03-09T06:00:00.000Z/PT1S,2015-03-09T09:00:00.000Z/2015-03-09T09:00:00.000Z/PT1S,2015-03-09T12:00:00.000Z/2015-03-09T12:00:00.000Z/PT1S
(it keeps going, I’ve just trimmed the data here).

Specifically, that client doesn’t like the end time not being greater than the
start time. I’m going to have to fix this on the server side (or perhaps via
some XSLT magic on the client side), but I’m wondering if that is really
“legal” per the WMS 1.3.0 spec and OGC 12-111r1 best practice guide.

If the start and end are the same, should we really be doing just a list of
instants:
2015-03-09T00:00:00.000Z,2015-03-09T03:00:00.000Z,2015-03-09T06:00:00.000Z,2015-03-09T09:00:00.000Z,2015-03-09T12:00:00.000Z,2015-03-09T15:00:00.000Z

Irrespective of whether it is legal / compliant, are there interoperability
reasons why we need to keep the start/start/PT1S convention anyway?

Basically, I’m trying to figure out if I should try to put this change upstream
or just keep it local.

Brad

Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/

Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–

==

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

AVVERTENZE AI SENSI DEL D.Lgs. 196/2003

Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy’s New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.

3

On Mon, 16 Mar 2015 04:28:27 AM Andrea Aime wrote:

I'm not 100% sure, but believe GeoServer is just re-publishing what it's
getting from the NetCDF driver.
Daniele (cc'ed), do you know why/under which conditions the netcdf reader
publishes time periods
instead of simple time intervals?
From a quick look at the GeoTools NetCDFReader code, it looks like there will

always be time periods (DateRange instances) for the global time domain in
NetCDF.

It might not be very hard to change the behaviour to special-case this on the
GeoServer side:

diff --git a/src/main/src/main/java/org/geoserver/util/ISO8601Formatter.java b/src/main/src/main/java/org/geoserver/util/ISO8601Formatter.java
index 00b6c40..bbb9cc2 100644
--- a/src/main/src/main/java/org/geoserver/util/ISO8601Formatter.java
+++ b/src/main/src/main/java/org/geoserver/util/ISO8601Formatter.java
@@ -46,14 +46,17 @@ public class ISO8601Formatter {
      * Formats the specified object either as a single time, if it's a Date, or as a continuous
      * interval, if it's a DateRange (and will throw an {@link IllegalArgumentException} otherwise)
      *
- * @param date
- * @return
+ * @param date the date or date range to format
+ * @return string containing date / date range in ISO8601 (as modified by OGC WMS) format
      */
     public String format(Object date) {
- if(date instanceof Date) {
+ if (date instanceof Date) {
             return format((Date) date);
- } else if(date instanceof DateRange){
+ } else if (date instanceof DateRange) {
             DateRange range = (DateRange) date;
+ if (range.getMinValue().compareTo(range.getMaxValue()) == 0) {
+ return format(range.getMinValue());
+ }
             StringBuilder sb = new StringBuilder();
             format(range.getMinValue(), sb);
             sb.append("/");

That works for my special case.

However I'm still not sure this is the right fix, or even if a fix is needed.
If it is, no problem with working up some tests and submitting
a PR.

Brad

4

Hi Andrea,

the NetCDF reader return the DateRange as time Intervals indeed.

As far as I can see, is a DateRangeVisitor inside the ImageMosaic reader which returns the temporal domain as compact time periods when it find date ranges.

Not sure to remember why it has been set to return them as periods instead of intervals. I vaguely remember some internal discussion about time range validity, in order to specify that the granules of the mosaic are continuously valid for the full extent of the interval, specifying that with a resolution of 1 second as period, in relation to some convention of specific services/specifications.

We may consider revisiting this behaviour if needed, with a look to the specifications.

Hope this helps.

Daniele

···

On Mon, Mar 16, 2015 at 4:28 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

Hi Brad,
I’m not 100% sure, but believe GeoServer is just re-publishing what it’s getting from the NetCDF driver.
Daniele (cc’ed), do you know why/under which conditions the netcdf reader publishes time periods
instead of simple time intervals?

Cheers
Andrea

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

Ing. Daniele Romagnoli
Senior Software Engineer

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

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

AVVERTENZE AI SENSI DEL D.Lgs. 196/2003

Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy’s New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.

On Mon, Mar 16, 2015 at 4:07 AM, Brad Hards <bradh@anonymised.com1…> wrote:

I’m working on trying to send data to a (closed-source) WMS client that
doesn’t like my GeoServer WMS GetCapabilities response.

The data is wave height (from the WaveWatch III model, thanks to all those who
worked on 4D support, and on netCDF and GRIB support). From the logs, the
problem appears to be the time dimension:
2015-03-09T00:00:00.000Z/2015-03-09T00:00:00.000Z/PT1S,2015-03-09T03:00:00.000Z/2015-03-09T03:00:00.000Z/PT1S,2015-03-09T06:00:00.000Z/2015-03-09T06:00:00.000Z/PT1S,2015-03-09T09:00:00.000Z/2015-03-09T09:00:00.000Z/PT1S,2015-03-09T12:00:00.000Z/2015-03-09T12:00:00.000Z/PT1S
(it keeps going, I’ve just trimmed the data here).

Specifically, that client doesn’t like the end time not being greater than the
start time. I’m going to have to fix this on the server side (or perhaps via
some XSLT magic on the client side), but I’m wondering if that is really
“legal” per the WMS 1.3.0 spec and OGC 12-111r1 best practice guide.

If the start and end are the same, should we really be doing just a list of
instants:
2015-03-09T00:00:00.000Z,2015-03-09T03:00:00.000Z,2015-03-09T06:00:00.000Z,2015-03-09T09:00:00.000Z,2015-03-09T12:00:00.000Z,2015-03-09T15:00:00.000Z

Irrespective of whether it is legal / compliant, are there interoperability
reasons why we need to keep the start/start/PT1S convention anyway?

Basically, I’m trying to figure out if I should try to put this change upstream
or just keep it local.

Brad

Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/

Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–

==

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

AVVERTENZE AI SENSI DEL D.Lgs. 196/2003

Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy’s New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.