Two layers with same data source show up wrong in Feature Info

[GoogleCodeExporter]

I have two layers. They're the exact same datasource, but with different 
styling (in lieu of a better way to do this I'm declaring twice).
They're declared thus:

    //MOSAIC note - the same dataset is referenced twice, but with a different style. See the "Styles" parrameter.
    //polygon
    new OpenLayers.Layer.WMS(
        "2011 Mosaic - Most Frequent Group",
        Heron.WCC.InternalUrls.geoserver_wms,
        {layers: "EXP_MOSAIC_AT_100M_GRID_2011", transparent: true, format: 'image/png'},
        {singleTile: true, visibility: false, featureInfoFormat: 'application/vnd.ogc.gml', metadata: {
            wfs: {
                protocol: 'fromWMSLayer',
                featurePrefix: 'Public_Data_DB',
                featureNS: 'http://www.warwickshire.gov.uk/public_data_db'
            }
        }}
    ),

    //polygon
    new OpenLayers.Layer.WMS(
        "2011 Mosaic - Most Frequent Type",
        Heron.WCC.InternalUrls.geoserver_wms,
        {layers: "EXP_MOSAIC_AT_100M_GRID_2011", transparent: true, format: 'image/png', styles:'polygon categorised Mosaic Type'},
        {singleTile: true, visibility: false, featureInfoFormat: 'application/vnd.ogc.gml', metadata: {
            wfs: {
                protocol: 'fromWMSLayer',
                featurePrefix: 'Public_Data_DB',
                featureNS: 'http://www.warwickshire.gov.uk/public_data_db'
            }
        }}
    ),


The bug:
When I query EITHER of those layers, the resultant query box always says "2011 
Mosaic - Most Frequent Group" as the layer I'm querying.

This is because I used "EXP_MOSAIC_AT_100M_GRID_2011" as the search criteria, 
but of course, that appears twice in the list now but its only got a 50/50 
chance of getting the right one.

Possible Solutions:
a) Better way to have the same data accessable with multiple styles.
b) Use a different unique identifier to find the right layer.

(b) is probably simpler.

Original issue reported on code.google.com by jonathan...@warwickshire.gov.uk on 30 May 2013 at 9:09

[GoogleCodeExporter]

Original comment by jonathan...@warwickshire.gov.uk on 30 May 2013 at 3:12

[GoogleCodeExporter]

Original comment by jus...@gmail.com on 7 Jun 2013 at 10:08

• Added labels: Milestone-Release0.74

[GoogleCodeExporter]

Very hard to solve: the response from a GFI from GeoServer has no reference to 
the original layer for each feature record. Tabs in the GFI grid are 
distinguished by mapping a feature type in the GFI response. That feature type 
is always the same for any layer with or without styles.

One thing we can do is to not request multiple layers with the identical names 
but different styles. .

I experimented with just having each layer be requested once, removing 
duplicates that have the same LAYERS= but different STYLES=. This is now on 
http://lib.heron-mc.org/heron/latest/examples/defaultnl/ (Layers: ThemaLagen | 
BAG Panden and BAG Panden Selected, these are buildings, need to zoom in). In 
that case I get the list of features only once in a single tab for whichever 
layer comes first. After all it is the same table. 

Original comment by jus...@gmail.com on 3 Jul 2013 at 4:26

[GoogleCodeExporter]

That's one possible solution and quite a good one.
However, one thing to keep in mind is that SLD's can be used to show different 
subsets of the same dataset.
You'd have to make sure that when the GFI request is sent there was no styling 
parameter at all in it to ensure the enter dataset is queried. Although of 
course if the user only wanted to query the visible (styled) subset... Yep, no 
easy solution.

Original comment by jonathan...@warwickshire.gov.uk on 4 Jul 2013 at 9:48

[GoogleCodeExporter]

Yes, I realize that SLDs and even worse custom filter/CQL can be used for 
subsets. In some cases there may be always STYLES parameters. The question is 
what to do in any case...Multiple separate GFI requests and assembling 
responses is one option but quite complicated.

Original comment by jus...@gmail.com on 4 Jul 2013 at 10:16

[GoogleCodeExporter]

Ah, I missed the filter/CQL stuff, it's not something I've dabbled much with 
yet.

I suspect the simplest solution is just to query the entire dataset stripping 
out style and filter/CQL stuff. It's generally better to return more than less 
and the number of people using layers setup like that is probably vanishingly 
small (although it will probably be a gotcha for them).
Alternately maybe stick in a config option that lets the implementer choose 
whether to keep the style/cql stuff or not.

Original comment by jonathan...@warwickshire.gov.uk on 4 Jul 2013 at 10:25

[GoogleCodeExporter]

