Eventually creating a PMTiles for parcels will make more sense than storing all that data in a relational database.
The Postgres database is great for iteration but not for long term usage if the data at some point will become static.
Creating a parcels.pmtiles file (similar to how the georgia.pmtiles file works) will simplify the process of serving that data to users as well as cutting down the total size by 30-50%. No database overhead and no 10GB database index for those 47 million rows of tiles.
What starts as a 29GB database table might shrink to 8-10GB, which is much easier to serve to a CDN if I want that.
PMTiles is also pretty smart about how it stores and presents data. Optimizing lines that overlap etc..
The process to create the file is pretty straightforward when using tippecanoe:
# Direct stream from Postgres to Tippecanoe
psql -d my_database -c "COPY (SELECT ST_AsGeoJSON(geometry), * FROM parcels) TO STDOUT" \
| tippecanoe -o parcels.pmtiles --base-zoom=13 --maximum-zoom=19 --drop-densest-as-needed
You can specify what metadata to keep a certain zoom levels and what size to keep tiles too and cull anything that goes past that threshold.
It also intelligently handles turning complex polygons into simplier shapes at zoom levels where you wont see that detail anyways. So this can make the data serving and rendering performance improve as well.
Expanding to showing parcels at lower zoom levels like 11 and 12 becomes much easier with PMTiles as the file size becomes more optimized.
It can also handle showing dots for parcels at lower zoom levels and automatically transition to full geometry at higher zooms: --include-only-points-at-lower-zooms
Final Thoughts
- Switch from serving tiles from the database to a parcels.pmtiles that is statically served like the georgia.pmtiles file.
- Test rendering performance and lag times
- If performance is still an issue, only include address, and acreage in the tiles and have all other data be a "fetch on click" process with a spinner in the popup to let users know whats happening.
Eventually creating a PMTiles for parcels will make more sense than storing all that data in a relational database.
The Postgres database is great for iteration but not for long term usage if the data at some point will become static.
Creating a
parcels.pmtilesfile (similar to how the georgia.pmtiles file works) will simplify the process of serving that data to users as well as cutting down the total size by 30-50%. No database overhead and no 10GB database index for those 47 million rows of tiles.What starts as a 29GB database table might shrink to 8-10GB, which is much easier to serve to a CDN if I want that.
PMTiles is also pretty smart about how it stores and presents data. Optimizing lines that overlap etc..
The process to create the file is pretty straightforward when using
tippecanoe:You can specify what metadata to keep a certain zoom levels and what size to keep tiles too and cull anything that goes past that threshold.
It also intelligently handles turning complex polygons into simplier shapes at zoom levels where you wont see that detail anyways. So this can make the data serving and rendering performance improve as well.
Expanding to showing parcels at lower zoom levels like 11 and 12 becomes much easier with PMTiles as the file size becomes more optimized.
It can also handle showing dots for parcels at lower zoom levels and automatically transition to full geometry at higher zooms:
--include-only-points-at-lower-zoomsFinal Thoughts