I have a heatmap and set of markers that are rendering fine in OpenLayers. Afterwards, when I change the center of the map programmatically using map.setCenter the heatmap appears offset by exactly double the change of center location. (So if the new center is 1km east, the heatmap appears offset by 2km east)
It's almost as though the redrawing of the heatmap layer is over compensating.
Has anyone come across this before and solved it? I've tried called heatmapLayer.redraw() to no avail.
I'm using OpenLayers 2.13.1 and Patrick Weid's heatmap.js' openlayers support.
I've managed to find a fix. No idea why this seems to work though when heatmaplayer.redraw() doesn't.
For the benefit of others:-
this.map.setCenter( new OpenLayers.LonLat(lon,lat).transform(
this.transformWgs84, this.map.projection), zoom,true,true);
the second 'true' did the trick. According to the OpenLayers docs this should just force a zoom change. It seems to also force a heatmap layer redraw. (The first true parameter forces drag events)
Docs: http://dev.openlayers.org/docs/files/OpenLayers/Map-js.html#OpenLayers.Map.setCenter
Related
I'm trying to create a circular masked overlay using Leaflet 0.8 that is positioned over the users currently location, extending a radius of 1000 meters. Essentially making the map visible around the user (as a circle), and grayed out beyond 1000 meters
Mockup:
As the user zooms in/out on the map, the circle should resize accordingly.
I tried using leaflet-maskcanvas, a plugin for Leaflet that looks like it would do exactly what I need, unfortunately with all refactoring done in Leaflet 0.8-dev, this plugin isn't compatible.
Has anyone been able to achieve this effect successfully with Leaflet 0.8?
I'm thinking of one hacky way of doing this is using Turf.js to take the map's current center point(map.getCenter()), buffer it 1000 meters with Turf, take that result, and then grab the map viewport's current bounds(map.getBounds()), and use turf erase on it. Then draw the resulting polygon on the map(which is the difference), and then update this on any move events.
http://turfjs.org/static/docs/module-turf_buffer.html
http://turfjs.org/static/docs/module-turf_intersect.html
http://turfjs.org/static/docs/module-turf_erase.html
I am building a tiled map based on d3. So I found the corresponding d3 example and copy pasted its code to start my implementation. I need to add overlays to the map so went on and discovered they were misplaced and did not follow the map tiles when zooming. I spent a lot of time bisecting the difference between my adapted copy-paste and the original example and found out this was due to the fact that the example uses v2 of d3 and I am using v3.
My findings is that the main change between v2 and v3 is the behavior of the zoom and translation together. So I tested by zooming and printing the translation vector, and my findings are:
In v2, the projection.translate vector is kept unchanged if the mouse cursor is on the (lat,long) = 0,0) on the initial tile.
In v3, the projection.translate vector is kept unchanged if the mouse cursor is on the top left (most NW point) of the initial tile.
I've made a fiddle in which I copy-pasted the example code, added my debug dots that should cover the earth plus a dot on Paris to see if alignment with the tiles is correct.
You will note that Paris is not correctly placed, (but would be if you run this on d3 v2).
So I guess now there is just some Math to do on my side to update the initial example logic, probably where the tile_origin or tile translation computation.is made. I just started to try to fix them but this seem not trivial. So I am asking here if anybody has an idea of what to change in the example to have it working in v3 (i.e. having a red dot following Paris whatever the zoom level is).
I also could not find any related change in the v3 changelog, if any knows what exactly changed this could help me.
Ok so the best solution is to start from scratch from a v3 example, like http://bl.ocks.org/mbostock/4132797 (which I tried and succeeded with) or http://bl.ocks.org/mbostock/4150951 as Lars Kotthoff commented.
We have a legacy website from which the powers-that-be have decided we need to remove all of our Google maps, replacing them with maps provided by MapBox. So I'm in the middle of a crash project to swap out the old for the new.
And here's my problem: the old site is written in ASP.NET, making heavy use of Telerik's controls. In this page we have a RadSplitter, and a Google map being drawn in a RadPane.
Swapping out the Google map with the MapBox map was simple enough, except that the MapBox map isn't rendering correctly. Only the tiles along the left edge of the pane are drawing. But - when I resize the browser window, the rest of the tiles draw.
The div is defined with position: absolute, and top, bottom, right, and left set to 0. Which Google maps worked with.
My guess is that Telerik is doing something that is confusing the MapBox rendering code about the actual size of the div. And that when the window resizes, MapBox re-evaluates things, and gets it right.
I've been playing around with this for a couple of hours now, and getting nowhere:
I've tried triggering a resize event in code, and the tiles didn't draw.
I've tried placing the map in a fixed-size div, inside the pane, and the map drew to the edges, and then the div sat inside the pane with scrollbars, which confirms, to me, that I'm dealing with a sizing issue, but I can't have the scrollbars, so
I've tried setting the width and height of the div to the size of the pane, in code, and that didn't trigger the map to draw the missing panes.
I'm running out of ideas.
Is there some event or function on the MapBox renderer that will cause it to redraw the way it does when the browser resizes?
Turns out the answer was pretty simple:
map.invalidateSize();
Edited - a few days layer
Turns out that only works in IE. In Chrome, invalidateSize() doesn't cause the map to properly resize itself.
so the map is being drawn in a pseudo-frame, which is probably throwing off the calculations for what's "visible"...
do you have a way of sharing the actual output HTML? like jsfiddle?
are there any console errors? maybe it's something as simple as you've met your quota for the map tile server...
try a different tile server?
everyone. Recently, we have faced one problem about the speed of loading google map components on different broswer. Regarding to the function , we have added 120 polygons, 360 sector ( also polygon ) and several attributes which attach to components on the map. The verson of JS tool is Google Map Javascript V3.
Now, this module is running fast and smoothly on Chrome and Foxfire broswer. HOWEVER, terreble problem would occur on IE8 or IE9. The process about loading informations into map becomes very slow, also during the period of dragging or zooming the map, which can not be accepted by users.
So, is there any solution about acceleration in this situation ?
Thank you very much for any reply !
In my experience it's just IE being IE.
I would suggest scaling down the number of polygons you need to show at one time by using the map bounds as the criteria to filter by. You'll still end up running into issues if you let the users zoom out to show the whole map so you may want to limit zoom levels as well.
If you take all the points that make up your polygon and push(extend) them to a LatLngBounds you can grab the bounding box and check to see if the center of that bounding box is in the map's current bounds.
In GoogleMaps when users zooms In/Out using mouse wheel the point under cursor stays the same (its coordinates), but OpenLayers map has different approach - when zooming center of the map is constant. Can one use GoogleMaps zoom style in OpenLayers map?
EDIT:
Actually current behaviour in my OpenLayers is that when I zoom in with some position under the cursor it moves that position to map center on the next zoom level. Probably it is some issue related to my map specific settings (like projection).
I guess you are using OpenLayers.Control.MouseDefaults control for navigation. Well, you shouldn't, because this control is replaced with OpenLayers.Control.Navigation and will be deprecated in OpenLayers 3.0.
A quick look at source code for MouseDefaults shows that it definitely centers map on the cursor position:
defaultWheelDown: function(evt) {
if (this.map.getZoom() > 0) {
this.map.setCenter(this.map.getLonLatFromPixel(evt.xy),
this.map.getZoom() - 1);
}
},
While cursor stays at the same position the map will centered to new location every time you zoom in/out, which is confusing.
OpenLayers.Control.Navigation uses the same approach as Google Maps. OpenStreetMap uses it and you can see that it works the same way here
Actually, when looking at the Basic Example at OpenLayers, it seems like the map zooms around the mouse pointer, just as Google Maps does. Or am I missing some detail in your question?