 |
 |
NEARC-L, I'm working in an environment that includes a custom web app that uses a variety of ArcGIS for Server map services, and I'd like your help in explaining some behavior that I don't understand. I'll preface the information below by stating that I'm not a web developer, and this app isn't my area of responsibility. But, the app's behavior manifests some back-end issues that are in my AOR, so I'm trying to understand the larger environment in hopes of diagnosing the server-side problems. The takeaway is: If anything I say below seems incorrect, you're probably right and I'm probably wrong, so please correct me or ask a follow-up question. The salient contextual points are: * From what I understand, the app interacts with ArcGIS for Server using the ArcGIS API for JavaScript. I don't know what version of the API it's using, but the app was built within the past two years, if that's any indication. * The map services are provided by a cluster of ArcGIS for Server 10.3.1 instances. * From watching the network traffic using Chrome Developer Tools (CDT), the app appears to ask for data in one of two ways: o As a map image resource in PNG format, via the Export Map operation, or; o As a feature set in JSON format, via the Query operation Per this last point, I don't know what this implies is happening at the JavaScript API level, but those are the underlying REST API requests that I see in CDT. The interesting part is: * For any one pan/zoom action on the end user's part: o There is a single Export Map request for a PNG that covers the whole map extent, but; o There are multiple Query requests for the feature sets, each of which covers only a portion of the map extent The following screenshot illustrates this behavior: [cid:[log in to unmask]] The number of Query requests varies. In the screenshot above, there are 12. I usually see 9, but sometimes 4, 6, or 8. This happens at all scales (that I've noticed, in my unscientific poking-and-prodding). If I extract the extent of each one of those Query requests from their respective URLs and draw them as graphics in ArcMap, I see a pattern that looks like the screenshot below. Note that the screenshot below (9 requests) doesn't go with the screenshot above (12 requests), but it illustrates the general behavior: [cid:[log in to unmask]] In this map, each of the 9 boxes represents the extent of one Query operation. The requests are sent in order like you're reading a book (left-to-right, top-to-bottom). My actual map extent fell within, and was slightly smaller than, the area covered by these requests. The lead app developer confirmed that they aren't explicitly querying data in this "tiled" pattern; rather, that the multi-request / tiled behavior is built in to the JavaScript API. My questions are: 1. Is it correct that the ArcGIS API for JavaScript allows the developer to make a single, spatially-filtered request for a feature set, and generates from that multiple REST API requests covering the area-of-interest? 2. If so, why? (Stated another way, why not just make one REST API request, like with PNG files?) Beyond simple curiosity, there is a practical consequence of this behavior - some of the Query requests either 1) take a long time, or 2) fail. (That's the server-side issue I'm investigating.) The impact on the end user is that the first row of "tiles" may display data immediately, while the second row could take 30 seconds, and the third row might fail to return data at all. There are no "still working" or "error" type messages in the UI (an app issue, or an API issue?), so the user may think that data only exists in the northernmost part of the map extent and draw the wrong conclusion. If you have any insight into this behavior that you're willing to share, I'd be much obliged. Thank you, in advance. -Michael Michael Mannion Database Consultant | Mannion Geosystems | +1 617.939.9958 | http://www.manniongeo.com<http://www.manniongeo.com/> ------------------------------------------------------------------------- This list (NEARC-L) is an unmoderated discussion list for all NEARC Users. If you no longer wish to receive e-mail from this list, you can remove yourself by going to http://s.uconn.edu/nearcsubscribe.