As the size of the community (and your number of posts!) continues to
grow, we'd like to make sure that we're getting all the right
information from everyone about Earth related bugs. With that in mind,
we've created a template that you can use to report a bug to the
group. Your posts will allow us to collect useful information about
the bugs that you're experiencing.

First and foremost, please make sure to distinguish between a problem
and a bug. We love hearing your feedback on your Google Earth likes
and dislikes, but let's keep this particular thread focused on
features that are broken!

Before you post a bug, remember to search, search, search! You'll find
the search bar in the upper right-hand corner of the Groups page. Take
a look here to find out more about searching effectively:

http://groups.google.com/support/bin/answer.py?answer=46024&topic=9256

Remember folks, you may need to use different terms to find what you
are looking for. You can also look around, browse previous threads in
the group, and check out the Google Earth Help Center at
http://earth.google.com/support

Another biggie is to make sure that you're running Google Earth with
the most recent graphics card driver that is available.  To learn more
about upgrading the graphics card driver specific to your platform,
visit these articles:

Microsoft Windows: http://earth.google.com/support/bin/answer.py?answer=21462

Mac OS X: http://earth.google.com/support/bin/answer.py?answer=32349

The last thing to remember before posting is that not all of our
imagery is in high resolution. Although we have high resolution
coverage for more than half of the world's population, there are some
areas that may still appear blurry. You can check out this article for
more information about blurry imagery:

http://earth.google.com/support/bin/answer.py?answer=21417

And if you've gone through all the above steps, and you're still
pretty sure you've found a bug, post your bug report to this thread
using the following template:

1. Google Earth Version:

2. Operating System (Windows Vista Ultimate 64-bit, Mac OS X 10.4.9,
etc):

3. Summary of issue (including error messages):

