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

Fri Dec 17 18:14:37 PST 2021

FWIW  I was thinking of using it as a better geojson mapping format.

Geojson is a little too fat and MVT the redundancy of the attribute data and more costliness of producing it makes it not as nice when you need real time viewing of constantly changing geometries and attribute data.

So you end up having to use both.  Flatgeobuf sounds like it might be a good balance between the two.

From: postgis-devel [mailto:postgis-devel-bounces at lists.osgeo.org] On Behalf Of Bruce Rindahl
Sent: Friday, December 17, 2021 1:05 PM
To: bjorn at wololo.org; 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

You're right.  My comments were not meant to be critical but focused on how I might use it.  I can see using ogr_fdw or ogr2ogr as a good,fast,compact data exchange.  My use case is not everyone else's.

On Fri, Dec 17, 2021, 2:29 AM Björn Harrtell <bjorn.harrtell at gmail.com <mailto:bjorn.harrtell at gmail.com> > wrote:

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 <mailto: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 <mailto:pramsey at cleverelephant.ca> > wrote:

> On Dec 16, 2021, at 10:04 AM, Bruce Rindahl <bruce.rindahl at gmail.com <mailto: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 <mailto: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 <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 <mailto: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 <mailto: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 <mailto:postgis-devel at lists.osgeo.org> 
> https://lists.osgeo.org/mailman/listinfo/postgis-devel
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org <mailto:postgis-devel at lists.osgeo.org> 
> https://lists.osgeo.org/mailman/listinfo/postgis-devel

_______________________________________________
postgis-devel mailing list
postgis-devel at lists.osgeo.org <mailto:postgis-devel at lists.osgeo.org> 
https://lists.osgeo.org/mailman/listinfo/postgis-devel

_______________________________________________
postgis-devel mailing list
postgis-devel at lists.osgeo.org <mailto:postgis-devel at lists.osgeo.org> 
https://lists.osgeo.org/mailman/listinfo/postgis-devel

_______________________________________________
postgis-devel mailing list
postgis-devel at lists.osgeo.org <mailto: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/e8486d6d/attachment.html>