IssueTracker

We have been made aware of several customer issues in the past few days with SSL/TLS due to this rollout having resumed.

At this stage, the best course of action is to ensure that your client TLS stack can dynamically work with intermediary certificates signed by any of the (~40) root CAs from https://pki.goog/roots.pem.

In other words, the root CA signing intermediary certificates for requests to https://maps.googleapis.com/* cannot be assumed to be static, nor can the set of root CAs be expected not to change before they expire.

We have published FAQs at the following addresses: https://pki.goog/faq/ is more high-level, and https://developers.google.com/maps/root-ca-faq is more technical.

Please note that many tools will only display and/or import the first certificate from https://pki.goog/roots.pem, which will not be sufficient to fix this situation.
Here are several sources that can be used to help you split the root.pem file into 1 file per certificate, if required by your tooling and software environment:

- https://developers.google.com/maps/root-ca-faq#how_do_i_extract_individual_certificates_from_rootspem
- https://geeklah.com/working_with_pem_files.html
- https://stackoverflow.com/questions/14660767/keytool-importing-multiple-certificates-in-single-file

As an immediate fix to get your Google Maps Platform requests working again, the main certificate to install is the "GTS Root R1" certificate, which begins at line 896 in the current roots.pem file. Please note that this issue may reoccur in the future if you don't install all the certificates.

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?

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?

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

Updated the title to reflect the equivalent v2 method missing from v3 which would
resolve this.

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.

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).

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.

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!

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.

Now with custom map types, we've exposed this function as part of MapCanvasProjection:
http://code.google.com/apis/maps/documentation/v3/overlays.html#CustomMapTypes

There is now a related request: http://code.google.com/p/gmaps-api-issues/issues/detail?id=2879
You may be interested to vote it...