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 usin
> 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.
If there are no holes in feature numbering, you could normally reuse the
existing .shp and
.sh
Even Rouault-2 wrote
> Another option is to not use shapefiles and use more powerful alternatives
> like GeoPackage
> or Spatialite.
>
> Even
I wonder how usable and reliable this peculiar attribute index is. Would it
be a big loss to stop supporting it?
-Jukka Rahkonen-
--
View this messag
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
On lundi 30 janvier 2017 16:56:29 CET Andrea Battisti wrote:
> Hi all,
>
> I have a shapefile created by GDAL/OGR 1.7 which is using a .ind/.idm
> attribute index on an integer field.
>
> If I SQL-query that integer field on OGR 2.1 I get the following:
> ERROR 7: BuildKey(): 8 bytes integer key
Hi all,
I have a shapefile created by GDAL/OGR 1.7 which is using a .ind/.idm
attribute index on an integer field.
If I SQL-query that integer field on OGR 2.1 I get the following:
ERROR 7: BuildKey(): 8 bytes integer key length not supported
I think that is because the new GDAL interprets th
