On samedi 10 juin 2017 17:28:06 CEST Djordje Spasic wrote: > Hello everyone, > > When converting an .osm file to .shp files with ogr2ogr.exe, one needs to > define a list of required fields in gdal-data\osmconf.ini file. I defined > today a total of 338 field names, and the ogr2ogr.exe succeeded > successfully in converting the .osm file to a .shp file containing all > those 338 fields. 2 additional fields are added on top of 338 fields > (osm_id, osm_way_id). Here is a screenshot of the fields from the .shp file > opened in QGIS (QGIS lists fields from 0 as a starting index): > https://www.dropbox.com/s/qw4uqvartn16b0b/shapefile_fields_QGIS2.jpg?dl=0 > > When .dbf file which is created along the .shp file is being opened in DBF > Viewer, it also shows 340 fields: > https://www.dropbox.com/s/hjzthyjzumjbddz/dbf_fields_DBFViewer2000.jpg?dl=0 > > My question is: how is this possible if a .shp file (.dbf file that is) can > only store maximum of 255 fields? This is what Jukka Rahkonen pointed to > me, a couple of months ago. Does this mean that when performing conversion, > the ogr2ogr.exe is using some other shapefile format?
The DBF spec (or recommandations for shapefiles like https://www.loc.gov/preservation/digital/formats/fdd/fdd000326.shtml) indeed say 255 fields but there's nothing technically storing the field count in the DBF, so in practice the limit is determined by the most constraining of those 2 conditions : field_count <= int((65535 - 33) / 32) = 2046 and sum of all field_widths <= 65535 When OGR adds the 256th field it emits the following warning """Creating a 256th field, but some DBF readers might only support 255 fields """ Even -- Spatialys - Geospatial professional services http://www.spatialys.com
_______________________________________________ gdal-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/gdal-dev
