Jump to content

Extension talk:KML Export

Add topic
From mediawiki.org
Latest comment: 15 years ago by Juliano in topic KMLExport with wiki family

Question for anyone who can help[edit]

I love this and it is working great. The only question I had is how do I get pictures to show up in the balloons on GE? I've tried several methods and nothing seems to work. I usually just get the grey or black box in the window. Any suggestions?


--Mfinney 00:41, 16 March 2008 (UTC)Reply

Hello Mfinney,
I never tried to put an image inside the description of a placemark. I just checked, and it seems that MediaWiki doesn't translate images URLs properly. KML Export installs some specific code which translates URLs like "/Article" (which would be invalid on Google Earth) to "http://yourwiki/Article". Thanks to your report I found that this code is not called when MediaWiki generates image references. I'll look for a fix for the next version of KML Export (which will take some months to be released, since I'm pretty busy right now), but as a workaround, you may just put the full URL of the image into the description. Instead of "[[Image:Xxx.png]]", write just "http://yourwiki/images/Xxx.png".
Best regards, --Juliano 19:57, 18 March 2008 (UTC)Reply
I have a working example of images inside KML markers here. See the [locations http://www.melpedia.com.au/wiki/Template:Infobox_Location] template for how I did it Rodeoclash 11:52, 27 August 2008 (UTC)Reply
Hi Rodeoclash,
Very good job you have at your wiki. But it also shows the problem reported by Mfinney. If you check the generated KML output, you will see that images are relative, and Google Earth doesn't work well with relative links in KML files. I'll fix this problem soon (I hope). It is a bug in MediaWiki (reported as bugzilla:9355 and bugzilla:15512), and I had to work around recently in another extension (Extension:Wikilog). I'll have to port the same fix to KML Export.
By the way, I think that your wiki is hitting the PHP's memory_limit when running KMLExport. You may want to raise the memory limit in your LocalSettings.php.
Thanks for using KML Export! Best regards, --Juliano 01:08, 12 September 2008 (UTC)Reply
Thanks J, I've increased my memory usage, I'll see if that fixes the odd bug I've had with the site now and again. Rodeoclash 05:25, 3 October 2008 (UTC)Reply

KML Export Encoded?[edit]

Any idea why my KML export is being encoded?


It was working fine a few days ago... Rodeoclash 11:33, 27 August 2008 (UTC)Reply

Ignore this, incorrect use of the extension caused it.

Mediawiki 1.13[edit]

Does somebody know if this extension still should work in Mediawiki 1.13? It stopped working on my wiki after the upgrade to 1.13. --Egel 13:45, 1 October 2008 (UTC)Reply

Hi Egel,
MediaWiki 1.13 changed a little the behavior of the parser, and this caused the current stable version of the extension to not work correctly under some situations. I fixed this problem in the latest version in the Subversion repository. Could you please test the latest version from http://svn.juliano.info/svn/mediawiki/extensions/KMLExport/trunk/ ?
Checkout the extension using Subversion from the above URL, and then touch (i.e. do some edit and save) your LocalSettings.php file in order to reset the parser cache, and then try again.
Regards, --Juliano 19:47, 1 October 2008 (UTC)Reply

with mediawiki 1.11?[edit]

This feature seems very nice and I love to have this on my wiki site.

Our mediawiki version is 1.11 (php 5.2.6 ) and after install and run this extension; on the (produced) xxx.kml file it says about 'undefined' errors.

I checked include/ParserOptions.php and found those (e.g., enableLimitReport) are not in there. (I am admitting that I am new to php though). Requirement is MediaWiki 1.9 or higher; so I wonder if I need to upgrade mediawiki. I hope there is a way to get over this without upgrading.

BTW, I have downloaded this extension yesterday (5/4/09).

Any comments? Thanks in advance.

----- in xxx.kml file -----
<?xml version="1.0" encoding="utf-8"?>
<kml xmlns="http://earth.google.com/kml/2.1">
<br />
<b>Fatal error</b>:  Call to undefined method ParserOptions::enableLimitReport() in <b>/home/xxxxx/public_html/wiki-test/extensions/KMLExport/KMLUtils.php</b> on line <b>61</b><br />

----- after the blocking #61 for experiment -----
<b>Fatal error</b>:  Undefined class constant 'OT_HTML' in <b>/home/xxxxx/public_html/wiki-test/extensions/KMLExport/KMLUtils.php</b> on line <b>65</b><br />

--Jimyoo 19:17, 5 May 2009 (UTC)Reply

You probably downloaded KMLExport 1.3, which is for MediaWiki 1.13 and higher. Since you are using MediaWiki 1.11, you need to download KMLExport 1.2.
Regards, --Juliano 14:08, 6 May 2009 (UTC)Reply
Very cool!!! it's working now; appreciate your diligent supports
Can't wait to explore this feature. --Jimyoo 15:05, 6 May 2009 (UTC)Reply

KMLExport with wiki family[edit]

First of all, thanks for this great extension! I love it! And I've been using it as a vital part of my wiki for some time.

However, I just expanded my wiki to a wiki family with three different languages, using this method (which I guess is the standard). And now my KMLExport is working strangely in the two new wikis (not in the original one, where it is still working fine). Basically, when you save an article with kml info, it gets included in the output from the KMLExport only for a certain time, and then it disappears. So if I go over the articles in my wiki and save them again, and then go to the Special:KMLExport file, it comes out fine. But then if I wait till the next morning and try to do an Export again, all the articles are gone from the KML output. Why is this?

All the three wikis are using the same database, but different tables (with prefixes set in LocalSettings.php). Could this be part of the problem? And of course they are using the same set of php files, via symbolic links in the file system. I tried to change this for one of the new wikis, deleting the links and copying in the extension files instead, but that didn't seem to affect the behaviour.

I'm using MediaWiki 1.11.1 and KMLExport 1.2.0, on top of: PHP: 5.2.6 (apache2handler) and MySQL: 5.0.45.

The wikis are here:

  • textopia.org (portal)
  • www.tekstopia.uio.no (original wiki in Norwegian, working fine)
  • en.textopia.org (new English wiki)
  • es.textopia.org (Spanish)

Cheers, --Anderssl 16:58, 18 June 2009 (UTC)Reply

Hi Anders,
You are welcome! :-) Thanks for your interest in my extension.
The wiki family setup definitely doesn't affect KML Export. For all cases, it is like three independent wikis. I don't know exactly what is happening, but from your description, it is definitely related to caching.
In the extension, geo data is collected and saved when articles are parsed (saved). This information is stored in the parser cache, in order to optimize MediaWiki performance. But articles in the parser cache expires after a few hours. Usually, KML Export reparses expired articles when building the kml file, and restore updated versions in the cache.
From your description, it seems that KML Export is generating the kml file only when the data is already on cache, and failing to generate it on-the-fly when it is not. This is probably what is happening, but I don't know why. I'm reviewing the relevant code from Version 1.2.0 of the extension (file SpecialKMLExport.php, class KMLExportGenerator), but I'm still unable to determine where it may be failing (it shouldn't be failing without some major breakage).
It may be some difference in the LocalSettings.php files of the three wikis. Check is any caching-related configs differ between wikis (specially important is $wgMainCacheType). Also, check if the web-server error logs contain any information about PHP warnings or errors. If they do, please send them to me.
I would like to investigate this further, and I would have to ask more questions, if you don't mind. Please, contact me through e-mail or Google Talk, so we can exchange information more easily.
Best regards,
--Juliano 04:01, 21 June 2009 (UTC)Reply