Comments on: WebADF – Put up or shut up

By: Dano

Dano — Mon, 04 Feb 2008 13:48:30 +0000

I really appreciate the comments.

I am sure that this is solution dependent; however, my strategy in the past was to use ArcXML for basic map querying and navigation capabilities and then have a custom ArcObjects through Web Services solution for the occasions where I really needed something more capable.

Considering the license arrangement with the ADF and ArcObjects, this seems like a very similar situation and a similar solution would suffice. As ESRI is very reluctant to provide any information or examples on using the SOAP service directly, I would love it if anyone could point me to any available resources on this.

Dan

By: Neil

Neil — Mon, 04 Feb 2008 13:19:55 +0000

@Dano:
One reason to go with an ArcObjects based solution is that it allows you to access functionality that is not available through the coarse-grained SOAP API.

Neil

By: timmy

timmy — Sat, 02 Feb 2008 17:08:57 +0000

If I may be so boldâ€¦

At best Iâ€™m a hack when it comes to programming but I have come to understand and accept my own personal limitations and strategize accordingly. So many challenges can be boiled down to assessing the problem, assessing resources, and taking action. Iâ€™ve seen many brilliant and intelligent posts on this forum, and I applaud the efforts of those who are inclined to put time and energy against solutions. There is something to be said for the Do It Yourself approach, but I think it could be argued that if someone could DIPLOMATICALLY organize all of the folks who share these common desires into a common voice you might get them to go in a direction that best suites you. I agree with the frustrations that have been expressed, but like it or not I know that I do not have the fiscal or mental capital to achieve anything beyond what ESRI is sellingâ€¦. Why not generate the political critical mass thatâ€™s necessary to leverage ESRIâ€™s resources? Weâ€™ve seen many Corporate responses to this blog and that is not because of James Fee (although due credit should be given for his work in creating and sustaining this community) but because the Corporations recognize the width and breadth of the community behind James Fee. Soâ€¦ what if we kindly remind key people whoâ€™s paying the bills and make constructive suggestions on behalf of the community that would be in everyoneâ€™s best interest? What do you all think?

By: Rachel

Rachel — Sat, 02 Feb 2008 16:29:42 +0000

@Dano:
I know of alot of people who created their own solutions against the AGS SOAP api, by passing the web ADF altogether.
I heard rumor of a really good flash app written against the SOAP api by one of the ESRI distributors but can seem to google it down.

By: Dano

Dano — Sat, 02 Feb 2008 16:10:24 +0000

When considering the available options, and believe me I am, why not use the SOAP API instead of developing a license bound ArcObjects solution? It performs at least as well the ADF and the application can be placed anywhere with no license complications. The lack of documentation, examples, and support from ESRI in doing this aside, are there other reasons to bypass this option?

Also, the ArcIMS connectors were slow and quite limited compared to simply dealing with the ArcXML directly. Will the REST API have the same problems? I hate to think of waiting for it and then realizing that it is a huge performance hindrance or limited in some other hideous way.

I appreciate any thoughts on this â€“

Dan

By: Rachel

Rachel — Sat, 02 Feb 2008 14:40:05 +0000

Well here you go, ask and ye shall receive.

Podcast: ArcGIS Server REST API

Jeremy Bartley and Keyur Shah discuss the ArcGIS Server REST API session at the upcoming Developer Summit that will be held March 17-20 in Palm Springs, California. Developers can learn of the content and highlights of this session.

http://blogs.esri.com/Info/blogs/devsummit/archive/2008/02/01/podcast-arcgis-server-rest-api.aspx

By: CuriousGeorge

CuriousGeorge — Sat, 02 Feb 2008 06:02:35 +0000

I really don’t see anything here that is going to help anyone except maybe a few egos. Bottom line – ESRI is developing a REST API and simple JavaScript API’s for 9.3 AND the Web ADF is better, faster, and more powerful at 9.3. You should wait until the Dev Summit.

Last word on the street that I got was that you will be seeing/hearing about this pretty soon…

By: Matt Priour

Matt Priour — Sat, 02 Feb 2008 04:51:01 +0000

@Christopher
First, let me say that you deserve some kind of award for all the truly amazing work that you have donein developing these open source tools and others. I don’t have a problem with using TileServer or FeatureServer myself.
My issue is the comfort level of most Arc* developers with Python versus .Net as well as some of the difficulties some people have had in getting everything to work properly on IIS. I am not as interested in creating something like FeatureServer as I am in seeing a FeatureServer .Net port (with a few minor changes). I think this wouldl make it easier to deploy on Windows under IIS and provide an opportuiniy to plug into a lot of code that I’m sure is already out there.
I did not realize that the TMS interperter was that loose and flexible as to directly hanlde tile requests form VE and others. Since the ESRI MapCache is stored in a hexidecimal encoded TMS style file structure, it seems like it would be simple to hook up with TileCache as well. So maybe just getting the community to add a few more storage and layer type providers is all that is needed for TileCache to fullfill any needs that I had in mind. For example, storing the cached tilesin raster data catalogues or adding a provider for the AGS SOAP API, etc..
As for returning links to feature resources rather than the multiple feature results:
I do have this working and working well in the maps on REmapper.com. There are situations in which as many as 300 features are requested and returned, though you won’t see it in that sample map. And it is much, much faster than parsing a 300 member GeoJSON feature collection and creting VE shapes out of it. The key is that each resource is cached on client and server. I will blog more about my experience building these maps and the results I had with several different techniques soon.
I appreciate your comments and direction, they are always appreciated.

By: Christopher Schmidt

Christopher Schmidt — Fri, 01 Feb 2008 23:24:27 +0000

For the record, I don’t see much here that doesn’t fit directly into the frameworks already delivered by FeatureServer and TileCache. (There are some technical limitations in FeatureServer that would need to be overcome, but that’s relatively minimal.) I’m perfectly happy to work with the community to extend either TileCache or FeatureServer in a way that anyone thinks is neccesary to make this fit their needs.

I don’t think that a new implementation of FeatureServer-like behavior makes sense. It’s possible I’m wrong. If I’m wrong, I’d like to understand why; it’s possible that FeatureServer or TileCache don’t communicate their goals well enough to understand why they already do what you want.

For example, Matt says that the replacement for TileCache (or alternative, or improvement, or whatever) should support “Google style tile requests”. Now, TileCache already supports answering TMS requests that are in the same z/x/y space as Google Maps tiles: I’ve used TileCache to serve up to VE and Google Maps with minimal effort for several different projects with no problem. (Additionally, OSM uses these type of URLs, so that’s another case to take into account here.) With that in mind, I don’t see what specifically he’s looking for here.

Matt also mentions the idea of making query results be links to specific features instead of the features themselves. This is fine if you’re working with small datasets, I suppose — and it’s definitely more RESTful — but imagine a case where I’m building a client side app, and I want to display 200 features on the map. I have to send a single query to get a list, then another 200 queries to the server to get the actual data? that seems… not ideal.

I think that there is a lot to be said for cleaning up the lacking functionality in these existing open source technologies, and even more importantly, *adding documentation* about how they already do what you want to do. But the fact that you don’t know how to do it already doesn’t mean that it can’t be done.

By: Sean Gillies

Sean Gillies — Fri, 01 Feb 2008 21:43:37 +0000

James, remember the scene in “Kill Bill” where Beatrix Kiddo is trying to work chopsticks with utterly wrecked hands? Her Master, Pai Mei, absolutely insists that she eat like a human, not like a dog. He’d consider “REST API” equally low, I’m sure

You gotta love that movie.