[core] AddedMap::{set,get}LatLngBounds#8583
Conversation
1ec5
left a comment
There was a problem hiding this comment.
For the most part, this PR looks reasonable, but I have some concerns about the antimeridian edge case (the gift that keeps on giving). I’d also defer to someone on the Android side to speak to whether this addresses the Android SDK’s needs.
#3602 (comment) called for a setMinTilt() and setMaxTilt(), which would imply a setMinPitch() and setMaxPitch() in mbgl::Map. Would that fall within the scope of this PR?
| LatLngBounds(const CanonicalTileID&); | ||
|
|
||
| explicit operator bool() const { | ||
| return (sw.latitude <= ne.latitude) && (sw.longitude <= ne.longitude); |
There was a problem hiding this comment.
This would be consistent with the GeoJSON specification, but inconsistent with GeoJSONVT’s behavior of allowing a single feature or annotation to span the antimeridian (#6088), correct? If one were to calculate the bounding box of an annotation, would this operator end up evaluating to false? Would it still be possible to fit the bounds to the annotation?
There was a problem hiding this comment.
My understanding of LatLngBounds::extend is that it preserves the assertion above. Also, this should be fine as long as the coordinates used are unwrapped.
Nonetheless, we can add a unit test to verify 👍
Do you have one in particular? From my tests, this shouldn't be an issue as every coordinate passed to the map gets unwrapped e.g. here. |
Yep, we can certainly add it too 😃 |
I was referring to #8583 (comment). But as long as you’ve considered this possibility, 👍. |
| LatLng(double lat = 0, double lon = 0, WrapMode mode = Unwrapped) | ||
| constexpr LatLng(null) : latitude(std::numeric_limits<double>::quiet_NaN()), longitude(latitude) {} | ||
|
|
||
| constexpr LatLng(double lat, double lon, WrapMode mode = Unwrapped) |
There was a problem hiding this comment.
| } | ||
|
|
||
| void Transform::setMaxZoom(const double maxZoom) { | ||
| void Transform::setMaxZoom(double maxZoom) { |
There was a problem hiding this comment.
Why did you remove const? I generally don't add it in the headers, but do add it in the implementation files to avoid modifying the parameter. Those definitions are compatible.
There was a problem hiding this comment.
As you mentioned, there is no point in adding this to headers. Also, const-pass-by-value is not a common behavior in our codebase.
For me, it is clear that a non-const pass-by-value is a different object from the one it has been copied from i.e. declaring it const does not guarantee that the original object remains immutable.
There was a problem hiding this comment.
Sorry, what I meant to say is that I'm doing this as a convention to avoid accidental changes to the parameter that might get read later on in the function.
There was a problem hiding this comment.
Ack - let's add them back on the definition file 👍
|
|
||
| ScreenCoordinate point = { | ||
| -latLng.longitude * Bc, | ||
| -constrained.longitude * Bc, |
There was a problem hiding this comment.
That's where we constrain the received LatLng to the specified bounds. I preferred this to be done when inserting because I suppose we set LatLng values much less than we request them from TransformState.
|
Been testing out and adding binding integration in #8622, |
4b8849b to
893bc78
Compare
|
Removed the |
893bc78 to
93f7a11
Compare
| } | ||
| return LatLng { | ||
| p.latitude < sw.latitude ? sw.latitude : p.latitude > ne.latitude ? ne.latitude : p.latitude, | ||
| p.longitude < sw.longitude ? sw.longitude : p.longitude > ne.longitude ? ne.longitude : p.longitude, |
There was a problem hiding this comment.
Parentheses to clarify operator precedence would make the code mode readable
93f7a11 to
713974b
Compare
713974b to
5891f0c
Compare
|
@kkaefer can you please re-review? |
Implements a setter and getter for coordinate bounds in
MapAPI - which can be used e.g. to limit the boundaries in which the user can set geographical coordinates.Related: #3602.