ArcGIS APIs do not allow adding tilesets to ArcGIS Online

[brendan-ward]

Reported in #113

Need to ensure that tilesets with ArcGIS APIs enabled can be successfully added to ArcGIS Online, or provide guidance in the README as to why not.

[brendan-ward]

Possible bug in showing all LODs. See example ArcGIS API endpoint (shows only LOD 0)
and tileJSON which supports everything between 0 and 21.

When adding to ArcGIS Online, it also makes a request to the info endpoint, which we don't provide (example valid info).

If the info request succeeds, it then makes a request to the MapServer endpoint, which we provide here. Then it makes another request to the layers endpoint (example), which we provide as an extremely minimal endpoint (we don't have info about the layers).

It also may need to make a request to the legend endpoint (example), which we provide as an extremely mimimal endpoint (we don't have info about the legend).

So - first task is to support the info endpoint and see where things break after that.

[reyemtm]

I was able to get it to add an empty layer item to ArcGIS Online just by using the MapServer endpoint, but it then looks for the single layer at the layer endpoint, which is not "MapServer/layer/" but rather "MapServer/0", with 0 being the first layer of the "layers" array. I believe if this would return the first item in the layers array it should work.

Edit - I have it working but it only shows the minScale level of detail. It appears the level of detail function is not populating all the levels.

Edit - The lod for loop function did not like uint8, changing that to int seems to work, now to fix the incorrect tile coordinates...needed to add the flip y code. The layer is working in AGOL but alas print is still not working. The print result is empty.

[reyemtm]

I'm wondering if instead of targeting a MapServer endpoint with layers, we should instead target just a MapServer with no layers, at least for image mbtiles with one layer. The whole service is contained within one response - see this response from a cache served via ArcGIS Online.

https://tiles.arcgis.com/tiles/CRjnKyCe3OfYTMC3/arcgis/rest/services/2020_Fairfiled_3857_Cache/MapServer?f=pjson

Also still facing the issue that my working MapServer layer will not print. It may have something to do with this issue - https://support.esri.com/en/technical-article/000018259. The tiles are fetched, they just don't show up on the map.

[brendan-ward]

@reyemtm thanks for digging into this further and trying to get it working. Are you able to turn your fixes for LOD and tile coordinates into a PR?

For debugging the print issue, it might be useful to enable request logging on your server (if you haven't already), then inspect the logs for all requests made while the print job is running. That would give us greater insight into what endpoints the print job is hitting, and where it might be hitting an endpoint it expects that causes it to fail. Or maybe you already did this, and that's what you meant by "the tiles are fetched" ?

Good point about not returning any layers, at least for image services, if we can get away with it. The layers endpoint still exists though:
https://tiles.arcgis.com/tiles/CRjnKyCe3OfYTMC3/arcgis/rest/services/2020_Fairfiled_3857_Cache/MapServer/layers

But can return empty layers array.

[reyemtm]

There's another issue I haven't figured out with this service, the tiles are shifted slightly. It's not clear to me where this would be happening, except maybe in the flip y coords code. If you have any ideas... I'll download a clean copy of the repo and add the minimum needed to get the service working. I've tweaked it so much now I'd want to start with a clean version.

…

On Wed, Aug 4, 2021, 12:27 PM Brendan Ward ***@***.***> wrote: @reyemtm <https://github.com/reyemtm> thanks for digging into this further and trying to get it working. Are you able to turn your fixes for LOD and tile coordinates into a PR? For debugging the print issue, it might be useful to enable request logging on your server (if you haven't already), then inspect the logs for all requests made while the print job is running. That would give us greater insight into what endpoints the print job is hitting, and where it might be hitting an endpoint it expects that causes it to fail. Or maybe you already did this, and that's what you meant by "the tiles are fetched" ? Good point about not returning any layers, at least for image services, if we can get away with it. The layers endpoint still exists though: https://tiles.arcgis.com/tiles/CRjnKyCe3OfYTMC3/arcgis/rest/services/2020_Fairfiled_3857_Cache/MapServer/layers But can return empty layers array. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#114 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABQ2HUMTRVTY4SWQYUXPESLT3FS6HANCNFSM5BJHFUNA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email> .

[brendan-ward]

@reyemtm can you please clarify what you mean by

tiles are shifted slightly

Are they shifted in the Y direction or X direction or both? Is the shift roughly consistent (as a proportion of tile size) across zoom levels, or does it increase with increasing zoom level?

[reyemtm]

Both directions, to the SE. It is slight but noticeable. It's weird since they are pointing to the same data as the tile server. It would appear that AGOL is performing some sort of transformation, not sure why since it has the same projection as the working cached service. I even tried to add the wkid as Esri has it - but that did not change anything. It is not porpotional, it is a very slight maybe 2-3' shift, which would be consistent with a projection/transformation shift.

"spatialReference": {
    "wkid": 102100,
    "latestWkid": 3857
}

https://arcg.is/DvG0r

[brendan-ward]

It looks like the shift is only observable at the highest zoom levels, which suggests that it is has to do with the absolute coordinate position of the tileset origin rather than a slight shifting at each level of detail.

It looks like the origin values are slightly different between what shows in your TileJSON from mbtileserver:

20037508

(though it is hard-coded to correct value here?)

Whereas in the AGOL cached map service:
https://www2.ci.lancaster.oh.us/tileserver/arcgis/rest/services/2020_fairfield_3in_z21/MapServer

-20037508.342787

and the WMTS service

-20037508.34278925

[reyemtm]

Nice catch on the origin. Now to figure out which one is right...

Looks like this is hard-coded in the wmts package.

And it looks like this is a case where GO is not treating the integers correctly or as expected. They are defined as float32 but should be float64 (confirmed). The values could also be changed from what AGOL is providing (current):

"origin": {
    "x": -20037508.342787,
    "y": 20037508.342787
},

to the result of the actual calculation:

xmin: -20037508.3427892,
ymin: -20037508.3427892,
xmax: 20037508.3427892,
ymax: 20037508.3427892