Layer for reading tiles from an ESRI ArcGIS Server (AGS) Mapcache

[mpriour]

There have been several requests and attempts at providing support for ESRI's ArcGIS Server mapcache tiles ( http://n2.nabble.com/forum/Search.jtp?query=ArcGIS+cache&local=y&forum=1822462). The tiles in these tile caches are stored in a TMS style. However instead of base 10 rows & columns, they use HEX numbered rows & columns. The previous code for this from Steven Ottens sandbox included some tile calculation errors which caused all manner of difficult and haphazard problems for people attempting to use it. Hopefully this will fix many of those problems.

[mpriour]

Patch to add ArcGIS Server Mapcache support

[mpriour]

I have created an example for this layer class. The patch for that is attached. Also I have changed the line endings to Unix format. I have also included the patch for that. The example hits ESRI's demo server:  http://serverx.esri.com/ I would encourage anyone that has access to other AGS servers or AGS created mapcaches to test against those. I have tested against both actual server installations and the cache directory copied to a web server with no ESRI server installed.

[mpriour]

Patch for this layer with UNIX style line endings

[mpriour]

Example using the ArcGISCache Layer

[mpriour]

Can't figure out how to delete patches other than to name them the same name. Uploading another patch that includes all changes, the layer class file, and the example. This patch was created against the trunk, unlike the previous ones which were incorrectly created against the individual files.

[bjornharrtell]

I've tried this patch on a custom tilecache produced by an unknown version of ArcGIS Server with the spatial reference system SWEREF99_TM (EPSG:3006) png images with success using 7 resolution levels.

I found the example very well explained. I got stuck on only one thing though - in my conf.xml I have origin values -5120900,-9998100 but the layer will only work with -5120900,9998100 as in the example. I can't explain this...

Really nice work Matt! :)

[bjornharrtell]

Uh oh. Sorry to say this but I wasn't looking hard enough it seems.

The spatial reference doesn't seem right, and zooming between the resolutions isn't right - if you make a zoombox on an area you'll get images from somewhere else than that zoomed area. Using a coordinate display (MousePosition control) it seems like the coordinates/images are in the wrong place also.

I get this with both the external example int the patch and with my own cache.

[mpriour]

Setting up some stuff to test this problem. I have 2 different map caches that I hit without any issues. The math is pretty simple it is almost identical to the TMS logic. The biggest change is a conversion from base 10 to hex 'folder' numbers.

[mpriour]

*USE THIS ONE* ArcGIS MapCache Layer plus Example

[erjackson]

I also tried this patch with a custom tilecache produced by ArcGIS 9.3 sp1. The SR is EPSG:4326 and it has 15 levels (same scales as arcgisonline services) I can view all levels but zooming in/out jumps the center of the map around. The zoombox also doesn't return what was expected, a different part of the map shows. I also see this behavior with the patch example, and my cache.

[crschmidt]

Matt:

I've seen a couple examples from you, but none of them actually work thus far. Upon further investigation, I've realized that no one I've talked to has been able to set up a cache with this layer code.

I know that you said on IRC that you thought you had it working, but I'm not seeing that, and at least two other users are also not able to do so.

Additionally, the adding of the gridOrigin support -- which this code seems to need rather desperately in order to be usable -- doesn't seem like it's going to be possible to get in in an appropriate time frame.

Because of these factors, my inclination is to not include this in 2.8: that it would be better to push it out, get some more testing and feedback, and do it 'right', than rush it in and have to change things later.

I don't know how tightly you are tied to releases, so we can discuss what that means -- 2.9 quickly, or something different -- after 2.8 is out, but at this point, I think that we simply can't commit to including this in 2.8.

I appreciate the work you've done, and look forward to continuing it with you after the current release cycle.

[mpriour]

I totally understand that this layer just is not ready for primetime without the changes to gridOrigin which you have proposed. I'm going to try to follow the grid layout logic and see if there is an easy solution to this. But I agree with you. At this point there are far to many ways to get it wrong and only a few to get it right. I've gotten right on private caches which I'm not allowed to share, but have yet to make it work on any publicly available cache.

[bartvde]

Bumping, only bugs and regressions for 2.9.

[mpriour]

I propose we just put this as "wont fix". There is a rapidly decreasing demand for this layer since the normal OpenLayers.Layer.XYZ layer works for all 9.3+ ArcGIS Server caches. This direct access using hex encoded row & column values was only in use for the 9.2 version of ArcGIS Server.

[bartvde]

@mpriour: so do you also suggest removing the direct access option from ticket:3030 ?

[mpriour]

No, I was not aware of the new patch for this feature that they had done in ticket:3030 . That patch works and is well tested. Also the direct access is still an option for people using 9.3+, it just uses a much nicer url format. Now that I've seen ticket:3030 I would mark this ticket as 'duplicate'.

[mpriour]

replaced by ticket:3030