xamarin forms map sometimes very slow to update tiles, unless I rotate device - xamarin.forms

I am using xamarin forms map for a tracking application, so the view tends to move across the landscape and tiles need to be loaded to show the new area. I am scrolling using map.MoveToRegion
Sometimes the map tiles are loading extremely slowly, to the point where the entire region is just white with no graphics. Initially I thought it was a data speed issue, but it turns out that if I rotate the device, changing the layout landscape/portrait, this makes the map instantly refresh, so the data was apparently available, it was just not being rendered. Zooming can have the same effect, albeit not quite as effectively.
How can I force a refresh, or alternatively just make the map refresh more quickly?

Turns out the issue is that the way to move the forms.map is by MoveToRegion, and that animates the motion. If the animation takes one second and new positions are being set at a higher, or equal, frequency, the map is effectively always in the middle of an animation.
When the map is animating, it is not willing to refresh the tiles, and so the map eventually becomes blank.
When I rotated the device, this constant animation was interrupted, and it could refresh the tile graphics.
The solution was to make a custom renderer with an alternative - non animated - method to move map focus.
private void moveToFast(Location location)
{
var update = CameraUpdateFactory.NewLatLng(new
Android.Gms.Maps.Model.LatLng(location.Latitude, location.Longitude));
googleMap.MoveCamera(update);
}
There are plenty of examples of custom map renderes, so I will not post that here. The main takeaway is really just that...
while the map is animating, it will not refresh its tiles, so if you constantly update the map location, you should do so in a non-animated way.

Related

leafletjs setMaxBounds wont let zoom out to see whole world

I am using leaflet js to show a world map using cloudmade tiles. When I setMaxBounds to the map the bounds work great except to north. That is, however, not my biggest concern. My concern is, as I use maxBounds I can not zoom out to see whole world in any screen size.
The bound I used reaches all the way from north east corner of canada to south west of australia. I can pan to reach the bounds but cant zoom out to see whole map. I set minZoom to 0. Without maxBound, it is zoomed out too far you can see the world repeat thrice on big screen.
map = L.map('canvas',{zoomControl: false}).setView([38.82259, -2.8125], 0);
map.setMaxBounds([[84.67351256610522, -174.0234375], [-58.995311187950925, 223.2421875]]);
Any help is appriciated.
Anil
If I understand correctly, your problem is that you want to be able to see the entire world in your view, but you want to be able to restrict the user from seeing the tiles wrapped around.
First, Leaflet is doing exactly what you are telling it to do. Check out this JSFiddle I created with your code. http://jsfiddle.net/zF6bf/ I can zoom out to see the entire world, but only if I resize the result pane to be large enough to show the entire world, without violating your maxBounds rule. This appears to be correct behavior to me.
Second, if you really do not want the world to wrap, you can also set the noWrap option to true when creating a layer.
var osmLayer = new L.TileLayer("http://{s}.tile.openstreetmap.org/{z}/{x}/{y}.png", { noWrap: true}).addTo(map);
This will prevent that layer from wrapping around the map. If this wrapping is what made you create the bounds in the first place, then perhaps removing the wrapping will remove your need to set the maxBounds. Then the map will be able to be panned and zoomed freely.

Creating a permanent static overlay for QGraphicsView scene

I am making an app using Qt (currently 4.8) which displays a literal map from a large number of QGraphicsScene items. I would like to annotate the view with a scale. My requirement for the scale is that it is permanently fixed w.r.t the viewport widget. It needs to be updated whenever the view scale changes (zoom in, etc). There are other possible overlay items as well (compass, etc) so I'd prefer a generic solution.
I have looked at earlier questions around this which suggest:
using the ItemIgnoresTransform
using an overlay pixmap.
I tried IgnoresTransform but that way didn't work right: I couldn't figure out how to fix it in place in (say) the bottom corner of the viewport and was having some difficulty getting the text and lines always displaying in the correct size.
I scrapped that and subclassed QGraphicsView, adding an overlay pixmap by reimplementing the paintEvent (calls original one, then paints the overlay pixmap on top), and an alignment option to indicate where it goes. Coding some pixmap paint code produces a usable scale on the view. Yay! ... but it doesn't work with scrolls - I get "shattered" renderings of the scale all over, or sometimes no scale at all. I think this is because QGraphicsView::scrollViewportBy() uses viewport()->scroll() so I wondered if switching to ViewportSmartUpdate would help, but it doesn't help enough. I'd prefer not to switch to ViewportFullUpdate as that would likely slow the app down too much (there are millions of items in the scene and that would require a full repaint just to move around).
So. Any ideas from here? Would adapting my pixmap code to write to a new mostly-transparent Widget that is overlaid on the viewport be a better way?
Thanks for any help...
Though it may not be the best way of doing this, in the past I've added custom widgets to the window that holds the QGraphicsView / QGraphicsScene, which have the same graphic style as the QGraphicObjects in the scene. When the view is then used to move objects in the scene, or the scene itself, the items on the window remain in the same place.
Hope that helps.

Google map api overlay takes controls

I'm displaying an image over the entire google map. The image is transparent. I follower the documentation from google and everything worked out fine. The image will change each time i move or zoom on the map. After a while I can't zoom or move the map anymore, I'm zooming and moving only the image. Why does this happen and how can I solve it?
There are multiple issues contributing to problems on the page:
You are destroying and recreating your overlay on center_changed and zoom_changed events. Instead, you should just be updating the image within the overlay. You should really only need to create the overlay once.
Instead of adding your weather image to your OverlayView, you are adding it to a div that covers the map. This is what is blocking your events from effecting the map (the click and drag events are occurring on your weather div not the map).

Handling overlays on Google Streetview custom panoramas

i'm trying to use overlays on a custom google StreetView Panorama.
I was able to simply put one on my pano, but the position is totally random (i made some attempts until the effect was alright), and the change of rendering mode (in chrome which renders as a sphere) changes the effect.
The problem is clear: the custom panorama has no information about its dimensions (it has only a LatLng), so the relative positions are wrong.
Am i missing something?
The only thing i need is to put some clickable labels on the walls of a room, which modify themselves along with the rotating panorama. I searched a lot, but my efforts were inconclusive.
Mapsicle seemed to do what i needed, but if i understood correcly it's a dead project.

Moving a Flex GUI window confused by underlying Papervision3D viewport

I'm developing a Flex 2 application, and I noticed that part of the library which is responsible for moving GUI windows (TitleWindows) around when you drag them with the mouse gets confused if there is a clickable (buttonMode = true) sprite beneath them. When I say confused, I mean that the window is moved around normally for a while, but then at some point "jumps" into the upper left corner of the flash app, and makes very minor movement there. Then at some other point it jumps back. It is more difficult to explain than to experience, so please go and see for yourself. Here's how to reproduce the problem:
Go to http://www.panocast.com
In the left sidebar, choose "Real Estate"
Just below the bottom right corner of the flash window, choose "high res" by clicking on the rightmost icon.
When (part of) the video loads, click on the staircase. A TitleWindow will pop up.
Try dragging it around the screen. When the mouse cursor is moved above one of the clickable areas (like the staircase), the window is misplaced.
(Sorry, but can't give you a direct link, part of the page is generated dynamically.)
(What's makes the problem even more interesting is that for me, in "low res" mode, the problem does not occur! There is very little difference between the various modes.) I would really appreciate if someone told me what was going on here and how it can be fixed.
I'm not sure if it matters, but the underlying sprite is actually not just plain sprite, rather it is a Papervision3D renderer object with some 3D elements in it. I'm telling this because it is possible that the incorrect mouse coordinates somehow come from the texture UV mapped on the clickable objects.
I've managed to replicate this on the low res mode as well, so I don't think it's related to the resolution.
This looks to be because the MouseEvent is being handled by the TitleWindow AND the Papervision3D window. Perhaps you need to force stopImmediatePropagation() on one or the other? Or maybe switch off the MouseEvent handling for the Pv3D window when the TitleWindow pops up?
That's a tough one to debug without some source; something's apparently calling either move() or setting x and y properties on that TitleWindow and scheduling it be moved.
When I first read the post, it "smelled" like maybe a rotation miscalculation somewhere (using Math.atan vs. Math.atan2 can sometimes have that kind of effect), so you're right, it could have something to do with PaperVision, assuming you're not using Math.atan or setting rotation properties yourself anywhere. Just thought I'd mention it, though it's probably not happening in your case. You never know, though. ;)
More likely the LayoutManager is moving the component in response to a property change on the component. The Flex docs explain that in addition to setting its x and y properties, and explicit calls to move(), a UIComponent's move event can also be triggered when any of the following other properties change:
minWidth
minHeight
maxWidth
maxHeight
explicitWidth
explicitHeight
PaperVision or no, maybe that info might help you isolate the source of the move. Good luck.
I got this figured out. Apparently, this is a Papervision3D problem. There is a class deep inside Papervision3D called VirtualMouse, which is supposed to generate MouseEvents programmatically. This happens, for example, when the user interacts with any of the interactive objects on stage, e.g., a Plane with an interactive material on it (as in my case).
The problem is that the x and y coordinates of the generated event represent texture UV coordinates (just as I suspected) and not real world screen coordinates. When a TitleWindow (or any Panel object) is dragged, a "mouseMove" handler (among others) is added to the SystemManager, which then uses the stageX and stageY properties of the event object to determine the new position of the window. Unfortunately for VirtualMouse's mouse events, these are invalid, since the original x,y coordinates, which are probably used to determine the global stage coordinates are, as I said, not screen coordinates.
Honestly, I'm still unsure whether the events dispatched by VirtualMouse are used anywhere within Papervision3D itself, or they are just offered for convenience, but they sure make it difficult to integrate a viewport into a Flex program. Assuming that such events aren't necessary for PV3D itself, there is a one-liner fix for my problem, which must be added right after the creation of the viewport:
viewport.interactiveSceneManager.virtualMouse.
disableEvent(MouseEvent.MOUSE_MOVE);
BTW., there was a very similar (or rather, as it turns out, the same) bug with dragging sliders, also fixed by this line.

Resources