Why does PrintWidget create Web_Map_as_JSON with explicit geometries for FeatureLayer features?

1847
13
Jump to solution
08-22-2017 12:43 PM
JustinRussell
New Contributor

I'll apologize upfront for the cross post - this has also been asked here. If cross posting is frowned upon I'll be happy to take this down.

I'm using a print widget to get exports of a map view. My view has a number of layers, one of them is a feature layer (in this case, showing US ZIP codes). When I look at the ExportWebMap specification it looks like the syntax for feature layers, I should be able to simply provide object IDs for the features that ought to be displayed in the export. However, when I look at the JSON that's sent to the export service's execute task I see that my feature layer was instead treated as a collection of client side graphics - with full geometries listed instead of object IDs.

Aside from being slow this also causes the export operation to crash when my request payload gets too large.

Any insight as to why my FeatureLayer features might be getting serialized as client side graphics?

I'm using version 4.4 of the ArcGIS API for JavaScript.

0 Kudos
1 Solution

Accepted Solutions
RobertScheitlin__GISP
MVP Emeritus

Justin,

   This is the expected behavior and has been for a long time (even in the 3.x API).

View solution in original post

0 Kudos
13 Replies
RobertScheitlin__GISP
MVP Emeritus

Justin,

   This is the expected behavior and has been for a long time (even in the 3.x API).

0 Kudos
JustinRussell
New Contributor

Thanks, Robert. To be perfectly honest, this is my first time using the print widget. Can you point to where this specific behavior is documented? I didn't seem to come across that mentioned anywhere. I don't doubt that I'm seeing intended behavior, but it does seem like a sub-optimal (though arguably more generic) use of the API so I'm wondering if there are hooks for either intercepting the built JSON or otherwise configuring what get's sent to the server. In my case I may need to find a workaround or else effectively rebuild the print widget from scratch...

0 Kudos
RobertScheitlin__GISP
MVP Emeritus

Justin,


  As William most JS API internals there is no specific documentation on this. For those of use that have used the API for years now we are just familiar with this. You can as some have alter the json before it is sent using esriRequest.

0 Kudos
JustinRussell
New Contributor

Hi, Robert. I'm sorry, would you mind elaborating on that last comment? I see esriRequest but it looks like an AJAX helper utility. Is there a way to intercept requests made by the framework with this? Or are you suggesting I just redefine "esri/request".

0 Kudos
JustinRussell
New Contributor

It sounds like this is technically the correct answer for the question as asked. Though many thanks for TSolow-esristaff for super helpful info on getting me around the issue.

0 Kudos
JustinRussell
New Contributor

Incidentally, I followed up with an Esri rep and confirmed this is the expected behavior.

0 Kudos
ThomasSolow
Occasional Contributor III

My feeling is that the features are going to have to make their way to the print service one way or another in order to be converted to an image. Whether this is done by your client sending whatever feature data it has currently or the service making separate requests to the feature service based on the oids passed in, the result is going to be more or less the same.

It's surprising to me that this is causing issues.  Are the features that get passed in filtered by the extent of the view?  How many features are we talking about here?

0 Kudos
JustinRussell
New Contributor

Hi Thomas, thanks for the response! It's a fair point about features needing to make their way to the print service either way. That said, coming from the client we're potentially talking about a lot to send over the wire. We also have much less control over network speeds, etc. I feel like you could support better (or just different) feature resolution with those geometries getting expanded on the server as opposed to just using what's on the client. But you're absolutely right, it's gotta happen somewhere.

It looks like I'm *mostly* seeing things being filtered by view extent with a bit of a buffer. This makes sense, depending on the dimensions of the export image vs the client side view you might need more or fewer features than reside within your view extent.

I copied the error from ArcServer logs below. The Web Map as JSON param is definitely present when the request leaves my browser. It could be getting truncated somewhere along the way - I'll need to do some digging there.

Error executing tool. Export Web Map Task : ERROR 000735: Web Map as JSON: Value is required The value is empty. The value is empty. ERROR 000735: Web Map as JSON: Value is required

0 Kudos
JustinRussell
New Contributor

FYI I'm seeing request payloads of about ~20MB. This thread (Export Web Map Task - JSON length limit?) led me to check my own server configs and indeed I'm at the default of 10MB as a cap for POST sizes. I checked the other components of my stack and as far as I can see this is the only place I could be hitting a size limit.

Hopefully that provides a short term fix but figuring out how to bring this down to a reasonable number could still be interesting.

0 Kudos