4. Links to other posts about this issue (please don't repost bugs):

5. Reproduction Steps/Notes:

6. Workaround (if you've found one):

We'll compile the results and make sure all of your information gets
to the right place, even if we can't reply to every post. We
appreciate your feedback and help as we work to improve Google Earth!

2. Windows Vista Home Premium.

3. Running NVIDIA GeForce 7350 LE video card, driver is 7.15.10.9816 -
checked and there is no newer update. When I sign on, and have borders
"on", the earth's globe appears transparent - and I get to see the
borders from the other side of the earth as well as the side I am
viewing! Some of the borders disappear if I zoom in far enough.

4. No other links/posts.

5. Reproduction isn't necessary - all I have to do is load Google
Earth Plus.

4.1.7076.4458

2. Operating System (Windows Vista Ultimate 64-bit, Mac OS X 10.4.9,
etc):

Ubuntu Feisty Fawn (7.04) Linux (2.6.20.0)

3. Summary of issue (including error messages):
Ok, so I just spent a good hour trying to debug this, as I thought it
might be a problem on my server producing proper KML.  But after
digging I'm 95% sure it's a bug in GE for linux.  When loading KML
files that are polygons, most of the time I get just a big white box
around where the polygon should be.

So I start digging in to things and discover that the Google Earth KML
sample files all work great with linux.  Huh, that's weird, though
reassuring that there's that level of QA.  So I start fiddling trying
to get the samples to break or my output to appear.  After many trials
it comes down to this:

If you have

<extrude>1</extrude>
<altitudeMode>relativeToGround</altitudeMode>

then everything works great.  If you remove those then you get the
white square of death.  Note that this is only the case for polygons.

4. Links to other posts about this issue (please don't repost
bugs):http://groups.google.com/group/earth-linux/browse_thread/thread/
8a60618a3cb30de9/1637cec254802501

5. Reproduction Steps/Notes:

To replicate the bug, go to the sample KML files of polygons of
Google's Campus.  Then remove those two lines:

<extrude>1</extrude>
<altitudeMode>relativeToGround</altitudeMode>

 and you'll see.  Latest release of google earth for linux.  Actually,
you just need to remove altitudeMode, or just switch altitudeMode to
clampToGround and you should see the errors.

6. Workaround (if you've found one):

Windows XP Home SP2

screen overlay images become distorted after they load a second time

other links http://groups.google.com/group/earth-pro/browse_thread/thread/c0979ed...

To Recreate:
1. Load the "KML Samples" (http://code.google.com/apis/kml/
documentation/KML_Samples.kml).
2. Save the "Screen Overlay" section to a local KML file (eg "C:
\Screen Overlays.kml").
3. Remove KML Samples from Temporary Places.
4. Double-click on "C:\Screen Overlays.kml". It will load and display
the screenoverlay images as expected.
5. Double-click again on "C:\Screen Overlays.kml" to load it again.
All screen overlay images are now distorted.

On Jul 18, 12:19 pm, trailblazer9000 wrote:

1. Google Earth Version:
All versions

2. Operating System (Windows Vista Ultimate 64-bit, Mac OS X 10.4.9,
etc):
Any

3. Summary of issue (including error messages):

This is somewhat more of a blundering typographical error than a bug,
and is likely Discovery's problem but Google should be made aware
because it is glaringly obvious and reflects somewhat badly upon
google earth.

In the centre of Sydney's CBD there is a huge Discovery.com link for
our city. It has a massive "D" next to it and is seen from a high zoom
altitude (so all google users looking at our city will see it).

It is embarassingly and ignorantly misspelt "Sidney".

It would be akin to spelling other major world cities "New Yerk" or
"Lindon".

2. Operating System (Windows Vista Ultimate 64-bit, Mac OS X 10.4.9,
etc):
Windows XP (SP2)

3. Summary of issue (including error messages):
  I have a Samsung widescreen monitor, which because of my work I have
configured to work sideways (the long way, like a piece of paper).
When I log onto GoogleEarth, the page itself is correctly oriented as
per the monitor, but the the big sat image of the actual earth is
still going the other way, so it is 90 degrees off and impossible to
control, as well as covering up much of the web page. Help! How do I
fix it so the whole page is oriented the correct way for my monitor?

4. Links to other posts about this issue (please don't repost bugs):
    none that I've found.

5. Reproduction Steps/Notes:
    I click on the Google Earth icon on my desktop and it happens. I
haven't found any way to fix it.

1. Google Earth Version: 4.1.7087.5048 (beta)

2. Operating System: Windows Vista Home Premium

3. Summary of issue (including error messages):
  Label in GPS import dialog is misleading; it merely says "draw icons
at track points", but doesn't mention that it will discard timestamps
and other data for individual track points unless you set it.  It's
not checked by default, so it throws away data unless you tell it not
to.  Better to have the option say something like "preserve individual
point data (time, altitude, etc)"

4. Links to other posts about this issue (please don't repost bugs):
  http://groups.google.com/group/earth-gps/browse_thread/thread/fb62152...

5. Reproduction Steps/Notes:
   Import from GPS and don't check "draw icons"; note that your tracks
are missing timestamps and thus the time slider is useless

6. Workaround (if you've found one):
  When you want to keep altitude, timestamp for a point, make sure
that you check the "create icon" option.

2. Operating System: Windows Vista Home Premium

3. Summary of Issue (including error messages):
  Long lines (eg from London to Johannesburg) are drawn through the
middle of the Earth.  You can set the altitude of each end point, but
it always draws a straight line between them.  Makes plotting airline
routes difficult.

4. Links:
  none I've found

5. Reproduction Steps/Notes:
  Draw line that's long enough for the curvature of the earth to be a
factor.  Note it disappears.

There is a conflict between CA Antivirus and GE4.1. It seems that on
startup, CA AV interprets .kml files as a threat?

6. Workaround:

6.1 Check to see if this is the cause by snoozing the CA AV when
starting GE. GE may work.
6.2 If so, go into CA Antivirus > Advanced Settings > Options  > Real-
Time Scanner Exclusions, and add '*.kml' and '*.kmz' to your
exclusions list. This pokes a hole in your real-time security.

6. Workaround (if you've found one): Don't load this file.

********
Of course this is not a big issue, but it was annoying to me during
development of a tool. It took me some time to discover what was wrong
with a .kml file. An error message like "Expected value at line 8193"
would have been handy.

On Jul 16, 10:28 pm, Earth Ranger SV123 wrote:

4.1.7076.4458 (beta)

2. Operating System (Windows Vista Ultimate 64-bit, Mac OS X 10.4.9,
etc):

Mac OS X 10.4.10

3. Summary of issue (including error messages):

I live in Woodlands Park near Maidenhead in Berkshire, United Kingdom.

The Google Earth placemark for this village is at 51°30'14.12"N
0°45'47.62"W

Google Earth insists on calling this place "Woodland Park" (i.e.
without the "s" on the end of "Woodlands").

Can this be fixed to the correct name (which is "Woodlands Park") as
in this StreetMap reference?

http://www.streetmap.co.uk/newmap.srf?x=485500&y=178500&z=3&sv=woodla...[City/Town/Village]&searchp=newsearch.srf&mapp=newmap.srf

4. Links to other posts about this issue (please don't repost bugs):

None found

5. Reproduction Steps/Notes:

Look for "Woodland Park" vs. "Woodlands Park", Berkshire, UK in Google
Earth

6. Workaround (if you've found one):

1. Google Earth Version: 4.1.7076.4458

2. Operating System (Windows Vista Ultimate 64-bit, Mac OS X 10.4.9,
etc): Debian GNU/Linux 4.0 (Etch)

3. Summary of issue (including error messages): When using the Driving
Directions flying tour feature, especially on routes through
mountainous areas, the camera keeps jumping to a very high altitude
and then descending about every second or so. Apparently someone has
emailed GE support about it with no response. The tour seems to work
fine with GE 4.0. For example, try touring from Lincoln, CA to Sparks,
NV with the default settings.

4. Links to other posts about this issue (please don't repost bugs):

http://groups.google.com/group/earth-plus/browse_thread/thread/b6c527...

http://groups.google.com/group/earth-free/browse_thread/thread/8ed0e4...

5. Reproduction Steps/Notes:

1. Use the default settings for touring

1. Enter "lincoln, ca" in the From: box of the driving directions tab,
and "sparks, nv" in the To: box.

2. Click the magnifying glass button next to the To: box.

3. Click the "Play" button underneath the list of turns to play the
tour.

You will notice the problem after a few seconds.

http://groups.google.com/group/earth-free/browse_thread/thread/8ed0e4...

On Jul 30, 10:24 am, eee wrote:

2. Operating System: Lunar Linux 1.6.0-i686
Kernel 2.6.22.1 on an Athlon64 3000+ (Venice core) 1GB RAM

3. Summary of issue (including error messages):
Something wrong happened to "Google Earth" application->"Help"->"Check
on-line updates" for Linux. Google Earth (ver 4.1.7076.4458) says
there is updated version: 4.1.7087.5048 available for download. Below
there is button with link to:
http://dl.google.com/earth/client/current/GoogleEarthLinux.bin
after download and installation Google Earth displays the same update
dialog.
During GoogleEarthLinux.bin self-unpacking I see:
Uncompressing Google Earth for GNU/Linux 4.1.7076.4458....
So I think someone forgot to update:
http://dl.google.com/earth/client/current/GoogleEarthLinux.bin
with new version. Manual download from Google Earth www pages points
to the
same file link as Google Earth update dialog.

4. Links to other posts about this issue (please don't repost bugs):
http://groups.google.com/group/earth-linux/browse_thread/thread/6d29b...

5. Reproduction Steps/Notes:
1. Run GE
2. In GE menu choose: "Help"->"Check on-line updates"
3. Click on update url to download GE update.
(your default web browser will open and download old GE version)

2. Operating System: all

3. Summary of issue (including error messages):
http://earth.google.com/intl/pl/tour/thanks-linux.html
The page tag: charset= is wrong (is windows-1250, should  be UTF-8)
making non US characters displayed as junk.

There is:
<!-- Inserted by TRADOS: --><META HTTP-EQUIV="content-type"
CONTENT="text/html; charset=windows-1250">

Should be:
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />

4. Links to other posts about this issue (please don't repost bugs):
none

5. Reproduction Steps/Notes:
a. Open web browser
b. Choose Polish as language (restart web browser if required)
c. Open: http://earth.google.com/intl/pl/tour/thanks-linux.html in any
web browser.
You will see some crazy junk inside some words. Manually set charset
to UTF-8 so junk disappears.

2. Operating System: Lunar Linux 1.6.0-i686
Kernel 2.6.22.1 on an Athlon64 3000+ (Venice core) 1GB RAM

3. Summary of issue (including error messages):
--
Google Earth: Missing font
You don't seem to have the Bitstream Vera Sans font installed. Most
Linux distributions should ship with this font preinstalled. If you
don't
have it, you can find a free download and installation instructions at
the
following link. We will continue with whatever font we could find, but
some text may look incorrect.

http://www.gnome.org/fonts/
--

I have this font installed. Every application except GE can see it.

Why Google Earth should _not_ use Bitstream Vera Sans:
Bitstream Vera Sans is very old and not expandable font (due to
license problem which allows free distribution but no changes to it).
That is why this font does _not_ and will _not_ contain non US English/
Western Europe codepages/characters. This is problem as Google Earth
being translated is hard to read using font not supporting for example
Eastern Europe languages.

Google Earth should use instead dejavu font family from http://dejavu.sourceforge.net/
which has this issue resolved and looks very similar to Bitstream Vera
Sans. Almost every Linux distribution have dejavu font installed by
default.

4. Links to other posts about this issue (please don't repost bugs):
http://www.google.pl/search?q=Google+Earth+Bitstream+Vera
19 300 results

5. Reproduction Steps/Notes:
Run GE in Linux and the message will appear during start (on most
Linux distributions)

2. Windows XP Professional/SP2

3. Summary of issue (including error messages):
Dynamic images with "+" in filename do not display in infowindow. A
gray square is shown instead. Pasting the image link into the built-in
browser correctly shows the image, so Google Earth knows how to fetch
and display it.

4. Links to other posts about this issue (please don't repost bugs):
None found; some other posts about dynamic images but those all have
a ? in the link. That bug appears to have been fixed. This is a
dynamic image, but due to URL rewriting, the format of the link makes
it look like a static image, except for the +.

5. Reproduction Steps/Notes:
Create a KML file with the following description tag in a placemark:
<description><![CDATA[<a href="http://127.0.0.1/gallery/v/test/
1203+0003.jpg.html">
<img src="http://127.0.0.1/gallery/d/11907-2/1203+0003.jpg"></
a><br>]]></description>
Note: the important part is the + in the img src.

2. Vista Home Premium

3. EncycloSteve's description matches mine verbatim, (borders appear
through the oceans etc. ie. Madagascar appears off the coast of Long
Island, NY). Zooming in does eliminate some of the borders. The
problem seems to happen with water, and generally not through land
masses. I have the same issue with the GeForce Go 7300 (Acer 5630
notebook with 2GB DDR2). The graphics driver is: NVIDIA Corporation
(00006.00000.06000.16386).  Interestingly, it says that the DirectX
renderer is DX8(?) No error messages appear at any time. I have a
screenshot of both the problem and the settings dialog in the GE
window, but I have no way of attaching that here.

4. This is a reply to EncycloSteve's post about the same issue, but
includes a possible workaround.

5. The issue reproduces itself upon program initialization.

6. The workaround that worked for me regarding this problem was the
use of (ack!) OpenGL rendering instead of the preferred DX rendering.
Seems like a waste of the graphics card, but it works, albeit slowly.

You're not alone, Steve!

On Jul 16, 5:16 pm, EncycloSteve wrote:

1. Google Earth Version:4.1.7087.5048 (beta)

2. Operating System : Windows XP PRO

3. Summary of issue : SCALING ISSUE; I am taking screen shots of
different cities at 1.00 KM. Curitiba, Brazil is WAY off. At 1km it
barely displays an entire block. NO error message. Most of the graphic
information is there for the city, the camera is just wrong.
4. Links to other posts about this issue :

5. Reproduction Steps/Notes:

2. Operating System (Windows Vista Ultimate 64-bit, Mac OS X 10.4.9,
etc):
Microsoft Windows XP (Service Pack 2)

3. Summary of issue (including error messages):
Even if you set the altitude to be shown in kilometers / meters, the
selection
for the ruler (to measure distances) is reset to "miles" every time
you restart the program.

4. Links to other posts about this issue (please don't repost bugs):
N/A

5. Reproduction Steps/Notes:
a) start Google Earth
b) Select the "show ruler" icon
c) Switch "Length" setting from "miles" to "kilometers"
d) close and restart the application (you don't even need to close the
dialog box before)
=> You will see the "Length" to be shown in "miles" again...

6. Workaround (if you've found one):
Change this setting every single time you use Google Earth! - And this
can get really annoying.

2. Operating System: Windows XP Home Edition

3. Summary of issue (including error messages): No error messages. If
I add a place with links to JPEG files on my hard disk there is a not
equal behavior, depending if I want to see just a thumbnail or if I
want to see a high resolution image.

4. Links to other posts about this issue (please don't repost bugs):
no links to other posts

5. Reproduction Steps/Notes: For example, if on Properties-Description
I put:

---snip---
Restaurante de comida chilena en Quebrada Alvarado.<br><a
href="file:///c:/Documents%20and%20Settings/jdiaz/Mis%20documentos/
WDMAM_%20image%20flyer.jpg">click to view full size<br><img
src="file:///c:/Documents%20and%20Settings/jdiaz/Mis%20documentos/
WDMAM_%20image%20flyer_t.jpg">
---snap---

then the thumbnail (WDMAM_ image flyer_t.jpg) is not being displayed
but the high resolution version (WDMAM_ 20image flyer.jpg) is
displayed.

However if I use the following format then both the thumbnail and the
high resolution images are displayed.

---snip---
Restaurante de comida chilena en Quebrada Alvarado.<br><a
href="file:///c:/Documents%20and%20Settings/jdiaz/Mis%20documentos/
WDMAM_%20image%20flyer.jpg">click to view full size<br><img src="c:
\Documents and Settings\jdiaz\Mis documentos\WDMAM_ image
flyer_t.jpg">
---snap---

Interestingly if I use:

---snip---
Restaurante de comida chilena en Quebrada Alvarado.<br><a href="c:
\Documents and Settings\jdiaz\Mis documentos\WDMAM_ image
flyer.jpg">click to view full size<br><img src="c:\Documents and
Settings\jdiaz\Mis documentos\WDMAM_ image flyer_t.jpg">
---snap---

Then again both the thumbnail and the high resolution images are
displayed.

In other words, at least working on Windows it appears that thumbnail
invocation to files on hard disks is only allowed by using the DOS-
format (not using HTML-format). And high resolution images can be
displayed using both formats. To be universal thumbnails should be
invoked using HTML-format too.