GE removes x/y/w/h parameters from Icon href

[GoogleCodeExporter]

1)  Create a KML a ScreenOverlay such that the Icon href has any of these 
parameters:

<Icon>
  <href>http://testserver/foo.png?
a=1&amp;h=8&amp;i=9&amp;w=23&amp;x=24&amp;y=25&amp;z=26</href>
</Icon>

2)  Right click the Image overlay and note that in the Properties, the 
x/y/w/h params have been removed.

The 2.2 spec notes that x/y/w/h are indeed deprecated, but this implies it 
should only matter if you are using these as elements under the icon*, and 
not in the href itself, as shown here:

<Icon>
          <href>http://test/foo</href>
          <x>100</x>
</Icon>

Original issue reported on code.google.com by jli...@google.com on 23 Mar 2010 at 6:38

[GoogleCodeExporter]

See also https://groups.google.com/group/kml-support-getting-
started/browse_thread/thread/9e9f773f7b8aabed for related discussion.

One workaround is to url-encode x, y, w and h (%78, %79, %77 and %68 
respectively).

Original comment by jli...@google.com on 23 Mar 2010 at 6:42

[GoogleCodeExporter]

I am working on a KMLServer which generates SuperOverlay for existing image 
system. Unfortunately this system has the x= and y= parameters in the URL, and 
they are removed by GE.

The urlencoded %78 and %79 queries does not run in my case (it seems the server 
does not accept the encoded url in this form and GE does not decode them before 
submitting the HTTP query probably). When I was testing urlencoded queries on 
my own scripts it was running, but not in case of the image system (which 
handle the requests internally).

Is there any scheduled work on this issue?

Right now I don't see any possibility how to display the images in GE. Is there 
any other workaround then changing the server, as it is technically not 
possible - it is a proprietary product with thousands of images already 
available trough it - transcoding of all these is unmanageable.

Thank you for answer.

Original comment by klo...@gmail.com on 11 Oct 2010 at 5:13

[GoogleCodeExporter]

Hi there,

Can you confirm you are still seeing this issue in the latest 5.2.1.1588 
release?

Original comment by jli...@google.com on 11 Oct 2010 at 5:24

[GoogleCodeExporter]

Yes. Tested with 5.2.1.1588 on Mac - both in the plug-in and the desktop 
application. Should I send you an example KML?

BTW Thanks for super fast reaction.

Original comment by klo...@gmail.com on 11 Oct 2010 at 5:36

[GoogleCodeExporter]

Yes, please go ahead and attach a KML.  If you happen to also have a server url 
to test against that could be useful.  Feel free to send me these directly if 
needed.

Original comment by jli...@google.com on 11 Oct 2010 at 5:44

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Thanks for the details:  I've confirmed this is still an issue with the latest 
5.2 release and informed the team.  The only workaround I am aware of right now 
is the urlencoding, which as you note unfortunately will not necessarily be 
respected by all servers.  

Original comment by jli...@google.com on 12 Oct 2010 at 4:41

[GoogleCodeExporter]

Tested with new Google Earth 6.0. This bug is still an open issue.

The workaround fix would be quite easy - it is done in five minutes by anybody 
who has access to the source code of Google Earth and it does not introduce any 
regression:

Just replace the four url-encoded strings ("%78", "%79", "%77", "%68") in the 
URL by their true meaning ("x","y","w","h") before the query is submitted to 
the Internet. It is maximally four lines of code and the patch is clean and 
this issue fixed!

The KML demonstrating the problem was submitted to Josh. I am also attaching it 
now here to maximally simplify the testing of this issue to anybody who is 
involved.

Original comment by klo...@gmail.com on 2 Dec 2010 at 4:40

Attachments:

• xywh-test.kml

[GoogleCodeExporter]

Fix is currently in for review. We are targeting this fix for the 6.1 client.

FYI, the fix was a little bit more involved because of some other behavior that 
relied on this stripping behavior and the proper fix was too risky to put in 
for the 6.0 client.

Also, thanks for the KML sample!

Original comment by nite...@google.com on 3 Dec 2010 at 3:23

[GoogleCodeExporter]

Great! Thank you a lot. I am looking forward to test the GE 6.1 ;-).

Original comment by klo...@gmail.com on 3 Dec 2010 at 8:15

[GoogleCodeExporter]

Hi Josh at al,

it seems that the fix of this issue has never made it into production. After 
almost two years the latest GE still displays the xywh-test.kml in a wrong way 
and the x and y request are not correctly passed and there is no workaround for 
servers which do not accept url-encoded requests.

Any chance this ticket will be once marked as "fixed"? :-)

Original comment by klo...@gmail.com on 4 Sep 2012 at 4:20

[GoogleCodeExporter]

This issue is still present in:
Google Earth     6.2.2.6613
Build Date       4/11/2012
Build Time       10:28:06 pm

Original comment by mikefirt...@googlemail.com on 11 Dec 2012 at 8:28