Le mercredi 20 mai 2015 14:41:23, Stefan Keller a écrit : > Salut Even > > Thanks and sorry me again. > We tried to compile GDAL 2.0.0beta1 version and still have problems. > Perhaps our config params are wrong?
No they are fine > $ ogr2ogr -f 'GPKG' out.gpkg WFS:http://maps.zh.ch/wfs/TbaBaustellenZHWF > S > ERROR 1: failed to execute insert : NOT NULL constraint failed: > baustellen-detailansicht.weiteregemeinden > ERROR 1: Unable to write feature 518 from layer baustellen-detailansicht . > ERROR 1: Terminating translation prematurely after failed translation > of layer baustellen-detailansicht (use -skipfailures to skip errors) Thanks. This is an interesting feedback. The issue is that OGR interprets the following <ms:weiteregemeinden></ms:weiteregemeinden> as being NULL, instead of empty string. And the schema of the layer as defined by http://maps.zh.ch/wfs/TbaBaustellenZHWFS?SERVICE=WFS&VERSION=1.1.0&REQUEST=DescribeFeatureType&TYPENAME=baustellen- detailansicht makes the attribute mandatory, hence NOT NULL. Presumably the cleaner way of addressing this would be to make the GML driver report an empty string, instead of NULL, but I still think that the intent is generally NULL and this was the historic behaviour, so I'm hesitant to change this by default. So in light of this, I've reconsidered that not-nullable fields in GML/WFS drivers to be reported by default to avoid such issues. Users that want to be pedantic can use the just newly added open option EMPTY_AS_NULL=NO so as to have empty fields as empty strings and NOT NULL fields being reported. So all in all, things should run smoothly now in both the default mode (EMPTY_AS_NULL=YES) and in the pedantic mode (EMPTY_AS_NULL=NO) Tracked in ticket http://trac.osgeo.org/gdal/ticket/5968. In the meantime, you can workaround the issue by adding -forceNullable to the ogr2ogr command line which will drop those NOT NULL constraints. Side remark: http://maps.zh.ch/wfs/TbaBaustellenZHWFS?SERVICE=WFS&VERSION=1.1.0&REQUEST=GetFeature&TYPENAME=baustellen- detailansicht doesn't pass XML validation against the schema because of things like <ms:lmutdat>2015-03-16 00:00:00</ms:lmutdat> which are not valid xs:date. This should be <ms:lmutdat>2015-03-16T00:00:00</ms:lmutdat> and the field should be declared as <element name="lmutdat" type="dateTime"/>, but that might be a MapServer issue Even -- Spatialys - Geospatial professional services http://www.spatialys.com _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
