Both. It depends on the size of the polygon. No sense having a building footprint at zoom 5, as it make no sense to have every vertex of Lake Tahoe at zoom 5.

That makes sense, though I suppose the simplification logic might be somewhat application specific.

The short version is I can't think of a way to do what you're asking without breaking the format in a couple different ways. And those ways aren't much better than just having separate FGB's like you already are.

Could one or more additional rtree's be added to the FGB file that points to geom in the data that would simulate a low res chunk of that data?

I'm not sure what you mean by "simulate a low res chunk of that data". Currently the file only contains full resolution vector data.

It'd be possible (by breaking the format) to add a separate index that points to a subset of these features, but they will all be full resolution features.

It'd be possible (by breaking the format) to write low resolution features in a separate feature buffer and then have the aforementioned low resolution index point to those low resolution features, but at that point, I'm not sure you've gained much vs. what you are currently doing: having a high resolution FGB and a low resolution FGB.

I guess one thing that could be gained from storing the simplifications in the same file is that they could, in theory, reference the same non-geometry attributes ("properties"), so you wouldn't need to copy the non-geometry data for each resolution level, giving you some space savings over having separate FGBs.

Currently though, the geometry and non-geometry properties are stored adjacently, so that'd be (another) big breaking change from the current format.

I wonder if you've looked at pmtiles?

https://github.com/protomaps/PMTiles

Sounds like it might be closer to what you're looking for.

Hey Michael, I appreciate the responses! I realize what I was suggesting was a big deal, but I thought I'd throw it out there.

FGB made it possible to move away from any sort of tiling debacle, ie, PMTiles. Maintaining, updating tiles for zoom levels 1-18 with a national dataset is only for those with resources to deal with it, which is few of us. With PMTiles you can only get the vector data for a bbox of a tile, not the underlying geometry, without some server side implementation. Try clipping a raster in browser with vector data from a PMTIle, it's not pretty. With FGB it's a no-brainer. FGB also allows easy analysis of 2 or more vector data sets in browser. Again, with PMTiles it's a nightmare, if even possible without server side help.

With the availability of FGB, vector tiles make zero sense to me.

@mtravis the largest data sets I use are CONUS FEMA vector flood zones and vector building footprint. 39GB and 36GB. Give it a try. Click on a building foot print.

Using the techniques above, fema data is rasterized and used for zoom levels 1-12, zoom 13+ FGB vector data is displayed. The FGB building footprints are only shown at zoom 15+. So, 1 COG file and 2 FGB files.

The important feature is, I can click on a building footprint, get its area and the flood zone(s) it occupies. No server side processing, only the FGB files sitting on a web server. All done in the browser.

FEMA does regular, daily updates. Using ogr2ogr I upsert any new data to a .gpkg, gdal_rasterize for new raster, then ogr2ogr for new FGB. This massive FGB fema dataset gets updated nightly.

I couldn't imagine doing this with vector tiles. Tippacanoe, probably python, who knows what else, creating vector tiles for zoom 13-18 for all of CONUS, nightly. Even worse, I can't interact with underlying vector data (flood polygons) in browser without some server side assistance.

Spatial visualization in a cloud native manner, meaning no server/services processing, is the holy grail. FGB and COG make this possible. Visualization and light analysis in your browser is utterly simple. I'm shocked more people haven't run to this with open arms.

@bjornharrtell pg_tileserv is server side processing. It negates the whole concept of cloud native data formats. For visualization of cloud native data/formats it defeats the purpose.

Again, vector tiles are fine for small data sets and/or small range of zoom levels. Vector tiles are a nightmare for large areas and a wide range of zoom levels. If you need to do light analysis on the underlying vector data, it's impossible without server side.

Happy you are happy 🙂 I do have some similar use in production here and there and it can definitely work well, just don't want to claim it is a silver bullet.

@bjornharrtell I don't think you realize just how awesome your FGB format is and what it's capable of. I'm sure glad you put it together!

@mtravis the largest data sets I use are CONUS FEMA vector flood zones and vector building footprint. 39GB and 36GB. Give it a try. Click on a building foot print.

Using the techniques above, fema data is rasterized and used for zoom levels 1-12, zoom 13+ FGB vector data is displayed. The FGB building footprints are only shown at zoom 15+. So, 1 COG file and 2 FGB files.

The important feature is, I can click on a building footprint, get its area and the flood zone(s) it occupies. No server side processing, only the FGB files sitting on a web server. All done in the browser.

FEMA does regular, daily updates. Using ogr2ogr I upsert any new data to a .gpkg, gdal_rasterize for new raster, then ogr2ogr for new FGB. This massive FGB fema dataset gets updated nightly.

I couldn't imagine doing this with vector tiles. Tippacanoe, probably python, who knows what else, creating vector tiles for zoom 13-18 for all of CONUS, nightly. Even worse, I can't interact with underlying vector data (flood polygons) in browser without some server side assistance.

Spatial visualization in a cloud native manner, meaning no server/services processing, is the holy grail. FGB and COG make this possible. Visualization and light analysis in your browser is utterly simple. I'm shocked more people haven't run to this with open arms.

Nice. That's a cool use of FGBs!