Take the 2-minute tour ×
Geographic Information Systems Stack Exchange is a question and answer site for cartographers, geographers and GIS professionals. It's 100% free, no registration required.

A typical limitation of web based processing is that urls are limited to 2 thousand characters for a GET request. From my understanding of how the ESRI Javascript API works, JSONP is utilized to interact with ArcGIS Server Geoprocessing services via the REST API, requiring the use of a GET request?

This seems to pose a problem if I'm attempting to send large quantities of user defined runtime data (> 100 coordinate pairs and several other user parameter strings) to be worked upon in a geoprocessing service via the standard ESRI Javascript API.

What's the best way to tackle this problem?

I'm thinking about writing a proxy service that will receive GET requests, but will issue POST requests to the REST API.

share|improve this question
add comment

3 Answers 3

I'm not sure, there might be a way to POST to a GP service, but I chose this approach instead:

Write a standard WCF REST site using the online project template. Modify the site to allow you to POST large objects (as json) where other sites can see them as a resource (with a URL). (I just saved json streams to files.)

When calling the GP service, pass the URL as an argument. The gp service GETs the object from the WCF site referenced by the URL, and DELETEs it upon successful completion.

While it does make things a bit more complicated for the client, it simplifies debugging. By refactoring my GP tool, I can pass a url to it and step through it with the debugger. Also having a history of job inputs that I can review is helpful.

Update:

Also, I forgot to mention, if your WCF Rest service is on the same machine as your GP service, you can have the WCF svc return the filepath of the resource, then the client can pass that to the GP service. That way the gp service doesn't need to retrieve the job input from the WCF service - it can just open the file directly.

share|improve this answer
add comment

My current flag-ship app has us actually going a slight different way. I have my users to submit to me a file (csv is the easiest) that I import into a SQL staging table; then I pass that table name to my Rest Services as a variable where I do the processing.

I have users sending me files that are over 35K points with additional attributes that are used further down the process.

Your thought process you have there may be the best for your solution, having your own service that can accept the larger dataset, then que up batches to go to the REST service and responds back to yours where you aggrigate those responses and then send the total response back to the user.

share|improve this answer
1  
Interesting have you thought about automating the process. We use FME Server to get users to upload the file - it is validated if fails user is informed - if passes goes to a GIS intermediate table, oracle processes geometry then when done is inserted into the MasterDB. –  Mapperz May 27 '11 at 16:48
    
@Mapperz: Yes, actually FME plays a big part in this project, since I take data in various formats we read it into a SQL2008(geometry) staging DB, then based on the format of data will pass to FME services for loading into the production system; or will pass to ESRI/Rest services to Geocode through 1 of 7 different geocoders to build a point; then once the points are matched; then passed to FME again to load into the normalized datawarhouse for even more edits and visualization. –  D.E.Wright May 27 '11 at 16:51
    
@Mapperz: We actually use a piece of software JAMS that manages the events we process through. We have a series of master webservices to read in a variety of spatial formats or even excel; then talking to JAMS que up the right sequence of events to build the data through the entire process. Very smooth; tight integration between ASP.Net/JSAPI/Dojo UI, WCF/ASMX webservices going to REST and FME services. –  D.E.Wright May 27 '11 at 16:56
add comment

Yes, the JavaScript API by default use GET, which most browsers limit to about 2K.

I think the best way to tackle this problem is what you suggested yourself (for larger requests, use a proxy page). This is documented in the Resource Center for the ArcGIS API for JavaScript, which also include example proxy pages in multiple languages. http://help.arcgis.com/en/webapi/javascript/arcgis/help/jshelp_start.htm#jshelp/ags_proxy.htm (Using the proxy page)

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.