Feature querying; more geometry types #5110
Conversation
1ec5
added
iOS
It specifies them as
Nice! |
👍 These two would go well together. |
Ah, I mistakenly thought the prose readme was the canonical specification. 👍 With |
|
I need to investigate a crash querying features in a tile that also has annotations. It has to do with the indexed feature having no name but the annotation layers having names like |
|
Split out #5159 for the crash querying annotation tiles. |
1ec5
changed the title
1ec5
force-pushed
the
1ec5-features-352
branch
2 times, most recently
from
aa1c9a1
to
354396a
Compare
1ec5
added
✓ ready for review
and removed
⚠️ DO NOT MERGE
|
@jfirebaugh, would you mind reviewing the Objective-C++ changes in MGLFeature.mm, MGLFeatureTests.mm, and MGLMapView.mm, plus the C++ changes in shape_annotation_impl.cpp? Thanks! @boundsj, would you mind reviewing the rest of the geometry-related changes in platform/darwin/? Thanks! |
| */ | ||
| class PropertyValueEvaluator { | ||
| public: | ||
| PropertyValueEvaluator() {} |
There was a problem hiding this comment.
This default constructor can be removed; the compiler will generate it automatically.
There was a problem hiding this comment.
Removed the vestigial constructor and force-pushed.
|
Here’s the new feature’s documentation:
|
|
How would the API change if we added the the |
We’d add additional variations of this method, like The typical solution in C++ would be to pass in a struct representing the query, but structs in Objective-C (really, C structs) don’t support ARC and thus can’t hold Objective-C objects like NSString. (This is fixed in Swift, but without any backwards compatibility for Objective-C.) We went down this road in the past with I don’t think we should introduce a class with only one property. If lots more options become available down the road, or if MGLStyleLayer becomes a type the developer can interact with, we can do the deprecation dance with these methods at that point. |
|
I’ve tweaked the Swift names of these MGLMapView methods to be briefer and accommodate additional options in the future. For example, Hopefully it won’t be too confusing for the Swift names to be slightly different than the Objective-C names, now that realm/jazzy#136 has made it into our build system. Eventually, we can also refine the declarations for Swift, marking each labeled parameter as optional so you can specify any permutation of these parameters. |
|
|
||
| The keys and values of this dictionary are determined by the vector tile | ||
| source. Vector tiles are stored in <a href="http://geojson.org/">GeoJSON</a> | ||
| format; they additionally conform to the |
There was a problem hiding this comment.
What does it mean to store a vector tile in GeoJSON format?
Vector tiles are stored in GeoJSON format?
There was a problem hiding this comment.
Oops, that’s incorrect and it’s the next part, about the vector tile spec, that we should be emphasizing anyways.
| On the other hand, if the style does include bus stops, an `MGLFeature` object | ||
| representing that bus stop is returned and its `featureAttributes` dictionary | ||
| has the `maki` key set to `bus` (along with other attributes). The dictionary | ||
| does not indicate how the feature is rendered by the current style. |
There was a problem hiding this comment.
This explanation is good and correct. As a thought exercise, I wonder what it'd look like to frame this description more in terms of what the API does rather than what it doesn't do.
This API returns the set of features that are rendered on the map at a point.
There was a problem hiding this comment.
I think all but the last sentence in this paragraph explains what the API does do – or at least, that’s what I was trying to do. The point I was trying to make at the end is that you shouldn’t expect paint properties to be included in the attribute dictionary.
Added methods to MGLMapView that return the rendered features at a visible point or within a visible rectangle on the map, optionally restricted to a set of layers, plus voluminous documentation. Added several new geometry classes corresponding to distinct geometry types supported by geometry.hpp. Added parallel “feature” classes to represent these geometries along with tags (IDs) and attributes (properties) from the source. Grouped classes in the Foundation and SDK groups by theme. In iosapp, dropped pins’ callout views now display the name of the topmost named feature at that point. In osxapp, a long press on the map highlights the features under the cursor. Dropping a pin via the menu or context menu item shows the usual dropped pin, but the pin’s title is now the name of a feature under the cursor, if available, rather than “Dropped Pin”. Fixes the iOS/OS X side of #352.
Made writability of MGLFeature properties private, to avoid having to awkwardly explain that changes to the properties don’t change the map (maybe someday they will). This allows the identifier and attributes to be set in only one place, avoiding copy-pasta.
MGLPolygon (and by extension MGLMultiPolygon) now supports interior rings. The data is preserved in feature querying results, and interior rings are respected when adding polygon overlays to the map. Fixes #1729. [ios, osx] Updated changelog
Removed a level of indirection when creating Objective-C collections from C++ collections. Adopted mbgl typedefs for geometry.hpp types. Factored out MGLPolygon construction.
Ignore any multipolyline, multipolygon, or shape collection object passed into -addAnnotation: or -addAnnotations:. Previously, these methods broke apart the compound shape into its constituent shapes in order to recursively add them to the map. But that broke assumptions about a one-to-one correspondence between annotations and their contexts during selection and deletion.
Moved feature selection to the context menu and restored the press gesture for dropping a pin. Bust complex features into simple shapes to feed into MGLMapView as overlays.
Added methods that return the visible features at a given point or in a given rectangle on the map. Each feature is represented by a class conforming to the MGLFeature protocol and, conveniently enough, the MGLAnnotation protocol. Yup, that means you can feed the features right back to the map in the form of point and shape annotations. These classes derive from the usual suspects (MGLPointAnnotation, MGLPolyline, etc.), but there are several new classes to represent geometry types supported by geometry.hpp but not by MapKit (MGLFeatureCollection, MGLMultiPolyline, etc.). Complex geometry types like multipolygon cannot yet be added as overlays, but this PR does add support for holes in simple polygons.
In addition to the usual annotation properties, each feature object has an identifier and a dictionary of attributes (properties) that come from the source. The dictionary contains boxed Foundation types such as NSString and NSNumber, as appropriate. Identifiers are also represented as NSNumbers: mbgl allows features to have IDs within the entire
uint64_tspaceand the Mapbox GL Vector Tile Spec doesn’t specify the ID data type, so there’s no room for magic numbers.In iosapp and osxapp, dropping a pin (by long-pressing or via the context menu) shows the usual callout view, but now its title is the name of a feature under the cursor, if available, rather than “Dropped Pin”. Choose “Select Features” from the context menu to highlight all the features under the cursor.
More to come:
mbgl::geometry::values to Cocoa typesmbgl::Features toMGLFeaturesNSPointon OS XCGPointon iOSMigrate(split out into mbgl::AnnotationManager should use mapbox::geometry types #5158)mbgl::AnnotationManagertombgl::geometrytypes?mbgl::AnnotationManager-managed featuresNSRect/CGRectFixes the iOS/OS X side of #352.