[gdal-dev] shapefile field indexing on OGR 1.x vs 2.1

Andrea Battisti battisti at actgate.com
Tue Jan 31 03:13:14 PST 2017



>
>> What is the proper way to use new GDAL on the old shapefile without
>
>> modifying it?
>
>> Is there a way to explicitly tell GDAL to use that field as Integer and
>
>> to make the field indexing work?
>
>
>
> I'm not sure if MapInfo indexes support 64 bit integers (probably not),
> but the code does not support them indeed.
>
>
>
> You can try to open the shapefile with the ADJUST_TYPE=YES open option
> so that it can check if a potential colum with 64 bit integers really
> contains 64 bit integers or not. If not, it will be downgraded to
> integer and the attribute index will be available.
>
>
>
> Another option would be to resize the column to 8 characters or less if
> the data fits in it (with the RESIZE=YES creation option)
>
>
>
> Another option is to not use shapefiles and use more powerful
> alternatives like GeoPackage or Spatialite.
>
>


Even,

I tried ogr2ogr -lco RESIZE=YES and indeed the Integer64 field becomes 
Integer, but that changes the original shapefile, I was hoping to use 
the existing shapefile without touching it.

Related to the attribute index: when using SQL WHERE clauses like
WHERE myfield IN (1, 2, 3) on the integer field, it reports on the last 
one only, like if the query was
WHERE myfield = 3
(while there are rows with myfield = 1 and 2 as well...)

This is happening only if using the mapinfo attribute index on 2.1 (was 
working on 1.x). If I manually remove the index files the query executes 
correctly.

I see from here
http://www.gdal.org/drv_shapefile.html
that the index only accelerates "fieldname = value" queries so maybe the 
WHERE IN () is not accelerated but should still work I guess?

Thanks!
Andrea


More information about the gdal-dev mailing list