Fixes issue #12472.
This commit doesn't address the underlying issues that come from symbolAnnotationTree using a slightly lower precision coordinate system than the annotations themselves.
Instead, it just puts a small padding around each tile when it queries for tile data, so that symbols right at the tile boundary will be included in both tiles.
The rendering/querying code will take care of only displaying one instance.
The padding is in global coordinates, so at higher zoom the padding will be larger in tile units -- this is consistent with precision loss also being greater at higher zoom.
- log2 is not available on Android before API 18.
- Android doesn't have 'round' on the std:: namespace when using g++.
Co-authored-by: Thiago Marcos P. Santos <thiago@mapbox.com>
This patch fixes the compilation errors on QNX 7:
1) QNX 7 compiler (i.e qcc based GCC 5.4.0 with libc++ from LLVM) has a
limited c++11 feature support and causing the compilation
errors with the inheriting constructors. This fixes the issues by
providing the required constructors explicitly.
2) Resolves an ambiguous overload error with optional<T>
- Remove unused/vestigial 'maxCameraDistance'
- Create a single collision circle for line labels that are less than half the width of a collision circle
Use a single template function for each of {to,from}ExpressionValue, always dispatching to ValueConverter.
Remove unused ValueConverter::ExpressionType typedefs.
When detecting an expression used as a filter, relax the check for expressions to allow comparison expressions to contain a fourth member for the collator.
Based on patch from @lbud (Lauren Budorick).
Give `HeatmapColorPropertyValue` a more generic name,
since the same value type will be used for both `heatmap-color`
and `line-gradient` properties.
* Introduce AspiringActor, EstablishedActor
This pair of objects represents the two-phase (parent-thread /
child-thread) construction that's needed to support constructing
Thread<Object> without blocking until the child thread is up and
running.
An `AspiringActor<O>` is responsible for:
- ownership of the actor's `Mailbox`
- allocating the memory for (but *not* constructing) the target object `O`
Using these two pieces--the mailbox and a stable address for `O`--an
`AspiringActor<O>` can accept messages for the target object, or provide
`ActorRef<O>`s that do so, before the object has actually been
constructed by the corresponding `EstablishedActor<O>`. (Such messages
are queued in the mailbox until after the object is constructed.)
This allows for an `AspiringActor<O>` to be created and safely used by a
thread other than the one on which the target object will (eventually)
live.
An `EstablishedActor<O>` is responsible for managing the lifetime of the
target object `O` and the open/closed state of the parent's `mailbox`.
The `O` object's lifetime is contained by that of its owning
`EstablishedActor<O>`: the `EstablishedActor` constructor executes the
`O` constructor via "placement new", constructing it at the address
provided by the parent `AspiringActor`, and the `~EstablishedActor`
destructor similarly executes the `~O` destructor (after closing the
mailbox). `EstablishedActor` should therefore live entirely on the
thread intended to own `O`.
* Remove Actor#{invoke,ask}
