Identify layer feature

[mmoosbac94]

Hello everyone,

We have a question regarding layer feature identification. Currently, we use the proxy.identifyLayers method, which works well. However, when the internet connection is slow and a user taps on a layer feature on the map, it can take some time to retrieve the feature identification.

We understand that portal requests are necessary to fetch specific data for a layer feature, such as displaying information in a floating panel. However, is there a way to first retrieve the feature identification locally via the proxy, allowing us to display the floating panel with a loading spinner while the data is being fetched?

Or should we consider alternative approaches, such as showing a loading indicator elsewhere while retrieving the layer feature data after a tap?

Thank you!

[RyanOlson1]

What kind of layer are you calling it on? (ie Vector tiled layer, feature layer, etc)

[mmoosbac94]

We are using feature layers and passing a screen point to check if the tapped spot on the map corresponds to a layer feature.

[RyanOlson1]

The ideas so far that I have are to try to use identify(on:...) as opposed to identifyLayers(...), in case there are one or two slower layers slowing down the call.

Another idea is to try to pass 1 for the parameter value of maximumResults. Passing 1 for that allows it to use GPU test for identify which may speed it up a bit.

[mmoosbac94]

Hi @RyanOlson1, thanks for your tips! We'll give that a try. However, it's not so much about the speed but rather the loading process. Maybe there is no option to first identify the feature on the map and then fetch the data afterward? That way as I said we could display a progress indicator in the floating panel in the meantime. Otherwise, we might consider showing an indicator elsewhere.

Our problem is that we cannot display the floating panel and show an indicator until we determine whether the tap on the map is actually an element or empty.

Example workflow: Check for User Location (if yes, return) -> Check for Layer Feature (if yes, return) -> If both is not identified, there is no element (its "empty").

[Ting]

Hi Marvin, thanks for your post. After some discussion we identified (pun not intended) 2 issues:

1. Prolonged identify operation time. In ideal situation, an identify operation should be really fast, no more than 1 second, most likely at even less than 100ms. However, there is a problem with our current serial request queue setup, where all the map update network requests (tiles, features, etc.) go to the same queue as the identify requests. Thus, if the map has many data layers and while the map is loading, an identify operation is called, it may result in slow identify time.

    - Plus the slow network, the slowdown can be even worse.

    - Identify on empty location can also be slowed down if there are many layers to query.

2. About your original request, we had similar discussion before. Say we build an app that support mouse or Apple Pencil hover - when the cursor hovers above a feature, we want to select or animate its symbol, without accessing its underlying data.

    - Currently, there isn't a good way to achieve this, especially when we want smooth animation.

    - Identify operations are intrinsically asynchronous and take time to get response.

    - Ideally, there can be a synchronous "identify" or "hit test" method that access locally available feature's data. No public API available for it yet.

---

To sum up, a few actions can be considered:

- Log an idea on ArcGIS Maps SDKs Native Ideas so we can triage your request about local identify. Describe your workflow and what type of API you expect to improve the UX.

- Reduce the network load when identify operation is called: finish loading map before identify; only identify 1 layer at a time; discourage quick repetitive identify operations

- While showing the spinner, show a graphic to signify that a tap is made on the map at certain point. and clear the graphic once the identify completes… or similar ideas. This could serve as an interim alternative to the problem of "we cannot display the floating panel until we determine whether the tap on the map is actually an element or empty"