[gdal-dev] COG + javascript + openlayers

[Marty J. Sullivan]

You might also try reporting your issues to geotiff.js project on GitHub. I’m fairly certain that library decodes tiles using JavaScript so it is probably that which is slowing it down over simply downloading the tiles. I’ve been going back and forth on an issue related to WebP support, where the project maintainer is adding a feature for browser-based decoding. This happens to work for the way GDAL produces COGs with WebP encoding, where each tile is stored as a standalone WebP file, and might be true for other compression schemes as well. However, if for example, each encoded tile is not standalone and requires information from the GeoTIFF headers, then this won’t be possible.

Marty Sullivan
Cornell University

From: gdal-dev <gdal-dev-bounces at lists.osgeo.org> on behalf of Patrick Young <patrick.mckendree.young at gmail.com>
Date: Tuesday, April 13, 2021 at 11:35 AM
To: Javier Jimenez Shaw <j1 at jimenezshaw.com>
Cc: gdal dev <gdal-dev at lists.osgeo.org>
Subject: Re: [gdal-dev] COG + javascript + openlayers

There is a COG mailing list (not very active from the looks of it):

https://lists.osgeo.org/mailman/listinfo/cog

You might ping Vincent https://github.com/vincentsarago too!

P

On Tue, Apr 13, 2021 at 2:31 AM Javier Jimenez Shaw <j1 at jimenezshaw.com<mailto:j1 at jimenezshaw.com>> wrote:
Maybe this channel is not the best place for this question. Do you know a better place to ask?

Thank you
.___ ._ ..._ .. . ._.  .___ .. __ . _. . __..  ... .... ._ .__
Entre dos pensamientos racionales
hay infinitos pensamientos irracionales.


On Tue, 6 Apr 2021 at 22:40, Javier Jimenez Shaw <j1 at jimenezshaw.com<mailto:j1 at jimenezshaw.com>> wrote:
Hi

While I was reading about COG format, I thought it was great to replace "gdal2tiles" if the COG was properly generated (I mean, using the option TILING_SCHEME=GoogleMapsCompatible , and maybe something else I miss. I am generating it, so I can optimize that).
Then I was expecting that geotiff.js (or any other client js library) will be able to do the proper RANGE request to produce the tiling that libraries like openlayers of leaflet is expecting. Yes, in Web Mercator projection with aligned tiles, so no transformation is needed.

My initial target is just for RGBA uint8 images... plain vanilla. Storing the COG file in S3, without any proxy in between doing any conversion. Just relying on the RANGE request to get the needed area. My initial idea is to keep the openlayers/leaflet 256x256 tiles. This allows parallel requests to the server, and is very fast (and I do not have to refactor all my js code). But maybe there is a better/faster solution (again, with S3 direct access, no proxy in the server side. That would require deploying the "proxy" on every geographical region).

However I have not found any proper solution (my search-fu is not the best, to be honest). I would like something that performs at least as fast as the tiles produced by gdal2tiles.

Do you know any solution/example?

Thanks
.___ ._ ..._ .. . ._.  .___ .. __ . _. . __..  ... .... ._ .__
Entre dos pensamientos racionales
hay infinitos pensamientos irracionales.
_______________________________________________
gdal-dev mailing list
gdal-dev at lists.osgeo.org<mailto:gdal-dev at lists.osgeo.org>
https://lists.osgeo.org/mailman/listinfo/gdal-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20210413/aeb1594f/attachment-0001.html>