[GeoNode-users] Geofence rule behaviour depending on layer upload method

[EFTAS Oliver Buck]

Dear all,

it might be my limited understanding of the system, or a configuration issue, but I noticed the following behaviour in Geonode in combination with Geoserver and my trial to use WMS in QGIS.

Here is what we have.


1)      a geonode system running as docker installation

2)      one layer (GIS vector) imported via Geonode "Drag&Drop" Upload function

3)      one Layer (raster) imported via Geoserver (image pyramid) due to its size

If I look at the Geofence Data Rules in the Geoserver the layer 2) is listed as beloning to the default Geoserver workspace "geonode". The layer 3) is listed as belonging to a "remoteWorkspace". Access conditions etc. are similar, as set up in the Geonode GUI. Both layers show up in Geonode. 2) directly, 3) after importing via "Remote Service".

Now if I want to use the Geoserver als WMS provider in QGIS, I only get layer 2) as available layer, despite the access rule set to "Anyone" for both layers in Geonode GUI. Layer 3 is not visible/accessible. It only gets available once I manually change the Geofence data rule for this layer (set the workspace to "geonode" and allow WMS access for anyone. This rules is then afterwards not changeable via the Geonode GUI.


Is this correct, or am I getting anything wrong here. Why is my layer imported via Geoserver listed as "remoteWorkspace", which seems fine for Geonode, but not for QGIS/WMS?

Any hints are appreciated
Oliver


--
Intergeo<https://www.intergeo.de/intergeo-en/index.php> 2019: 17th - 19th September 2019, Stuttgart, Germany.
Meet us at booth F1.050 in hall 1!


[cid:image002.gif at 01CBBECE.B2C97A40]
Oliver Buck
MSc Environmental Science

E F T A S    Fernerkundung
Technologietransfer GmbH
Oststraße 2-18
48145 Münster
Fon: +49 251 13307-57     E-Mail: oliver.buck at eftas.com<mailto:oliver.buck at eftas.com>
Fax: +49 251 13307-33   Web:   http://www.eftas.com<http://www.eftas.com/>
Geschäftsführer:
Dipl.-Ing. Georg Altrogge

Sitz der Gesellschaft: Münster
Amtsgericht Münster, HRB 2999
USt.-IdNr. DE 126038986
******************************************************************
[cid:image006.png at 01CD642E.9C14BB50]

        [cid:image006.png at 01D564A7.B4C541C0]



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/geonode-users/attachments/20190906/3870c3f5/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 206 bytes
Desc: image001.png
URL: <http://lists.osgeo.org/pipermail/geonode-users/attachments/20190906/3870c3f5/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.gif
Type: image/gif
Size: 2259 bytes
Desc: image002.gif
URL: <http://lists.osgeo.org/pipermail/geonode-users/attachments/20190906/3870c3f5/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 267 bytes
Desc: image003.png
URL: <http://lists.osgeo.org/pipermail/geonode-users/attachments/20190906/3870c3f5/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.png
Type: image/png
Size: 228 bytes
Desc: image004.png
URL: <http://lists.osgeo.org/pipermail/geonode-users/attachments/20190906/3870c3f5/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image006.png
Type: image/png
Size: 522 bytes
Desc: image006.png
URL: <http://lists.osgeo.org/pipermail/geonode-users/attachments/20190906/3870c3f5/attachment-0003.png>