POST
|
Oh I see, ok so the whole map is already subdivided in tiles, and after a zoom/pan event there instead of making 1 request to get all the features in the extent, the api makes 1 request for each tile visible in the current extent, and each request specifies the row/column for this tile. Thanks for the info, I thought they were all the same requests but clearly they are not. Long story short, 2 months ago our map services were "attacked" severely by script bots to try and get our data in bulk (which we do not allow). To prevent this we put in place the resource-proxy and disabled direct access through the previous URLs. One of the parameters of the proxy is "rate limiting", meaning if the user makes more then X requests in Y time, then the proxy rejects the request with a 429 Too Many requests response. So, if Snapping is enabled and the API suddenly makes all those requests, I had difficulty figuring out a good value for this "rate limiting" parameter. When snapping was enabled we reached the limit very quickly. In the end we decided to just disable Snapping for our public access mode, so we worked around the issue this way. Thanks
... View more
06-16-2017
08:40 AM
|
0
|
0
|
446
|
POST
|
The proxy returns the following json content: { error: { code: 429, details: [ "This is a metered resource, number of requests have exceeded the rate limit interval." ], message: "Error 429 - Too Many Requests" } } The ArcGIS JavaScript API does trigger the error callback of the queryTask, but I cannot find this json content anywhere in the error object returned. Ok yeah, perhaps this error format is just not compatible with what the API expects. I'll verify this with resource-proxy. Thanks Thomas.
... View more
05-15-2017
01:24 PM
|
0
|
0
|
1274
|
POST
|
Hi, Following some script bot data mining abuse of our map services recently, we now use a proxy to throttle requests to our map services. We are using the Java version of the resource-proxy. It works fine so far, all ArcGIS requests now go through the proxy and we enabled a few security features in the proxy configuration including rate limiting (throttling). I modified the proxy so that only "query" requests are throttled. This way the map rendering is not affected for actual human users and it protects us against data mining by scripts. When a query request is rejected because of throttling, the response has HTTP status code 429 (too many requests). In rare cases where a human user exceeds the number of allowed requests set by the proxy, I was wondering if it's possible (using the error handler of the queryTask in the ArcGIS API) to know the status code of the query failure. For instance if it's 429 I would display a different message to the human user in our GUI. I parsed through the error object returned by the error handler of QueryTask, but I haven't found anything so far. Many thanks, Yohan
... View more
05-15-2017
11:02 AM
|
0
|
2
|
2248
|
POST
|
I enabled snapping on the Map and I'm using a couple of FeatureLayers with MODE_ONDEMAND with it so that it can fetch all the required geometry from the MapServer required for snapping to lines in the map. It works fine, but I noticed that for each pan or zoom operation in the map, the API triggers a total of 3 to 6 identical queries to the map server to get the FeatureLayer geometry. A zoom operation always triggers 12 queries (6 per FeatureLayer). They are all identical queries except a small difference in the xmin and xmax of the geometry used for the spatial intersection in the query. I'm assuming the map generates a bunch of extent-change events when zooming and that the SnappingManager accepts them all and makes a query to get the FeatureLayer geometries for each of them. (We have over 215 clients/map services so this is pretty wasteful. Especially since we plan to throttle the map services using a resource-proxy in the near future. All these queries will make it harder to configure the proxy properly.) Is there a way to maybe throttle the extent-change events the map generates? Thanks for the help, I attached a screenshot of all the queries it generates for a single zoom in the map. EDIT: I'm not using MODE_SNAPSHOT with the FeatureLayer because it would then be limited to 1000 features as set by the map service config and 1000 is not enough is some situations. Yohan
... View more
05-08-2017
09:42 AM
|
0
|
2
|
919
|
POST
|
Awesome thanks, I can finally use this properly format code. I just edited my answer with this formatting, and replaced the original code with the better code version I was talking about too.
... View more
03-08-2017
10:47 AM
|
0
|
0
|
253
|
POST
|
No, each client is assigned a specific server. But I'm not convinced ArcGIS Server is to blame for the lags here, I didn't mean to imply it was. If I had to take a guess I'd say the problem probably lies with a bad Apache web server configuration. All requests go through Apache before being redirected to 1 of the 9 servers. I've seen lags with other requests too, sometimes simple html files, for instance. It's like sometimes connections are hanging. However I still think it's bad practice for the measurement widget to assume the geometry service will respond before the user has time to add another point. It shouldn't rely on that.
... View more
03-08-2017
05:35 AM
|
0
|
0
|
694
|
POST
|
Yes I have esriConfig.defaults.geometryService = new GeometryService(this.config.geometryService.url); We actually have 9 servers (each with a geometry service) spread over 30 clients, each with 1 to 10 map services. We've always had some minor lag issues at peak usage times (e.g. 9am, 2pm), sometimes by chance 2-3 users will make a bunch of requests at the same time. However usually it doesn't create bugs, it just takes longer to get the response.
... View more
03-07-2017
02:36 PM
|
0
|
2
|
694
|
POST
|
For now I implemented this, I hate it but it's the best I've got so far. Basically if I receive a bunch of measure-end events together, I count them up but call the handlers with a 750ms delay. Then I can check if I have more then one and act accordingly if that is the case. I'm sure it's not full proof, but I tested it in the worst navigator for this issue (i.e. Internet Explorer) and it seems to do the job to work around this. this.esriMeasurement.on('measure-end', lang.hitch(this, function(event){
this.measureEndCount++;
setTimeout(lang.hitch(this, function(){
this.measureEndCount > 1 ? this.onMeasureEvent(event) : this.onMeasureEndEvent(event);
this.measureEndCount--;
}), 750);
}));
... View more
03-07-2017
01:42 PM
|
0
|
4
|
694
|
POST
|
When using the area measuring tool, for each point you add (starting from the third point) the widget starts making areasAndLength requests to the geometry service to find the surface area of the current polygon. After receiving the surface from areasAndLength, the widget sends a "measure" event each time (except the last time where it sends you a "measure-end" event if you double-clicked instead of clicked). The problem is that if for some reason the areasAndLength requests are pending and take a while to return, it doesn't stop you from adding points and even double-clicking to add the last point. Then when the areasAndLength requests finally return, instead of sending the "measure" events and one final "measure-end" event, the widget sends a bunch of "measure-end" events. This is problematic because I have specific/different code in my "measure" and "measure-end" event handlers. If all goes well it works fine, but intermittently if there's a lag with the geometry service then the wrong handler will be called multiple times, creating a bug in my application. I can't figure out a way to work around this at the moment. I can't just ignore the extra "measure-end" events, I really need to call my regular "measure" event handler for each point, but the thing is when I receive the first "measure-end" event, I have no idea that more might follow because of this issue. Otherwise I would just redirect it to my "measure" handler instead. I'm wondering if anyone else has this problem and how they deal with it. Thanks
... View more
03-07-2017
12:22 PM
|
0
|
5
|
1335
|
POST
|
Thanks Ken, yeah I'll definitely make a few adjustments. Would be cleaner to just build a list of group layers once, and then use that list as a parameter to array.filter the list of visibleLayers to display. Now that I was able to hotfix this issue quickly, I'll be able to polish it a little. Kind of an unrelated question but how the heck did you format your code in geonet? The code tool does nothing for me, seems broken. Maybe it just doesn't work with Chrome I'm not sure. What browser are you using?
... View more
03-07-2017
06:31 AM
|
0
|
2
|
253
|
POST
|
I did and as predicted the group layers I removed became unchecked in the layers widget. It's alright though, I ended up just unbinding the widget from the ArcGISDynamicMapServiceLayer and give it the list of visibleLayers myself, manually. Not as bad as I thought. As for the ArcGISDynamicMapServiceLayer, whenever I need to set the visibleLayers I call this function to remove the group layers. For anyone interested: initGroupLayers: function(){
this.groupLayers = [];
array.forEach(this.dynamicMapServiceLayer.layerInfos, lang.hitch(this, function(layerInfo){
if (layerInfo.subLayerIds){
this.groupLayers.push(layerInfo.id);
}
}));
}
_setVisibleLayers: function (params) {
// Filter out any group layer from the list of visibleLayers
var filteredLayers = array.filter(params.visibleLayers, lang.hitch(this, function(layer){
return this.groupLayers.indexOf(layer) === -1;
}));
// Update using the filtered list
this.dynamicMapServiceLayer.setVisibleLayers(filteredLayers);
} The initGroupLayers function is called once in the "load" event handler of the dynamicMapServiceLayer
... View more
03-06-2017
01:19 PM
|
0
|
4
|
1697
|
POST
|
Hi Robert, Thanks for the confirmation. I realise I could just remove the group layer ids for the visibleLayers but that will break the layers widget, which is binded to the list of visibleLayers. If there is no other way I'll try and figure something out but it will really complexify my code. I really wish this was optional through the API, I mean the exclude parameter of the export request is right there, it's available, why not use it..
... View more
03-06-2017
09:58 AM
|
0
|
6
|
1697
|
POST
|
Pretty sure yes. Well the response is just an image but I can see the top child layer 257 is rendered, since it's on top of the other child layers. What I want rendered is only the old 1950 ortho layer: but instead it renders the newest one, here is the response in Chrome: Also this was just an example, I have seen similar results with all the other layers in the service. For instance we have an infrastructure group including stuff like man holes, fire hydrants, etc.. if I check a single child layer in the group, ArcGIS Server will render all the child layers (all the infrastructure layers) in the image. I'm not using LayerDrawingOptions anywhere in my code, no. Are you saying that this is not normal? Should the normal behavior of ArcGIS Server be to render ONLY the layers included in the layers parameter of the export request? I can't find any doc that says so specifically. Thanks
... View more
03-06-2017
07:18 AM
|
0
|
10
|
1697
|
POST
|
I have an issue where the image render returned by the MapServer does not seem to correspond to the list of visibleLayers specified in the ArcGISDynamicMapServiceLayer. It seems all child layers of a group layer are rendered, whether they are included in the list of visibleLayers or not. ArcGIS API for JavaScript 3.19 ArcGIS Server 10.3.1 Here is an example of a group layer 256 with child layers 257 to 270 Using a layers widget binded to the list of visibleLayers of the ArcGISDynamicMapServiceLayer, if I check one of the child layer, this is export request sent by the API: You can see that only 256 and 270 are included in the layers parameter of the export request, yet the MapServer will render ALL sublayers 257 to 270. Is this the default behaviour of the MapServer?? If so, how do I work around this? I'm thinking maybe I could manually remove group layers in the list of visibleLayers of the ArcGISDynamicMapServiceLayer, but that could create issues with the layers widget, where the group layer would be unchecked too (since it's binded to it), which is not what we want. I see the export request (Export Map (Operation) ) layers parameter also include an "exclude" option. Is there a way I could exclude all unchecked layers using a setting or option in the ArcGIS JavaScript API? Otherwise how would I do this? Thanks EDIT: Here is a more obvious example with an infrastructure group layer: Only child layer 168 is included in the list But it renders them all:
... View more
03-06-2017
06:41 AM
|
0
|
12
|
3166
|
POST
|
Neat widget. I really appreciate you testing this on your side and confirming this. It's harder to see on your pale basemap, but yeah if I test it on a darker patch (for better contrast) I could clearly see you have the same issue at steeper angles. So at least now I know it's not something related to my code and there's probably not much I can do. I did notice it seems to happen more frequently at steep angles, but not all the time, and I can't see a specific pattern. I think that In the end if it's really a Chrome bug and there's nothing I can do I'll probably just increase the halo size by 1. I'll still have some thinner halos when the bug happens, but at least I won't have text with no halos at all. But if I do find some fix or workaround I'll let you know. Thanks
... View more
01-12-2017
02:28 PM
|
0
|
1
|
1061
|
Title | Kudos | Posted |
---|---|---|
1 | 08-11-2023 10:17 AM | |
1 | 12-10-2013 05:28 AM | |
1 | 11-07-2017 07:56 AM | |
2 | 05-04-2015 10:19 AM | |
2 | 05-04-2015 09:21 AM |
Online Status |
Offline
|
Date Last Visited |
08-11-2023
08:53 PM
|