3 ms·

Could we build a static “Google Maps” using really big GeoTIFF files and downloading part of them with the section of a file functionality. Just like the SQLit

Could we build a static “Google Maps” using really big GeoTIFF files and downloading part of them with the section of a file functionality. Just like the SQLite example: https://news.ycombinator.com/item?id=27025829 https://news.ycombinator.com/item?id=27025829

gregsadetsky 5y ago
I think that you meant to link to https://news.ycombinator.com/item?id=27016630 https://news.ycombinator.com/item?id=27016630 instead which was the recently posted SQLite/SQL.js/HTTP range library And there was a specific sub-thread in the conversation that mentioned using this for maps too! https://news.ycombinator.com/item?id=27020372 https://news.ycombinator.com/item?id=27020372
- punnerud 5y ago
  Thank you, a bit too fast there
kylebarron 5y ago
You could, you'd just have to be wary of how large the header metadata would be. If you had a single Cloud-Optimized GeoTIFF of the world with internal tiles up to zoom 14, the header metadata could be a few MB, which wouldn't be ideal to load in every client.
- gregsadetsky 5y ago
  The posts on this topic on your site are really fascinating! https://kylebarron.dev/blog/cog-mosaic/overview https://kylebarron.dev/blog/cog-mosaic/overview https://kylebarron.dev/blog/cog-mosaic/naip https://kylebarron.dev/blog/cog-mosaic/naip
  - kylebarron 5y ago
    Thanks! The text is still relevant but those demos are a little old. If you're curious these demos are from last week (using Cloud-Optimized GeoTIFFs under the hood to serve image data quickly): - https://studio.unfolded.ai/public/9a2c5cd8-f0f0-43ce-b231-78bb6af905fb https://studio.unfolded.ai/public/9a2c5cd8-f0f0-43ce-b231-78... - https://studio.unfolded.ai/public/96c70224-dd89-431f-ae7a-0a56d9e2efb7 https://studio.unfolded.ai/public/96c70224-dd89-431f-ae7a-0a... - https://studio.unfolded.ai/public/af792fd8-1990-4cdc-bf2b-99e6a1ad3b45 https://studio.unfolded.ai/public/af792fd8-1990-4cdc-bf2b-99...
- kylebarron 5y ago
  See also: https://github.com/pangeo-data/cog-best-practices/issues/9 https://github.com/pangeo-data/cog-best-practices/issues/9
- simonw 5y ago
  Sad to say it but these days loading a few MB to a client is par for the course. I don't think it's a reason not to try and get this working - the range header trick does sound particularly relevant to this format. UPDATE: Just read https://kylebarron.dev/blog/cog-mosaic/overview https://kylebarron.dev/blog/cog-mosaic/overview which is excellent and clearly you're already very on top of the range request mechanism!
bdon 5y ago
Yes, though for zooming in to sufficient detail you will need recursive indexes if you don't want the initial fetches to be really huge. https://github.com/protomaps/pmtiles#specification https://github.com/protomaps/pmtiles#specification

gregsadetsky 5y ago

I think that you meant to link to https://news.ycombinator.com/item?id=27016630 https://news.ycombinator.com/item?id=27016630 instead which was the recently posted SQLite/SQL.js/HTTP range library And there was a specific sub-thread in the conversation that mentioned using this for maps too! https://news.ycombinator.com/item?id=27020372 https://news.ycombinator.com/item?id=27020372

punnerud 5y ago
Thank you, a bit too fast there

kylebarron 5y ago

You could, you'd just have to be wary of how large the header metadata would be. If you had a single Cloud-Optimized GeoTIFF of the world with internal tiles up to zoom 14, the header metadata could be a few MB, which wouldn't be ideal to load in every client.

gregsadetsky 5y ago
The posts on this topic on your site are really fascinating! https://kylebarron.dev/blog/cog-mosaic/overview https://kylebarron.dev/blog/cog-mosaic/overview https://kylebarron.dev/blog/cog-mosaic/naip https://kylebarron.dev/blog/cog-mosaic/naip
- kylebarron 5y ago
  Thanks! The text is still relevant but those demos are a little old. If you're curious these demos are from last week (using Cloud-Optimized GeoTIFFs under the hood to serve image data quickly): - https://studio.unfolded.ai/public/9a2c5cd8-f0f0-43ce-b231-78bb6af905fb https://studio.unfolded.ai/public/9a2c5cd8-f0f0-43ce-b231-78... - https://studio.unfolded.ai/public/96c70224-dd89-431f-ae7a-0a56d9e2efb7 https://studio.unfolded.ai/public/96c70224-dd89-431f-ae7a-0a... - https://studio.unfolded.ai/public/af792fd8-1990-4cdc-bf2b-99e6a1ad3b45 https://studio.unfolded.ai/public/af792fd8-1990-4cdc-bf2b-99...
kylebarron 5y ago
See also: https://github.com/pangeo-data/cog-best-practices/issues/9 https://github.com/pangeo-data/cog-best-practices/issues/9
simonw 5y ago
Sad to say it but these days loading a few MB to a client is par for the course. I don't think it's a reason not to try and get this working - the range header trick does sound particularly relevant to this format. UPDATE: Just read https://kylebarron.dev/blog/cog-mosaic/overview https://kylebarron.dev/blog/cog-mosaic/overview which is excellent and clearly you're already very on top of the range request mechanism!

bdon 5y ago

Yes, though for zooming in to sufficient detail you will need recursive indexes if you don't want the initial fetches to be really huge. https://github.com/protomaps/pmtiles#specification https://github.com/protomaps/pmtiles#specification