Unnecessary 0/0/0 tile fetch

09-15-2021 05:21 AM
New Contributor III

Hi, we use AGSArcGISVectorTiledLayer to display vector tiles. 

Before adding the layer to the operationalLayers list, we set min- and maxScale on the layer instance, since we do not want to show these data before layer 12. 

Investigating a server proxy logs, we do see that the app tries to fetch data from the upper levels:

GET server:port/service/layer/tile/5/6/7.pbf 
GET server:port/service/layer/tile/4/3/3.pbf 
GET server:port/service/layer/tile/3/1/1.pbf 
GET server:port/service/layer/tile/2/0/0.pbf 
GET server:port/service/layer/tile/1/0/0.pbf

We add these layers to the map after a successfull map.load on the latest 100.12.0 runtime. Even though the server do return data for these top levels, nothing is rendered in map (as expected). 

0 Kudos
4 Replies
Esri Regular Contributor

Hi @kris. Thanks for the question and the details.

One thing springs to mind: When are you setting the AGSMapView's viewpoint? If your AGSMap has an initialViewpoint set, and you animate to another viewpoint, then if at some point (initial viewpoint, or during the animation) the vector tile layer is within visible scale range, it's possible it could trigger a tile request. And because we use overzooming, we might need to fetch these higher level tiles. By the time the map view settles into its new viewpoint, we won't display the data.

To help debug, you could try adding the layer once the map view has displayed (just throw in a timer delay for this test) and see if you still see the requests.

You can also use AGSRequestConfiguration.global().debugLogRequests and debugLogResponses to output these requests to the console.

If it is the case that setting the AGSMapView's viewpoint is triggering this, you could try setting the initialViewpoint on the AGSMap (you can do this before you load it), or setting the AGSMapView viewpoint immediately without an animation. That should override any stored initialViewpoint on the map and avoid any MapView viewpoint transitions.

I've made a lot of assumptions there of course, so let me know if your code isn't doing anything to trigger this.

0 Kudos
Esri Regular Contributor

I've spoken with the team some more about this, and it's deliberate and one of the issues we plan to address over the next few releases.

A little background: the initial Runtime vector tile layer implementation focused on basemaps, so we were able to make certain assumptions about layer visibility, and that is likely why requests are be being made despite the layer being out of visible range.

Separately, as I mentioned, overzooming is why we request data outside of the configured visible range. For example: in the Pacific, there may be no need to bake level 12 tiles for a given area when the single level 2/3/4/5 etc. tile works fine.

Tiles and overzoom for vector tilesTiles and overzoom for vector tiles

That's discussed a little more here.

Hope that helps.

0 Kudos
New Contributor III

We do set a high/large initial viewpoint before the GPS eventually kicks in, so that kind of explains it. We use aerial rasters as default background map, and these vector layers are operational layers that only make sense zooming in.

Not sure if the server provides that tile index though (actually not sure if it really caches the tiles yet either (making it really sweat for that 0/0/0 tile;). Thanks for details and console logging tips!

Esri Regular Contributor

Sure thing.

One additional nicety to note about AGSRequestConfiguration is that you don't have to log globally. Any class that implements AGSRemoteResource can have its own AGSRequestConfiguration set, so you can log just for a specific table, layer, or task, for example. Something like…

if let rc = AGSRequestConfiguration.global().copy() as? AGSRequestConfiguration {
    rc.debugLogResponses = true
    myTroublesomeTiledLayer.requestConfiguration = rc

And it is strongly recommended that you do NOT log in production releases. There is a definite performance and resource overhead. Of course, sometimes that's necessary to get to the bottom of an issue, but make that a strictly opt-in and temporary process (ideally, say, with a special build or TestFlight release).