<div dir="ltr"><br><br>On Tue, May 21, 2019 at 10:16 PM Even Rouault <<a href="mailto:even.rouault@spatialys.com">even.rouault@spatialys.com</a>> wrote:<br>><br>> Makus,<br>><br>> > Extents and spatial filter settings with Geopackage are unprecise such that<br>> > they are unusable.<br>> ><br>> > For example I created a Geopackage with a single point: 176418.99585285,<br>> > 317579.62751027<br>> > ogrinfo reports extents of<br>> > Extent: (176419.000000, 317580.000000) - (176419.000000, 317580.000000)<br>> > I think this can happen if the coordinates are converted to float or<br>> > converted to a string with something like %.6g or %.g.<br>><br>> Ah indeed. Fixed per<br>> <a href="https://github.com/OSGeo/gdal/commit/0f28425fe8a2c70061b8896748f40182aff3f2ee">https://github.com/OSGeo/gdal/commit/0f28425fe8a2c70061b8896748f40182aff3f2ee</a><br><div><br></div><div>Thanks for the quick fix! BTW, there are many more instances of %g in other OGR drivers, not sure if some of them need adjustment as well.<br></div><div>></div>> > Thus the point in the Geopackage is outside the extents of the Geopackage.<br>> > If I adjust the extents of the Geopackage to<br>> > minx: 176418.823581<br>> > maxx: 176419.176419<br>> > miny: 317579.682420<br>> > maxy: 317580.317580<br>> > and use this as a spatial filter, the point is still excluded.<br>><br>> Yes, that's expected: your miny_filter > y_geometry. You probably meant<br><div>> miny=317579.582420</div><div><br></div><div>Oops, yes of course, that works, that means it was only the extents suffering from loss of precision.</div><div><br></div><div>Markus M<br></div><br></div>