[QGIS-Developer] Questions wrt. problems with empty layers
Richard Duivenvoorde
rdmailings at duif.net
Fri May 10 08:04:18 PDT 2019
Hi,
Just tried with a Geoserver (2.15) I have running here.
Moved a shp file with 1 feature in a postgis db, created a wfs service
for it and loaded in QGIS, styled it etc: fine.
Removed the (one) feature from the table, retarted Geoserver, and had a
look into the requests QGIS is firing [0].
QGIS first does a GetCapabilities request:
/geoserver/wfs?SERVICE=WFS&REQUEST=GetCapabilities&ACCEPTVERSIONS=2.0.0,1.1.0,1.0.0
Then a describefeature request (to determine the type):
geoserver/wfs?SERVICE=WFS&REQUEST=DescribeFeatureType&VERSION=2.0.0&TYPENAME=test:wfspointPostgis
That one responses with
<xsd:element maxOccurs="1" minOccurs="0" name="geom" nillable="true"
type="gml:PointPropertyType"/>
So Geoserver (still?) knows about the geometry type of the table.
Not sure if that is cached? But it is available in the
'geometry_columns'-view of Postgis (stating type=POINT).
And QGIS keeps the styling, even after several restarts/reloads.
One thing I can think of: is that the postgis table does not have a type
defined, with someting like:
geom geometry
instead of
geom geometry(Point,28992),
what I see when the table created via QGIS...
Could it be that
- geoserver cannot determine the type?
To test I created a minimal table:
CREATE TABLE public.testgeoms
(
id integer,
geom geometry,
fid integer NOT NULL DEFAULT nextval('testgeoms_fid_seq'::regclass),
CONSTRAINT foo PRIMARY KEY (fid)
)
At that moment the geometry_columns view shows type=GEOMETRY
So (I think) without data, geoserver can never determine the type, hence
shows:
<xsd:element maxOccurs="1" minOccurs="0" name="geom" nillable="true"
type="gml:GeometryPropertyType"/>
in the DescribeFeatureType response...
And indeed if I then empty the table, and reopen the project the
WFS-point layer shows an 'img', as it cannot style the zero features.
AND it does not have type info?
So (confirmed) having that layer with zero (of unknown type) features,
QGIS forgets the style...
Is that a bug?
IF you create the layers with a feature TYPE (geom
geometry(Point,28992)) then the type will show up in the
'geometry_columns'-view and then in the describefeature response.
Without that knowledge QGIS retrieves NO type information (via the
describefeature) upon loading of the project/layer and (apparently)
forgets the type in the layer???
Does it work with you if you put the type in the table definitions in
Postgis (so they show up in the 'geometry_columns'-view)?
With me it does, but I just did a quick test.
Else I would create an issue for it or let somebody dive into this...
Regards,
Richard Duivenvoorde
[0] https://github.com/rduivenvoorde/qgisnetworklogger/tree/model_rewrite
On 09/05/2019 22.22, Bo Victor Thomsen wrote:
> Hi Lars and other members of this list..
>
> I feel somewhat obligated to help Lars since it's a problem he has
> inherited from me. (Sorry about that...)
>
> To sum it up:
>
> If QGIS connects to a WFS based layer from Geoserver using an existing
> project with styled layers and one or more layers containing /zero/
> objects, QGIS can't determine the object type (point, line-string,
> polygon...) for those layers. QGIS will not show legends and promptly
> forget any layer information stored in the project related to the
> object-type, ex. styling information.
>
> And what is worse - this is a permanent situation: If you save the
> project in the above-mentioned state and reopen it at a later time -
> where the layers /now/ contains objects - QGIS has forgotten the styling
> and other information, so the layers stays invisible and without the
> former styling.
>
> (long posting...)
>
> I've done some tests to determine the root cause of this problem:
>
> * Setup of a Postgres database /and /a SQL Server database.
>
> * Loaded the same MapInfo-dataset twice into each database, called
> them tableA and tableB, and populated the meta-table
> "dbo.geometry_columns" with the correct information for tableA and
> tableB in SQLServer.
>
> * Installed a fresh Geoserver 2.15 and MapServer TinyOWS WFS-T server
>
> * Setup a Workspace in Geoserver with 4 layers: tableA and -B from
> SQLServer and the same tables from Postgres using WFS.
>
> * In Geoserver, the datastore definition for the SQLServer tables has
> a pointer to the "dbo.geometry_columns" meta-table.
>
> * Setup of TinyOWS with tableA and -B from Postgres
>
> * And lastly: Made a project in QGIS 3.4.7 /Windows 64bit with the 6
> WFS layers:
>
> o tableA is shown 3 times:
>
> 1. From SQLServer through GeoServer;
> 2. From Postgres through GeoServer
> 3. From Postgres through Tiny-WFS
>
> o tableB is shown 3 times using the same setup as tableA
>
> All 6 layers in QGIS was shown correctly and the object type for all
> layers was recognized.
>
> After this I /deleted/ all rows from tableB in /both/ MS-SQLServer and
> in Postgres and reopened the same QGIS project:
>
> * The layer showing (the zero objects) tableB from SQLServer through
> GeoServer was not in order.
> * The 5 other layers was shown correctly. Legends was correct and
> styling was not deleted
>
> I'm drawing the following conclusion:
>
> * GeoServer WFS connections (maybe in conjunction with QGIS) doesn't
> work properly when the dataprovider is MS-SQLServer and the layers
> contains zero objects. More precisely: GeoServer's SQLServer
> dataprovider can't or don't use geometry_columns meta-table defined
> in the datastore as described in:
> https://docs.geoserver.org/stable/en/user/data/database/sqlserver.html#using-the-geometry-metadata-table
> .
>
> After this test I've tried to change the placement and existence of the
> "geometry_columns" metadata table:
>
> * No value
> * dbo.geometry_column (ordinary placement)
> * data.geometry_column (I made a copy of the geometry_columns table
> and placed it in the same schema as the test tables)
> * geometry_columns (without schema definition)
>
> Nothing of the above worked.
>
> @Lars:
> You might change your database system to Postgres and perhaps replace
> GeoServer with TinyOWS for WFS purposes (ducks and and run....) .
> Or getting the issue investigated and fixed using some GeoServer core
> developer, perhaps in cooperation with a QGIS core developer?
> Apparently the problem is fixable, since neither TinyOWS or
> GeoServer/Postgres have the same issues.
>
> Obviously, the above is a far cry from a really rigorous investigation
> of the problem, but it points at some of the "pain" points
>
> Regards
>
> Bo Victor Thomsen
>
> AestasGIS
> Denmark
>
> Den 09-05-2019 kl. 13:36 skrev Lars I. Nielsen, LIFA A/S:
>>
>> Hi developers.
>>
>>
>>
>> I asked this question on the user’s list, so far without any answers,
>> but have been advised to ask here as well.
>>
>>
>>
>>
>>
>> I’m working with a number of projects, which statically open a fixed
>> number of layers. All layers are fetched using WFS / WFS-T.
>>
>>
>>
>> Each layer has an extensive rule based styling, and an extensive
>> field/attribute dialog setup. This is saved in the project files.
>>
>>
>>
>> Our plugin changes the data provider filter for many layers, when the
>> user works with the data. These filter expressions are also saved in
>> the project, of course.
>>
>>
>>
>> Our problem is, that if the user accidently chooses a work area (= new
>> data provider filter), which contain no data in any layer, those
>> layers lose all styling etc. And it’s apparently impossible to recover
>> these styles etc. by changing the filter back.
>>
>>
>>
>> So basically the user’s project is unrecoverably trashed at this point
>> in time.
>>
>>
>>
>> A - Is this a correct description of how QGIS handles “no-data” layers ?
>>
>>
>>
>> B - Are there any standard ways to handle this in QGIS (using metadata
>> or otherwise) in an automated fashion (i.e. not manually) ?
>>
>>
>>
>> C - If the answers to A and B are yes and no resp., are there any
>> plans to remedy this unnecessarily serious problem ?
>>
>>
>>
>>
>>
>> Might it not be solved simply by adding an (optional?) layer metadata
>> key, that stores the last used topology, and revert to this if no data
>> are found on the layer ?
>>
>>
>>
>>
>>
>> Using 3.4.5 x64 (Danish)
>>
>>
>>
>>
>>
>> Med venlig hilsen
>>
>> Lars I. Nielsen, LIFA A/S
>> GIS-konsulent, FME Certified Professional
>>
>> Beskrivelse: http://website.lifa.dk/lsp.gif
>>
>> *T*
>>
>>
>>
>> 6313 6800
>>
>>
>>
>> *@*
>>
>>
>>
>> lin at lifa.dk
>>
>> *D*
>>
>>
>>
>> 6313 6849
>>
>>
>>
>> *W*
>>
>>
>>
>> www.lifa.dk <http://www.lifa.dk>
>>
>> *M*
>>
>>
>>
>> 2492 4866
>>
>>
>>
>> *CVR*
>>
>>
>>
>> 20937289
>>
>>
>> Beskrivelse:
>> C:\Users\lin\AppData\Roaming\Microsoft\signatures\21x21-Images-Get-L749-l8.png
>> <https://www.linkedin.com/company/lifa-a-s/>
>> Følg os på LinkedIn og læs de seneste nyheder fra LIFA A/S
>>
>>
>>
>> _______________________________________________
>> QGIS-Developer mailing list
>> QGIS-Developer at lists.osgeo.org
>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>
> _______________________________________________
> QGIS-Developer mailing list
> QGIS-Developer at lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
More information about the QGIS-Developer
mailing list