Hacker News new | past | comments | ask | show | jobs | submit login
Learning About the GeoTIFF File Format with a Hex Editor (2018) (medium.com/planet-stories)
93 points by oldpatricka on May 5, 2021 | hide | past | favorite | 18 comments



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!


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


I think that you meant to link to 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


Thank you, a bit too fast there


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.


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!


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


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-78...

- https://studio.unfolded.ai/public/96c70224-dd89-431f-ae7a-0a...

- https://studio.unfolded.ai/public/af792fd8-1990-4cdc-bf2b-99...



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


I recently did something similar with Foobar 2000's playlist format [1]. It was a fun learning experience :)

[1] https://darekkay.com/blog/foobar2000-playlist-index-format/


Ah wow this is great! Very clear explanation. I particularly liked that there are fields that you couldn’t identify but you were still able to get the information you needed!


speaking of this, what hex editor would community recommend for examining (potentially quite large) binaries?


I haven't gotten my hands dirty with it myself yet, but Poke looks super interesting!

https://www.jemarch.net/poke

https://media.ccc.de/v/ASG2019-127-gnu-poke-an-extensible-ed...

Actually, it sounds like a fun weekend task to redo this GeoTIFF writeup in Poke :-)


I typed .doc without a TOPIC and poke segfaulted. Oh well.

The hex editor I rely on for multi-GB files is ired.


On the Mac, I cannot recommend Hex Fiend enough: https://hexfiend.com/


ImHex




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: