topic Re: Snapping performance issue in version 4.19 in ArcGIS JavaScript Maps SDK Questions

Snapping performance issue in version 4.19

ljnio — Thu, 29 Apr 2021 04:24:56 GMT

Hi all,

I had a go with the new snapping tool rolled out with version 4.19, but found although the self snapping works well, the performance is really bad when I try to snap to other feature layers.

I've tried a feature layer (something like this: https://stg-gis.mapshare.vic.gov.au/arcgis/rest/services/mapshare/PropertyAndParcel/MapServer/5), and a geojson layer (simple 4 points rectangle), but none of them works well.

The browser I used is Chrome. Once I move my cursor close to the snapping point, the screen will freeze for at least 20 seconds. I even got unresponsive page warning from Chrome.

Any ideas in terms of why this could happen?

Thanks,

Johnny

Re: Snapping performance issue in version 4.19

Anonymous User — Thu, 29 Apr 2021 23:32:44 GMT

Hello,

Glad to hear that you having been testing out the new 2D snapping in version 4.19. I tested the layer you provided, and I see it has over 3 million polygons. I am seeing some of the issues you described, however, once I wait for the errors to show up in the console, the feature snapping works fine. If I try beforehand, feature snapping does not work as you mentioned.

Thank you for bringing this up, we will be looking into this, and I will provide you with an update.

Would you be able to provide us with the geojson layer of the 4 polygons as well? Do these polygons have large numbers of vertices?

Thanks,

Jose

Re: Snapping performance issue in version 4.19

ljnio — Mon, 03 May 2021 05:12:01 GMT

Hi Jose,

Thanks for the update. Here's the polygon I used:

