[gdal-dev] What is the maximum number of fields a shapefile can contain?

[Even Rouault]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20170610/e9035d5a/attachment.html>