Landry Breuil

i would agree with you since that's what i ended up doing to workaround this problem (see my first comment).. that's just a bit awkward when your tileindexes are in...

that also works ! ``` checking for paddr_t... yes $grep PADDR /usr/obj/ports/testdisk-7.2/testdisk-7.2/config.h #define HAVE_PADDR_T 1 ```

my first thought reading this was *oh $deity, ppl already have a hard time grasping the difference between roles and orgs and misuse them most of the time, why adding...

"notre usage des groupes GeoNetwork dans geOrchestra ne permet pas à un utilisateur de collaborer sur des métadonnées avec un autre issu d'un autre organisme." isnt it already possible to...

i *think* i have a similar issue on a service but with EPSG:900913, using 1.13.0 on debian, the full traceback is: ``` CRITICAL - mapproxy.wsgiapp - fatal error in service...

rebased branch on top of master

I've backported [3cebff0](https://github.com/geosolutions-it/MapStore2/pull/7865/commits/3cebff05d4d150e2fa1f95def866e501e8c04882) on top of my local 2022.01 branch, and tested it in my dev instance: - loaded layer `opendata_raw` (nested 4 levels of Layers in the capabilities tree)...

oh, and one last test done, loading a layer from geoserver using a workspace-specific url (eg https://fqdn/geoserver/ws/ows) -> it also finds the ISO19115:2003 metadataurls.

@tdipisa @allyoucanmap should be ready for merging ?

> Hi @landryb, > > to test this PR and to create functional tests on the metadata tool to be used over time, we need layers, like the ones mentioned...