kml created on the fly works for some, not for others

7 views
Skip to first unread message

Douglas

unread,
Jul 15, 2008, 5:07:05 PM7/15/08
to KML Developer Support - KML Server Side Scripting
Hi,

On my site, I have a link on each page that takes some url parameters
declared in the page ($lat & $long etc) to create a link to a php
script which then writes a kml file on the fly. The browser then
downloads and opens the file with GE.

Apparently this is not what happens for all visitors to my site. Users
of Opera see nothing but the CDATA sectons of the resultant kml file
displayed in the browser window. Some users of Firefox have the kml
file open with dreamweaver or see GE attempt to open the php file and
thus do nothing much Yet, other users see it work perfectly as
intended.

Here is an example link from one particular page:

http://oceandots.com/flyto.php?lat=16.360&long=145.655&place=Anatahan&group=Mariana+Islands

The php script shown below takes the necessary parameters from the url
and creates a kml file

PHP script:

<?php
header("Content-type: application/vnd.google-earth.kml+xml");
echo "<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n";
echo "<kml xmlns=\"http://earth.google.com/kml/2.1\">\n";
echo "<Document>\n";
$lat = $_GET['lat'];
$long = $_GET['long'];
$place = $_GET['place'];
$group = $_GET['group'];
$link = $_SERVER['HTTP_REFERER'];
echo "<Placemark>\n";
echo "<description><![CDATA[$place, $group<br /> lat: $lat, long:
$long<br /><a href='$link'>$place</a> ]]></description>\n";
echo "<name>$place</name>\n";
echo "<LookAt>\n";
echo "<longitude>$long</longitude>\n";
echo "<latitude>$lat</latitude>\n";
echo "<range>5000.00</range>\n";
echo "<tilt>20.0</tilt>\n";
echo "<heading>0</heading>\n";
echo "</LookAt>\n";
echo "<visibility>0</visibility>\n";
echo "<Point>\n";
echo "<extrude>1</extrude>\n";
echo "<altitudeMode>relativeToGround</altitudeMode>\n";
echo "<coordinates>$long,$lat</coordinates>\n";
echo "</Point>\n";
echo "</Placemark>\n";
echo "</Document>\n";
echo "</kml>\n";
?>

which makes a kml file like this:

<?xml version="1.0" encoding="UTF-8"?>
<kml xmlns="http://earth.google.com/kml/2.1">
<Document>
<Placemark>
<description><![CDATA[Anatahan, Mariana Islands<br /> lat: 16.360,
long: 145.655<br /><a href='http://oceandots.com/pacific/mariana/
anatahan.htm'>Anatahan</a> ]]></description>
<name>Anatahan</name>
<LookAt>
<longitude>145.655</longitude>
<latitude>16.360</latitude>
<range>5000.00</range>
<tilt>20.0</tilt>
<heading>0</heading>
</LookAt>
<visibility>0</visibility>
<Point>
<extrude>1</extrude>
<altitudeMode>relativeToGround</altitudeMode>
<coordinates>145.655,16.360</coordinates>
</Point>
</Placemark>
</Document>
</kml>

I had thought that maybe the server should be sending the correct MIME
types for GE-opening files, but since it works for many visitors as
is, I'm not too sure that this is the issue. I have a shared hosting
account so have little or no control over server configuration.

Any ideas why this works for some users, not for others and not for
Opera users at all?

Regards
Douglas Kerr

ps this is my first usenet posting, so I've no idea whether I've
formatted this post correctly. Apologies in advance.

ManoM

unread,
Jul 16, 2008, 1:46:13 PM7/16/08
to KML Developer Support - KML Server Side Scripting
Hi Douglas,

Could you post a link to your page? I'd have to check on the code to
see how you're opening it.

Mano

On Jul 15, 2:07 pm, Douglas wrote:
> Hi,
>
> On my site, I have a link on each page that takes some url parameters
> declared in the page ($lat & $long etc) to create a link to a php
> script which then writes a kml file on the fly. The browser then
> downloads and opens the file with GE.
>
> Apparently this is not what happens for all visitors to my site. Users
> of Opera see nothing but the CDATA sectons of the resultant kml file
> displayed in the browser window. Some users of Firefox have the kml
> file open with dreamweaver or see GE attempt to open the php file and
> thus do nothing much Yet, other users see it work perfectly as
> intended.
>
> Here is an example link from one particular page:
>
> http://oceandots.com/flyto.php?lat=16.360&long=145.655&place=Anatahan...

Douglas

unread,
Jul 17, 2008, 1:53:03 AM7/17/08
to KML Developer Support - KML Server Side Scripting
Hi mano,

You can see an example on this page:

http://www.oceandots.com/pacific/mariana/anatahan.htm (just look for
the "kml for Google Earth " link over the right)

Regards,
Douglas
> > formatted this post correctly. Apologies in advance.- Hide quoted text -
>
> - Show quoted text -

ManoM

unread,
Jul 17, 2008, 1:21:17 PM7/17/08
to KML Developer Support - KML Server Side Scripting
Hi Douglas,

Usually when you see this kind of problem, it's a Content Type (MIME
Type) issue, as you said. It appears it still is, but not in the
traditional sense. You have done everything right, as far as I can
tell. I used the FireFox extension LiveHttpHeaders to detect the
Content Type, and your script is generating this correctly.

