[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