-
Notifications
You must be signed in to change notification settings - Fork 1.3k
Conversation
return { segment }; | ||
} | ||
|
||
- (mbgl::ShapeAnnotation::Properties)shapeAnnotationPropertiesObjectWithDelegate:(__unused id <MGLMultiPointDelegate>)delegate { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Currently, if you call -[MGLMapView visibleFeaturesAtPoint:]
at the location of a multipoint (in geometry.hpp terms), you get an MGLMultiPointFeature object back. MGLMultiPointFeature is a subclass of MGLMultiPoint that conforms to MGLAnnotation, so you can add this MGLMultiPoint object to the map using -[MGLMapView addAnnotations:]
. With these changes, MGLMapView will end up calling -shapeAnnotationObjectWithDelegate:
on an MGLMultiPoint that has no implementation of -shapeAnnotationObjectWithDelegate:
, resulting in an Objective-C exception.
If it isn’t straightforward to create an mbgl::ShapeAnnotation
representing a multipoint geometry at this time, I think it’d be reasonable to implement a -shapeAnnotationObjectWithDelegate:
that asserts for now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
MGLMultiPoint
is trying to do too many things. It should represent the geometric "multi point" concept, and not also try to be a base class for MGLPolygon
and MGLPolyline
. (Our Java classes make a similar mistake.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed. Unfortunately, I think we’re stuck with MapKit’s concept of a multipoint (as any shape with multiple points) for backwards compatibility. What could we call the class that represents a standard GIS multipoint? Or should we bite the bullet and bump the major version number for simplicity?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
MGLSparseMultiPoint? 😬
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I make 5698978 part of this PR, how hard would it be to refactor things so that -annotationObjectWithDelegate:
is implemented by every class that implements MGLAnnotation
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
MGLAnnotation is a public protocol, so we can’t use any C++ types or expect the developer to implement this method themselves for their custom MGLAnnotation classes.
The base model class for things that get turned into mbgl::ShapeAnnotation
s is currently MGLMultiPoint. There’s no base model class for things that get turned into mbgl::PointAnnotation
s, because any Objective-C object can conform to the MGLAnnotation protocol and thus be added as a point annotation.
We could centralize this shape conversion logic to avoid any surprises, since it isn’t like the developer can really come up with their own novel geometry class. MGLMultiPoint is a natural place to host a centralized conversion method, but the most flexible approach would be to implement a standalone C function similar to MGLFeaturesFromMBGLFeatures()
.
On it. |
@jfirebaugh made it so it will build, but we are not really using shape annotations for Qt ATM and we are likely to rewrite it completely anyway. |
@jfirebaugh will review later today |
Merged the larger refactor into this PR and updated the description. |
@@ -6,6 +6,7 @@ | |||
#endif | |||
|
|||
#import <mbgl/util/geo.hpp> | |||
#import <mbgl/util/geometry.hpp> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is causing the Darwin unit tests to fail to compile. Those tests need only a couple of the methods in this header. We should split this header into MGLGeometry_Private.h (private visibility, so it's visible to test target) and MGLGeometry_Internal.h (project visibility, so it's visible only to the dynamic and static targets).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Alternatively, you can put MGLPointFromLocationCoordinate2D()
in MGLFeature_Private.h, which already houses some geometry type conversion code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The issue was that geometry.hpp
was still in src
rather than include
.
f1161dc
to
ac4ccdd
Compare
I tried building this locally with:
I have no issues with building but at runtime I'm running into:
I validated that this is not happening on master. The code itself LGTM and reading the C++ was really useful/insightful for me. LMK if I can help out or need to retest. |
@tobrun Looks to me like this crash does happen on |
It's #5108 again. 😠 |
Instead of providing both singleton and List-based implementations: * Define everything in terms of arrays * Do singleton ⇢ array and List ⇢ array conversions in Java
Annotation
type; eliminate type-specific add/update methods.