QGIS » QGIS Application

Oups, fixed link http://www.licadho-cambodia.org/qgis/big_reg.zip

I can confirm on Mac 10.7.5 with latest master, in QBrowser.

However, running ogrinfo -so 'gap_landcover.shp' 'gap_landcover' returns:

INFO: Open of `gap_landcover.shp'
      using driver `ESRI Shapefile' successful.

Layer name: gap_landcover
Geometry: 3D Polygon
Feature Count: 86668
Extent: (211823.109375, 1144262.940806) - (785034.000000, 1625281.000000)
Layer SRS WKT:
(unknown)
PA_NAME_EN: String (50.0)
PA_TYPE: String (5.0)
PROTECTION: String (40.0)
THREAT_STA: String (30.0)
PROTECTION: String (40.0)
ELEVATION_: String (10.0)
VEG_RECLAS: String (50.0)
VEG_GAP_FI: String (70.0)
AREA: Real (16.3)
PERIMETER: Real (16.3)
HECTARES: Real (16.3)
VEG_SIMPLE: String (60.0)

PROTECTION1 doesn't show up. OGR sees the second field as having the same name, i.e. it seems to only read the first 10 characters of the field name. Looks like it is a set function of the shapefile driver - see Creation Issues. I can only assume the same holds true for reading.

Larry, the strange thing is, with osgeo4w's QGIS 1.8, which is built against GDAL 1.9.2 just like QGIS master, it works fine.

I confirm this issue in the latest nightly build.

If you look at the header of gap_landcover.dbf you'll see that there are 2 fields called PROTECTION. There can not be a PROTECTION1 field, since it would be 11 character wide, and DBF field names are limited to 10 characters. There's no way OGR can read PROTECTION1, since it is not in the DBF file... I'd say that the DBF is prone to cause great confusion to shapefile readers.

I cannot confirm nirvn comment : I have opened it with QGIS 1.8.0 against GDAL 1.9.2 on Linux, and it reports 2 PROTECTION fields, not PROTECTION1. And the attributes for each of the PROTECTION field show up correctly in the attribute table. But this can cause various issues when a field is retrieved by its name, and not its index...

Note: After the change I've just done in http://trac.osgeo.org/gdal/changeset/25903, the ogr2ogr of GDAL 1.10 will be able to convert the above bogus shapefile in a shapefile with unique field names.

Before :
$ ogrinfo gap_landcover.shp -al -so
INFO: Open of `gap_landcover.shp'
using driver `ESRI Shapefile' successful.

Layer name: gap_landcover
Geometry: Polygon
Feature Count: 86668
Extent: (211823.109375, 1144262.940806) - (785034.000000, 1625281.000000)
Layer SRS WKT:
(unknown)
PA_NAME_EN: String (50.0)
PA_TYPE: String (5.0)
PROTECTION: String (40.0)
THREAT_STA: String (30.0)
PROTECTION: String (40.0)
ELEVATION_: String (10.0)
VEG_RECLAS: String (50.0)
VEG_GAP_FI: String (70.0)
AREA: Real (16.3)
PERIMETER: Real (16.3)
HECTARES: Real (16.3)
VEG_SIMPLE: String (60.0)

Conversion:
$ ogr2ogr gap_landcover_unique.shp gap_landcover.shp
Warning 6: Normalized/laundered field name: 'PROTECTION2' to 'PROTECTI_1'
Warning 1: Field 'PROTECTION' already exists. Renaming it as 'PROTECTI_1'

After:
$ ogrinfo gap_landcover_unique.shp -al -so
INFO: Open of `gap_landcover_unique.shp'
using driver `ESRI Shapefile' successful.

Layer name: gap_landcover_unique
Geometry: Polygon
Feature Count: 86668
Extent: (211823.109375, 1144262.940806) - (785034.000000, 1625281.000000)
Layer SRS WKT:
(unknown)
PA_NAME_EN: String (50.0)
PA_TYPE: String (5.0)
PROTECTION: String (40.0)
THREAT_STA: String (30.0)
PROTECTI_1: String (40.0)
ELEVATION_: String (10.0)
VEG_RECLAS: String (50.0)
VEG_GAP_FI: String (70.0)
AREA: Real (16.3)
PERIMETER: Real (16.3)
HECTARES: Real (16.3)
VEG_SIMPLE: String (60.0)