Hello, Thanks both of you. It seems that, finally, the client request was incorrect as it uses TIME value with second resolution.
I agree with Thomas about the bug for those who want to get second time resolution this won't work. Y. On Tuesday, February 16, 2016 15:54:20 thomas bonfort wrote: > Even, > I'm not sure I agree with your conclusion. > > I think the intention would be to write > > timecol between time0 and time0+resolution > > which translates to: > > time0<=timecol<=time0+resolution > > whereas we want: > > time0<=timecol<time0+resolution > > thus the hack to use time0+resolution-1second which is clearly incorrect > when the desired resolution is the second (and somewhat incorrect for the > other resolutions) > > > I'd say this is a bug. > > -- > thomas > > On 16 February 2016 at 15:43, Even Rouault <even.roua...@spatialys.com> > > wrote: > > Le mardi 16 février 2016 15:21:17, Yves Jacolin a écrit : > > > Hello, > > > > > > I have a WMS-T layer. The datasource is in a postgis layer. The SQL > > > > request > > > > > send by MapServer is something like this: > > > > > > ("timestamp" between date_trunc('second',timestamp > > > '2016-02-17T15:00:00.000Z') and date_trunc('second',timestamp > > > '2016-02-17T15:00:00.000Z') + interval '1 second' - interval '1 second') > > > > > > I understand the + interval '1 second' - interval '1second', but I can't > > > understand how the first interval resolution come from, see [1]. > > > > > > I guess this is calculated from wms_timedefault or wms_timeextent. Here > > > > my > > > > > METADATA LAYER of my mapfile: > > > "wms_timeextent" "2016-02-16T22:20/2016-02-17T21:20/PT1H" > > > "wms_timeitem" "timestamp" > > > "wms_timedefault" "2016-02-16T23:20" > > > > > > Any idea how I can "force" the interval resolution to minute? > > > > Yves, > > > > The resolution comes from the value of time parameter passed in the WMS > > request (or the timedefault value if time is not specified). To get a one > > minute resolution, the time parameter must be expressed in minutes. > > > > This is > > > > actually explained in http://mapserver.org/ogc/wms_time.html ( > > "Interpreting > > Time Values", "Exceptions to this rule") > > > > AFAICS there's no way to override that currently (although it might > > potentially be desirable, for example by taking into account the > > resolution in > > the timeextent syntax) > > > > One workaround to indicate the intent to the client is to specify > > "wms_timeformat". Although it doesn't seem to work properly currently, ie > > if > > you specify "YYYY-MM-DDTHH:MM", a value with seconds will be accepted as > > validating the beginning of the pattern. Hum looks like a bug. > > > > Even > > > > -- > > Spatialys - Geospatial professional services > > http://www.spatialys.com > > _______________________________________________ > > mapserver-users mailing list > > mapserver-users@lists.osgeo.org > > http://lists.osgeo.org/mailman/listinfo/mapserver-users -- Responsable Formation et Support Camptocamp France SAS Savoie Technolac, BP 352 73377 Le Bourget du Lac, Cedex Tel (France) : +33 4 58 48 20 43 (new !) Tel (Suisse) : +41 21 619 10 43 Mob. : +33 6 18 75 42 21 Fax : 04 79 70 15 81 Mail : yves.jaco...@camptocamp.com http://www.camptocamp.com _______________________________________________ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users