This repository has been archived by the owner on Aug 8, 2023. It is now read-only.
MGLFeature should contain MGLShape, not inherit from it #7454
Labels
annotations
Annotations on iOS and macOS or markers on Android
gl-ios
iOS
Mapbox Maps SDK for iOS
macOS
Mapbox Maps SDK for macOS
refactor
runtime styling
SEMVER-MAJOR
Requires a major release according to Semantic Versioning rules
Milestone
MGLFeature should be a class, not a protocol, and it should contain an MGLShape in its
shape
property. The various MGL*Feature classes that conform to the MGLFeature protocol should go away. MGLShapeCollectionFeature should be renamed to MGLFeatureCollection. MGLShape, MGLFeature, and MGLFeatureCollection should conform to a new MGLGeoJSONRepresentable protocol.In #5110, I needed to add classes for all the possible feature types that could be returned from the feature querying API. I made a series of MGL*Feature classes: each class conforms to the MGLFeature protocol and inherits from an MGLShape class (which corresponds to a GeoJSON geometry type). For example, MGLPolygonFeature inherits from MGLPolygon. By contrast, in the GeoJSON specification, a feature contains a geometry; it isn’t a kind of geometry.
I don’t remember if the taxonomy I implemented was a misreading of the GeoJSON specification on my part or a deliberate shortcut, but it proved to be very convenient for working with feature querying results. You can take the feature querying results and turn right around and add those results to the map as annotations (since some MGLShape types are annotation types). Unfortunately, this taxonomy works less well with the runtime styling API: for #7453, what happens when an array of MGLShapes is really a mixture of shapes and features?
The proposed refactoring mirrors the GeoJSON specification exactly and removes the rough edges around the runtime styling API.
/ref #5201 #7160 (comment)
/cc @boundsj @frederoni @jfirebaugh
The text was updated successfully, but these errors were encountered: