Hi, I have not seen flatgeobuf in the wild, and I believe it can be safely removed.
The current implementation is impaired by Postgres' life choices of 1GB limit and thus not usable for any data, just size-limited subset. ogr2ogr seems like a better suited place for it to reside. I'm -0 on adding flatgeobuf to core, and -1 on releasing with known crashers. This would converge to "remove if nobody can fix crashers". On Wed, Nov 24, 2021 at 11:10 PM Regina Obe <l...@pcorp.us> wrote: > This is a PSC vote, but we would like some feedback on this from packagers > and users as such comments will sway our vote. > > We have two blockers that center around the new FlatGeoBuf format. > > https://trac.osgeo.org/postgis/ticket/5005 (this one is easily > replicatable) > > https://trac.osgeo.org/postgis/ticket/5014 (this one I can only replicate > with the cowbuilder setup Bas Cowenberg provided) > > both I think are manifestations of the same problem how the header is > derived and what it's doing with numeric and geometry fields. > > I've taken a stab at troubleshooting and fixing, but did not have much > luck. > That said, if anyone is willing to help fix that would be great and fix > within a 1 to 2 week time period. > > If not I feel that we really need to take it out of our PostGIS 3.2.0 > release (which will be going on to 3.2.0beta2). > > I'd like to release PostGIS 3.2.0beta2 in about a week or so with > flatgeobuf > fixed or removed. If removed, we'll push flatgeobuf to PostGIS 3.3.0 > cycle. > > Thanks, > Regina > > > _______________________________________________ > postgis-devel mailing list > postgis-de...@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/postgis-devel >
_______________________________________________ postgis-users mailing list postgis-users@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/postgis-users
