What steps will reproduce the problem? 1. run the first attached html file, posTgtPt01.htm in a browser and observe the orientation of the arrow - straight up. 2. Close the session and open the second file, posTgtPt02.htm in the browser. This is identical to the first but with the heading of the icon and the LookAt increased by 45 degrees. The Icon is no longer straight up, but at an angle to the left.

What is the expected output or behavior? Expect to see the Icon still straight up as we have changed the heading of both the Icon and the lookAt by the same amount.

What do you see instead? The Icon is now angled at around 45 degrees to the left. I have tested further values - from 0 to 45 the variation increases to the left, from 45 to 90 it decreases to 0, from 90 to 135, it increases to the right and from 135 to 180, it decreases back to zero. From 180 to 360 the pattern is repeated. This bug was introduced in the version that first exhibited the Icon Name incorrect orientation that we reported in bug report 113. At the time we thought we had a bug in our code, but the above test demonstrates otherwise.

Which plugin version are you using? Current - 4.3.11528.8566

Which browsers and operating systems are affected? FireFox 3.0.5, IE 6.0.2900

Please provide any additional information (code snippets/links) below. In previous versions and the current Google Earth, the icon is displayed as a flat object in a plane that remains perpendicular to the LookAt irrespective of the lookAt's orientation. In this version of geplugin the plane of the icon appears to vary depending on the lookAt's orientation.

You may have fixed this in development, but if not, I have a thought on what mey be causing this. I had a similar problem - of directions not being true at different angles ... they were OK at the Cardinal points (N,S,E,W) and furthest off at NE,SW,SW and NW. That was caused by me incorrectly converting from distance (metres) North and East to lat/lon degrees, by MULTIPLYING the distance East (along the latitude) by cos(lat) INSTEAD OF DIVIDING by cos(lat) (D'OH). Just a thought. I'm REEEEALLY looking forward to a fix! Cheers,

Fixed as of 5.0.11655.6079.

http://code.google.com/apis/earth/documentation/releasenotes.html#2009-03-31

I don't think you have fixed this issue in Google Earth Plug-in, version 5.0.11655.6079. My program still displays the icons incorrectly. When I downloaded the two examples in my initial report (above) - they still display the documented mis-behaviour. Specifically, posTgtPt02.htm displays the arrow pointing off to the left.

Repro'd. Looks like we missed something. Apologies for the misinformation.

Bulk edit.

Fixed as of 5.1.3506.3999 (API v1.003); see announcement here:

http://groups.google.com/group/google-earth-api-notify/browse_thread/thread/6a32fdfcc60236e

If this issue is still not fixed, please let us know.

"Fixed as of 5.1.3506.3999 (API v1.003)" No, I'm afraid not... My problem demo at the top of this thread still misbehaves as before. I'm convinced this bug is all but unfixable, given the complex behaviour of Placemark icons (2D objects in a 3D world and auto scaling depending on camera range), so I have moved away from placemark icons to represent the target in my animations to using models - which are just fabulous!

My real bugbear is the "near clipping plane" bug (not strictly Plugin I know) which I would LOVE you guys to crack.

Keep up the good work - it's a fabulous product.

Urgh :-) This bug is haunting me. Will check into this again soon.

My project is based on the placemark icon heading using the map heading as specified in the API reference.

I think, before 5.1, the heading worked correctly, i.e. using the map heading, not the screen heading.

Please fix it soon!

Can the latest problem reporters verify this with 5.1.3533.1731?

Well done you guys ... my reported error is resolved in 5.1.3533.1731. Thanks for the dedication. Unfortunately it doesn't help me as I long ago abandoned using placemark icons to represent my target locations and am having lots of success with using models.

Now, please, oh! please, can you fix the "near clipping plane" issue #120 which was reported before this one (Dec 12 08) and has been confirmed as a bug.

Because after 5.1 icon heading behaves different, I think there should be two options for icon heading: 1. Do not rearrange the heading of placemark after view has been changed. It means placemark anchored and can not turn. 2. Always follow the screen top edge.

Can the latest problem reporters verify this with 5.1.3533.1731?

No. I have updated to 5.1.3533.1731 and there is no change.

The bug is described in detail in my post: http://groups.google.com/group/google-earth-browser-plugin/msg/c0b4f37125c2df77?hl=en

In comment 19, serhatalyurt suggests two options:

Option 1 is how the GE application works, confirmed by the KML reference, and how the API used to work. Option 2 is how it works in 5.1.3533.1731

Two options would be OK but if only one option is possible, option 1 should be the one ,being in line with the GE application and the KML reference.

I see, despite two recent posting 19 and 20, the issue's status is still "fixed", ,when clearly it is not.

Still an issue with 5.1.3533.1731. Used to work with version 4. Now icon rotates with the screen, where it is supposed to have the geographic heading.

I am using Google Earth Pro v5.1.3509.4636 (beta) and it's not working. barryhunter (KML Guru) at the developer forum pointed me to this post. I am attaching 2 images. Image1.png is the correct orientation of the arrows with N arrow pointing at 0 degree. Image2.png is the in-correct orientation of the arrows with N arrow pointing at 90 degree (based on diagram on this page: http://code.google.com/apis/kml/documentation/kmlreference.html#headingdiagram)

I'm satisfied that the problem as stated has been solved. I'm not sure what problem is being reported by Cyclope above as we can't see the issue in GE - a png image doesn't do it full justice. My interpretation of the icon behaviour is that its orientation follows the orientation of the Navigation Control, but it remains in the plane of the camera (or screen) and follows some undocumented rules about sizing - but which roughly keeps it visible at all ranges. I would also point out that his reference is related to the orientation of the lookAt, not the Icon, which is a bit confusing.

If you "view" or "download" Cyclope's two pngs, , the issue is clear, the wind direction icons do not follow the orientation of the Navigation Control but it remains in the orientation of the screen.

Here is another example of the problem:

Oops!

My similar issue is resolved. Turns out, I had what is now an invalid in my placemarks. It used to be OK in GE 4, but in GE 5, the bad with a # sign would cause the to be ignored.

I dealt directly with Cyclope and that was his problem as well - an invalid

Comment deleted

I don't understand why I can't use a styleUrl and a Style for the same placemark.

I have a document-level Style id="balloonStyle" for info windows. I have hundreds of Placemarks organized into folders with special Style for icons (wind barbs) with heading. I want the balloonStyle to be applied to all

Why does this snippet cause icons with heading to not obey the heading? I've tried #balloonStyle and balloonStyle. Both don't work. Removing the styleUrl allows the icon to have fixed heading again.

Is it because the balloonStyle is document-level, not folder-level? That doesn't make sense from an inheritance standpoint.

Weather Stations Generated: 2010-01-19 22:03:45 UTC

Only stations reporting within 3 hours are included in this document.

http://www.example.com/barb.php?spd=4&dir=74&val=7&col=65280&dia=100 -117.1323,32.115332,0

Comment deleted

Re Comment 30

Again, I have a similar bug, which was not in 5.0.11733.9347 but is in 5.1.3533.1731.

The problem occurs when an inline icon style with heading overrides a shared style. The heading is now to the screen heading, not the map heading. This is contrary to the KML Handbook, which is incidentally uses # in the tag.

Spectra Dials Gallery 1.2 0

http://www.artisanindustrials.com/Images/SundialWorldImages/ArtisanSpectraSunIcon.png

Spectra Sundials AUSTRALIA Bacchus Marsh Victoria Australia Bacchus Marsh VIC, Australia Latitude:37°41'S Longitude:144°26'E

    ]]></description>
<LookAt>
    <longitude>144.437663</longitude>
    <latitude>-37.675855</latitude>
    <altitude>0</altitude>
    <range>6133.616211</range>
    <tilt>0</tilt>
    <heading>180</heading>
    <altitudeMode></altitudeMode>
</LookAt>
<styleUrl>#sundial</styleUrl>
<Style>
    <IconStyle>
        <scale>1.2</scale>
        <heading>180</heading>
        <Icon>

http://www.artisanindustrials.com/Images/SundialWorldImages/ArtisanSpectraSunIcon.png 144.437663,-37.675855,0

I need the shared styles, so removing the is not an option.

Icon heading is a key elementin KML, particularly in navigation and meteorology

Can we know when the problem will be sorted, after all, it was not there until 5.1 ?

Comment deleted

Comment 34

At least can we recognize that the issue 131 is not fixed ?

There is a difference in icon heading in different versions of the plugin: in version 5.2.0.5932 it works as map heading in version 5.2.1.1329 it works as screen heading I would prefer that it will work as map heading. Is there a possibility to define it as map / screen heading?

The above kml examples seem to work for me the same in the client and the plugin in v 5.2.1.1329.

For example, if I load the sundials kml pasted above, I see the styleUrl is appropriately inherited (you can test by removing the Icon and Href from the individual placemark) and the Heading is also functioning (changing this value causes the heading to change appropriately - eg it is overriding the shared style.

If you are seeing something different can you reply with an example kml and a screenshot that shows the issue?

Comment deleted

Comment deleted

Comment deleted

Comment deleted

If you inadvertantly set the Icon heading to 0 (as I did!) you will see the icons always oriented North.

A little more experimentation reveals that if you have a element at all, even if it's or , then the icon will be oriented to the terrain. The only way I can see to keep it oriented to the screen is to avoid the element altogether. This behaviour is what I think has changed in 5.2.1 KML2.2 doco says: " Direction (that is, North, South, East, West), in degrees. Default=0 (North). (See diagram.) Values range from 0 to 360 degrees." It's the default=0 (North) that's a bit unclear. I wonder just what does that really mean, as when it's absent it doesn't default to North, it defaults to the screen orientation. It doesn't define what the behaviour is when is absent. Maybe we should beware of this as some enthusiastic Google engineer migh "fix this bug" which would scupper us all!

Thanks a lot for the additional details and research. If I understand the more recent comments correctly, it sounds like - inheritance currently works as expected (issue fixed) - the plugin acts the same way the downloadable client acts (current concerns are no longer plugin specific) - the current behavior of both is acceptable/expected - there is a concern about lack of clarity in the KML reference, specifically regarding the change in heading style from when is entirely omitted, versus whether any , including an empty (default North) one, is added.

If this is incorrect, or I've left anything out here, let me know. If not, please feel free to make a new issue at http://code.google.com/p/earth-issues/ for clarification in the documentation, and I will link that to an internal request to follow up on this.

I think that clarifies the issue for me. As you say, it's about the clarity in the KML reference - that the behaviour when is entirely omitted.

The problem I described occurs when using the earth api without any kml. I added one line of code to the creating placemarks example in the google code playground:

placemark.getStyleSelector().getIconStyle().setHeading(0);

Attached you can find the screenshots for the plugin versions 5.2.0.5932 and 5.2.1.1329: in version 5.2.0.5932 it works as map heading in version 5.2.1.1329 it works as screen heading

In our project I want to show the map heading, but some of the users see the icons as screen heading.

I'm afraid all you have demonstrated is that 5.2.1 is working to specification. SetHeading(0) is supposed to set the heading to 0 degrees - North. What you have demonstrated is that 5.2.0 had a bug which has been fixed in 5.2.1. Sorry.

But if i use SetHeading(90) the same problem occurs.

I agree, that's certainly wrong! Setting the heading to 90 should orient the icon to point East, not, as the demo shows, to have it point to the right of the screen irrespective of the orientation of the camera. I didn't test with different heading values, just the existance or absence of the element, so didn't see this. So you're correct this is certainly a bug, and I retract my confirmation that 5.2.1 is working to specification - it isn't.

And here's the problem: the API is generating an unwanted and unexpected screenUp element as you can see from the output from getKml() in the attached screen shot! Running 5.2.1

This problem just started for me today 1/1/11. I have not worked on my code for 2 months and it worked then. Is this going to be fixed or do we have to write workaround code. It can be done, but it is a performance hit. Please issue an expected date of repair as this is obviously a PRIORITY 1 ERROR!

Thanks for the additional details on this new issue. You can keep track of the status of this at issue #492

Hi, I'm a developer for Google Earth.

Yes this is a known bug and we are working on fixing it.

We also have a workaround/fix that will be forward compatible for you! The trick here is that you will need to create your IconStyle using text.

As gpsanimator correctly notes, there is an undocumented tag that is being assigned to the which will be released in a future client which is . screenUp is assigned by default iff the value is initially 0. If the value is something other than 0, northUp is being assigned.

Read that again.

Okay still with me? The reason why we do it this way is to emulate the way that earth used to use IconHeading before we had explicit heading modes. Unfortunately it also means that as soon as the headingMode is assigned it's (semi)permanent as far as the js developer is concerned.

Workaround:

Create your with northUp as kml text and parse it with the appropriate javascript apis (ge.parseKml() I assume).

Zach

Thank you for your help. This fixed the problem for me but created a new one. I have not played around much, but it seems that I can not use this method "inline" in the placemark while inheriting attributes from a global style. Example, I can not make a style, referenced with then modify just the heading inline in the placemark.

Do you know of an easy way around this without having to modify all my styles in-line when rotation is desired? I would love to set color/icon/hotspot globally and just mod heading in the placemark tag.

Brings me to another question. How far back does this tag work? I'm using GE EC 5.1.3533.1731 and it works.

Is there any way we can expedite the "documented" nature of this feature so we can all use it? Example, from what I read in your comment, it sounded like to make "90" point "East" that I wanted to use northUp, but I'm using screenUp and 90 points East.