Unnecessary 0/0/0 tile fetch

Question

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).

Nicholas-Furness · Answer

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).

kris · Answer

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!

Nicholas-Furness · Answer

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 tiles

That's discussed a little more here.

Hope that helps.