#2459 closed defect (fixed)
v2.6 QUERYMAPFEATURES may produce inconsistent results
Reported by: | jng | Owned by: | jng |
---|---|---|---|
Priority: | high | Milestone: | 2.6 |
Component: | Rendering Service | Version: | |
Severity: | critical | Keywords: | |
Cc: | External ID: |
Description (last modified by )
The v2.6 QUERYMAPFEATURES works like this:
- Call MgRenderingService::QueryFeatures() with the given parameters (returns a MgFeatureInformation)
- Call MgRenderingService::RenderDynamicOverlay() with the given parameters (if inline selection is requested)
- Call MgRenderingService::QueryFeatureProperties() with the given parameters (if attributes is selected)
All 3 components are then married up to form the final response.
A click-based selection will issue QUERYMAPFEATURES with MAXFEATURES=1. For a map with more than 1 selectable layer (eg. Parcels, Trees), there may be cases where the following happens.
- Call MgRenderingService::QueryFeatures() with the given parameters. Returns a MgSelection with Parcels selected.
- Call MgRenderingService::RenderDynamicOverlay() with the given parameters. Returns an image of the selected parcel
- Call MgRenderingService::QueryFeatureProperties() with the given parameters. Returns the attributes of the first selected Tree. Because MAXFEATURES=1, no attributes for Parcels are returned.
The problem is when a click could select more than one layer, the attributes may be collected for the wrong layer, even if that layer has candidate matching features. When MAXFEATURES=1 and we requested LAYERNAMES=Trees,Parcels and a selection image/XML of Parcels is returned, at this point we only want to collect attributes from Parcels instead of Trees and Parcels.
Basically when we have a MgFeatureInformation, we should use its MgSelection to drive the whole attribute collection process instead of reissuing the same request parameters to QueryFeatureProperties() and hoping its set of attributes will match up with the rest of the response.
Attachments (1)
Change History (3)
by , 10 years ago
Attachment: | 2459.patch added |
---|
comment:1 by , 10 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:2 by , 10 years ago
Description: | modified (diff) |
---|---|
Priority: | low → high |
Severity: | trivial → critical |
Fixed trunk (r8252) and 2.6 (r8253)