You need to log in before you can comment on or make changes to this bug.
>8.If a query is active in a region of interest, and the Extract WFS >> Data button is pushed the GML returned is of the region of interest, >> not the GML of the query. Does this make sense? Paul wrote: I have checked the code and it seems to try to accomodate an existing filter on a layer by restoring it after extraction. In the specific case of the existing filter containing a spatial element starting with <bbox or <dwithin or <intersect, the existing filter will be used for extraction. Otherwise, the filter appears to be ignored (which could be a bug) for extraction. I think that the fix (if it is a bug) could be simple, since it happens in the specific case that the existing filter has no spatial component, the new filter could be added (on line 294 in my version of the code) in the else clause of the section that starts with the comment * Build Spacial Filter: else { $szSpacialFilter = "<AND>".$szSpacialFilter.$szExistingWFSFilter."</AND>"; // set flag to clear the metadata item after use $bClearFilter = true; } This will obviously need to be tested and I am not in a position to be able to do that so I defer implementation to Julien :>
Reassigned to Julien. (See also internal bug 2829)
Changed target to 1.99 RC 1.
To fix this I did two things: 1) I made the patch proposed by Paul to make the ExtractWFSData use the inline wfs_filter of a layer when no spatial filter is setted. This is in ExtractWFSData.php. 2) When creating a ExpressionBuilder layer, the newly created layer is now selected in the legend. Obviously, when deleting, the origin layer is selected. Marking as FIXED
