[postgis-devel] [postgis-users] PSC Vote: Keep or drop Flatgeobuf in PostGIS 3.2.0

[Björn Harrtell]

This seems a bit misguided to me. FlatGeobuf is not intended to compete
with MVT and does not have space optimization and rendering as a main
priority. The design goal was lossless (de)serialization performance
assuming relatively good IO throughput but without requiring random access.
>From the FlatGeobuf FAQ I write:

"FlatGeobuf does not aim to compete with vector tiles. Vector tiles are
great for rendering but they are relatively expensive to create and is a
lossy format, where as FlatGeobuf is lossless and very fast to write
especially if a spatial index is not needed."

That said, FlatGeobuf *can* be used to deliver data to a web client either
using http range requests against a single indexed large file or as tiles
and it could make good sense if the use case doesn't allow for lossy
representation.

Personally I see FlatGeobuf as a good alternative as a common ground
lossless wire transfer format between systems and as a go to file format
for static data for use in fx. GeoServer or QGIS. But I suppose imagination
is the limit. :)

/Björn

Den fre 17 dec. 2021 kl 00:55 skrev Bruce Rindahl <bruce.rindahl at gmail.com>:

> Rechecked the results.  I inadvertently had some .png tiles created.
>
> For MVT the sizes are
> Level 14 165 kb
> Level 15 410 kb
> Level 16 1290 kb
>
> I will run a few more levels over the weekend
>
> On Thu, Dec 16, 2021 at 10:07 AM Paul Ramsey <pramsey at cleverelephant.ca>
> wrote:
>
>>
>>
>> > On Dec 16, 2021, at 10:04 AM, Bruce Rindahl <bruce.rindahl at gmail.com>
>> wrote:
>> >
>> > MVT takes up a LOT of disk space.  The advantage is thousands of small
>> files that Leaflet only asks for the tiles in the view and can cache the
>> tiles.
>>
>> Does it? I would think the quantization would generally make them smaller
>> (though the dictionary handling of attributions and redudant repetition
>> from tile-to-tile of attributes could easily wash that out for an
>> attributively rich data set.
>>
>> P
>>
>> > I haven't done a full seed of the smallest level as that would take
>> days and days.  They are generated on the fly as requested and served
>> directly after that.
>> >
>> > On Wed, Dec 15, 2021 at 7:01 PM Regina Obe <lr at pcorp.us> wrote:
>> > Just curious what are your MVT sizes comparable for you deepest tile
>> level.
>> >
>> > I was hoping it would be better than Shapefile but guess not always,
>> but good to see it is better than GeoJSON.
>> >
>> >
>> >
>> > Thanks,
>> >
>> > Regina
>> >
>> >
>> >
>> > From: postgis-devel [mailto:postgis-devel-bounces at lists.osgeo.org] On
>> Behalf Of Bruce Rindahl
>> > Sent: Wednesday, December 15, 2021 7:29 PM
>> > To: PostGIS Development Discussion <postgis-devel at lists.osgeo.org>
>> > Subject: Re: [postgis-devel] [postgis-users] PSC Vote: Keep or drop
>> Flatgeobuf in PostGIS 3.2.0
>> >
>> >
>> >
>> > Doing a quick test with the wildfires in CA the past 3 years.
>> >
>> >
>> >
>> > Shapefile = 9.42 MB
>> >
>> > GeoJSON = 26.5 MB
>> >
>> > FlatGeobuf  = 9.42 MB
>> >
>> >
>> >
>> > Right now I am serving the fires up via MVT on open layers and will try
>> to add a FlatGeobuf layer for testing.
>> >
>> >
>> >
>> > Generated the file via ogr2ogr and will test when postGIS 3.2 is out
>> but it does look like a compact format.  QGIS imports it with no issues.
>> As an exchange format it will have to be on the command line via ogr2ogr or
>> psql either via GDAL or native postGIS
>> >
>> >
>> >
>> >
>> >
>> > On Thu, Nov 25, 2021 at 9:08 AM Jeff McKenna <
>> jmckenna at gatewaygeomatics.com> wrote:
>> >
>> > As an aside, I appreciate this explanation on speed and benefits,
>> Björn,
>> > of FlatGeobuf.  Thanks,
>> >
>> > -jeff
>> >
>> >
>> >
>> >
>> > --
>> > Jeff McKenna
>> > GatewayGeo: Developers of MS4W, MapServer Consulting and Training
>> > co-founder of FOSS4G
>> > http://gatewaygeo.com/
>> >
>> >
>> > _______________________________________________
>> > postgis-devel mailing list
>> > postgis-devel at lists.osgeo.org
>> > https://lists.osgeo.org/mailman/listinfo/postgis-devel
>> > _______________________________________________
>> > postgis-devel mailing list
>> > postgis-devel at lists.osgeo.org
>> > https://lists.osgeo.org/mailman/listinfo/postgis-devel
>>
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel at lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/postgis-devel
>>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/postgis-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20211217/19e295d0/attachment.html>