Memory Size and TileCache

[ilan-gold]

Target Use case

Hello! I am developing something that looks like it will have off-screen (i.e not visible) custom BaseTileLayers that I would like to have loaded for quick use and I would love to be able to allocate cache size equally and/or have each layer take up a predetermined percentage of the memory.

Proposed feature

I'd like if we could implement the maxCacheSize of the TileCache as a function of memory (allowing the user to control a percentage config, perhaps). I see that there is a TODO for it already here so I just wanted to make my use-case known. I am aware that my last PR seems to have opened something of a can of worms as per #4139 (very excited for these improvements, by the way!!!) so I understand if this is not coming for a while (until the API and location of the TileCache are finalized).

[Pessimistress]

To avoid unload the whole responsibility to the user, maybe we can do the following:

• Allow users to limit the cache by memory size, instead of the number of tiles. To track the memory used, we can look for a byteLength field on the result returned by getTileData. This will automatically work for ArrayBuffers, and applications need to manually populate this field for other data formats.
• Update TileCache settings when the layer's props change (minZoom, maxZoom, maxCacheSize etc.)

Logistic wise, we are making an effort to align the 2D TileLayer with Tile3DLayer. Because the two layers will share some dependencies, I am moving the BaseTileLayer back to the geo-layers module. In the long term, we would like both the 2D and 3D tile layers to support non-geospatial use cases, and they may warrant their own module.

[ilan-gold]

Just so I can get a sense of where things are heading, will moving that revert the newly exposed API for non-geospatial use cases or is the move in name only really? Also, is #4139 going to be in 8.1?

[Pessimistress]

It's not going to revert the new API. We will have one TileLayer that by default implements getTileIndices and tileToBoundingBox to the OSM spec.

#4139 is going to be in 8.1. I can publish an alpha release if you are interested in trying it out.

[ilan-gold]

That would be superb, actually - I've been on the other alpha branch (since I am using the BaseTileLayer) and everything has been working swimmingly. I can let you know if anything looks off. Thanks!

[Pessimistress]

@ilan-gold published 8.1.0-alpha.2

[ilan-gold]

Thanks! Just so I can know what's coming, is #4232 going to be in 8.1?

[Pessimistress]

Yes. I'll let you know when the change is in an alpha release. We also need to go through API audit before the official release, which might change some prop names.

[ilan-gold]

Thanks, that second part is good to know.

[Pessimistress]

@ilan-gold 8.1.0-alpha.5 is published with built-in support for non-geospatial tiles and cache size in bytes. The documentation on the master branch is up to date. Could you give it a try and let me know if things are working as expected?

[ilan-gold]

@Pessimistress I already checked out master and gave it a whirl. Ill test out the release tomorrow. I was planning on offering you all a PR with a small example of it, like map-tiles in the website example section. Would you be interested? There might be a question of where to store tile data for the non geospatial image if so.

[ilan-gold]

Here's the demo

[ibgreen]

@ilan-gold Love the demo!!! - what is the fully zoomed in resolution???

[ilan-gold]

24000 x 24000 - I just wanted to offer it up here as @Pessimistress did the unit tests and I offered a demo: #4246 (comment). If hosting the tiles are too much of a pain, no worries - I just wanted to follow up :)

[ilan-gold]

@Pessimistress The release worked for me, by the way.

[ibgreen]

24000 x 24000

seamless zooming on 576 Megapixel image, that is quite impressive!

If hosting the tiles are too much of a pain,

There is a deck.gl-data repo for storing big data sets for other demos. I believe your tiles would be welcome there, as long as they are under permissive license. Or you can set up another similar repo to serve them.

[ilan-gold]

@ibgreen I used libvips to create the tiled image pyramid. I got the image from http://lroc.sese.asu.edu/posts/293 so I can add that URL in the bottom corner as well.

[ibgreen]

I used libvips to create the tiled image pyramid

Interesting. You may want to mention that in the deck.gl-data README. And also perhaps in the info panel for the demo. I think users will be curious to learn how to make a dataset like this.

I got the image from http://lroc.sese.asu.edu/posts/293

I took a look on their site, but couldn't see a LICENSE. If not stated, can you contact them and ask for permission?

