Publishing raster tile service but resulting tile cache is obscenely huge

1225
4
Jump to solution
02-18-2023 04:50 PM
HollyTorpey_LSA
Occasional Contributor III

Greetings! I am reaching a state of desperation here.

I'm trying to publish some drone imagery to Portal as a tile service (about 150 acres captured from 400 ft with a 3.2 cm cell size... the orthomosaic tiff file is 2.1 GB, or 10 GB uncompressed), but the necessary tile cache for the tiling scheme I want is estimated to be in the terabytes. I need to publish all the way to zoom level 23 because the imagery will be used to identify vegetation classes, so resolution is important.

Recently I published another orthomosaic for a somewhat larger area with even high resolution. The orthomosaic tiff file was about 20 GB (44 GB uncompressed), and this is what its tile cache looks like (somewhere between 2 & 3 GB):

HollyTorpey_LSA_0-1676766053432.png

I was expecting a smaller total cache size for this new image because the file is much smaller (2 GB vs. 20 GB). However, this is what the estimated tile cache looks like for this new one (these are zoom levels 16 - 23): 

HollyTorpey_LSA_4-1676766819243.png

Why on earth would this image require 5 million tiles for zoom level 16 when the first image required 8? Why would the tile cache for a 2GB image be over a hundred TB?

I am publishing directly from Pro using "Share as web layer" with these settings: 

HollyTorpey_LSA_8-1676767389994.png

 

HollyTorpey_LSA_3-1676766578076.png

I have also tried using the tiling scheme from the other layer, but that for some reason brings in a scheme that will only cache tiles for zoom levels 5-11, even though the service actually has tiles for zoom levels 16-23, as shown above in the first screenshot.

I've also tried creating my own tiling scheme but that didn't seem to help at all either.

I have tried saving the SD file and publishing that directly through Portal using the "new item" button and the tile layer option. That produces the same results: 

HollyTorpey_LSA_1-1676766148731.png

I have compared the raster information of the two images and can find no explanation for the difference. If anything, the first image should have more tiles.

First image: 

HollyTorpey_LSA_7-1676767185395.png

Second image:

HollyTorpey_LSA_6-1676767135277.png

The only thing I can think of that is different is that the first orthomosaic was producted in Pix4Dmatic and the second one was produced in Pix4Dmapper. But why would that matter?

Does anyone have any idea why Pro and Portal want to produce such a massive tile cache? Is there another way I can get this imagery published in an efficient manner?

I will be incredibly grateful to anyone who can help me resolve this issue.

- Holly
1 Solution

Accepted Solutions
HollyTorpey_LSA
Occasional Contributor III

Okay, I'm still not sure what was going on, but here's what ended up working for me (in case anyone else is having the same problem):

I added a new map to my project. I did not set a projection but verified that the map was in Web Mercator. Then I added my orthomosaic tiff file. After I added it, I checked the map's coordinate system again and saw that it was now set to the projected coordinate system of the image (as was the first map, which is why I don't understand what is different in this map). Then I right clicked on the image an d opened the Share as Web Layer panel, selected the ArcGIS Online / Bing Maps / Google Maps tiling scheme, set the levels to 16 - 23 (also the same as my previous attempts) and then calculated the estimated cache size, getting a much more reasonable 1.25 GB. I have no idea what was different in this new map or why it made a difference, but after several days of gnashing my teeth, simply opening a new map was the solution. Wish I had tried it sooner. 

HollyTorpey_LSA_0-1676844239804.png

If anyone knows why publishing the imagery from a new map made a difference, please let me know! Stumbling onto a solution and not understanding why it works is rather unsatisfying. 😐

- Holly

View solution in original post

4 Replies
HollyTorpey_LSA
Occasional Contributor III

Also, I've checked the raster extent and it is as it should be. I've also tried adding it to a mosaic dataset, calculating footprint and boundary, and then publishing it, but that didn't help either.

- Holly
0 Kudos
HollyTorpey_LSA
Occasional Contributor III

Okay, I'm still not sure what was going on, but here's what ended up working for me (in case anyone else is having the same problem):

I added a new map to my project. I did not set a projection but verified that the map was in Web Mercator. Then I added my orthomosaic tiff file. After I added it, I checked the map's coordinate system again and saw that it was now set to the projected coordinate system of the image (as was the first map, which is why I don't understand what is different in this map). Then I right clicked on the image an d opened the Share as Web Layer panel, selected the ArcGIS Online / Bing Maps / Google Maps tiling scheme, set the levels to 16 - 23 (also the same as my previous attempts) and then calculated the estimated cache size, getting a much more reasonable 1.25 GB. I have no idea what was different in this new map or why it made a difference, but after several days of gnashing my teeth, simply opening a new map was the solution. Wish I had tried it sooner. 

HollyTorpey_LSA_0-1676844239804.png

If anyone knows why publishing the imagery from a new map made a difference, please let me know! Stumbling onto a solution and not understanding why it works is rather unsatisfying. 😐

- Holly
berniejconnors
Occasional Contributor III

Holly,

         The only reason the tile cache would be larger is if you are creating more tiles. I suspect the raster tile tool was using an oversized x/y extent to estimate the size of the tile cache.  Its great that just starting over again fixed the problem.

Bernie.

pkorst_coa
New Contributor III

This thread was very helpful. Thank you!