Referencing external resources with href

[GoogleCodeExporter]

I've defined style and icons in a file and I'd like to reference to it using 
relative paths in href.

Geoxml3 currently cannot resolve or use styles defined in documents other than 
the ones that are passed as an argument for geoXML3.parse().
Even if two documents are passed as an array, I don't think they can share 
styles either.

It would be nice to be able to pass a document containing styles, either as an 
option or as an argument.
I've made some simple changes to pass it as argument. I'll append my diffs as 
an attachment.

There's also the problem of resolving relative paths.
When a kml file is processed by Google Earth, the relative path starts from the 
folder where the kml file lives.
When an element references an external path, that has to be resolved depending 
on where the current kml file and the external one are.
I'm currently fixing the paths externally before passing the document 
containing styles:

  // assume a file "/kml/style.kml" containing styles 
  // has been parsed and is available as docs[0]
  // Now we want to parse the file "/rest/GpsPosition.kml"
  // that refers to style.kml using relative paths

  // fix path in styles relative to kml
  for (var styleID in docs[0].styles ) {
    var newStyleId = root + docs[0].url + styleID;
    styles[newStyleId] = docs[0].styles[styleID];
    styles[newStyleId].href =  root + "/kml/" + styles[newStyleId].href;
        }
  // Add a kml layer
  parser.parse(['/rest/GpsPosition.kml'], styles );
};

Original issue reported on code.google.com by theb...@emanueleziglioli.it on 13 May 2011 at 2:37

Attachments:

• revision.diff

[GoogleCodeExporter]

Just another small issue, the regular expression here:

var stdRegEx = 
/\/(red|blue|green|yellow|lightblue|purple|pink|orange)(-dot)?\.png/;

assumes an icon name is prepended by backslash, as far as I understand.
But paths should no longer use backslashes, am I wrong? 

Original comment by theb...@emanueleziglioli.it on 13 May 2011 at 3:29

[GoogleCodeExporter]

Seems reasonable.  Can you provide test cases so I can validate your code works?

Original comment by geocodezip on 13 May 2011 at 5:19

• Changed state: Accepted

[GoogleCodeExporter]

sorry for the delay, I've uploaded a first example here:
http://kmltest-ez.appspot.com/kapiti-1.html

(I've actually reused on example of yours but from the other side of the Tasman 
:-)
You should be able to inspect the source. In essence:

  geoXml = new geoXML3.parser({
                    map: map,
                    singleInfoWindow: false,
                    afterParse: useTheData
                });

  geoXml.options.afterParse = function( docs )
  {
     styles = docs[0].styles;

     // Add a kml layer
     geoXml.options.afterParse = useTheData;
     geoXml.parse(['kapiti.xml'], styles );
  };

  // load style
  geoXml.parse( ['styles.xml'] );

It's ugly having to override options.afterParse, it'd be more elegant to pass 
it as a parameter. 'styles' should probably be put into the options.

Next I'll work on an example with kml data and kml styles on different 
directories.
Please get back to me for more info.

PS The zipped files in attachment runs on Firefox but not on Chrome due to 
Cross Origin restrictions.

Original comment by theb...@emanueleziglioli.it on 16 May 2011 at 1:14

Attachments:

• kapiti-1.zip

[GoogleCodeExporter]

I've uploaded two other examples:
http://kmltest-ez.appspot.com/kapiti-2.html
http://kmltest-ez.appspot.com/kapiti-3.html

I've put two maps on each page, one uses the GeoXML3 parser, the other one uses 
google.maps.KmlLayer.
The goal is to achieve the same result, i.e. being able to load styles from an 
external kml using relative paths.
To add complexity, the data kml and the styles kml are on different paths.

When the data kml is parsed, all paths have to be relative to its location:
<styleUrl>../../kml/styles2.xml#normal-start-external</styleUrl>.
Before parsing the data kml with GeoXML3, I have to fix style ids and icon 
paths:

var styles = {};
var iconroot = "kml/";
var styleroot = "../../";

// fix path in styles relative to kml
for (var styleID in docs[0].styles ) {
  var newStyleId = styleroot + docs[0].url + styleID;
  styles[newStyleId] = docs[0].styles[styleID];

  var iconUrl = styles[newStyleId].icon.url;
  styles[newStyleId].href = iconroot + iconUrl;
  styles[newStyleId].icon.url = iconroot + iconUrl;
}

The result parses correctly using GeoXML3 and when loading the kml in a Google 
Maps search bar. It doesn't work with google.maps.KmlLayer!

Original comment by theb...@emanueleziglioli.it on 16 May 2011 at 11:29

[GoogleCodeExporter]

Seems like the "right" way to do this is to support external files when 
referenced by the kml tag styleUrl.

Original comment by geocodezip on 14 Jul 2011 at 2:53

[GoogleCodeExporter]

Hi, sorry about this OT!
thank you and good bye! I've switched to OpenLayers.
So far their KML looks more advanced, they also parse gx:Track tags and create 
features from their child nodes.
They ignore Timestamp for Placemarks, something I've added myself (thinking 
about the Google Earth plugin, which I've also bridged from OpenLayers based on 
http://code.google.com/p/google-maps-utility-library-v3/source/browse/trunk/goog
leearth/src/googleearth.js?r=286).
It's been very useful to work on the Geoxml3 project though!

Original comment by theb...@emanueleziglioli.it on 14 Jul 2011 at 9:12

[GoogleCodeExporter]

"Seems like the "right" way to do this is to support external files when 
referenced by the kml tag styleUrl."

Is that a realistic option at all?

I just found geoxml3 myself but am having some styling issue that would be 
resolved with the styleurl being followed to an external file.

Original comment by HiddenAl...@gmail.com on 11 Oct 2011 at 11:47

[GoogleCodeExporter]

Sorry, realized that issue #51 is a dupe of this issue.  The good news is that 
I'm almost finished with a patch to fix this.

Original comment by sineswi...@gmail.com on 8 Feb 2012 at 3:43

[GoogleCodeExporter]

Oops, that's issue #49, not 51.

Original comment by sineswi...@gmail.com on 8 Feb 2012 at 3:46

[GoogleCodeExporter]

external styles now work in the kmz branch

http://www.geocodezip.com/geoxml3_test/kapiti-1/kapiti-1.html

http://www.geocodezip.com/geoxml3_test/v3_geoxml3_kmztest_linkto.html?filename=k
apiti2.xml

Original comment by geocodezip on 23 Feb 2012 at 4:57

• Changed state: Fixed

[GoogleCodeExporter]

Well done, I might still some ideas for OL :-)

Original comment by theb...@emanueleziglioli.it on 23 Feb 2012 at 9:07