[ilan-gold]

I can reach out, yes. I’ll also add information on the generation of the data from the source.

[ilan-gold]

I reached out but I also saw this @ibgreen http://lroc.sese.asu.edu/about/terms

[ibgreen]

OK, those terms look good.

• Link to those terms in deck.gl-data PR
• Add a Citation (compliant with those terms) in deck.gl-data
• Add a Citation (compliant with those terms) in the example README and info box.

I noticed in http://lroc.sese.asu.edu/posts/293 that they are using an app called zoomify to offer the same (seamless zoom) functionality, and if you look in the network tab while zooming we can see them loading their version of "tiles"...

Just a crazy idea, maybe we could make our tile layer compatible with zoomified data sets:

• if we could deduce the zoomify naming scheme
• if we could make our tile layer load those tiles directly.
• not clear if those "zoomified tiles" are covered under the license

[ilan-gold]

@ibgreen I think writing utilities for that sort of thing would probably be very nice. I use DeepZoom which is another "format". We have other formats as well that we could be interested in offering once we have written the finalized them. Maybe some sort of data-utils folder would be nice. You can have a look at the DeepZoom structure in my PR to deck.gl-data.

Another thing that I was planning on tackling was writing a MapController that offers smoother zoom/pan, kind of like OpenSeaDragon. If y'all were interested, I could contribute it here once done.

[ibgreen]

I think writing utilities for that sort of thing would probably be very nice. I use DeepZoom

Maybe the first step is simply to create a short markdown doc, that talks about different tiled formats for deep image zoom (listing the tools available to generate that format, and the resulting file structure, whether format is proprietary etc). This would be a great go-to resource for users who are new to this problem and help establish the TileLayer as a serious option for visualizing such image stacks.

It would be cool if we could cover a lot of the available formats just by defining some template strings, that user could supply as a prop. If not, as you say, we could show how to write the tile URL generation functions in the docs, and later maybe even offer a library of such functions.

[ibgreen]

writing a MapController that offers smoother zoom/pan, kind of like OpenSeaDragon.

You mean a controller with inertia/dampening, so that it scrolls pixel by pixel and keeps scrolling a bit after we release? Yes that is a beautiful feature that we currently miss.

Some complications with taking such a PR on the core frameworks :

• The design should ideally work for all our controllers, not just the map controller,
• Have thorough test cases to make sure it keeps working in future releases
• Be carefully architected so it does not constrain view/controller development in other areas

Obviously, you'd get some help to work through those issues, just as long as you are ready for them. If not, we can always accept a PR for an example as a first step.

[ilan-gold]

Ok that sounds good for the tiling. Thanks for the direction on the controller - I think it should be within my skill range.

[kylebarron]

• if we could deduce the zoomify naming scheme

It looks like the network requests are for the normal z/x/y tiling scheme, just that instead of having them nested in folders, the images are named {z}-{x}-{y}.jpg.

• if we could make our tile layer load those tiles directly.

Those tiles don't have the right cors settings, so I don't think we could load them directly.

Other notes: the image-tile example dir isn't yet included in the bootstrap settings, so I had to run yarn again in the dir.

[ibgreen]

Those tiles don't have the right cors settings, so I don't think we could load them directly.

In what sense? Is it the case where they can be loaded as images but only "opaquely" so textures can not be created?

[kylebarron]

As in trying to call

fetch('http://lroc.sese.asu.edu/ptif/zoomify/wac_nearside/TileGroup0/1-0-0.jpg')

from a non asu.edu domain returns

Access to fetch at 'http://lroc.sese.asu.edu/ptif/zoomify/wac_nearside/TileGroup0/1-0-0.jpg' from origin 'http://example.com' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. 

[HGS-areichma]

It looks like the network requests are for the normal z/x/y tiling scheme, just that instead of having them nested in folders, the images are named {z}-{x}-{y}.jpg.

Zoomify URLs require a TileGroup in addition to a z/x/y mapping, where a TileGroup contains up to 256 tiles. For reference, here's the OpenLayers source:

https://github.com/openlayers/openlayers/blob/master/src/ol/source/Zoomify.js