17 comments

[ 4.3 ms ] story [ 46.1 ms ] thread
speaking of this, what hex editor would community recommend for examining (potentially quite large) binaries?
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

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.
The posts on this topic on your site are really fascinating!

https://kylebarron.dev/blog/cog-mosaic/overview

https://kylebarron.dev/blog/cog-mosaic/naip

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 which is excellent and clearly you're already very on top of the range request mechanism!

This is a good hex editor overview, but also the part about Cloud-Optimized GeoTIFFs is quite good. In the past couple of years COGs have really revolutionized the satellite imagery industry. Even USGS has seen this is the future and publishes the official Landsat data in Cloud-Optimized GeoTIFF format [0].

I've been leveraging COGs recently to quickly bring satellite imagery into the browser for analysis [1].

[0]: https://www.usgs.gov/core-science-systems/nli/landsat/landsa...

[1]: https://www.unfolded.ai/blog/2021-04-28-raster-layer/

We use COGs at work with mapserver (and GDAL's /vsis3/ magic) to serve up imagery internally for qa/qc:

https://github.com/pedros007/mapserver-docker

Literally saves hundreds of thousands of dollars a year by avoiding having to stage the imagery locally before serving it out!