Infeasible
Status Update
Comments
yo...@gmail.com <yo...@gmail.com> #2
Just to make sure I understand the request, you want LatLng coordinates translated to
absolute pixel coordinates? Is that correct?
absolute pixel coordinates? Is that correct?
wi...@gmail.com <wi...@gmail.com> #3
Filing the feature request, but please confirm my question above.
cb...@google.com <cb...@google.com> #4
Yes, absolute pixel coordinates.
[Deleted User] <[Deleted User]> #5
Sorry, I just woke up, i meant to say. Yes, absolute pixel coordinates. Thanks for
the response :)
the response :)
[Deleted User] <[Deleted User]> #6
Got it, thanks!
wa...@gmail.com <wa...@gmail.com> #8
Unfortunately, I can't speak for the "fromLatLngToPixel" crowd, but I can say that
I/we use (and would like in v3) "fromContainerPixelToLatLng". We use it specifically
to get a wider bounds for populating map markers.
In more detail:
When a user views a map, we create a buffer -- let's say 200 extra pixels on all
sides, and use the corresponding lat/lng bounds to get a set of data points within
the map through AJAX. This way when a user moves the map just a little within the 200
pixel buffer we don't have to do another AJAX request. It's essentially just a box
outside of the box. Without "fromContainerPixelToLatLng" we can't get accurate
lat/lng for the buffer box.
Correct me if I'm wrong, but wouldn't creating an Overlay (at least as described in
your examples) just be unnecessary overhead?
I/we use (and would like in v3) "fromContainerPixelToLatLng". We use it specifically
to get a wider bounds for populating map markers.
In more detail:
When a user views a map, we create a buffer -- let's say 200 extra pixels on all
sides, and use the corresponding lat/lng bounds to get a set of data points within
the map through AJAX. This way when a user moves the map just a little within the 200
pixel buffer we don't have to do another AJAX request. It's essentially just a box
outside of the box. Without "fromContainerPixelToLatLng" we can't get accurate
lat/lng for the buffer box.
Correct me if I'm wrong, but wouldn't creating an Overlay (at least as described in
your examples) just be unnecessary overhead?
cb...@google.com <cb...@google.com>
ti...@gmail.com <ti...@gmail.com> #9
Tariqseif, you can do this currently by subclassing an OverlayView to display a fixed
viewport over a map. Granted this isn't the intended use case for an OverlayView (is
more of a custom control), it's certainly doable.
Check out the example I hacked up:
http://savedbythegoog.appspot.com/?id=ag5zYXZlZGJ5dGhlZ29vZ3ISCxIJU2F2ZWRDb2RlGL318AEM
viewport over a map. Granted this isn't the intended use case for an OverlayView (is
more of a custom control), it's certainly doable.
Check out the example I hacked up:
jo...@gmail.com <jo...@gmail.com> #10
I third the motion for disabling continuous zoom
re...@gmail.com <re...@gmail.com> #11
Updated the title to reflect the equivalent v2 method missing from v3 which would
resolve this.
resolve this.
ti...@gmail.com <ti...@gmail.com> #12
Cross-posted with 1794: this request (1523) is different from 1794 feature request.
1523 is about converting absolute screen pixel coordinate into LatLng coordinates,
while 1794 is about getting map offset data from API to get absolute pixel
coordinates. While I may want to have LatLng in some cases, in other cases I do not
(for example, if I operate with tiles). Although it's possible to convert LatLng back
to pixels I'd like to avoid this unnecessary step.
1523 is about converting absolute screen pixel coordinate into LatLng coordinates,
while 1794 is about getting map offset data from API to get absolute pixel
coordinates. While I may want to have LatLng in some cases, in other cases I do not
(for example, if I operate with tiles). Although it's possible to convert LatLng back
to pixels I'd like to avoid this unnecessary step.
ac...@gmail.com <ac...@gmail.com> #13
Also, a suggestion for google folks: when you merge issues I think it makes sense to
combine their ratings (as long as they are from different users).
combine their ratings (as long as they are from different users).
cb...@google.com <cb...@google.com>
ac...@gmail.com <ac...@gmail.com> #14
What you're describing are different use cases of the same feature, which is the
ability to convert pixel coordinates relative to the developer provided map canvas
container to lat/lng coordinates on the map and vice versa. With this capability
added, you can then calculate absolute pixel coordinates, etc.
I understand the request. However, I'm still not understanding what it is you're
specifically trying to do and why. For instance, if your intent is to position an
HTML container of some kind relative to the map canvas container you provided, for
what scenario would you ever need to translate these coordinates to lat/lng on the
map? Are you seeking to place a fixed position HTML container over the map which
doesn't move as the map is dragged? Even in this case, why do you need to calculate
the lat/lng coordinates underneath it?
It's important to note the v3 API doesn't yet support custom tile overlays nor does
it support custom map controls. These should not be part of your justification to
add this feature and are instead completely separate feature requests. In other
words, I'm trying to isolate what it is you really want from the API. This request
sounds more like a workaround to add a feature not currently supported by the API,
e.g. custom controls/tiles.
Please followup with any comments on this issue.
ability to convert pixel coordinates relative to the developer provided map canvas
container to lat/lng coordinates on the map and vice versa. With this capability
added, you can then calculate absolute pixel coordinates, etc.
I understand the request. However, I'm still not understanding what it is you're
specifically trying to do and why. For instance, if your intent is to position an
HTML container of some kind relative to the map canvas container you provided, for
what scenario would you ever need to translate these coordinates to lat/lng on the
map? Are you seeking to place a fixed position HTML container over the map which
doesn't move as the map is dragged? Even in this case, why do you need to calculate
the lat/lng coordinates underneath it?
It's important to note the v3 API doesn't yet support custom tile overlays nor does
it support custom map controls. These should not be part of your justification to
add this feature and are instead completely separate feature requests. In other
words, I'm trying to isolate what it is you really want from the API. This request
sounds more like a workaround to add a feature not currently supported by the API,
e.g. custom controls/tiles.
Please followup with any comments on this issue.
re...@gmail.com <re...@gmail.com> #15
d... the "hacked up example" you gave will hopefully help serve my purposes, but I will
take a look at it today and report back. I can say, however, that my portion of this
feature request has nothing to do with custom controls/tiler and everything to do with
marker management. Thanks!
take a look at it today and report back. I can say, however, that my portion of this
feature request has nothing to do with custom controls/tiler and everything to do with
marker management. Thanks!
an...@gmail.com <an...@gmail.com> #16
I have a similar problem:
How can I get bounds coordinates (four LatLng corners) by center's LatLng point,
width and height in pixels and zoom level?
I must calculate them on a server side - no javascript can be used.
"fromContainerPixelToLatLng" math formulas will be the best way.
How can I get bounds coordinates (four LatLng corners) by center's LatLng point,
width and height in pixels and zoom level?
I must calculate them on a server side - no javascript can be used.
"fromContainerPixelToLatLng" math formulas will be the best way.
cb...@google.com <cb...@google.com> #17
ba...@gmail.com <ba...@gmail.com> #18
re...@gmail.com <re...@gmail.com> #19
[Comment deleted]
re...@gmail.com <re...@gmail.com> #20
Well if this bug isn't going to be fixed, I opened another similar ticket here - specifically addressing the "Zooming/Stretching" effect that occurs on markers inside of a Custom OverlayView. As this is really what is killing my production applications.
http://code.google.com/p/gmaps-api-issues/issues/detail?id=3397
ms...@gmail.com <ms...@gmail.com> #21
Well, no, you didnt' fix the root of the problem because the root is that zoom animation is something not under user control. That's what I requested.
Thanks a lot.
Thanks a lot.
an...@gmail.com <an...@gmail.com> #22
Can a Google engineer please elaborate on what was fixed? I've got a map with lots of markers animating reeeeaaalllyyyyy slowly (latest Chrome) and I'd love to turn off the animated zoom.
ba...@gmail.com <ba...@gmail.com> #23
What was 'fixed' was now the API doesnt use continuous zoom when changing more than 2 zoom levels at once.
This addresses one of the undirsable affects of the continuous zoom. It doesnt address them all :(
Andybak, you should probably star
http://code.google.com/p/gmaps-api-issues/issues/detail?id=3266
This addresses one of the undirsable affects of the continuous zoom. It doesnt address them all :(
Andybak, you should probably star
me...@gmail.com <me...@gmail.com> #24
I am really confused as to why the ability to disable continuous zoom is protected. It was exposed when it was first released, forcing animation is ALWAYS a bad idea; especially when working with JS. Even on the chrome browser, with all of its wonderful JS improvements, if I do only several operations (or even having a tile layer overlay); the bad performance is noticeable.
[Deleted User] <[Deleted User]> #25
I agree - I just went to try to figure out how to turn it off, and I can't! Please allow this to be an option, thanks! :)
ma...@gmail.com <ma...@gmail.com> #26
I've been working on a client project recently,
and I was so frustrated until I found an easy workaround for this issue.
1) Override the mousewheel event:http://www.adomas.org/javascript-mouse-wheel/
Instead of applying the event to the window object, attach it to the maps container to not affect other page components.
2) Now, when the mousewheel event is triggered, instantly hide all markers from the map (you probably got them stored in some array). After that, according to the »delta« value of above mentioned script, zoom in or out with the setZoom function.
3) When the zoom (or even drag) interaction has finished, the map triggers the »idle« event. Use this one to restore all markers by setting them to visible again.
This is the only solution I have figured out so far.
The only thing that remains is replacing Google's default zoom control. You will probably have to disable it and replace it with your own one. This is still in progress in my case.
and I was so frustrated until I found an easy workaround for this issue.
1) Override the mousewheel event:
Instead of applying the event to the window object, attach it to the maps container to not affect other page components.
2) Now, when the mousewheel event is triggered, instantly hide all markers from the map (you probably got them stored in some array). After that, according to the »delta« value of above mentioned script, zoom in or out with the setZoom function.
3) When the zoom (or even drag) interaction has finished, the map triggers the »idle« event. Use this one to restore all markers by setting them to visible again.
This is the only solution I have figured out so far.
The only thing that remains is replacing Google's default zoom control. You will probably have to disable it and replace it with your own one. This is still in progress in my case.
gu...@gmail.com <gu...@gmail.com> #27
There's been no comments on this for a few months but I want to add my voice to the chorus here. Enforcing animation on zoom is bad. Developers should be able to disable it. I have a project that uses many map overlays and in Chrome the animation makes the zoom transitions very slow. The net result is that often my project functions better in other browsers, which is surely NOT the result Google would want.
It surprises me that the Google Maps devs don't seem to understand how irritating this is for other developers.
It surprises me that the Google Maps devs don't seem to understand how irritating this is for other developers.
ff...@googlemail.com <ff...@googlemail.com> #28
I have the same problem on my machine with Chromium Embedded. If I add overlays like the directions renderer it seems that rendering couldn't be finished correctly. Very often it shows very ugly tile-mirroring (the tiles are displayed upside-down) or other graphic waste on zooming. Sometimes the directions renderer isn't displayed anymore.
*WHY* is there no option to disable the animated zoom?
I agree with comment #25 and #28. Developers (and users!) should be able to switch off animations, especially in JS environments.
*WHY* is there no option to disable the animated zoom?
I agree with
ze...@gmail.com <ze...@gmail.com> #29
I believe the problem is that the Google engineers work with the latest high end computers, so they are incapable of noticing the issue.
ze...@gmail.com <ze...@gmail.com> #30
Well, you can disable the map chunks fade-in/fade-out transitions adding an !important CSS rule to the map:
* {
-webkit-transition-property: none!important;
transition-property: none!important;
/* These doesn't affect anything, but, just in case. */
-webkit-animation: none!important;
animation: none!important;
}
It does increase the overall performance a bit while loading the map, but the zooming animations are still there, I believe those are made in the canvas, and I think are done by JavaScript...
* {
-webkit-transition-property: none!important;
transition-property: none!important;
/* These doesn't affect anything, but, just in case. */
-webkit-animation: none!important;
animation: none!important;
}
It does increase the overall performance a bit while loading the map, but the zooming animations are still there, I believe those are made in the canvas, and I think are done by JavaScript...
re...@gmail.com <re...@gmail.com> #31
[Comment deleted]
se...@gmail.com <se...@gmail.com> #32
[Comment deleted]
se...@gmail.com <se...@gmail.com> #33
Been in contact with Google Maps premiere support.
There is an undocumented setting in the map options that does this (at least on v3.9):
gMap.setOptions({
animatedZoom: false,
...
});
There is an undocumented setting in the map options that does this (at least on v3.9):
gMap.setOptions({
animatedZoom: false,
...
});
ad...@gmail.com <ad...@gmail.com> #34
The map.setOptions({animatedZoom:false}) trick doesn't work for me.
So much for "lighter" code in v3...
So much for "lighter" code in v3...
lu...@gmail.com <lu...@gmail.com> #35
Is there any motivation - somewhere, anywhere - for why this is set to Wont Fix?
For all the reasons mentioned in the previous comments, this would be an excellent improvement to the API. There doesn't seem much feedback from the maintainers on this issue.
For all the reasons mentioned in the previous comments, this would be an excellent improvement to the API. There doesn't seem much feedback from the maintainers on this issue.
ba...@gmail.com <ba...@gmail.com> #36
1) The developers dont think its needed. Adding it as a documented feature, would mean a long term commitment to maintain it. With every new release of the API, would then have to test animatedZoom set both to true and false on very browser. Lots of additional testing (and hence rounds of bugfixing).
2) Brand dilution, and inconsistency to users. Users get used to Google Maps working in a certain way, with an option it will invariably mean different maps will work differently. Real or not, its a consideration that it could.
2) Brand dilution, and inconsistency to users. Users get used to Google Maps working in a certain way, with an option it will invariably mean different maps will work differently. Real or not, its a consideration that it could.
jo...@gmail.com <jo...@gmail.com> #37
The Google Maps API is currently the only Mapping API that does not allow the disabling of animation. There are very valid reasons for being able to disable animation especially if you are doing more than just show some markers on a map.
This is just bad form essentially enforcing what amounts to an aesthetic. It also feels subtly patronizing.
This is just bad form essentially enforcing what amounts to an aesthetic. It also feels subtly patronizing.
me...@gmail.com <me...@gmail.com> #38
I have figured out a code hack to disable continuous zoom. You need to call map.panTo(map.getCenter()); right after you call setZoom.
function noContinuousZoomIn() {
map.setZoom(map.getZoom() + 1);
map.panTo(map.getCenter());
}
I have no idea the performance implications of this but it effectively allows you to disable the animated zoom.
function noContinuousZoomIn() {
map.setZoom(map.getZoom() + 1);
map.panTo(map.getCenter());
}
I have no idea the performance implications of this but it effectively allows you to disable the animated zoom.
fu...@gmail.com <fu...@gmail.com> #39
This is very much needed still, why has this not been added! We are experiencing crashes with a large number of layers which doesn't occur if the zoom level is increased by more than 2
fl...@gmail.com <fl...@gmail.com> #40
Please make "animatedZoom" - some applications don't require this.
ho...@gmail.com <ho...@gmail.com> #41
I have tried #38
, but that was not really working for me, who knows why. (And yep, this is still an issue in late '21.) I managed to disable it by calling setZoom
twice. This way there are twice as many zoom calls, but none of them is continuous zoom. I have not really noticed anywhere the effect of the first setZoom
call.
function instantZoom(newZoom) {
// just add a number here such that abs(currentZoom - newZoom - arbitraryNumber) > 2
const arbitraryNumber = 3;
map.setZoom(newZoom + arbitraryNumber);
map.setZoom(newZoom);
}
ro...@doordash.com <ro...@doordash.com> #42
Comment has been deleted.
rk...@gmail.com <rk...@gmail.com> #43
Is there fix my prolem? nah please help me i really hope animatedZoom of property.
goodevs! i wish release this
goodevs! i wish release this
ve...@gmail.com <ve...@gmail.com> #44
The map.setOptions({isFractionalZoomEnabled:true}) worked for me (v3.53)
Description
The problem with the animation is that it's completely uncontrollable and there's know way of knowing what the map exactly displays during the animation. For my application that's undesirable because I paint and overlay over map and the content needs to be in sync with what the map displays. If I don't know the location and extents, I can't paint to the right coordinates.
Thanks!
Markus