Hello,
In my application I call SetViewpointCenterAsync(MapPoint center, double scale), with scale being the current scale of the map. Most of the time it centers correctly on the MapPoint I pass in, but there are times where it centers on a MapPoint that's different from the one I passed in.
I can't see a common trend when it's different - sometimes the point it's centered on is north, sometimes is south, sometimes is west, sometimes is southwest, etc. of the MapPoint it's supposed to be centered on. At first I thought maybe it was being interrupted by another view navigation (thus returning false) which was causing this, but I have verified in my logs that the method is still returning true when not centering correctly, which I interpret as the set view animation is completing and thus should be centered correctly. I have also verified that in these cases there are not other MapView methods being called around the same time, which could also potentially cause this issue.
I was wondering if there's perhaps a known bug that causes SetViewpointCenterAsync correctly (doubtful, but want to confirm since I have been looking into this for awhile and am stumped why it's not working sometimes). If not, could there be something wrong with how/when I'm calling it, or the parameters I'm passing in?
Is the spatial reference of your center point always the same?
...also does this ever happen if you use the non-async SetViewpoint method?
Yes, I am always using the WGS84 spatial reference...I have not tried to use the SetViewpoint method yet
I have not been able to reproduce it based on the limited information you provided.
For this scenario, when I say I'm calling SetViewpointCenterAsync, I am calling it from another method called CenterMapAsync.
async Task<bool> CenterMapAsync(double latitude, double longitude)
{
//run other stuff...
return await mapView.SetViewpointCenterAsync(new MapPoint(longitude, latitude, SpatialReferences.Wgs84), _mapView.MapScale);
}
When I call CenterMapAsync from our test application it always works; it is when it's being used in our cilent application that it occasionally does not center (So I personally have never been able to recreate it. I have seen screenshots from when this happens when other people recreate it, and the logs when this occurs show that it's being called and SetViewpointCenterAsync is completing successfully).
Thanks.
Any chance you can try it with v100.2 ? There's been some fixes with respect to the navigation animations and cancellation.
If not, can you share some details about the PCs that are reproducing the issue?
Btw, this is how I tried to reproduce it using the tapped event:
private void mapView_GeoViewTapped(object sender, Esri.ArcGISRuntime.UI.Controls.GeoViewInputEventArgs e)
{
var mp = GeometryEngine.Project(e.Location, SpatialReferences.Wgs84) as MapPoint;
mapView.SetViewpointCenterAsync(mp, mapView.MapScale);
}
If it can't be reproduced in a simple app on the PC that sees the issue, it might be worth to start stripping away layers in your app till the problem goes away. It might give you a hint at what's causing it.
Also make sure you try and reproduce without the debugger attached. That could be a key difference between your setup and PCs where it gets recreated.
I'm seeing this in 100.11.2, specifically when I turn on the GPS tracking and turn it off. After that, if I have a feature at a certain X,Y and I do:
var vp = new Viewpoint(point, currentScale);
await MapView.SetViewpointAsync(vp);
If I then put a marker at the centroid of the viewpoint, it is placed about 5 pixels up and 2-3 pixels to the right of the feature which I used to get the point in the code above. If I never turn the GPS tracking on and off, it gets placed correctly.
Correct placement:
After turning GPS tracking on, then off, then repeating the same operation:
Again, we never have the problem without turning the GPS tracking on and off.
Everything is projected to the spatial reference of the MapView itself. Seems to happen on all Xamarin Forms platforms.
We're still seeing this problem. Is there a way to file a ticket that can get this addressed?
The issue described above by @ChristopherPalmer99 is still happening with 100.13.