Using Google Maps JavaScript API v3, it is possible to change the zoom of a map using the setZoom method, see the Map class.
I am able to set the zoom to a fractional value and it works, i.e. gmap.setZoom(1.1) works. However, it stops working on the 4th call with a fractionnal zoom, i.e.:
gmap.setZoom(1.1) works
gmap.setZoom(1.2) works
gmap.setZoom(1.3) works
gmap.setZoom(1.4) doesn't work, the map turns grey.
It's not the 1.4 value that doesn't work. Setting 1 then 1.4 does work. It really seems to be on the 4th time that we set a fractionnal value.
Is this a known bug or is there a way to avoid the map to turn grey after multiple zooming using fractionnal zooms?
I'm surprised it works ever. Fractional zoom levels are not supported. From the documentation:
zoom | Type: number
The initial Map zoom level. Required. Valid values: Integers between zero, and up to the supported maximum zoom level.
Related issues in the issue tracker:
Issue 10977: Bug: Zoom cannot be set to e.g. 6.5 initially - map is shown in gray color only
Issue 9948: Fractional zoom level(fine zoom)
Related
Result of my code:
Basically, what the issue is, the transparent part of my image are not blending correctly with what is drawn before it. I know I can do a
if(alpha<=0){discard;}
in the fragment shader, the only issue is I plan on having a ton of fragments and don't want the if statement for each fragment on mobile devices.
Here is my code related to alpha, and depth testing:
var gl = canvas.getContext("webgl2",
{
antialias : false,
alpha : false,
premultipliedAlpha: false,
}
);
gl.enable(gl.BLEND);
gl.blendFunc(gl.SRC_ALPHA, gl.ONE_MINUS_SRC_ALPHA);
gl.enable(gl.DEPTH_TEST);
gl.depthFunc(gl.GREATER);
Also, these are textured gl.POINTS I am drawing. If I change the order the two images are drawn in the buffer, the problem doesn't exist. They will be dynamically rotating during the program's runtime so this is not an option.
It's not clear what your issue is without more code but it looks like a depth test issue.
Assuming I understand correctly you're drawing 2 rectangles? If you draw the red one before the blue one then depending on how you have the depth test setup the blue one will fail the depth test when the X area is drawn.
You generally solve this by sorting what you draw, making sure to draw things further away first.
For a grid of "tiles" you can generally sort by walking the grid itself in the correct direction instead of "sorting"
On the other hand, if all of your transparency is 100% draw or not draw then discard has its advantages and you can draw front to back. The reason is because in that case drawing front to back, the pixel drawn (not discarded) by the red quad will be rejected when drawing the blue quad by the depth test. The depth test is usually optimized to happen before running the fragment shader for a certain pixel. If the depth test says the pixel will not be drawn then no reason to even run the fragment shader for that pixel, time saved. Unfortunately as soon as you have any transparency that is not 100% opaque or 100% transparent then you need to sort and draw back to front. Some of these issues are covered in this article
A few notes:
you mentioned mobile devices and you mentioned WebGL2 in your code sample. There is no WebGL2 on iOS
you said you're drawing with POINTS. The spec says only POINTS of 1 pixel in size are required. It looks like you're safe up to points of size 60 but to be safe it's generally best to draw with triangles as there are other isses with points
you might also be interested in sprites with depth
What are "levels" in polyline encoding/decoding, and exactly how do they relate to map zoom levels in Google Maps API v3 or Android Maps API v2?
The only description I can find is from the Interactive Polyline Encoder Utility:
Polylines in Google Maps are formed as a set of latitude/longitude pairs. In addition, for each vertex (location) in an encoded polyline, a level can be specified indicating that the location should appear on that level and any level higher (i.e. any decrease in zoom.). If a location does not appear on a given level, then the line will go from the last visible location to the next visible location. Note that the first and last locations must be Level 3 points, otherwise the polyline won't display on all levels.
Does "Level 3" correspond to a zoom level of 3 in the Google Maps API v3 or Android Maps API v2?
Here's what a zoom level of 3 looks like in the Google Maps API v3 (no polyline is displayed - this is simply to illustrate what the "zoom level = 3" looks like):
Should a "Level 3" point be displayed if we zoom out one step further, to zoom Level 2?
The quote:
Note that the first and last locations must be Level 3 points, otherwise the polyline won't display on all levels.
...seems to indicate that Level 3 points should be displayed on all levels, including zoom levels 2, 1, and 0.
I'm wondering if the statement:
...a level can be specified indicating that the location should appear on that level and any level higher (i.e. any decrease in zoom.)
...should actually be:
...a level can be specified indicating that the location should appear on that level and any level higher (i.e. any increase in zoom.)
"decrease in zoom" doesn't seem correct, because Level 18 (very zoomed in) points would be rendered on Level 3 (very zoomed out).
"increase in zoom" seems to generally make sense (you'd render a Level 3 zoomed out point also when you zoom in to Level 18 - in other words, you add detail as you zoom in closer to the map) - however, it seems to contradict the statement that Level 3 points should be rendered at lower zoom levels 2, 1, and 0.
On Android, the open-source android-maps-utils library includes a method to decode polylines, but it doesn't handle levels, so I can't tell if there is a readily-available mapping to Android Maps API v2 zoom levels.
Can anyone provide clarity on this?
Levels are an obsolete feature. They controlled whether points were visible at certain zoom levels. They were a significant feature of Google Maps API v2, but you should ignore them now; Google Maps API v3 does it automatically.
zoom level defines the resolution of the current view.
zoom level
0: to encompass the entire earth
1: World
5: Landmass/continent
10:City
15: Streets
20: Buildings
"zoom=12" isused in below exapmle
https://maps.googleapis.com/maps/api/staticmap?center=40.714728,-73.998672&zoom=12&size=400x400&key=YOUR_API_KEY&signature=YOUR_SIGNATURE
I am working on a qwtPlot and have implemented custom scrollbars to illustrate the position of things on the plot when zooming in (in regards to the whole thing - so basically the percentage).
Now, everything works fine, apart from the moment, when I do any zooming or panning right at the beginning (or simply when I see the whole plot and then I want to zoom in).
This is a slot I am using to refresh the appearance of the scrollbar:
void ScrollHorizontal::refreshAfterChanges() {
setValue(myPlot->getLowerBound(QwtPlot::xBottom));
setPageStep(myPlot->get_X_delta());
setSingleStep(myPlot->get_X_delta()/10);
setMaximum(myPlot->dataFromSources->lastTimeValMicro()-pageStep());
update();
printV("HorizontalScroll::setValue",myPlot->getLowerBound(QwtPlot::xBottom));
printV("value", value());
printV("pageStep", pageStep());
in the constructor I set the maximum to 0 (just in case, but it doesn't change anything)
The last 3 lines print out some values useful for debugging. What I found out thanks to them is that the slot is executed correctly, but the setValue(int) function doesn't work as I would expect it to:
//printed values right after starting the program
HorizontalScroll::setValue=0
value=0
pageStep=7320
//printed values after using the zoomer once
HorizontalScroll::setValue=956.316
value=0
pageStep=2225
Then, when I move the plot a tiny bit, e.g. zoom it 1.1 times, the setValue works properly and value() return the same thing I set. But if I go to the 100% view (the starting point) I get the same problems again.
Just to illustrate it, here are some screenshots:
http://tinypic.com/view.php?pic=2znph7s&s=8#.UvNkDoZhauY
(100% view, right before zooming in)
http://tinypic.com/view.php?pic=ke7nn9&s=8#.UvNkYIZhauY
(badly set qscrollbar)
Ok - problem was caused by the line
setMaximum(myPlot->dataFromSources->lastTimeValMicro()-pageStep());
It was setting the maximum to 0 sometimes. why? I wanted the slider to take up the whole length of the scrollbar so that at the beginning when the plot was shown in 100% view, you couldn't scroll it and I could achieve that by setting the pagestep to my plot's maximum value and the maximum to 0.
But that caused the setValue(int)problem - you can't set a value bigger than the maximum.
So what finally worked for me is:
double valueToSet=myPlot->getLowerBound(QwtPlot::xBottom);
if(valueToSet>maximum())
setMaximum(valueToSet);
setValue(myPlot->getLowerBound(QwtPlot::xBottom));
setPageStep(myPlot->get_X_delta());
setSingleStep(myPlot->get_X_delta()/10);
setMaximum(myPlot->dataFromSources->lastTimeValMicro()-pageStep());
update();
I use the Google Maps Javascript API v3 for calculating the directions from my current position to my end destination in an iPad PhoneGap Application.
Now I want to make a function which automatically recalculates the directions, if you take the wrong lane. That means, I will make a marker for the current position on the map and then should check if it's near the directions-polygon, if not recalculate the route.
The directions are printed out in a canvas-element and I couldn't find anything how to compare it with my markers…
Any idea?
The following line works. Just set the tolerance as desired.
google.maps.geometry.poly.isLocationOnEdge (point, polyline, tolerance)
It will return true if point is located in the polyline/ polygen. Let me know if tyhis doesn't work.
axs
There seems to be a huge bug in Markerclusterer/Markerclusterplus for API V3: In (mainly) zoom-level 2 not all markers are clustered.
However, the same behaviour occurs in speedtest examples (demos!) of Googles reference pages: Markercluster with API V2 works fine, but with V3 it does not.
I have put all speed test versions together using iframes, so you can compare the different versions very easy:
http://findini.com/apps/map/markertest/?visit=sec.
No idea. Anyone who knows a workaround?
SOLUTION: Use MarkerClustererPlus from http://code.google.com/p/google-maps-utility-library-v3/wiki/Libraries
There IS a problem with MarkerClusterer.
In createClusters_, the TopRight lat+long are computed, along with the BottomLeft lat+long.
For Zoom levels 3 and higher, TopRight lat > BottomLeft lat and TopRight long > BottomLeft long. These two conditions are ALWAYS true.
But for Zoom level 2, TopRight long is ALWAYS consistently less than BottomLeft long, and this causes all sorts of problems. Hence panning around seems to fix the problem - because it creates conditions for (TopRight long > BottomLeft long) and that causes clustering to work correctly.
For Zoom level 1, the probability of the error condition is lower than for Zoom 2. Hence it may work sometimes, and sometimes not.
I have also experienced this behavior using MarkererClusterer (not sure of the version) and MarkerClustererPlus v2.0.5 (not realizing there were more recent versions). Expanding on the answer provided by #Ranjeet, I upgraded to MarkerClustererPlus v2.0.9 and this seemed to solve the problem. http://google-maps-utility-library-v3.googlecode.com/svn/tags/markerclustererplus/