Features are sub-divided are high zoom levels.

[jesus-deepblocks]

Hey guys! First of all, thanks for such an amazing tool. We are using mapbox-gl-js version: 0.43.0 and we are encountering the following "strange" behavior:

We are working with land parcels and we created a style using mapbox studio which adds a layer on top of the streets-v9. This new layer only includes for every feature (parcel) folio, address, zip code and the geometry that in most cases is only one polygon. Now in our app, we want to highlight the parcels while the user moves the mouse over the map, but as you can see in the gif below with higher zooms the feature gets sub-divided into smaller ones (not happening at lower zoom levels).

Even more strange as you can see in the image below this "smaller" features overlap their geometries. (I put a 0.5 opacity so the overlapping areas look darker)

Now, we would like to know if this is expected behavior or could be something that we are doing wrong. In the case that this is the expected behavior would be nice to have some insights on the reasons behind it.

Thanks in advance.

[jfirebaugh]

Thanks for using Mapbox, and sorry to hear you're running into an issue. Can you verify if this issue persists in the current version, 0.46.0? If so could you please create a minimal self-contained example on jsbin.com that demonstrates the issue?

[jfirebaugh]

The behavior in the animated gif is expected; see the documentation for queryRenderedFeatures for details. The rendering in the static screenshot may or may not be expected -- it depends on what code you are using to produce it.

0.46.0 includes a new feature that makes this kind of use case easier -- setFeatureState and the feature-state expression. The "Create a hover effect" has been updated to show how to use these new features, which may address your issues.

[jesus-deepblocks]

@jfirebaugh Thanks for the quick reply. Reading the documentation on queryRenderedFeatures I can see that what we are getting is expected behavior (we still do not clearly understand why the "sub-features" overlap). Now for the screenshot behavior, you don't have to worry about that's done in our end (we query first on a point and then again filtering all the features that share the same folio).

The problem with our specific use case is that what we need is to have is the polygon surrounding each parcel (coloring it is not much of a problem, setting opacity 1 in the example above does the trick). Even if visually we can color the whole parcel, underneath we have to deal with several polygons instead of one. From what I read about setFeatureState it can be of help with on-the-fly drawings and layer manipulations but do not "join" all the "child" features.

Now, regarding version 0.46.0 we are just going to wait a little bit until the PR #6841 gets merged as we really really need that one (haven't found any decent workaround for it).

Thus, If you guys feel that having a method that accepts a feature and returns its "source" (the one that it was sub-divided from) is a good addition, would love to have it, otherwise, you can close this issue and we'll find a way to compute the union of several polygons.

Thank you for all your help.

[jfirebaugh]

#5639 asks whether query*Features for GeoJSON sources specifically can produce the original geometry. For vector tile sources, feature reconstruction is something that will require support from the vector tile specification, so for now you'll indeed need to explore polygon union based approaches if that's something you need.

[raegen-work]

For anyone who ends up here with the problem at hand - there is really no need to reconstruct or calculate anything, just add a property with the original feature to 'properties' of the original features. Then when you get it from query*Features, you can access the original feature through feature.properties[whateveryounamedthepropertywithoriginalref].