However, not all browsers deal effectively with content type. Safari
and Opera are two that don't always behave correctly. Firefox often
goes by the extension rather than the Content Type. Also, what the
Content Type tells the browser is what type it is, but if people have
set their systems to handle that content type differently, then all
the browser knows is that system has decided to open that content type
with a different kind of application, like Dreamweaver.

However, there is hope. The most common way that systems know what
application to open is to use the file extension. In your case,
that's .php, but you could put on your server a re-direct. A link to,
say, flyto.kml opens http://www.oceandots.com/flyto.php?lat=16.360&long=145.655&place=Anatahan&group=Mariana+Islands,
for instance.

Mano

NiallBCarter

unread,
Jul 18, 2008, 4:33:52 AM7/18/08
to KML Developer Support - KML Server Side Scripting
Hi Douglas,

I am doing a very similar problem but with perl and I found that I had
to amke sure that the Content type was correct for Google Earth. Then
I had the problem of the new version of GE not opening my perl file as
a KML. To solve this I had to change the content type to:
print "Content-Disposition: attachment; filename = $file_name\n\n";

This told the browser what to download the file as. I found this a
really useful thing to use as it also meant that I could specify a
nice user friendly file name as well.

I don't know if this will help but thought I would throw it out
there.

Niall

On Jul 17, 6:21 pm, ManoM wrote:
> Hi Douglas,
>
> Usually when you see this kind of problem, it's a Content Type (MIME
> Type) issue, as you said. It appears it still is, but not in the
> traditional sense. You have done everything right, as far as I can
> tell. I used the FireFox extension LiveHttpHeaders to detect the
> Content Type, and your script is generating this correctly.
>
> However, not all browsers deal effectively with content type. Safari
> and Opera are two that don't always behave correctly. Firefox often
> goes by the extension rather than the Content Type. Also, what the
> Content Type tells the browser is what type it is, but if people have
> set their systems to handle that content type differently, then all
> the browser knows is that system has decided to open that content type
> with a different kind of application, like Dreamweaver.
>
> However, there is hope. The most common way that systems know what
> application to open is to use the file extension. In your case,
> that's .php, but you could put on your server a re-direct. A link to,
> say, flyto.kml openshttp://www.oceandots.com/flyto.php?lat=16.360&long=145.655&place=Anat...,
> for instance.
>
> Mano
>
> On Jul 16, 10:53 pm, Douglas wrote:
>
> > Hi mano,
>
> > You can see an example on this page:
>
> >http://www.oceandots.com/pacific/mariana/anatahan.htm(just look for

Douglas

unread,
Jul 18, 2008, 9:24:33 AM7/18/08
to KML Developer Support - KML Server Side Scripting
ManoM, Niall,

Thanks for responding and looking into this matter.
With the info gathered I have solved the Opera problem (users need to
tell Opera how to handle that file type in their prefs).
For the other issue and ideas suggested I'll have a look in more
detail later.

Thanks for your time.

DAK.
> > >http://www.oceandots.com/pacific/mariana/anatahan.htm(justlook for
> > > > - Show quoted text -- Hide quoted text -
Reply all
Reply to author
Forward
0 new messages