Describe the bug
Using this.camera.fitBounds([lng, lat], [lng, lat], [0, 0, bottom, 0], 1000), the bottom padding attribute work as Vertical padding ignoring the 0 for top padding and using the same value as bottom.
To Reproduce
Calling this.camera.fitBounds([lng, lat], [lng, lat], [top, right, bottom, left], 1000) setting the bottom padding by half screen height and 0 (or any other value) for top, right, left.
Example:
selectRoute = () => {
...
this.fitBounds( [highLong, highLat], [lowerLong, lowerLat], [0, 0, height*0.5, 0]);
}
fitBounds(northEast: SingleCoordinate, southWest: SingleCoordinate, padding: Array<number> = [50,50,50,50]) {
this.camera.fitBounds(northEast, southWest, padding, 500);
}
render() {
return (
<MapboxGL.Camera
ref={camera => this.camera = camera}
followUserLocation={false}
followUserMode={'normal'}
/>
)
}
Expected behavior
The center of northEastCoordinates and southWestCoordinates used must be at the center of the upper half of the screen (padding half height). However it is centered in the middle of screen.
Versions (please complete the following information):
Platform: Android, iOS 13.3.1
Device: Iphone XR
react-native-mapbox-gl Version 8.0.0-rc1 (8.0.0)*
React Native Version 0.61.5
Mapbox Version 1.0.0-beta10
The upstream issue causing it: https://github.com/mapbox/mapbox-gl-native-ios/issues/198
@mfazekas Are you sure, this is causing the problem? The top padding is ignored in iOS as well as on Android devices.
@baijii pls check this comment: https://github.com/mapbox/mapbox-gl-native-ios/issues/198#issuecomment-620387699
I think top padding is not ignored, it's just looks it considered as a minimum padding and it's always made symmetrical.
And sure this issue is likely coming from the C++ layer which is common in ios and android.
@mfazekas My bad, thanks for explaining
Example to reproduce the issue:
import React from 'react';
import {SafeAreaView, Button} from 'react-native';
import MapboxGL, {
MapView,
ShapeSource,
LineLayer,
Camera,
} from '@react-native-mapbox-gl/maps';
import accessToken from './accesstoken.json';
MapboxGL.setAccessToken(accessToken);
const aLine = {
type: 'LineString',
coordinates: [[-74.00597, 40.71427], [-74.00697, 40.71527]],
};
class BugReportExample extends React.Component {
render() {
return (
<SafeAreaView style={{flex: 1, flexDirection: 'column'}}>
<Button
title="fitBounds"
onPress={() => {
this.camera.fitBounds(
[-74.00597, 40.71427],
[-74.00697, 40.71527],
[0, 0, 300, 0],
);
}}
/>
<MapView style={{flex: 1}}>
<Camera
centerCoordinate={[-74.00597, 40.71427]}
zoomLevel={14}
ref={ref => {
this.camera = ref;
}}
/>
<ShapeSource id="idStreetLayer" shape={aLine}>
<LineLayer id="idStreetLayer" />
</ShapeSource>
</MapView>
</SafeAreaView>
);
}
}
export default BugReportExample;
On ios as a workaround, (works on 8.1.0-rc2 and later) add:
ENV['REACT_NATIVE_MAPBOX_MAPBOX_IOS_VERSION'] = '~> 5.6.0'
example Podfile:
platform :ios, '9.0'
require_relative '../node_modules/@react-native-community/cli-platform-ios/native_modules'
ENV['REACT_NATIVE_MAPBOX_MAPBOX_IOS_VERSION'] = '~> 5.6.0'
...
Also submitted fix to https://github.com/mapbox/mapbox-gl-native-ios/pull/323
I installed 8.1.0rc2, used the suggested fix on iOS, and tested the example code above. On both platforms, the fit bounds button worked on the first press.
I then pressed the button again without moving the map. On iOS, nothing happened, which seems like the intended behavior. On Android, the map moved up a bit, then an error appeared: Unable to calculate appropriate zoom level for bounds. Vertical or horizontal padding is greater than map's height or width.
I experience the same bug as @sunny-lirr (only on Android too). I'm not using fitBounds, but I'm updating bounds state that I use as the map's camera bounds props. I also use a constant padding.
On high zooms, for example with the following bounds:
const bounds = {
sw: [2.310149073600769, 48.85784],
ne: [2.335765, 48.869005749964536],
paddingLeft: 10,
paddingRight: 10,
paddingTop: 100,
paddingBottom: 100,
};
On Android, passing this props to the camera give the above mentioned crash:
<Mapbox.Camera
animationMode={'flyTo'}
animationDuration={this.state.animationDuration}
bounds={bounds}
/>
On my side the bug only happens on high zoom values but I can still zoom up to the requested level manually (fitting the input bounds manually). I guess that's the same bug appearing when calling the fitBounds method.
@cglacet this should be addressed by #973, can you please verify?!
https://github.com/react-native-mapbox-gl/maps/issues/956#issuecomment-665886930
I can, do I need to compile anything once I've updated the source? Or should I just re-build my react-native application?
I think I have the answer to my own question as the bug doesn't seem to appear anymore. Thanks.
Any chance this will be merged any time soon?
@cglacet it's a native part, so you'll need to invoke the gradle stuff (via gralew or android studio or via react-native run-android)
Thanks for testing.
Does anybody have a solution for this? It's very weird for us. Padding up to 40 works fine, but once we get to 40 we receive the error:
Mapbox error [event]:General [code]:-1 [message]:Unable to calculate appropriate zoom level for bounds. Vertical or horizontal padding is greater than map's height or width. {"filePath": "virtual bool mbgl::MGLCoreLoggingObserver::onRecord(mbgl::EventSeverity, mbgl::Event, int64_t, const std::string &)", "level": "error", "line": 30, "message": "[event]:General [code]:-1 [message]:Unable to calculate appropriate zoom level for bounds. Vertical or horizontal padding is greater than map's height or width."}
Our implementation for this scenario is quite simple:
<MapboxGL.MapView ref={mapViewRef} style={styles.map} styleURL={styleUrl}>
<MapboxGL.Camera
ref={mapCameraRef}
defaultSettings={{
bounds: bounds
? {
ne: bounds?.ne ?? 0,
sw: bounds?.sw ?? 0,
paddingLeft: 40,
paddingRight: 40,
paddingTop: 40,
paddingBottom: 40,
}
: undefined,
}}
/>
{children}
</MapboxGL.MapView>
the weird part is that the padding works just fine... but it does throw the error, do we just ignore?
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Addressed in #1057
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.