This question comes up almost every day. If you ask me I’ll tell you the same thing every time, use the ESRI REST API with OpenLayers. Picking an ESRI ArcGIS Server API always makes me think of a good movie:
About
James Fee - jfee@weogeo.com
James works for WeoGeo helping people organize, share and monetize their geo-content.
Connect
Subscribe
17 Comments
Some questions are better left unasked.
http://www.youtube.com/watch?v=cYfjq3ZYZbA
“There are two kinds of people in this world my friend, those with guns and those that dig. Now dig…”
@Archie Belaney.
Should that not be Arch Stanton
Would you still choose REST API if web editing functionality is required?
Since editing requires the Web ADF, I’ll work around it. Plus I’m of the mind that editing via web is never a good thing.
Even for simple editing? I take your point but given the cost of ArcGIS desktop, web editing must be an option.
What about using an OpenLayers web client application to edit data in arcgis server/sde using the OGC WFS-T protocol?
Theoretically, if you stick to really simple features, esri claims their implementation of WFS-T for arcgis server finally really works now. I haven’t had occasion to try it yet, so I can’t confirm anything from personal experience. Maybe someone else can comment on how successful their technical experience with it has been…
If you have ArcGIS server standard though, it’s unlikely that you don’t have desktop licenses. An ArcView license can do simple edits and doesn’t have to stay on maintenance to do it. (and what is the cost of development versus the cost of an ArcView license?)
Looks like Google is taking a don’t-let-the-perfect-be-the-enemy-of-the-good approach with 3D web based editing via Building Maker. I found it a bit difficult to use, but that’s just me. If that editor gains traction I’ll really feel dumb.
You say it’s never a good thing but it’s upon us. I have folks sending me kml and kmz files showing me “where it’s at” after drawing something in GE.
Redlining isn’t editing.
James, I’m curious as to why you think editing via web in never a good thing. Would you oblige me with a few of your thoughts? Thanks!
So explain to me how you can develop tools that are going to keep your data accurate? Web UIs are sloppy and don’t give you the fine grained control you need. Redlining maps for editing later is best (sort of what Google is doing with their “report a problem” on a map. If you’ve gone to the trouble of sub-foot GPS, why would you allow web users to convert that into sub-meter (or worse)?
From my experience, there’s no reason why you can’t do very accurate editing in a web application so long as the features are not multi-part, there are no holes, the polylines and polygons are all simple line segments (no arcs), and the features are not massive. You can get around these caveats as well but, at that point, the UI is sufficiently complex as to call into question why the users aren’t just using ArcMap.
Editing via the web is bad? There is a lot more GIS data out there than sub-foot survey data James. Let me guess, 640k is enough for anyone right?
Give me a break.
The API’s are all great for certain things. This question is not going away however since the JavaScript, SilverLight, and Flex control suites are inherently dependent on a single underlying API (REST). This makes it unbelievably easy to do what the underlying API can handle but extraordinarily difficult to leverage the other APIs. The reality is that no one API is best for everything. If you just want to pull a map tile, REST is typically the easiest. If you need to access Z or M values or access any of the power of ArcObjects, REST is no help to you. If you need to be “REST-full” the ADF is of no help to you. If forced to pick one of the three, I’d go with SOAP but I have not been able to obtain optimal results by leveraging just one API for awhile now.
Can anybody explain to me what REST and SOAP is and the difference between them? Appreciate!
The very short answer is that SOAP is an XML communication format that ESRI supports for communicating with ArcGIS Server through HTTP connections. The REST api is much simpler in that it allows clients send create requests to ArcGIS Server that are wholly encapsulated in an HTTP URL. Under the hood, REST requests are (at least for now) just serviced through the SOAP api. As you can probably imagine, REST is much easier/quicker to develop against and has thus become the API upon which the 9.3 JavaScript, Flex, and Silverlight map controls are built upon.