[gdal-dev] Geopackage precision issues

Even Rouault even.rouault at spatialys.com
Tue May 21 13:16:22 PDT 2019


Makus,

> Extents and spatial filter settings with Geopackage are unprecise such that
> they are unusable.
> 
> For example I created a Geopackage with a single point: 176418.99585285,
> 317579.62751027
> ogrinfo reports extents of
> Extent: (176419.000000, 317580.000000) - (176419.000000, 317580.000000)
> I think this can happen if the coordinates are converted to float or
> converted to a string with something like %.6g or %.g.

Ah indeed. Fixed per 
https://github.com/OSGeo/gdal/commit/0f28425fe8a2c70061b8896748f40182aff3f2ee

> Thus the point in the Geopackage is outside the extents of the Geopackage.
> If I adjust the extents of the Geopackage to
> minx: 176418.823581
> maxx: 176419.176419
> miny: 317579.682420
> maxy: 317580.317580
> and use this as a spatial filter, the point is still excluded.

Yes, that's expected: your miny_filter > y_geometry. You probably meant 
miny=317579.582420

> Not the reason for this, but another precision issue is at
> https://github.com/OSGeo/gdal/blob/master/gdal/ogr/ogrsf_frmts/gpkg/ogrgeopa
> ckagetablelayer.cpp#L3544
> 
>                 SQLEscapeName(pszC).c_str(), sEnvelope.MinX - 1e-11,

I'm not sure if those bbox extension are needed at all. They don't seem 
necessary if trying

printf 'id,WKT\n1,"POINT(176418.99585285 317579.62751027)"\n' > point.csv
ogr2ogr point.gpkg point.csv
ogrinfo point.gpkg -al \
    -spat 176418.99585285 317579.62751027 176418.99585285 317579.62751027

Even


-- 
Spatialys - Geospatial professional services
http://www.spatialys.com


More information about the gdal-dev mailing list