[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