Layer filter with layers from other workspaces

[Severin Menard]

Hi,

I noticed in MapStore 2023.02 for geOrchestra that the filter layer drop-down list only proposes layers from the same GeoServer workspace as the target layer, whereas in previous versions, any vector loaded in the map could be used as layer filter, and it worked very well. Is this a bug?

Sincerely,

Severin

[Tobia Di Pisa]

Dear Severin,

Only layers coming from the same source can be filtered using the cross layer filtering function. That's also how the GS extension works. It is reported in the UI helper.

Best Regards,

     Tobia Di Pisa

--
You received this message because you are subscribed to the Google Groups "mapstore-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mapstore-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/mapstore-users/8ae46e1c-5379-41cf-b4bb-252c0b9908den%40googlegroups.com.

--

==
GeoServer Professional Services from the experts!

Visit http://bit.ly/gs-services-us for more information.
==
Dott. Ing. Tobia Di Pisa
Technical Lead / Project Manager

GeoSolutions Group
phone: +39 0584 962313

mobile: +39 340 1781783
fax:      +39 0584 1660272

https://www.geosolutionsgroup.com/
http://twitter.com/geosolutions_it
-------------------------------------------------------

Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni circostanza inerente alla presente email (il suo contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato se potesse darmene notizia.

This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. We remind that - as provided by European Regulation 2016/679 “GDPR” - copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this email by mistake, please notify us immediately by telephone or e-mail.

[gaetan....@gmail.com]

Hi,

We were able to reproduce this issue and identify a solution.

I believe the previous answer is not accurate.

If the data comes from the same GeoServer, then the filter should be able to work.

The issue comes from the URL check in the code:

- https://github.com/geosolutions-it/MapStore2/blob/bf5431e2df1ae87045bdf783b783fcd333e2cbdd/web/client/components/data/query/CrossLayerFilter.jsx#L21

It strictly compares URLs and therefore rejects the use of two layers from the same workspace, even when the GeoServer itself is identical.

If the data is grouped within the same workspace, it works correctly.

I think this condition should not take the workspace into account and should instead compare the GeoServer URL itself.
Indeed, if both layers come from the same GeoServer instance, they necessarily share the same capabilities (in particular, the Query Filter plugin must be installed on that GeoServer).

From a functional point of view, there is therefore no reason to block cross-layer filtering in this case.

As it stands, this forces users to group data into a single workspace and does not encourage proper GeoServer organization.

Examples of the current behavior:

• Case 1 – KO: /geoserver/wms/FOO vs /geoserver/wms/BLA

• Case 2 – OK: /geoserver/wms/FOO vs /geoserver/wms/FOO

• Case 3 – maybe KO: /geoserver/ows/FOO vs /geoserver/wms/FOO

• etc.
  

Regards,
Gaetan Bruel

[gaetan....@gmail.com]

Sorry, my previous comments contain wrong cases.

Cases are better here : 

• Case 1 – KO: /geoserver/FOO/wms vs /geoserver/BLA/wms

• Case 2 – OK: /geoserver/FOO/wms vs /geoserver/FOO/wms

• Case 3 – maybe KO: /geoserver/FOO/ows vs /geoserver/FOO/wms

• etc.

Thanks Landry ;)

Regards,
Gaetan Bruel

[Lorenzo Natali]

Hi,

Yes at the moment they have to match exactly the same source as URL. This should guarantee anyway to use all the layers from all the workspaces if you use the global services (e.g. /geoserver/ows).

If I undertsood correctly. the problem you have happens only when you have layers from 2 or more different catalogs (E.g. using different services like /wms and /ows, or using workspaced services /FOO/wms and /BAR/wms).

Yes, thinking to it, even if it is technically possible from the functional point of view, we can not assume they are compatible by default.

There are several technical limitation that need to be investigated to workaround the standard rule and make them communicate. For instance:

- How to identify they belong to the same geoserver? we can not simply assume they have /geoserver in the path.

- if the workspaces are configured as isolated, communication may be denied anyway.

I think that, rather than try to guess these information (that are not directly exposed via API) it is simpler for the users to use the same global services if they want to use the layers together.

I think it is simpler and less error prone, and should be the best practice.

Sometimes doing these kind of workarounds may cause issues in terms of maintainance (complicated code) and interoperability.

Anyway I haven't investigated on this that much,  I may be wrong. so if you have a simple and clean solution that I didn't figure out, please share it.

Even if I missed something or I didn't fully get the problem, feel free to point it out.

Thank you in advance,

Lorenzo