|
| Soupy wrote:
| This is ridiculously cool, demo is slick and fast! I work pretty
| extensively with tiling pipelines and GeoTiffs right now as I'm
| building out a mass repository and platform for historical map
| and aerial analysis (https://pastmaps.com - still very early so
| don't judge it too hard please)
|
| As part of this work, I similarly hit problems with using the raw
| GeoTiff files as my source and found that I was able to build
| some custom tiling hooks into MapLibre coupled with http range
| queries on the static files hosted in S3 to bypass the need for
| tiling. It does push the compute to the clients but I've found
| it's actually pretty fast even on older mobile devices.
|
| If this MapLibre GeoTiff source support is at all of interest,
| I'm happy to share some basic code or even open source some of
| that work. Here I was thinking I was the only weird dude on the
| internet messing with this stuff :D
| avibryant wrote:
| See also https://geoblaze-gsoc.vercel.app and the underlying
| libraries it uses, which also do range queries on GeoTIFFs.
|
| I'm super interested in this space, including in helping
| financially support some projects. I already emailed Ted about
| this, but would be happy to chat to anyone doing this stuff. My
| email's in my profile.
|
| (Luckily this is niche enough I'm not worried about my inbox
| blowing up....)
| tppiotrowski wrote:
| Ah. I hadn't even thought that I could do byte offsets on the
| fly. In general I would err on the side of over-sharing because
| until ChatGPT came along I struggled to understand what tools
| and options were to generate tiles as there wasn't much data I
| could find online.
|
| One thing specific in my case: the LiDAR GeoTiffs are in
| imperial feet with a 32 bit floating point precision. If you
| take the elevation range from sea level to Everest in meters
| (8848) and pack it into an int16, you can get .2 meter
| precision. That's plenty for ShadeMap so converting from
| float32 to int16 should save half the cloud storage space in
| theory and more when taking PNG compression into account.
| Soupy wrote:
| This code is _rough_ , and that's an understatement, but
| here's a basic gist showing how I'm doing what I'm doing in
| case it helps you in any way: https://gist.github.com/craigsc
| /fdb867f8971ff5b4ae42de4e0d7c...
|
| I'm similarly using R2 as my static hosting backend and it's
| been pretty fast and seamless
|
| note that i'm using the geotiff.js and fast-png libraries for
| the heavy-lifting behind the range-queries and the client-
| side png encoding. why reinvent the wheel, right?
| jamessb wrote:
| > coupled with http range queries on the static files hosted in
| S3 to bypass the need for tiling
|
| Did you look into Cloud Optimized GeoTIFF format?
|
| https://www.cogeo.org/
|
| It is supported by OpenLayers:
| https://openlayers.org/en/latest/examples/cog.html
|
| (I don't think that Maplibre or Leaflet have built-in support
| for it)
| Soupy wrote:
| I did actually! For my particular source dataset it was far
| easier just to lean on the plain old GeoTiff format since
| that's what my source data was already formatted in and my
| testing of the client-side on-the-fly tiling using range
| queries and fast-png for encoding resulted in close to par
| performance with 0 increase in hosting costs and 0 headache
| in building custom pipelines to encode the cloud-optimized
| versions. Basically, I'm lazy, I'm sure it's the "correct"
| answer for other use-cases
|
| I also have been digging pretty extensively into protomaps
| though for some newer non-GeoTiff datasets I'm in the process
| of pulling in, in my opinion it's the future for this space -
| https://protomaps.com/
| veec_cas_tant wrote:
| Wow, this is very neat. Awesome project
| punnerud wrote:
| Something that could be converted into SQLite database and served
| as static file at a fraction of the cost?
| https://news.ycombinator.com/item?id=27016630
|
| Range request in HTTP is doing the magic, but that part is
| already "solved"
| Soupy wrote:
| that's essentially the route that Mapbox went down and they've
| even invented an entire mbtiles file format that essentially is
| just a sqlite db for doing these kinds of queries on the server
|
| it's the "status quo" approach today in the industry, but it
| has some downsides still especially for smaller builders (ie
| me):
|
| 1. i'd have to run a separate tile server to take in the tile
| requests and convert them to "sql" requests (or mbtile
| requests) under the hood, and I'm just not a fan of more moving
| parts 2. I'd have to take my 10+ TB (and growing) of geotiffs
| and process them all into mbtiles which is a huge compute and
| walltime cost 3. the resulting mbtiles end up being similar in
| size at best, but at worst far larger than the original
| geotiffs so it balloons up the hosting and egress costs in
| exchange for faster requests. this is a great compression
| optimization breakdown for geotiffs that dives into this if
| you're interested -
| https://blog.cleverelephant.ca/2015/02/geotiff-compression-f...
|
| anyways, I'm sure ted has his own thoughts as well but this is
| at least what I've taken away from this space after diving into
| it with fresh eyes in the past few months
| verelo wrote:
| I love Shademaps. I wish my product that has been using it was
| more of a hit, but I'll say this, Ted and Shademaps are cool.
| Adding trees is super practical, in many of the areas I leverage
| this tool we're in Urban centres but in scenarios where i'm not,
| the tree data is almost always more relevant than the buildings
| or elevation (Ontario is pretty flat and thats 99% of my users)
|
| Keep up the great work!
| tppiotrowski wrote:
| Thanks Andrew. Still struggling a bit with the
| business/marketing side of things but the idea appears popular
| and the work itself is fun and fulfilling.
|
| Thanks again for your support.
___________________________________________________________________
(page generated 2023-07-09 23:00 UTC) |