I'm afraid this turns into a sort of Catch-22 situation. It is not possible, at 
least not without intervening deep into OpenLayers code, to strip-off the 
STYLES and CQL params. But even then other scenarios may break down. There may 
be cases where STYLES (or CQL) has been put in deliberately, e.g. to filter 
from a huge object set (let's say all castles from all buildings and another 
STYLE to have a layer show only houses and another barns etc). They could be 
mutually exclusive. Making only the castles and barns layers visible I would 
rather not see all castles, barns AND houses under the "castles" tab...In that 
case if these were really considered different feature types, I would consider 
maintaining a single DB table but arrange for different VIEWs within the DB and 
have a Layer per view. Another issue with the last approach is that a possible 
WFS solution is more robust.

This is common practice in PostGIS.

Original comment by jus...@gmail.com on 4 Jul 2013 at 2:07

• Changed state: Started

[GoogleCodeExporter]

The problem with views is that they use more database resources and are slower 
- plus not all GIS's seem to handle them well. Ourselves we generally split 
stuff across different tables.

> There may be cases where STYLES (or CQL) has been put in deliberately
Yes, but that's why I suggested an implementer config option. They could then 
choose if styles/CQL are to be obeyed or discarded dependent on their database 
setup.

Original comment by jonathan...@warwickshire.gov.uk on 4 Jul 2013 at 2:11

[GoogleCodeExporter]

Ok, fixed as follows:

- in case of duplicate layer names, request only one layer
- if the property discardStylesForDups is set, this one layer will be requested 
without any styles

CQL and Filters are appearantly not sent with GFI within OpenLayers where the 
GFI request is constructed.

Please test with the latest Heron.js.

Original comment by jus...@gmail.com on 8 Jul 2013 at 3:56

[GoogleCodeExporter]

So far I'm not seeing any change in behaviour. How and where do I set 
"discardStylesForDups"? Is it a per-layer setting or with the feature 
information tool declaration or somewhere else?

Original comment by jonathan...@warwickshire.gov.uk on 16 Jul 2013 at 1:38

[GoogleCodeExporter]

discardStylesForDups is a config property for FeatureInfoPanel with false as 
default, for example for a toolbar popup:

    {type: "featureinfo", options: {
        pressed: true,
        popupWindow: {
            width: 320,
            height: 200,
            featureInfoPanel: {
                // Option values are 'Grid', 'Tree' and 'XML', default is 'Grid' (results in no display menu)
                displayPanels: ['Grid'],
                // Export to download file. Option values are 'CSV', 'XLS', default is no export (results in no export menu).
                exportFormats: [],
                // exportFormats: ['CSV', 'XLS'],
                maxFeatures: 10,

                // In case that the same layer would be requested more than once: discard the styles
                discardStylesForDups: true
            }
        }
    }},

Original comment by jus...@gmail.com on 16 Jul 2013 at 2:03

[GoogleCodeExporter]

Thanks for that. I've now tried it out and I can still see absolutely no change 
in behaviour from before.

Performing a query, there's a 50/50 chance it will return the right text for 
the tab. The data returned is fine as that isn't changed by the SLDs.

Original comment by jonathan...@warwickshire.gov.uk on 16 Jul 2013 at 2:21

[GoogleCodeExporter]

Ok, there were at least two minor mishaps that I've fixed:

- tab naming was not consistent (even showed non-visible layer names)
- styles parameters could be "eaten" from a Layer object

But still: with 2 layers of the same name with different STYLEs only one will 
be queried and shown in the tab. Can you try again?

My test steps, layers in example:
http://lib.heron-mc.org/heron/latest/examples/defaultnl/

- zoom to level 13
- make overlay Layers: "BAG - Panden" en "BAG - Panden Selected" (buildings) 
visible
- try out combinations with GFI (NB duplicate gid-fields are not duplicate 
features, they differ in some columns, this is in the dataset itself).

Hopefully you have time today, as I really would like to close this issue to 
move to 0.74 and then integrate GFI Panel and WFS result Panels: issue 239 and 
issue 240. This will make GFI also show geometries and additional export 
formats.

Original comment by jus...@gmail.com on 17 Jul 2013 at 11:02

[GoogleCodeExporter]

This seems to work. The tab name is correct for the layer clicked now.
If both layers are active and queried in the same click, behaviour remains 
unchanged (one tab opens with a random name from the two). I guess that's 
desired.

So looks ok to me.

Original comment by jonathan...@warwickshire.gov.uk on 17 Jul 2013 at 11:25

[GoogleCodeExporter]

Good! Closing then...

Original comment by jus...@gmail.com on 17 Jul 2013 at 11:32

• Changed state: Verified