Opened 11 years ago
Last modified 11 years ago
#2459 closed defect
v2.6 QUERYMAPFEATURES may produce inconsistent results — at Initial Version
Reported by: | jng | Owned by: | jng |
---|---|---|---|
Priority: | high | Milestone: | 2.6 |
Component: | Rendering Service | Version: | |
Severity: | critical | Keywords: | |
Cc: | External ID: |
Description
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 want to use the layer names within its MgSelection for collecting the matching attributes instead of using the layer names from the original request.