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

[Bruce Rindahl]

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>
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
> >:
>
>> 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
>>
> _______________________________________________
> 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/7a9b734e/attachment-0001.html>