Opened 9 years ago

Last modified 8 years ago

#3764 new enhancement

[WMS] Cascading WMS GetFeatureInfo

Reported by: jlacroix Owned by: aboudreault
Priority: normal Milestone: 6.2 release
Component: WMS Client Version: unspecified
Severity: normal Keywords:
Cc: dmorissette, assefa, tomkralidis, jmckenna


LAYER with CONNECTIONTYPE WMS cannot be requested with a GetFeatureInfo?. MapServer should cascade GetFeatureInfo? requests and return the response to user he gets to the user without interpreting it.

To prevent any problem in formatting the cascade should only be allowed if the request is done on layers coming from the same WMS servers.

Attachments (2)

3764.patch (11.8 KB) - added by aboudreault 9 years ago.
wms getfeatureinfo cascading
gdb_output_rev11973_brokengetmap.txt (1.2 KB) - added by jgolinowski 8 years ago.
Debugging output (gdb)

Download all attachments as: .zip

Change History (9)

comment:1 Changed 9 years ago by dmorissette

Cc: assefa tomkralidis added
Milestone: 6.2 release

comment:2 Changed 9 years ago by aboudreault

It seems that if the user doesn't specify the "wms/ows_cache_to_disk" metadata, the data retrieved on the remote server is stocked in a buffer, which has a default size of 2048. I think this size is too low for a GetFeatureInfo?. Should we force the user to use wms_cache_to_disk if they want to cascade that request or should we use add a different BUFFER_LENGTH for the WMS GetFeatureInfo??

comment:3 Changed 9 years ago by aboudreault

Nevermind, I saw the HTTPWriteFct that use a dynamic buffer.. so the code I checked if probably never used.

Changed 9 years ago by aboudreault

Attachment: 3764.patch added

wms getfeatureinfo cascading

comment:4 Changed 9 years ago by aboudreault

I've attached a patch for the WMS GetFeatureInfo? cascading. I'm going to keep it locally until the 6.0 branch is created.

comment:5 Changed 8 years ago by aboudreault

Cc: jmckenna added

Committed in r11828. Could anyone also test this feature?

comment:6 Changed 8 years ago by jgolinowski

It seems this feature broke GetMap? cascading. I did some testing with the current trunk (revision 11973). Adding a WMS layer results in a segmentation fault. Using GDB I traced it down to msPrepareWMSLayerRequest() in mapwmslayer.c (line 979) (I will attach gdb output).

There is a logical mistake in this if-else-statement:

    if (nRequestType == WMS_GETMAP &&
        ( msBuildWMSLayerURL(map, lp, WMS_GETMAP, 
                             0, 0, 0, NULL, &bbox, &bbox_width, &bbox_height,
                             &sThisWMSParams) != MS_SUCCESS) )
        /* an error was already reported. */
        return MS_FAILURE;

    else if (msBuildWMSLayerURL(map, lp, WMS_GETFEATUREINFO,
                                nClickX, nClickY, nFeatureCount, pszInfoFormat,
                                NULL, NULL, NULL,
                                &sThisWMSParams) == MS_FAILURE)
        /* an error was already reported. */
        return MS_FAILURE;

If the request type is WMS_GETMAP and msBuildWMSLayerURL() returns MS_SUCCESS the first condition is false and the second condition is checked. That check leads to the segfault because pszInfoFormat is NULL.

Adding nRequestType == WMS_GETFEATUREINFO to the second condition solves this issues (at least for me).

Changed 8 years ago by jgolinowski

Debugging output (gdb)

comment:7 Changed 8 years ago by dmorissette

Nice catch. Fix committed in SVN trunk r12012.

Note: See TracTickets for help on using tickets.