Fixed
Status Update
Comments
d....@gtempaccount.com <d....@gtempaccount.com> #2
CORRECTION: this is only pertaining to Scorecards, I'm aware I can do this on a table. My apologies.
d....@gtempaccount.com <d....@gtempaccount.com> #3
Filing the feature request, but please confirm my question above.
bb...@gmail.com <bb...@gmail.com> #4
Yes, absolute pixel coordinates.
bb...@gmail.com <bb...@gmail.com> #5
Sorry, I just woke up, i meant to say. Yes, absolute pixel coordinates. Thanks for
the response :)
the response :)
d....@gtempaccount.com <d....@gtempaccount.com> #6
Got it, thanks!
d....@gtempaccount.com <d....@gtempaccount.com> #7
Can you describe one (or a few) practical use cases where you'd need this instead of
using the one provided by the OverlayView class?
using the one provided by the OverlayView class?
ta...@gmail.com <ta...@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?
d....@gtempaccount.com <d....@gtempaccount.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:
d....@gtempaccount.com <d....@gtempaccount.com> #11
Updated the title to reflect the equivalent v2 method missing from v3 which would
resolve this.
resolve this.
pa...@gmail.com <pa...@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.
pa...@gmail.com <pa...@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).
d....@gtempaccount.com <d....@gtempaccount.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.
ta...@gmail.com <ta...@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!
fe...@gmail.com <fe...@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.
Description
different values since its not evenly spreaded.
Making this feature available in v3 will make it possible for MarkerManager
to work, and perhaps there are more applications who really need this. I've
talked to Berry Ratliff and he has had limited succes in implementing his
own version.
The implementation of Berry can been seen here: