Bug report #17817
WFS vs WMS (OGR?) data types
|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|
(talking about 2.18 here)
WFS and WMS of the same service seem to create different attribute
Going to this WFS:
there is a layer with 'panden' (houses), which have a column
'identification' which is (should be) a long integer (up to about 15
On a WMS GetFeatureInfo request (same url) you will see those id's as
nice long integers/strings:
BUT if you request the same house in a WFS layer, you will see floats:
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:
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.
#1 Updated by Even Rouault about 2 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