search

fmgagliano / earth-api-samples

Automatically exported from code.google.com/p/earth-api-samples
0 stars 0 forks source link

Icon heading displayed incorrectly. #131

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
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.

Original issue reported on code.google.com by gpsanima...@gmail.com on 27 Dec 2008 at 7:24

Attachments:

GoogleCodeExporter commented 8 years ago

Original comment by api.roman.public@gmail.com on 5 Jan 2009 at 5:00

GoogleCodeExporter commented 8 years ago 
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,

Original comment by gpsanima...@gmail.com on 9 Feb 2009 at 6:05

GoogleCodeExporter commented 8 years ago 
Fixed as of 5.0.11655.6079.

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

Original comment by api.roman.public@gmail.com on 2 Apr 2009 at 12:01

GoogleCodeExporter commented 8 years ago 
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.

Original comment by gpsanima...@gmail.com on 4 Apr 2009 at 6:08

GoogleCodeExporter commented 8 years ago 
Repro'd. Looks like we missed something. Apologies for the misinformation.

Original comment by api.roman.public@gmail.com on 6 Apr 2009 at 5:47

GoogleCodeExporter commented 8 years ago

Original comment by api.roman.public@gmail.com on 22 May 2009 at 1:39

GoogleCodeExporter commented 8 years ago

Original comment by api.roman.public@gmail.com on 22 May 2009 at 1:56

GoogleCodeExporter commented 8 years ago

Original comment by api.roman.public@gmail.com on 22 May 2009 at 1:56

GoogleCodeExporter commented 8 years ago

Original comment by api.roman.public@gmail.com on 9 Aug 2009 at 12:52

GoogleCodeExporter commented 8 years ago 
Bulk edit.

Original comment by api.roman.public@gmail.com on 9 Aug 2009 at 1:02

GoogleCodeExporter commented 8 years ago

Original comment by api.roman.public@gmail.com on 9 Aug 2009 at 1:12

GoogleCodeExporter commented 8 years ago 
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/6a32
fdfcc60236e

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

Original comment by api.roman.public@gmail.com on 9 Sep 2009 at 10:17

GoogleCodeExporter commented 8 years ago 
"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.

Original comment by gpsanima...@gmail.com on 9 Sep 2009 at 11:02

GoogleCodeExporter commented 8 years ago 
Urgh :-) This bug is haunting me. Will check into this again soon.

Original comment by api.roman.public@gmail.com on 10 Sep 2009 at 6:16

GoogleCodeExporter commented 8 years ago

Original comment by api.roman.public@gmail.com on 18 Sep 2009 at 9:34

GoogleCodeExporter commented 8 years ago 
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!

Original comment by pw240...@gmail.com on 8 Nov 2009 at 9:54

GoogleCodeExporter commented 8 years ago 
Can the latest problem reporters verify this with 5.1.3533.1731?

Original comment by api.roman.public@gmail.com on 24 Nov 2009 at 4:19

GoogleCodeExporter commented 8 years ago 
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.

Original comment by gpsanima...@gmail.com on 24 Nov 2009 at 9:04

GoogleCodeExporter commented 8 years ago 
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.

Original comment by serhatal...@gmail.com on 25 Nov 2009 at 9:34

GoogleCodeExporter commented 8 years ago 
>>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.

Original comment by pw240...@gmail.com on 30 Nov 2009 at 12:21

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

Original comment by pw240...@gmail.com on 8 Dec 2009 at 11:29

GoogleCodeExporter commented 8 years ago 
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.

Original comment by msperlin...@gtempaccount.com on 9 Dec 2009 at 6:13

GoogleCodeExporter commented 8 years ago 
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)

Original comment by Cyclope....@gmail.com on 22 Dec 2009 at 10:59

Attachments:

GoogleCodeExporter commented 8 years ago 
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.

Original comment by gpsanima...@gmail.com on 22 Dec 2009 at 10:20

GoogleCodeExporter commented 8 years ago 
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:

Original comment by pw240...@gmail.com on 24 Dec 2009 at 9:20

Attachments:

GoogleCodeExporter commented 8 years ago 
Oops!

Original comment by pw240...@gmail.com on 24 Dec 2009 at 9:24

GoogleCodeExporter commented 8 years ago 
My similar issue is resolved.  Turns out, I had what is now an invalid 
<styleUrl> in 
my placemarks.  It used to be OK in GE 4, but in GE 5, the bad <styleUrl> with 
a # 
sign would cause the <icon><heading> to be ignored.

Original comment by msperlin...@gtempaccount.com on 28 Dec 2009 at 4:06

Attachments:

GoogleCodeExporter commented 8 years ago 
I dealt directly with Cyclope and that was his problem as well - an invalid 
<styleUrl>

Original comment by gpsanima...@gmail.com on 28 Dec 2009 at 7:48

GoogleCodeExporter commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago 
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
<styleUrl>#balloonStyle</styleUrl> and <styleUrl>balloonStyle</styleUrl>.  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.

<?xml version="1.0" encoding="UTF-8"?>
<kml xmlns="http://www.opengis.net/kml/2.2"
xmlns:gx="http://www.google.com/kml/ext/2.2"
xmlns:kml="http://www.opengis.net/kml/2.2" 
xmlns:atom="http://www.w3.org/2005/Atom">
<Document>
  <name>Weather Stations</name>
  <description><![CDATA[<p>Generated: 2010-01-19 22:03:45 UTC</p> <p>Only stations
reporting within 3 hours are included in this document.</p>]]></description>
  <open>1</open>
  <Style>
    <ListStyle>
      <listItemType>radioFolder</listItemType>
      <bgColor>00ffffff</bgColor>
      <maxSnippetLines>2</maxSnippetLines>
    </ListStyle>
  </Style>
  <Style id="balloonStyle">
    <BalloonStyle>
      <text><![CDATA[
      <h2 style="font-size:1.1em;border-bottom:solid #333 1px;">Instrument: 
      $[name]</h2>
      $[description]
      ]]></text>
    </BalloonStyle>
  </Style>
  <Folder>
    <name>Visibility and Avg Winds</name>
    <Style>
      <ListStyle>
        <listItemType>checkHideChildren</listItemType>
        <bgColor>00ffffff</bgColor>
        <maxSnippetLines>2</maxSnippetLines>
      </ListStyle>
    </Style>
    <visibility>0</visibility>
    <Placemark>
      <name>Any Instrument ID</name>
      <description><![CDATA[ <p><font color="#999">Sample Date</font></p> <div>Data
Table Here</div>]]></description>
      <styleUrl>#balloonStyle</styleUrl>
      <Style>
        <IconStyle>
          <scale>3.25</scale>
          <heading>0</heading>
          <Icon>

<href>http://www.example.com/barb.php?spd=4&dir=74&val=7&col=65280&dia=100</href
>
          </Icon>
        </IconStyle>
      </Style>
      <Point>
        <coordinates>-117.1323,32.115332,0</coordinates>
      </Point>
    </Placemark>
  </Folder>
</Document>
</kml>

Original comment by preu...@gmail.com on 19 Jan 2010 at 11:23

GoogleCodeExporter commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago 
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 <styleUrl> tag.

<?xml version="1.0" encoding="UTF-8"?>
<kml xmlns="http://www.opengis.net/kml/2.2"
xmlns:gx="http://www.google.com/kml/ext/2.2"  
xmlns:atom="http://www.w3.org/2005/Atom">
<Document>
<name>Spectra Dials Gallery</name>
<Style id="sundial">
<IconStyle>
    <scale>1.2</scale>
    <heading>0</heading>
    <Icon>

<href>http://www.artisanindustrials.com/Images/SundialWorldImages/ArtisanSpectra
SunIcon.png</href>
    </Icon>
</IconStyle>
</Style>

<Folder id= "Spectra Sundials">
<name>Spectra Sundials</name>
<Folder id = 'Australia'>
<name>AUSTRALIA</name>
<Placemark id = 'Bacchus Marsh VIC, Australia'>
    <name>Bacchus Marsh Victoria Australia</name>
    <address>Bacchus Marsh VIC, Australia</address>
    <description><![CDATA[
        <br>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>

<href>http://www.artisanindustrials.com/Images/SundialWorldImages/ArtisanSpectra
SunIcon.png</href>
            </Icon>
        </IconStyle>
    </Style>
    <Point>
        <coordinates>144.437663,-37.675855,0</coordinates>
    </Point>
</Placemark>
</Folder>
</Folder>
</Document>
</kml>

I need the shared styles, so removing the <styleUrl> 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 ?

Original comment by pw240...@gmail.com on 1 Feb 2010 at 11:15

GoogleCodeExporter commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago 
Comment 34

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

Original comment by pw240...@gmail.com on 19 May 2010 at 4:51

GoogleCodeExporter commented 8 years ago 
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?

Original comment by norbert....@gmail.com on 2 Aug 2010 at 11:57

GoogleCodeExporter commented 8 years ago 
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?

Original comment by jli...@google.com on 2 Aug 2010 at 4:14

GoogleCodeExporter commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago 
If you inadvertantly set the Icon heading to 0 (as I did!) you will see the 
icons always oriented North.

Original comment by gpsanima...@gmail.com on 2 Aug 2010 at 11:22

GoogleCodeExporter commented 8 years ago 
A little more experimentation reveals that if you have a <heading> element at 
all, even if it's <heading/> or <heading></heading>, 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 <heading> element altogether.
This behaviour is what I think has changed in 5.2.1
KML2.2 doco says:
"<heading>
    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 <heading> is absent. Maybe we should beware of this as 
some enthusiastic Google engineer migh "fix this bug" which would scupper us 
all!

Original comment by gpsanima...@gmail.com on 3 Aug 2010 at 12:40

GoogleCodeExporter commented 8 years ago 
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 <heading> is entirely omitted, versus whether any <heading>, 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.

Original comment by jli...@google.com on 3 Aug 2010 at 3:07

GoogleCodeExporter commented 8 years ago 
I think that clarifies the issue for me. As you say, it's about the clarity in 
the KML reference - that the behaviour when <heading> is entirely omitted.

Original comment by gpsanima...@gmail.com on 3 Aug 2010 at 4:14

GoogleCodeExporter commented 8 years ago 
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.

Original comment by norbert....@gmail.com on 3 Aug 2010 at 7:24

Attachments:

GoogleCodeExporter commented 8 years ago 
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.

Original comment by gpsanima...@gmail.com on 3 Aug 2010 at 11:24

GoogleCodeExporter commented 8 years ago 
But if i use SetHeading(90) the same problem occurs.

Original comment by norbert....@gmail.com on 3 Aug 2010 at 12:00

Attachments:

GoogleCodeExporter commented 8 years ago 
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 <heading> 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.

Original comment by gpsanima...@gmail.com on 3 Aug 2010 at 10:30

GoogleCodeExporter commented 8 years ago 
And here's the problem: the API is generating an unwanted and unexpected  
<gx:headingMode>screenUp</gxHeadingMode> element as you can see from the output 
from getKml() in the attached screen shot!
Running 5.2.1

Original comment by gpsanima...@gmail.com on 3 Aug 2010 at 10:59

Attachments:

GoogleCodeExporter commented 8 years ago 
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!

Original comment by j...@simxlive.com on 2 Jan 2011 at 5:09