Clarification on 4.23 hitTest return value

[james-rae]

My apps need to figure out the top-most feature under the mouse pointer, so the latest hitTest update has required me to fiddle around with things. The documentation doesn't mention anything about the order of HitTestResults in the array (or I'm blind, it happens lol ).

Doing some console logging, I think I see the pattern but want to clarify (and request the documentation be updated).

It appears to me the graphics in the result array are order by layers, top-most to bottom-most, but graphics belonging to the same layer are ordered bottom-most to top-most.

So for example, if I have a pile of overlapping features from layers BL (bottom layer) and TL (top layer), my result array of graphics looks something like

[ TL_lowest, TL_middle, TL_highest, BL_lowest, BL_highest ]

Can anyone in the know confirm? Much obliged.

[james-rae]

I'm also noticing a loss of fidelity. My v4.22 build would be fairly accurate saying what the mouse was touching. I'm now seeing hit results for graphics where the mouse is a good four pixels away from it. If anyone else is experiencing the same, would appreciate a chime-in so I can say it's not just me.

[mgeorge · Accepted solution]

@james-rae the hittest uses a distance of 6 pixels for the test. Thanks for the feedback regarding the tolerance being too large, I think we just need to provide a way for this to be specified externally. It's a balance between making things precise and "too hard to click," that I think app devs would probably best be deciding for themselves. I'll put in an issue to discuss this.

The returned results are unordered. Are you currently using orderBy for your feature layer? We're planning to document/define that behavior for 4.24 and sort returned features top-down. 

[james-rae]

Great response, thanks.
I had missed the addition of orderBy in v4.21, so using this or waiting until v4.24 should get me where I'm going.

Interesting revelation about the hitTest tolerance. I had falsely assumed something in the API guts was doing measurements against the actual symbol size. I guess my days of being spoiled with the SVG precision of API v3 are long gone. But I'm glad to know this and can begin to mitigate on my end. And yes if a tolerance parameter is added in the future that would go a ways.

[mgeorge]

@james-rae the api does consider the the symbol size (including size impacting stuff like visual variables that are applied shader side), and should be precise. It just uses a large hittest radius to make it "easier to click," esp. for mobile where it's hard for users to be exactly click on something. We're thinking though that maybe we need to vary this for mobile / desktop, using a smaller radius on the latter. 

[james-rae]

Great, even better. Appreciate the insider info.

[mgeorge]

FYI, brought this up with the team

[LaurenBoyd]

@james-rae good news for version 4.29 - when performing a hitTest() on the MapView , the drawing order of the features in the layer will now be respected. The returned features will adhere to the default drawing order of the data or a specific order if orderBy is specified on the layer. Hope this helps!

[james-rae]

Great news, thanks for the heads up!