<div dir="auto">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.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Dec 17, 2021, 2:29 AM Björn Harrtell <<a href="mailto:bjorn.harrtell@gmail.com">bjorn.harrtell@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>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:</div><div><br></div><div>"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."<br></div><div><br></div><div>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.</div><div><br></div><div>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. :)</div><div><br></div><div>/Björn</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Den fre 17 dec. 2021 kl 00:55 skrev Bruce Rindahl <<a href="mailto:bruce.rindahl@gmail.com" target="_blank" rel="noreferrer">bruce.rindahl@gmail.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Rechecked the results. I inadvertently had some .png tiles created.<div><br><div>For MVT the sizes are</div><div>Level 14 165 kb</div><div>Level 15 410 kb</div><div>Level 16 1290 kb </div><div><br></div><div>I will run a few more levels over the weekend</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Dec 16, 2021 at 10:07 AM Paul Ramsey <<a href="mailto:pramsey@cleverelephant.ca" target="_blank" rel="noreferrer">pramsey@cleverelephant.ca</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
> On Dec 16, 2021, at 10:04 AM, Bruce Rindahl <<a href="mailto:bruce.rindahl@gmail.com" target="_blank" rel="noreferrer">bruce.rindahl@gmail.com</a>> wrote:<br>
> <br>
> 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.<br>
<br>
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.<br>
<br>
P<br>
<br>
> 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.<br>
> <br>
> On Wed, Dec 15, 2021 at 7:01 PM Regina Obe <<a href="mailto:lr@pcorp.us" target="_blank" rel="noreferrer">lr@pcorp.us</a>> wrote:<br>
> Just curious what are your MVT sizes comparable for you deepest tile level.<br>
> <br>
> I was hoping it would be better than Shapefile but guess not always, but good to see it is better than GeoJSON.<br>
> <br>
> <br>
> <br>
> Thanks,<br>
> <br>
> Regina<br>
> <br>
> <br>
> <br>
> From: postgis-devel [mailto:<a href="mailto:postgis-devel-bounces@lists.osgeo.org" target="_blank" rel="noreferrer">postgis-devel-bounces@lists.osgeo.org</a>] On Behalf Of Bruce Rindahl<br>
> Sent: Wednesday, December 15, 2021 7:29 PM<br>
> To: PostGIS Development Discussion <<a href="mailto:postgis-devel@lists.osgeo.org" target="_blank" rel="noreferrer">postgis-devel@lists.osgeo.org</a>><br>
> Subject: Re: [postgis-devel] [postgis-users] PSC Vote: Keep or drop Flatgeobuf in PostGIS 3.2.0<br>
> <br>
> <br>
> <br>
> Doing a quick test with the wildfires in CA the past 3 years.<br>
> <br>
> <br>
> <br>
> Shapefile = 9.42 MB<br>
> <br>
> GeoJSON = 26.5 MB<br>
> <br>
> FlatGeobuf = 9.42 MB<br>
> <br>
> <br>
> <br>
> Right now I am serving the fires up via MVT on open layers and will try to add a FlatGeobuf layer for testing.<br>
> <br>
> <br>
> <br>
> 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<br>
> <br>
> <br>
> <br>
> <br>
> <br>
> On Thu, Nov 25, 2021 at 9:08 AM Jeff McKenna <<a href="mailto:jmckenna@gatewaygeomatics.com" target="_blank" rel="noreferrer">jmckenna@gatewaygeomatics.com</a>> wrote:<br>
> <br>
> As an aside, I appreciate this explanation on speed and benefits, Björn, <br>
> of FlatGeobuf. Thanks,<br>
> <br>
> -jeff<br>
> <br>
> <br>
> <br>
> <br>
> -- <br>
> Jeff McKenna<br>
> GatewayGeo: Developers of MS4W, MapServer Consulting and Training<br>
> co-founder of FOSS4G<br>
> <a href="http://gatewaygeo.com/" rel="noreferrer noreferrer" target="_blank">http://gatewaygeo.com/</a><br>
> <br>
> <br>
> _______________________________________________<br>
> postgis-devel mailing list<br>
> <a href="mailto:postgis-devel@lists.osgeo.org" target="_blank" rel="noreferrer">postgis-devel@lists.osgeo.org</a><br>
> <a href="https://lists.osgeo.org/mailman/listinfo/postgis-devel" rel="noreferrer noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/postgis-devel</a><br>
> _______________________________________________<br>
> postgis-devel mailing list<br>
> <a href="mailto:postgis-devel@lists.osgeo.org" target="_blank" rel="noreferrer">postgis-devel@lists.osgeo.org</a><br>
> <a href="https://lists.osgeo.org/mailman/listinfo/postgis-devel" rel="noreferrer noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/postgis-devel</a><br>
<br>
_______________________________________________<br>
postgis-devel mailing list<br>
<a href="mailto:postgis-devel@lists.osgeo.org" target="_blank" rel="noreferrer">postgis-devel@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/postgis-devel" rel="noreferrer noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/postgis-devel</a><br>
</blockquote></div>
_______________________________________________<br>
postgis-devel mailing list<br>
<a href="mailto:postgis-devel@lists.osgeo.org" target="_blank" rel="noreferrer">postgis-devel@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/postgis-devel" rel="noreferrer noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/postgis-devel</a><br>
</blockquote></div></div>
_______________________________________________<br>
postgis-devel mailing list<br>
<a href="mailto:postgis-devel@lists.osgeo.org" target="_blank" rel="noreferrer">postgis-devel@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/postgis-devel" rel="noreferrer noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/postgis-devel</a><br>
</blockquote></div>