{

"type": "FeatureCollection",

"features": [

{

"type": "Feature",

"properties": {},

"geometry": {

"type": "Polygon",

"coordinates": [

[

144.96160626411438,

-37.810326435534755

[

144.96244311332703,

-37.810326435534755

[

144.96244311332703,

-37.80976700036787

[

144.96160626411438,

-37.80976700036787

[

144.96160626411438,

-37.810326435534755

]

}

]

}

Basically, I just added it as a geojson layer, but still getting quite a bit of lag when snapping.

I'm using React and Redux in the front-end. Not sure if this could be an issue.

btw, this is also the first time we tried to use the ES modules: @arcgis/core. Previously, we've been using the webpack plugin. Not sure if this impacts our performance.

Thanks,

Johnny

Re: Snapping performance issue in version 4.19

Anonymous User — Mon, 03 May 2021 14:49:45 GMT

Hi Jonny,

Thanks for providing the geojson geometry! We will be looking into this as well. To give you an update, I created an issue internally with our team, and we are looking into this.

We did test snapping with @arcgis/core in React prior to the release, so I'm curious to see why this geometry may impact the feature snapping. We will be looking into this as well.

Thank you for bringing up this issue to us!

Thanks,
Jose

Re: Snapping performance issue in version 4.19

Anonymous User — Mon, 03 May 2021 19:45:21 GMT

Jonny,

I just tested the GeoJSON polygon you provided, and it seems to work with feature snapping pretty well. I tested both with a JavaScript application, and with a React application using @arcgis/core. Both are using version 4.19. The following is the JavaScript application used for testing (same code was used for React test). All you have to do is pass in your GeoJSON url for the GeoJSONLayer.
https://codepen.io/banuelosj/pen/abpeMXO

If you could provide a simplified app that reproduces the issue with the GeoJSON polygon geometry, I would be happy to look at it.

Thanks,

Jose

Re: Snapping performance issue in version 4.19

ljnio — Thu, 06 May 2021 03:52:25 GMT

Hi Jose,

Thank you very much for the demo. It did take a bit of time to investigate, but I ended up finding where the problem is.

In our code, when we define the view, we set up the initial extent with a Web Mercator projection. Like this:

const view = new MapView({

container: "viewDiv",

extent: {

spatialReference: {

wkid: 102100

xmax: -23934416.14150726,

xmin: -23941338.469881326,

ymax: -4550908.389997464,

ymin: -4555384.733466409

map: map

});

And whenever this is used. The snapping tool will go around the globe to snap a point that's very close to it.

I've modified your version a bit and got a demo here: https://codepen.io/jianingliu/pen/QWpWMzP

Drag the map a bit, and it will generate some random polygon for you to snap.

You'll see what I mean after trying to snap there.

Thanks,

Johnny

Re: Snapping performance issue in version 4.19

Anonymous User — Thu, 06 May 2021 20:35:04 GMT

Hello Jonny,

I see it now. I added the extent onto the test app I provided, and can reproduce the same issue. The drawing visuals display from the opposite side of the map. I created an issue internally for this as well, and we will be looking into this as well!

I wanted to also provide an update on the feature snapping source timeouts with the 4 million polygons. We have a layer that we test at 125 million polygons, and we were not able to reproduce the issue. We are seeing a timeout on the initial request to fetch the layer extent of the feature layer from here:
https://stg-gis.mapshare.vic.gov.au/arcgis/rest/services/mapshare/PropertyAndParcel/MapServer/5

The layer extent is queried when you initially configure the featureSource property of the SnappingOptions. We are doing some further testing to try to narrow down the issue. I just wanted to provide an update and inform you that we have tested snapping successfully with over 125 million features.

I will reach out to you directly to provide updates, and if we have additional questions as we continue to look into this. Thanks for reaching out with these issues you ran into while utilizing the new snapping functionality, and looking forward to getting to the root cause of this issue.

Thanks,

Jose

Re: Snapping performance issue in version 4.19

kgcroteau — Mon, 24 May 2021 19:51:26 GMT

Hello Jose,

Have you learned anymore about this issue? We are also seeing a significant delay when snapping is initialized. As you indicated, the issue appears to be caused by a slow response from the request for the snapping layer's extent.

Do you know if there will be a fix for this with 4.19, or if it will be fixed in 4.20?

Thank you for any additional information you can provide.

Best,

Keith

Re: Snapping performance issue in version 4.19

JoseBanuelos — Fri, 18 Jun 2021 15:38:47 GMT

Hello Keith and Johnny,

I would like to inform you that this issue has been resolved at 4.20.

Thanks,

Jose

Re: Snapping performance issue in version 4.19

ThomasMahar — Mon, 21 Jun 2021 18:07:16 GMT

Great! Thank you for the update Jose.

Best,

Keith

Re: Snapping performance issue in version 4.19

kgcroteau — Fri, 16 Jul 2021 16:36:50 GMT

Hello Jose,

We are now using 4.20, but still seeing an approx. 20 second delay for snapping to be initialized - the snapping layer is relatively large parcel layer for the island of Oahu.

Once initialized , performance is very good.

Thanks,

Keith

Re: Snapping performance issue in version 4.19

JoseBanuelos — Mon, 19 Jul 2021 18:40:52 GMT

Hello Keith,

Appreciate the feedback. Would you be able to share the service url for us to test? While working on this bug last release, we tested layers with millions of features, including the service from the original post here. After running our tests on the bug fix through these layers, we were comfortable enough to say that this issue was resolved.

However, you may have an example of a dataset where this is not completely resolved. Therefore, it would be very helpful if you could provide the service url if possible to test. If you don't feel comfortable posting your data here, feel free to message me directly via Esri Community.

Thanks,

Jose

Re: Snapping performance issue in version 4.19

kgcroteau — Tue, 20 Jul 2021 13:46:23 GMT

Hi Jose.

Thank you for the response. Unfortunately, I am unable to share the map service because it is an intranet AGS service.

However, maybe some additional information will help: The screenshots below show the "returnExtentOnly" request which is issued when snapping is initialized, and this appears to be the request that is causing the slowdown.

The feature count is 177,403 features - which is much lower than the numbers you had tested with.

Perhaps it is something unique to our map service or ArcGIS Server setup (v10.7.1).

Thanks,

Keith

Re: Snapping performance issue in version 4.19

JoseBanuelos — Thu, 22 Jul 2021 16:29:32 GMT

Hello Keith, @kgcroteau

In version 4.20, we removed the requirement to wait for the extent to complete before we can start snapping. It is strange to see that it looks like your service is still being affected. Especially with less than 200,000 features. Are these features polylines, polygons, or points? Do you have other services experiencing this same issue?

Just to double-check. Are you currently using version 4.20, and does the layer finish drawing before you attempt to start snapping?

The server we tested with the service provided in the original post was a 10.6.1 service with nearly 4 million polygons.

Thanks,

Jose

Re: Snapping performance issue in version 4.19

kgcroteau — Thu, 22 Jul 2021 20:29:50 GMT

Hi Jose,

Thanks for the feedback.

It is a polygon featureclass (parcels). I don't believe there is anything particularly unique about it - but perhaps we are missing some indexing or something - which is slowing down the returnExtent call?

I have confirmed that we are using 4.20:

In our instance, it does seem like snapping is still not operable until the "returnExtent" request is complete.

If you have any additional thoughts, please let me know. Meanwhile we will examine the featureclass and the map service to see if it's something in our configuration.

Thanks for your help.

Best,

Keith

Re: Snapping performance issue in version 4.19

JoseBanuelos — Fri, 23 Jul 2021 16:09:18 GMT

Hello Keith, @kgcroteau

You are welcome, and yes please take a look at maybe republishing the service. I went back and ran some testing on our test services and I was able to start snapping immediately with millions of features on a service that eventually timed out on the full extent request. Therefore, that request never completed and snapping was still possible immediately.

If republishing still doesn't resolve this, we can take our conversation via direct message on Esri Community, so I can maybe take a note of some of your service configurations.

Lastly, I setup a test sample you can use in your testing with over 1 million features. Its hosted on ArcGIS Online so its a different implementation, but in case you want to use it as a reference when testing, this would be a good example: https://codepen.io/banuelosj/pen/zYwPwVN

Thanks,

Jose

Re: Snapping performance issue in version 4.19

kgcroteau — Fri, 23 Jul 2021 20:48:12 GMT

Hi Jose,

OK, I believe we figured out why our instance was still slow. We only had a single pooling instance configured for the map service. So, even though the 4.20 client snapping tool no longer waits for the returnExtentOnly response, it was still unable to get responses from other required requests, because they were being blocked until returnExtentOnly finished.

We increased the pool instances to 5 for or snapping services, and now snapping seems to initialize much faster.

Thank you for all of your assistance with this issue!

Best,

Keith

Re: Snapping performance issue in version 4.19

JoseBanuelos — Mon, 26 Jul 2021 23:20:54 GMT

Hi Keith, @kgcroteau

Ahhhh yes the pooling instance. This is great news! I am glad you and your team were able to resolve this. It was my pleasure to help!

Thanks,

Jose