Repository: bokeh/bokeh

Issue:
GMap points don't move consistently
When I move around the GMap Plot the points don't move consistently move with the map and appear in a different location.

![screen shot 2014-10-23 at 4 34 07 pm](https://cloud.githubusercontent.com/assets/4940549/4761946/8057af68-5afc-11e4-94a4-350a6dd49813.png)
![screen shot 2014-10-23 at 4 33 29 pm](https://cloud.githubusercontent.com/assets/4940549/4761947/8067b4b2-5afc-11e4-9a29-e599513ea563.png)

We are using this script (plotting.py):

``` python
from bokeh.embed import components
from bokeh.glyphs import Circle
from bokeh.objects import (
    GMapPlot, Range1d, ColumnDataSource,
    PanTool, WheelZoomTool, BoxSelectTool,
    BoxSelectionOverlay, GMapOptions)
from bokeh.resources import CDN

from bokeh.plotting import scatter

def map_builder(column_data_source):

    x_range = Range1d()
    y_range = Range1d()

    map_options = GMapOptions(lat=10, lng=-8, zoom=2) # centers on West Africa

    plot = GMapPlot(
        x_range=x_range, y_range=y_range,
        map_options=map_options,
        # title = "Map"  # Should probably pass a name to map function
    )

    plot.map_options.map_type="hybrid"
    circle = Circle(x="longitude", y="latitude", size=10, fill_color="fill", line_color="black")
    plot.add_glyph(column_data_source, circle)

    pan = PanTool()
    wheel_zoom = WheelZoomTool()
    # TODO Add hover tooltip with extra column data
    plot.add_tools(pan, wheel_zoom)

    return components(plot, CDN)
```

A complete example would be:

``` python
from blaze import *
from bokeh.objects import ColumnDataSource
from plotting import map_builder
 t = Data('/data/geo.csv')
t2 = t[['longitude', 'latitude']]
cds = into(ColumnDataSource, t2)
script, div = map_builder(cds)
```

I'll send you the file.

cc: @bryevdv 



Discussion:
@chdoig where can I find the data?

@bryevdv, I've just sent it to you by email, but just found out there is the same issue with example glyphs/maps.py, so that might be easier to work with anyway.
![austin](https://cloud.githubusercontent.com/assets/4940549/4815890/c8664be8-5eda-11e4-9b8d-e2267d92d139.png)

Just to clarify, this only happens when zoomed far out, correct? After inspecting things at the point that the misplotting occurs, the issue appears to be when, for instance, a negative longitude wraps back over to positive longitude, as happens when zoomed very far out. This will probably require a new mapper type that understands periodic ranges, I doubt it will go in before 0.7 unless someone else can work on it. 

ping @chdoig 

Instead of posting a new issue, I think this is related: even small incremental zooms shift points a little.  Here's an example:

http://jsfiddle.net/u1mk6L4e/

For example, look at the topmost point on the right that's just across the border in Oregon south of Walla Walla.  If you hover, you see that it's Milton Freewater.  The positioning is correct.  Then zoom out one level and you'll see that the point is now north of the border in Washington.  Zoom out again and you see the points drifting north.  One more zoom out and they are now mostly all in WA.  Of course when you zoom out even more they move position completely which is related to what was posted above.

But the small shifts must be due to a different cause than wrapping longitudes.  I wonder if the positioning of the map on the canvas can get off a little?

Also, to mitigate the "zoom way out" issue, support could be added for `maxZoom` and `minZoom` in the google maps api.

Here's another example with a choropleth map overlaid on a GMap plot.  The default view is below.  I played with several initial window dimension / zoom level combinations but it was consistently off.

<img width="903" alt="gmap1" src="https://cloud.githubusercontent.com/assets/1275592/8733365/8b133fd4-2bd1-11e5-93d0-ef31f2dca823.png">

After you zoom in quite a bit, things start to align better.  For example, below, you can start to see county boundaries start to visually align with features of the map:

<img width="902" alt="gmap2" src="https://cloud.githubusercontent.com/assets/1275592/8733433/cb13bd02-2bd1-11e5-919b-b68f0330e045.png">

I don't know if this is a projection issue or an issue or what.

It would be great to figure this out since most of the awesomeness of having a Google map plot is the ability to overlay stuff on top of it, and this needs to be reliable.

Been looking around a little and thought I'd double check before investigating further.  I presume that points are transformed to the appropriate google map projection before being plotted?

http://gis.stackexchange.com/questions/5265/using-the-proj4js-library-to-convert-from-google-maps-to-projected-values

https://alastaira.wordpress.com/2011/01/23/the-google-maps-bing-maps-spherical-mercator-projection/

@hafen no, that's probably what needs to happen

Ok.  I was thinking this maybe should be a thing that the user needs to take care of when specifying the plot, but then I realized that I think that the projection depends on where you are on the map, etc., which means it would need to be done in js on the fly.  I'm not a GIS expert though.

Given tha Greenland shows up as bigger than the US, and also that straight-line 48th parallel I guess I just assumed the gmaps were unprojected.

<img width="1144" alt="screen shot 2015-07-16 at 3 55 24 pm" src="https://cloud.githubusercontent.com/assets/1078448/8734947/1ad3c6ce-2bd3-11e5-99eb-65c5eb01fc3e.png">

@birdsarah @brendancol this might be something one of you could look into. 

Yes that's what I thought.  But turns out it's some kind of mercator projection that preserves angles and is tile friendly.

It will probably be easy enough to apply a transformation to individual coordinates, I doubt we can go as far as trying to transform rect or wedge or line primitives, at least in the short term. So scatter plots will see the most benefit, and other glyphs should be OK (positioned correctly but maybe distorted) on smaller local scales

Yes, rect, wedge, etc. could pose a problem - the coordinates could be transformed, but where the edges end up with things like height, etc., could not.

But in the case of lines and patches, it should be an easy thing to transform, since the entire specification of what to plot is dictated by coordinates.

Should transforming data superposed on a gmap plot be a new issue separate from this one?

Sorry one more comment...  Figuring this out is extremely important as GMap without superposing Bokeh stuff on top isn't too exciting, and with the way it is now, what is plotted cannot be viewed reliably.  Effort here would not be wasted, as I think things like open street map have the same issue.

@damianavila let's see about getting this into a 0.9.3 release 

Fingers crossed for 0.9.4 :)

We are not doing a 0.9.4 before the 0.10 release at the end of the month. I would love to see this fixed for that relaase, but I could really use some help here, I am not actually sure how to fix this. 

ping @brendancol 

Hey @bryevdv, @hafen, I took a look at this and I think made some improvements, but overall I wouldn't say its satisfactory. 

There are two separate issues, I think:
- how we interact/respond to google maps (which I think I've improved)
- having projected axes that match the projection on the tile exactly, so that the coordinates of our glyphs match the coordinates on the tile. (haven't looked at this - but I think it's what's causing the outstanding discrepancies)

some screenshots of where it's at - notice the last one - I would argue the "before" is better

after (left) | before (right) - sorry that's counter-intuitive.

<img width="874" alt="screen shot 2015-09-13 at 5 32 57 am" src="https://cloud.githubusercontent.com/assets/1796208/9836942/1692e7ba-59e2-11e5-8ee1-88d1512c1a93.png">
<img width="1196" alt="screen shot 2015-09-13 at 5 37 06 am" src="https://cloud.githubusercontent.com/assets/1796208/9836948/49f517d6-59e2-11e5-8b08-57e4036bfb9f.png">
<img width="932" alt="screen shot 2015-09-13 at 5 35 07 am" src="https://cloud.githubusercontent.com/assets/1796208/9836950/50074f9a-59e2-11e5-86bb-d724d4511260.png">
<img width="1227" alt="screen shot 2015-09-13 at 5 34 34 am" src="https://cloud.githubusercontent.com/assets/1796208/9836951/550a065e-59e2-11e5-8e0d-5dad26ef7e9c.png">

Well, there is a new ticker that takes explicitly supplied tick locations, maybe this could be used. 

had a good chat with @brendancol - have a clear & short path for a PR that at least is somewhat better.


Resolving patch:
diff --git a/bokeh/models/map_plots.py b/bokeh/models/map_plots.py
--- a/bokeh/models/map_plots.py
+++ b/bokeh/models/map_plots.py
@@ -48,6 +48,10 @@ class GMapOptions(HasProps):
 class GMapPlot(Plot):
     """ A Bokeh Plot with a `Google Map`_ displayed underneath.
 
+    Data placed on this plot should be specified in decimal lat long coordinates e.g. 37.123, -122.404.
+    It will be automatically converted into the web mercator projection to display properly over
+    google maps tiles.
+
     .. _Google Map: https://www.google.com/maps/
 
     """


Test patch: