Floating points are not honored when evaluating the symbolSortKey

[johnnewman]

When iconAllowsOverlap is false and the values for the symbolSortKey evaluate to doubles, the ordering of those values doesn't change the z-level of where the icons are drawn in a style layer. The same feature will always appear on top of the other whether you reverse the values for the sort (by multiplying by -1) or leave them as-is.

Somewhat similar to #15964.

Steps to reproduce

1. Add a symbol style layer to the map with 2 overlapping features
2. Set textAllowsOverlap and iconAllowsOverlap to false
3. Set textOptional to true
4. Ensure both features have values for the symbolSortKey
   • Make sure these values are doubles. I used 0.99999896 and 0.99999898

Expected behavior

I'm trying to get the feature with the higher sort of 0.99999898 to appear on top.

Actual behavior

With the floating points above, the feature with the sort value of 0.99999896 will always be on top. This is also true if you reverse the order by multiplying the sort values by -1.

If I set iconAllowsOverlap to true, the sort order appears to be honored and the feature with the larger sort of 0.99999898 is drawn on top.

This gist replicates the issue: https://gist.github.com/johnnewman/d69b5c28c9f8d0895f9bb5e36eb1baeb.

Here is a working project with the code from the gist. Just supply an API key in AppDelegate.swift.
IconOrderingProject.zip

Configuration

Mapbox SDK versions: 5.6.1
iOS/macOS versions: iOS 13.3
Device/simulator models: iPhone 7
Xcode version: 11.3

[chloekraw]

Whether the sort keys are integers or floats doesn't affect the cause of the behavior you're seeing, which is that symbols are not sorted by their sort keys during placement when overlap is disabled. It should also be fixed by #16023 just like the other ticket you opened and linked, which we're working towards getting into the next release.

cc @ansis

[johnnewman]

Thank you for checking this out! I will keep my eyes on that PR.

The odd thing I noticed about this issue was that if I switch the floats to integers like 1 and 2, then the symbols do appear to be influenced by the sort key, I just have to multiply by -1 and the lowest value will draw on top. This same approach does not work with the floats.

red = -0.99999898, blue = -0.99999896	red = -2, blue = -1

[chloekraw]

@johnnewman can you reproduce that reliably for sets of points at different locations in tiles? Based on previous testing we've done, I think this is just coincidence. There is some kind of deterministic order for which icons win in collision detection within a tile.

[johnnewman]

@chloekraw So far I've only seen the feature with -2 take priority and draw on top of the -1. I've randomly generated about 60 lat/lon values to confirm. I also tried with the -0.99999898 and -0.99999896, but I only see the larger -0.99999896 draw on top.

Hopefully this was a valid test: I was updating the coordinate property of the two MGLPointFeature objects, reassigning the shape of the MGLShapeSource, and taking note of the new display order when the features redrew.

[chloekraw]

Okay, thanks! We’ll take a look then @johnnewman. Appreciate the time you took to test.

[ansis]

Yep, it looks like we should probably switch these from floats to doubles internally. In the meantime can you work around this by reducing the precision necessary for your sort keys?

[johnnewman]

This makes sense and we can definitely work around it 👍. For context: we have millions of potential sort values and I was normalizing them to all be between 0 and 1 before passing them into the style layer. Oops! Thank you @ansis.

[stale]

This issue has been automatically detected as stale because it has not had recent activity and will be archived. Thank you for your contributions.