parseGeoraster .ovr detection

[sammertime]

Hi,

Great package! I'm using this along with georaster-layer-for-leaflet to overlay cloud optimized geotiffs on a leaflet map.

Going off of the various examples here https://github.com/GeoTIFF/georaster, when I use the "load from url on front-end"/arraybuffer example, it works fine. However, when I use the "load cloud optimized geotiff" example where no arraybuffer is used, I get a HEAD 403 error from the parseGeoraster function - it seems to be looking for a .ovr file that doesn't exist. My files have internal overviews and thus no .ovr files should exist, but the parseGeoraster function seems to automatically look for a .ovr file and throws an error if not found..

I see in the description for this method - "It will also attempt to automatically discover any available overview files." Will this method work with cog's with internal overviews vs external? Is there a way I can bypass this error or an option I can provide to specify that my files use internal overviews? I'd much prefer to avoid loading the whole file via the arraybuffer route for speed/efficiency purposes i.e. one of the main benefits of a cog.

Thanks much for any insight!

Best,
S

[DanielJDufour]

Hello, great question. GeoRaster will automatically use any internal overviews if no external overviews are present. Hopefully that answers your question. Let me know either way.

…

On Wed, Aug 3, 2022, 8:11 PM sammertime ***@***.***> wrote: Hi, Great package! I'm using this along with georaster-layer-for-leaflet to overlay cloud optimized geotiffs on a leaflet map. Going off of the various examples here https://github.com/GeoTIFF/georaster, when I use the "load from url on front-end"/arraybuffer example, it works fine. However, when I use the "load cloud optimized geotiff" example where no arraybuffer is used, I get a HEAD 403 error from the parseGeoraster function. It seems to be looking for a .ovr file that doesn't exist - my files have internal overviews. The file url that's producing the error ends with ".ovr", but I'm not storing overviews externally (only internally) and thus no .ovr files exist in my system, hence the error. I see in the description for this method - "It will also attempt to automatically discover any available overview files." Will this method work with cog's with internal overviews vs external? Is there a way I can bypass this error or an option I can provide to specific internal overviews? I'd much prefer to avoid loading the whole file via the arraybuffer route for speed/efficiency purposes i.e. one of the main benefits of a cog. Thanks much for any insight! Best, S — Reply to this email directly, view it on GitHub <#69>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABA5C53PXADA73VIO53QI6LVXMDDTANCNFSM55QUST7A> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[sammertime]

Thanks for the prompt reply Daniel!! Much appreciated..

So it sounds like an error I can just ignore when using parseGeoraster on a cog? i.e. not going the arrayBuffer route.

I've switched over to that method but now it looks like the mins, maxs, and ranges are missing from georaster. Is that expected behavior i.e. do I need to extract that information using another method when using parseGeoraster without an arrayBuffer?

Sorry for doubling up on the question.

Thanks!!
S

[DanielJDufour]

No prob. They are great questions and the answers will help others who read this, too!

Q: So it sounds like an error I can just ignore when using parseGeoraster on a cog?
A: Yes that is correct

Q: I've switched over to that method but now it looks like the mins, maxs, and ranges are missing from georaster. Is that expected behavior i.e. do I need to extract that information using another method when using parseGeoraster without an arrayBuffer?
A: It's expected because georaster wants to avoid calculating statistics which would require it to fetch all the pixel data. You don't need statistics to do a visualization as newer versions of GeoRasterLayer (if you are using LeafletJS) will dynamically calculate statistics from the user rendered pixels. It's not the true stats, but good enough for most visualization. Because it's JavaScript, you can also directly add mins, maxs and ranges properties to the georaster object as well. You could also just specify a pixelValuesToColorFn.

Note: I'm doing a big multi-year refactor of georaster and improving statistical calculations is definitely a part of that. I think currently, it won't read COG's GDAL stats metadata, but that will improve in the future.

Let me know if you have any other questions.

[sammertime]

10-4! Understood - thanks again! I plan to use a pixelValuesToColorFn and was doing so using the min/max/ranges and the arrayBuffer method but now I just need to figure out how to do the same using parseGeoraster without arrayBuffer - working on that now : )

S

[sammertime]

Hi again Daniel,

Another question regarding this packages .ovr file detection. Though my cog's are loading as expected, the performance/speed of load is not what I was hoping for. In looking into it via the "network" tab of the developer tools, I'm wondering if it's because of the query for the external overview files that don't exist on my end. Attached is a screenshot of the network tab when I load a single cog on the map. That top line in red is the query for the external overview and, as you can see, it's eating up the majority of time to load compared with the cog, which was in the browser cache for this example.

I *think I read elsewhere that there is no way around this at this time? If that's the case and considering performance is of a high priority for me, would I be better off for the time being going with another package? If so, any suggestions? i.e. should I go with geotiff.js instead?

I'd love to use this package but if I'm unable to get around the default query for external overviews, I'm wondering if it makes sense to use another package for now - understanding of course that there is an overhaul underway, as you mentioned.

Many thanks,
S