Wednesday, January 21, 2009

Brief interlude: What the hell ESRI?

Listen this makes no sense:
  1. The documentation for your VE and GMap JS extensions - which appear to be roughly identical in function - have documentation that contains very different information. To figure out details on the VE.Geometry.ProjectToVEShapes method, I had to hunt down the similar function in the GMaps documentation.
  2. Stop pretending these are really REST functions. Be a little more clear about which JS functions are just SOAP requests you later make into JSON clientside. ProjectToVEShapes demands a proxy for larger requests, which means it is running into browser security features meant to prevent cross-domain scripting attacks (detailed a bit here). Oddly the demand for a proxy was only returned when I tried it in IE, in Firefox I had trouble finding it even with Firebug.
  3. The JS objects you return from ArcServer queries differ in format to the JS objects you require for functions in the aforementioned extensions. If I make an ArcServer Query for some feature class, the object it returns is not valid as an input to Project, for example.
These API extensions, and ArcServer itself, is pretty new. I can understand some of the documentation stuff, but could you be a little more consistant about the JSON formatting? Converting between the two is a bunch of unnecessary work. Am I wrong here? I'm pretty new to this, I could be missing a simple solution or not understand the problem.

2 comments:

James Fee said...

1. That isn't a documentation issue, but an "example" issue. The documentation for the function is there.

2. I would say that the need for a proxy has nothing to do with something being RESTful.

3. I've gone all WGS84 so I've not had to deal with projecting JSON output.

I suppose the simple solution is to just serve up WGS84 services.

Ben R said...

Hey, how did the guy who owns the first google hit for "gis blogs" manage to find my crummy website full of poorly informed ranting about ESRI's JS extensions?

1. True, but the example in this case is sorta everything. This is my first dive into this whole world, but "JSON-formatted geometries" as a string wasn't terribly descriptive. If they had one standard JSON geometry object I'd have no excuse, but they appear to have at least two slightly different ones and it tripped me up until I wandered around the Gmap documentation.

The error it tossed back wasn't particularly useful either.

2. Like so many, I am undoubtedly misusing that word. Corrected in post.

3. I'd like to, but it would involve abandoning a corporate standard data access webservice that was finished just before everything was made a little easier.

Actually doing so is sounding better all the time though. I'll try it next, thanks James!