Bug report #17817

WFS vs WMS (OGR?) data types

Added by Richard Duivenvoorde almost 7 years ago. Updated over 5 years ago.

Status:Closed
Priority:Low
Assignee:-
Category:Data Provider/OGR
Affected QGIS version:2.18.15 Regression?:No
Operating System: Easy fix?:No
Pull Request or Patch supplied:No Resolution:wontfix
Crashes QGIS or corrupts data:No Copied to github as #:25713

Description

(talking about 2.18 here)

WFS and WMS of the same service seem to create different attribute
data-types?

Going to this WFS:

https://geodata.nationaalgeoregister.nl/bag/ows?

there is a layer with 'panden' (houses), which have a column
'identification' which is (should be) a long integer (up to about 15
positions long).

On a WMS GetFeatureInfo request (same url) you will see those id's as
nice long integers/strings:
1598100000022426

BUT if you request the same house in a WFS layer, you will see floats:
1.59810000002243e+15
for example in the attribute table, or if you use the info-tool.

This is a problem if you need that id to create joints/relations.

I had a look into the sqlite file which is created in:
~/.qgis2/cache/wfsprovider/pid_16544
and indeed see this create table sql:

CREATE TABLE 'features' ( "__ogc_fid" INTEGER PRIMARY KEY AUTOINCREMENT,
'identificatie' FLOAT, 'bouwjaar' FLOAT, 'status' VARCHAR,
'gebruiksdoel' VARCHAR, 'oppervlakte_min' FLOAT, 'oppervlakte_max'
FLOAT, 'aantal_verblijfsobjecten' BIGINT, 'actualiteitsdatum' BIGINT,
'__qgis_gen_counter' INTEGER, '__qgis_gmlid' VARCHAR,
'__qgis_hexwkb_geom' VARCHAR, "__spatialite_geometry" POLYGON)

Is this a fixable (hopefully 2.18 only) problem?
As 2.18 will be LTR for some time.

wfsdatatypes.qgs - test project (12.8 KB) Richard Duivenvoorde, 2018-01-08 12:20 PM

History

#1 Updated by Even Rouault over 6 years ago

  • Priority changed from Normal to Low

ok, so this is a QGIS 2.x only issue, as things seem to work well in QGIS 3
The root cause is that the 'identification' column is reported as xs:decimal by DescribeFeatureType, and xs:decimal can potentially a floating point value, hence QGIS correctly decides to expose it as a double. If the server reported it as a xs:long or xs:string, that should work better

#2 Updated by Jürgen Fischer almost 6 years ago

  • Status changed from Open to Feedback

Please test with QGIS 3.4 - QGIS 2.18 reached it's end of life.

#3 Updated by Richard Duivenvoorde almost 6 years ago

  • Resolution set to wontfix

Closing, as indeed it is working in 3.x

#4 Updated by Giovanni Manghi over 5 years ago

  • Status changed from Feedback to Closed

Also available in: Atom PDF