Snapping performance issue in version 4.19

Hello Keith and Johnny,

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

Thanks,

Jose

All comments

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

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

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

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

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

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

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

ThomasMahar

Great! Thank you for the update Jose.

Best,

Keith

Hello Keith and Johnny,

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

Thanks,

Jose

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

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

ljnio

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

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

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

ljnio

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