-
Notifications
You must be signed in to change notification settings - Fork 1.3k
Warn about attribute loss when using shape collection in shape source #11287
Comments
I've found the fix is simply to use an MGLShapeCollectionFeature instead of MGLShapeCollection. This wasn't clear in the documentation - the documentation made it appear that the difference was simply that the shape collection itself was also given an identifier and attributes. Especially considering that the MGLShapeCollection's I found the solution by looking at the implementation of MGLShapeSource's I recommend updating the documentation of MGLShapeCollection to point out that if you want to maintain the attributes of features added to use the MGLShapeCollectionFeature, and update the documentation of MGLShapeCollectionFeature to point out that it is recommended to use instead of MGLShapeCollection when you're adding features instead of shapes. |
Ahh, I had done some searching but didn't see that. I see in one of them you even discuss either changing to MGLShapeCollectionFeature when detecting a feature in the shapes array, or turning the feature into a shape. Personally, the current functionality would have been easy to work with if I had any understanding of what was going on. A debug log saying "Warning: One or more shapes added to this MGLShapeCollection were features. All metadata will be stripped. Please use MGLShapeCollectionFeature if you'd like to retain the metadata" or something similar would have made this a much smaller head ache. |
That’s a good point. Until we fix #7454, documentation can only mitigate this trap but not eliminate it. A one-time console warning is a good idea. |
visibleFeaturesAtPoint
when added to an MGLShapeSource via MGLShapeCollection
That's all I would have needed! A note at the top of this documentation saying "If using MGLShapeFeatures, you should use an MGLShapeCollectionFeature instead." And perhaps modify this MGLShapeCollectionFeature documentation to say it uses ShapeFeatures instead of Shapes? From the documentation, it says |
Is the documentation update considered enough to close this issue? I'd still think the one time console warning would be ideal. Are there any use cases where one would intentionally want to stick features into an MGLShapeCollection instead of MGLShapeCollectionFeature? |
I suppose that would be one way to erase feature attributes without having to create separate copies of everything, but I’m struggling to think of a use case for what’s essentially data loss. The one-time warning would be useful, so this issue remains open to track that improvement. |
Assuming there is a legitimate use case for stuffing a feature in a shape collection, we could instead warn when adding a shape collection to a shape source, as originally suggested above. |
Platform: iOS
Mapbox SDK version: 3.7
Steps to trigger behavior
Expected behavior
Attributes of the MGLPointFeatures which were added to the MGLShapeCollection are accessible
Actual behavior
Attributes are not accessible
I have a handful of 'types' of markers I'm trying to display, and tapping them should open a new screen. In order to format the new screen, I'm adding some meta data to the attributes of each of these MGLPointFeatures. However, when I call
visibleFeaturesAtPoint
, the points exist but have no attributes.When I'm adding points, I am accessing a reference to the MGLShapeCollection with the existing points, and creating a new NSArray of MGLPointFeatures using
[[shapeCollection shapes] arrayByAddingObject:newPoint];
When I add a break point and view this new array, it contains all of my features with their full attributes, so the MGLShapeCollection has the appropriate data. I create a new MGLShapeCollection with this new array, and I call[source setShape:shapeCollection];
This works in the sense that it adds all of the MGLPointFeatures to the map. They'll be formatted according to the MGLSymbolStyleLayer that the source belongs to. But their attributes are gone when I try to access them when the map is tapped.The text was updated successfully, but these errors were encountered: