Closed GoogleCodeExporter closed 9 years ago
Original comment by api.roman.public@gmail.com
on 5 Jan 2009 at 5:00
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
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
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
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
Original comment by api.roman.public@gmail.com
on 22 May 2009 at 1:39
Original comment by api.roman.public@gmail.com
on 22 May 2009 at 1:56
Original comment by api.roman.public@gmail.com
on 22 May 2009 at 1:56
Original comment by api.roman.public@gmail.com
on 9 Aug 2009 at 12:52
Bulk edit.
Original comment by api.roman.public@gmail.com
on 9 Aug 2009 at 1:02
Original comment by api.roman.public@gmail.com
on 9 Aug 2009 at 1:12
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
"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
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
Original comment by api.roman.public@gmail.com
on 18 Sep 2009 at 9:34
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
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
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
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
>>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
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
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
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:
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
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:
Oops!
Original comment by pw240...@gmail.com
on 24 Dec 2009 at 9:24
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:
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
[deleted comment]
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
[deleted comment]
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
[deleted comment]
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
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
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
[deleted comment]
[deleted comment]
[deleted comment]
[deleted comment]
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
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
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
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
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:
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
But if i use SetHeading(90) the same problem occurs.
Original comment by norbert....@gmail.com
on 3 Aug 2010 at 12:00
Attachments:
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
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:
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
Original issue reported on code.google.com by
gpsanima...@gmail.com
on 27 Dec 2008 at 7:24Attachments: