[mapserver-users] GetFeatureInfo request for multiple times on tileindex raster layer

Fri Aug 5 07:06:50 PDT 2016

Thanks for the response, Ben.

What would be the result of an *getmap*-Request

Yes, good point- it appears that if two discrete dates are requested via
GetMap, the result is a merged image (w/ the most recent date getting
precedence):

http://spatial.mtri.org/cgi-bin/mapserv.fcgi?SERVICE=WMS&
VERSION=1.1.1&REQUEST=GetMap&map=watersensing_map&LAYERS=
chl_erie&time=2015-09-24,2016-05-23&height=512&width=512&
format=image/png&sld=http://spatial.mtri.org/waterremotesensing/SLDs/chl_
erie.xml&srs=EPSG:4326&bbox=-83.55,39.45,-78.45,44.55&opacity=1

It's hard to tell in the above URL, but if you toggle between a two-date
and one-date request, you can tell that the two-date request has the maps
layered (w/ the map for the most recent date on top).  So it's probably a
good guess that the same logic is applying in the GFI requests.

I'll take a look at the source code to see if there might be a way to
override this logic. To anyone here who is already familiar with the source
code: I welcome any tips about where to look and whether or not my quest
may be futile unless I want to break everything.

On Fri, Aug 5, 2016 at 2:57 AM, Schepers, Benjamin <schepers at rvr-online.de>
wrote:

> Hi Mike,
>
>
>
> just my thoughts:
>
> What would be the result of an *getmap*-Request in your second scenario
> with multiple discrete timestamps?
>
> A getmap-request just can produce one single image – anything else
> wouldn’t make sense to me. So if you request two discrete timestamps, one
> would expect to get two rasters from DB/filesystem and there has to be a
> logic what should be done by mapserver with those two images (choose the
> topmost or the underlying or a merge of them – which merge method? – of
> those pics to get one of two or many)…
>
> Maybe the latest date, as you determined, is the topmost.
>
>
>
> My thought what getfeatureinfo logic does are equivalent to that…
>
> Maybe I’m wrong with that, but that could just be answered by someone who
> can read the sourcecode?!
>
>
>
> If you want to merge rasters on the fly (or their values) COMPOSITE maybe
> could help you: http://mapserver.org/de/mapfile/composite.html
>
>
>
> Sincerely
>
> Ben
>
>
>
>
>
>
>
> *Benjamin Schepers *
> Luftbild und Geoinformationssysteme
> Kronprinzenstraße 35
> 45128 Essen
> Fon: +49 201 2069-232
> Fax: +49 201 2069-500
> schepers at rvr-online.de
>
>
>
>
> *Die Regionaldirektorin *Kronprinzenstraße 35
> 45128 Essen
> Zentrale: +49 (0) 201 2069-0
> Fax: +49 (0) 201 2069-500
> www.metropoleruhr.de
>
> Postfach 10 32 64
> 45032 Essen
>
> Steuernummer: RVR 112/5797/0116
> USt.-ldNr.: DE 173867500
>
> Diese E-Mail koennte vertrauliche und/oder rechtlich geschuetzte
> Informationen enthalten.
> Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtuemlich
> erhalten haben, informieren Sie bitte sofort den Absender und vernichten
> Sie diese Mail.
> Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser E-Mail sind
> nicht gestattet.
> This e-mail may contain confidential and/or privileged information.
> If you are not the intended recipient (or have received this e-mail in
> error) please notify the sender immediately and destroy this e-mail.
> Any unauthorised copying, disclosure or distribution of the material in
> this e-mail is strictly forbidden.
>
> *Von:* mapserver-users [mailto:mapserver-users-bounces at lists.osgeo.org] *Im
> Auftrag von *Michael Billmire
> *Gesendet:* Donnerstag, 4. August 2016 21:53
> *An:* mapserver-users at lists.osgeo.org
> *Betreff:* [mapserver-users] GetFeatureInfo request for multiple times on
> tileindex raster layer
>
>
>
> Hi all,
>
>
>
> I'm serving raster layers as time-series using a PostGIS tile index (
> GetCapabilities
> <http://spatial.mtri.org/cgi-bin/mapserv?REQUEST=GetCapabilities&SERVICE=WMS&map=watersensing_map>,
> for reference).
>
>
>
> GetFeatureInfo is working fine for single timestamp requests, e.g.:
>
> http://spatial.mtri.org/cgi-bin/mapserv.fcgi?SERVICE=WMS&
> VERSION=1.1.1&REQUEST=GetFeatureInfo&map=watersensing_map&QUERY_LAYERS=
> chl_erie&LAYERS=chl_erie&time=2015-09-06&height=512&width=
> 512&srs=EPSG:4326&bbox=-83.55,39.45,-78.45,44.55&opacity=1&
> INFO_FORMAT=text/html&X=250&Y=250
>
>
>
> However, when requesting *multiple* *discrete* time stamps (e.g.
> time=2015-09-06,2016-05-23), I get multiple results (i.e. a result for each
> timestamp), BUT the pixel value returned is the same for each result,
> representing the raster with the latest date:
>
> http://spatial.mtri.org/cgi-bin/mapserv.fcgi?SERVICE=WMS&
> VERSION=1.1.1&REQUEST=GetFeatureInfo&map=watersensing_map&QUERY_LAYERS=
> chl_erie&LAYERS=chl_erie&time=2015-09-06,2016-05-23&height=
> 512&width=512&srs=EPSG:4326&bbox=-83.55,39.45,-78.45,44.
> 55&opacity=1&INFO_FORMAT=text/html&X=250&Y=250
>
>
>
> In my template, [value_list] returns just the single value (i.e. the value
> of the raster at the latest date), [value_0] returns that same value, and
> [value_1] returns nothing.
>
>
>
> Is there anything obvious here that I'm doing wrong? Is this type of
> multiple timestamp pixel querying even supported?
>
>
>
> thanks!
>
> -Mike
>
>
>
>
>
> --
>
> Michael Billmire, CMS-GIS/LIS
> Research Scientist
> Michigan Tech Research Institute (MTRI)
> 3600 Green Ct. Suite 100
> Ann Arbor, MI 48105
>
> michael.billmire at mtu.edu
> work: 734.913.6853
> cell: 513.739.0686
> fax: 734.913.6880
>

-- 
Michael Billmire, CMS-GIS/LIS
Research Scientist
Michigan Tech Research Institute (MTRI)
3600 Green Ct. Suite 100
Ann Arbor, MI 48105

michael.billmire at mtu.edu
work: 734.913.6853
cell: 513.739.0686
fax: 734.913.6880
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-users/attachments/20160805/b0ed497e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 8303 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/mapserver-users/attachments/20160805/b0ed497e/attachment-0001.jpg>