Add ArcXML support

This is hard at the moment because I don't have a proxy that does post. Bumping until I make one. Current work is in crschmidt/arcxml sandbox.

arcxml first round patch. Allows the ability to connect to ArcIMS service without using the WMS connector

It's been a while since I've had a chance to make OL updates, so I thought I would provide some help with this ticket if still interested.

I used the arcxml sandbox from crschmidt as a starting point and put together a first round patch (attached above). I modified the OpenLayers.Tile.ArcXML so that it is essentially the same as Tile.Image except that instead of calling Layer.getURL to get the image url, it gets the ArcXML string from the layer. It then uses this ArcXML to make an AJAX call and get the response to the tile image. One thought is that we could just add a couple new methods to OpenLayers.Tile.Image class that allows the image to be retrieved via ArcXML if desired. Just looking at alternatives to duplicating much code.

In addition to the Tile class, I added a new layer (OpenLayers.Layer.ArcXML) which is responsible for generating the ArcXML for the request. Right now you can specify the root URL with ArcIMS Service, a comma separated layer list, and both the featurecoordsys and filtercoordsys of the layer to be returned as. You can also specify the image type to be returned as "jpg", "gif", "png" or "png8".

This is still a first round patch for ArcXML support without the WMS connector. NOTE: In order to get this to work, you need to make sure you have patch.cgi working properly on your host (located within /examples/patch.cgi folder). Please see FAQ for help setting up. If on a Windows machine, I needed to point the top of proxy.cgi to:

#C:/Python25/python.exe

INSTEAD OF

#!/usr/bin/env python

Just make sure your Apache/CGI/proxy.cgi are configured properly.

TODO: We might want to look at allowing the ability to specify different rendering for the layers. Could give the option to allow users to add custom ArcXML for each LAYERDEF to allow the user to override the base ArcXML file rendering. Also, may want to break up the URL so that you just specify the root domain, then we append the servlet/com.esri.esrimap.Esrimap with the service name as well.

We implemented an OpenLayers.Layers.ArcIMS layer, with a corresponding OpenLayers.Format.ArcXML format. The ArcIMS layer uses the ArcXML format to make any requests to/from the ArcIMS server. It also has a method getUrlAsync, which will get the image via ajax, since ArcIMS takes a POST request to generate an image, then you need to GET the url afterwards. I modified OpenLayers.Tile.Image to be able to make sync/async requests, depending on the async property of the layer.

The ArcXML format implements a subset of the full ArcXML specification. It can handle basic image generation and layer switching, layer queries and spatial queries, dynamic rendering, and GET_FEATURE requests.

I started this work off the WMS layer, and not the ArcIMS sandbox.

Changing release for ArcXML out of future, into next release, 2.8 as per crshmidt's recommendation.

Commented all changes to classes, set up examples to use permanent map service.

Updated documentation, added comments in the patch, updated references in examples to point to a permanent ArcIMS mapping service.

This patch adds Layer.ArcIMS and Format.ArcXML, in addition to tests for both classes. Two examples are included, one that shows basic usage of the ArcIMS layer, and a second that shows advanced thematic mapping with queries and renderers.

This patch also includes modifications to Tile.Image. A change to Tile.Image is necessary to support asynchronous image tile requests from the ArcIMS layer. This is due to the way that ArcIMS generates images: an xml request to the server, with an xml response containing a URL to the image generated. In order to make the ArcIMS layer perform well, these requests have to be performed asynchronously. It is possible to use the ArcIMS layer synchronously, but dragging, zooming, and other map operations become jerky and clumsy in this mode.

Added a format, ArcXML.Features. This takes an ArcXML response, and reads the features out of that response.

Okay. way later than it should have been, but here's my reworked patch. Some changes:

• Drop the "NS" variant on most getElementBy and get/set Attr calls. They don't end up being neccesary, and this means we can use the 'native' IE stuff, which is likely to be significantly faster in some cases.
• Change the way read works: instead of parseResponse creating a new Format.ArcXML, just create a Format.ArcXML.Response; this response is what is returned from read now. Updated the layer and tests to match.
• Some coding style cleanups in addition.

zwarg, I've done some testing, and run your unit tests, and all appears to be well. If you were using .read() directly before, you'll have to change your code from using result.response.foo to result.foo directly, but that shouldn't be too difficult. can you give it a shot, and tell me how badly I broke it?

Thanks, Chris

Updated patch 2 with getFeatureInfo fix for new read() behavior

A few minor changes in the latest patch - made while trying to figure out why tests weren't passing in IE:

• a number of style tweaks to get this closer to our CodingStandards - mainly braces around one line blocks
• added semicolons at the end of a few lines
• removed concatChildren in favor of using XML method (was concatChildValues is getChildValues)
• removed trailing commas in object literals in tests (this turned out to be the only problem)

Next I'll see why the error isn't what is expected in the test_Format_ArcXML_parseerror test.

Ok, the following code was the issue (in ArcXML read):

    if(typeof data == "string") {  
        data = OpenLayers.Format.XML.prototype.read.apply(this, [data]); 
    } 

    var arcNode = null; 
    if (data.documentElement.nodeName == "ARCXML" ) { 
        arcNode = data.documentElement 
    } else { 
        arcNode = data.documentElement.getElementsByTagName("ARCXML")[0]; 
    } 

    if (!arcNode) { 
            throw { 
                message: "Error parsing the ArcXML request",  
                error: data.firstChild.firstChild.nodeValue, 
                source: data.firstChild.childNodes[1].firstChild.nodeValue 
            }; 
    } 

Ways that you won't get the exception you expect:

• data or data.documentElement undefined
• data.firstChild or data.firstChild.firstChild undefined
• data.firstChild.childNodes.length < 2 or data.firstChild.childNodes[1].firstChild undefined

Cool. All passing now. Now I look forward to actually checking out the code :)

add ArcIMS support

Changes to the ArcIMS layer (let me know if there is something I overlooked in making these changes):

• replace OpenLayers.Layer.Grid.prototype.getFullRequestString.apply( this, [{},''] ) with this.getFullRequestString() (and similar)
• got rid of Ajax.js dependency by using OpenLayers.Request.POST instead of OpenLayers.Ajax.Request
• getURL and getURL shared code based on arcxml.image.output, this is now in a method called getUrlOrImage
• changed comments about "create a synchronous ajax request to get an arcims image" to "create an asynchronous ajax request to get an arcims image" where async was true (if you want synchronous here, set false)
  • created ndocs for all properties in DEFAULT_OPTIONS - these all become properties of the layer and deserve some docs. It's a bit weird that the layer options property is used differently than with other layers - specifically that it is extended and sent to the format as the format's options arg. This means you won't get expected results with layer.clone. A better solution would be to carry around a formatOptions object if you needed one, but I'm not going to mess with this now.
  • other minor tweaks

This is really cool! Thanks for all the work in putting this together. I think this makes a terrific addition to 2.8.

I imagine we'll want to increase test coverage and show off some more stuff in examples at some point, but I know it has been a lot of work just getting to this point.

Let me know if any of the above mentioned changes are misinformed. Otherwise, please commit. I'm excited to let people know that we've got ArcIMS support in OL.

(In [9249]) Add support for ArcIMS/ArcXML to OpenLayers.

Thanks for the killer effort from David Zwarg from Avencia in building this, and for Tim Schaub from OpenGeo for his excellent review. r=me,tschaub (Closes #213)