Mega patch for various items

[GoogleCodeExporter]

This patch covers about 3 solid weeks of work getting some of the other 
features implement for my needs.  Maintaining KML standards and making sure 
everything was open-ended was priority over merely jury-rigging it to make it 
only suit my requests.

This patch implements the following:

* KMZ support with full support for inline images (though with some limitations 
in IE)
* Auto-loading of KML/Z files that are dependencies via styleUrl tags
* Full support for the following style tags:
  * BalloonStyle (bgColor, textColor, text, displayMode)
  * IconStyle (href, scale, hotSpot, gx:x/y/w/h)
  * LineStyle (color, colorMode, width)
  * PolyStyle (color, colorMode, outline, fill)
* Full support for styleMaps, including external references
* Proper defaults of styles, per KML 2.2 standards
* Proper implementation of colorMode=random in styles
* Support for visibility and gx:BalloonVisibility tags within Placemarks
* Support for ExtendedData tag set and description substitution using those 
variables
* Support for icon palettes and correct icon sizes
* Logging of XML parse errors
* Some tab/spacing refactoring (so, some of the patch add/removals are just 
space adjustments)

This should fix Issue #s: 14, 28, 47, 48, 49.

I apologize for the size and scope of this patch, but I'm willing to explain 
any code points you have questions with.

Original issue reported on code.google.com by sineswi...@gmail.com on 14 Feb 2012 at 9:52

Attachments:

• geoXML3-patch.txt.gz

[GoogleCodeExporter]

Original comment by geocodezip on 14 Feb 2012 at 10:30

• Changed state: Accepted
• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Do you have any links to examples that can be used to test any of the new 
functionality?  Or that you can attach to this issue?

Original comment by geocodezip on 15 Feb 2012 at 2:58

[GoogleCodeExporter]

Created a new branch with the patched version:
http://code.google.com/p/geoxml3/source/browse/branches/kmz/

Split out ZipFile.complete.js

Firefox gives me:
Error: Function.prototype.call called on incompatible Object
Source File: http://www.geocodezip.com/geoxml3_test/geoxml3.js
Line: 505

Chrome gives me:
Uncaught TypeError: object is not a function
geoxml3.js:505

IE gives me:
Message: 'Element' is undefined
Line: 1488
Char: 1
Code: 0
URI: http://www.geocodezip.com/geoxml3_test/geoxml3.js

and:

Message: Object expected
Line: 85
Char: 7
Code: 0
URI: http://www.geocodezip.com/geoxml3_test/geoxml3.js

Original comment by geocodezip on 15 Feb 2012 at 6:48

[GoogleCodeExporter]

could you verify the code in the kmz branch against what you are using?

http://code.google.com/p/geoxml3/source/browse/branches/kmz/

Original comment by geocodezip on 15 Feb 2012 at 1:35

[GoogleCodeExporter]

Sorry, must have been a last minute change I forgot to test.  Patch here:

Index: geoxml3.js
===================================================================
--- geoxml3.js  (revision 67)
+++ geoxml3.js  (working copy)
@@ -1485,9 +1485,9 @@
 }

 // IE8 doesn't define this, yay!
-geoXML3.getElementsByTagNameNS = 
-  (Element && Element.prototype && Element.prototype.getElementsByTagNameNS) ? 
Element.prototype.getElementsByTagNameNS.call :
-function(node, namespace, tagname) {
+geoXML3.getElementsByTagNameNS = function(node, namespace, tagname) {
+  if (node && node.getElementsByTagNameNS) return 
node.getElementsByTagNameNS(namespace, tagname);
+
   var result = [];
   var root = node.ownerDocument.childNodes[1];

Original comment by sineswi...@gmail.com on 16 Feb 2012 at 5:42

[GoogleCodeExporter]

That solves that problem.

I am now getting a problem here (on a different test case):
var cleanURL  = function (d, s) { return 
dehostURL(toAbsURL(d.split('#')[0].split('?')[0], 
s.split('#')[0].split('?')[0])); }

firefox tells me d is undefined;

IE gives me an error:
Message: 'geoXML3.getElementsByTagNameNS(...).0' is null or not an object
Line: 498
Char: 9
Code: 0
URI: http://www.geocodezip.com/geoxml3_test/geoxml3.js

Not sure if it is the same issue or not.

Original comment by geocodezip on 16 Feb 2012 at 7:14

[GoogleCodeExporter]

Here is an example set of KMZ files, showcasing many of the new features.

Original comment by sineswi...@gmail.com on 16 Feb 2012 at 7:42

Attachments:

• example-kmz.tar

[GoogleCodeExporter]

Is there an html file to go with the kmz files?
Or is this just the most basic use case (just point the parser at the file, no 
other options)?

Original comment by geocodezip on 16 Feb 2012 at 8:08

[GoogleCodeExporter]

Fixes to last issue above:

Index: geoxml3.js
===================================================================
--- geoxml3.js  (revision 67)
+++ geoxml3.js  (working copy)
@@ -1497,7 +1497,7 @@
     if (attr.prefix === 'xmlns' && attr.nodeValue === namespace)
       return node.getElementsByTagName(attr.baseName + ':' + tagname);
   }
-  return null;
+  return new Array();  // empty result set
 };

@@ -1527,8 +1527,8 @@
   return s.replace(new RegExp('^' + h, 'i'), '');
 }

-var cleanURL  = function (d, s) { return 
dehostURL(toAbsURL(d.split('#')[0].split('?')[0], 
s.split('#')[0].split('?')[0])); }
-var defileURL = function (s)    { return s.substr(0, s.lastIndexOf('/') + 1); }
+var cleanURL  = function (d, s) { return dehostURL(toAbsURL(d ? 
d.split('#')[0].split('?')[0] : defileURL(location.pathname), s ? 
s.split('#')[0].split('?')[0] : '')); }
+var defileURL = function (s)    { return s ? s.substr(0, s.lastIndexOf('/') + 
1) : '/'; }

 // Some extra Array subs for ease of use
 // http://stackoverflow.com/questions/143847/best-way-to-find-an-item-in-a-javascript-array

Original comment by sineswi...@gmail.com on 16 Feb 2012 at 8:09

[GoogleCodeExporter]

Re: #8

Just a basic use case.  Just load up a Google Map object, point the parser to 
the file, and everything should work.  Don't forget to include both the 
Zipfile.complete.js file and jQuery (from Google's servers should work).

Original comment by sineswi...@gmail.com on 16 Feb 2012 at 8:12

[GoogleCodeExporter]

My server doesn't support kml or kmz.  Here is my test page:
http://www.geocodezip.com/geoxml3_test/v3_geoxml3_kmztest_linkto.html

Doesn't seem to work, but haven't had a chance to investigate it yet.

Original comment by geocodezip on 17 Feb 2012 at 2:49

[GoogleCodeExporter]

A few things:

1. The ProjectedOverlay.js might be interfering with the existing code.  The 
poly branch doesn't have that file, anymore, so it's old code.

2. The filename 'Outage-customer_kmz.zip' isn't a valid extension.  It has to 
be named Outage-customer.kmz, despite the fact that it is basically just a zip 
file.

Original comment by sineswi...@gmail.com on 17 Feb 2012 at 3:37

[GoogleCodeExporter]

You wrote:
> A few things:
> 1. The ProjectedOverlay.js might be interfering with the existing code.  The 
poly 
> branch doesn't have that file, anymore, so it's old code.

No it isn't.  It is required by geoxml3 to render ground overlays.

> 2. The filename 'Outage-customer_kmz.zip' isn't a valid extension.  It has to 
be 
> named Outage-customer.kmz, despite the fact that it is basically just a zip 
file.

My server will not serve kml or kmz files.  It will serve .xml and .zip files.  
If the extension to support kmz will not handle .zip files; it will not be 
testable on my server.

Original comment by geocodezip on 17 Feb 2012 at 5:26

[GoogleCodeExporter]

I get this error:
Uncaught TypeError: Illegal constructor    geoxml3.js:312

This line:
    var temp = new obj.constructor();
in the clone function on this map:

http://www.geocodezip.com/geoxml3_test/v3_geoxml3_kmztest_linkto.html?filename=K
ML_Samples.xml

and this map:
http://www.geocodezip.com/geoxml3_test/v3_geoxml3_kmztest_linkto.html?filename=W
eeklyVolcanoGE-Reports_20100908-0914.xml

Most of the other regression tests seem to work OK.

Original comment by geocodezip on 19 Feb 2012 at 3:00

[GoogleCodeExporter]

It does look like there is a regression on missing <description> tags, this map 
shows "undefined" for the description:

http://www.geocodezip.com/geoxml3_test/v3_geoxml3_kmztest_linkto.html?filename=c
ta.xml

Compare to the same kml rendered by the version in the polys branch:

http://www.geocodezip.com/geoxml3_test/v3_geoxml3_polystest_linkto.html?filename
=cta.xml

Original comment by geocodezip on 19 Feb 2012 at 3:34

[GoogleCodeExporter]

The example uploaded now seems to be working (perhaps the "nightly build" was 
broken)

http://www.geocodezip.com/geoxml3_test/v3_geoxml3_kmztest_linkto.html

Although I don't see the "red" houses in IE.

Original comment by geocodezip on 19 Feb 2012 at 2:19

[GoogleCodeExporter]

The "undefined" may not be the description. This kml has that problem but 
includes a description:

http://www.geocodezip.com/geoxml3_test/v3_geoxml3_kmztest_linkto.html?filename=C
levelandNationalForest_kml.xml&type=t

Original comment by geocodezip on 19 Feb 2012 at 4:26

[GoogleCodeExporter]

clone is failing when it tries to clone an HTMLImageElement in processStyleMap

in this example:

http://www.geocodezip.com/geoxml3_test/v3_geoxml3_kmztest_linkto.html?filename=K
ML_Samples.xml

KML:

http://www.geocodezip.com/geoxml3_test/KML_Samples.xml

Original comment by geocodezip on 21 Feb 2012 at 5:43

[GoogleCodeExporter]

fixed issue with cloning an HTMLImageElement in revision 70

Original comment by geocodezip on 22 Feb 2012 at 4:41

[GoogleCodeExporter]

Re: comment 15, I now see the "red" houses in IE, so that must have been 
another issue with the nightly version.

Original comment by geocodezip on 23 Feb 2012 at 3:08

[GoogleCodeExporter]

fixed spurious 'undefined' in infowindows described in comments 15 & 17 in 
revision 71.

Original comment by geocodezip on 23 Feb 2012 at 3:30

[GoogleCodeExporter]

issue with this example:
http://www.geocodezip.com/geoxml3_test/v3_geoxml3_kmztest_linkto.html?filename=L
asTrampasRegionalWilderness_kmz.zip

Uncaught TypeError: Cannot read property 'ownerDocument' of undefined
geoxml3.js:1494  

which is this:
var root = node.ownerDocument.childNodes[1];

Due to styleNodes having length 0 for these accesses:
      icon.dim = {
        x: parseInt(nodeValue(getElementsByTagNameNS(styleNodes[0], gx, 'x')[0], icon.dim.x)),
        y: parseInt(nodeValue(getElementsByTagNameNS(styleNodes[0], gx, 'y')[0], icon.dim.y)),
        w: parseInt(nodeValue(getElementsByTagNameNS(styleNodes[0], gx, 'w')[0], icon.dim.w)),
        h: parseInt(nodeValue(getElementsByTagNameNS(styleNodes[0], gx, 'h')[0], icon.dim.h))
      };

fixed in revision 72.

Original comment by geocodezip on 25 Feb 2012 at 6:44

[GoogleCodeExporter]

What is jquery used for?

Original comment by geocodezip on 26 Feb 2012 at 11:35

[GoogleCodeExporter]

New patch.  This should fix a lot of those issues plus:

* Optimization improvements to Zipfile code.  Even larger KMZ files load 
lightning fast on Firefox and even moderately well in IE8.
* Added JSDoc comments in the GeoKML3 file; about 75% complete.  I leave it up 
to you to finish the rest, but this should help out in spitting out 
documentation Wikis for the new branch.
* Improved XML code for IE, including fully namespace-compatible XML TagName 
searches.
* New parserOptions class, instead of an anonymous set of options (made it easy 
to document).  Still works with legacy option passing, though.
* No longer requires jQuery; mistaken requirement for Zipfile on my part.
* Placemark visibility via gx:visibility works correctly
* Some code refactoring and whitespace cleanup

Original comment by sineswi...@gmail.com on 1 Mar 2012 at 4:43

Attachments:

• doc-cleanup.patch.gz

[GoogleCodeExporter]

What version of the code is this patch against?
It didn't apply against the kmz branch.

Original comment by geocodezip on 1 Mar 2012 at 8:09

[GoogleCodeExporter]

This is the error I am seeing:

patching file ZipFile.complete.js
patch: **** malformed patch at line 3895: @@ -2269,12 +2099,11 @@

Original comment by geocodezip on 3 Mar 2012 at 4:14

[GoogleCodeExporter]

Looks like the patch is applying to geoxml3.js OK, but not to 
ZipFile.complete.js.
Is the complete updated version of ZipFile.complete.js available somewhere (or 
could you attach it to this issue)?

Original comment by geocodezip on 3 Mar 2012 at 4:43

[GoogleCodeExporter]

Patch applied.  Had to use tortoise on Windows...
Revision 73, not tested at all yet

Original comment by geocodezip on 3 Mar 2012 at 5:48

[GoogleCodeExporter]

Seems to have stopped this example from working:
http://www.geocodezip.com/geoxml3_test/v3_geoxml3_kmztest_linkto.html?filename=M
LPMapPortal_network_link_kml.xml

Original comment by geocodezip on 3 Mar 2012 at 6:00

[GoogleCodeExporter]

http://www.geocodezip.com/geoxml3_test/v3_geoxml3_kmztest_linkto.html?filename=M
LPMapPortal_network_link_kml.xml

Getting this error in IE:
Line: 1671
Error: Unexpected token ':'.

.//-->:<--styleUrl

This is the line:
    if      (attr.prefix   === 'xmlns' && attr.nodeValue === namespace) return node.getElementsByTagName(attr.baseName + ':' + tagname);

Original comment by geocodezip on 3 Mar 2012 at 6:10

[GoogleCodeExporter]

It does work with the version before the patch (has issues in IE, but displays 
something):
http://www.geocodezip.com/geoxml3_test/v3_geoxml3_kmztestR72_linkto.html?filenam
e=MLPMapPortal_network_link_kml.xml

Original comment by geocodezip on 3 Mar 2012 at 6:26

[GoogleCodeExporter]

Another example that works with revision 72 but doesn't work with the latest:

http://www.geocodezip.com/geoxml3_test/v3_geoxml3_kmztest_linkto.html?filename=f
reeatvmaps_kmz.zip

HTTP/ZIP warning retrieving freeatvmaps_kmz.zip: WARNING: at offset 0x4E3, 
found unexpected signature: 0x74952569
geoxml3.js:1270

works w/ r72:
http://www.geocodezip.com/geoxml3_test/v3_geoxml3_kmztestR72_linkto.html?filenam
e=freeatvmaps_kmz.zip

Original comment by geocodezip on 3 Mar 2012 at 7:02

[GoogleCodeExporter]

There also seems to be an issue with non-zipped kml.  I don't see errors, it 
just doesn't display:

http://www.geocodezip.com/geoxml3_test/v3_geoxml3_kmztest_linkto.html?filename=u
s_states_AK.xml

With revision 72 it displays:
http://www.geocodezip.com/geoxml3_test/v3_geoxml3_kmztestR72_linkto.html?filenam
e=us_states_AK.xml

Original comment by geocodezip on 3 Mar 2012 at 7:09

[GoogleCodeExporter]

Seems to be the kml namespace.

This namespace is used in us_states_AK.xml:
<kml xmlns="http://earth.google.com/kml/2.2">

kmlNS is 'http://www.opengis.net/kml/2.2'

if I change getElementsByTagNameNS back to getElementsByTagName, it works.

Was there a reason you changed all the references to getElementsByTagName to 
getElementsByTagNameNS with that specific namespace?

It seems to cause issues with legacy files.

Original comment by geocodezip on 3 Mar 2012 at 10:02

[GoogleCodeExporter]

In this example:
http://www.geocodezip.com/geoxml3_test/v3_geoxml3_kmztest_linkto.html?filename=s
tate_capitals.xml

There is an issue with this line:
line 510: 
var styleUrl = nodeValue(getElementsByTagNameNS(node, kmlNS, 
'styleUrl')[0]).split('#');

When there are no styleUrl tags.

Original comment by geocodezip on 3 Mar 2012 at 10:18

[GoogleCodeExporter]

looks like there are kml files with at least the following namespaces:

<kml xmlns="http://www.opengis.net/kml/2.2">

<kml xmlns="http://earth.google.com/kml/2.0">
<kml xmlns="http://earth.google.com/kml/2.1">
<kml xmlns="http://earth.google.com/kml/2.2">

Original comment by geocodezip on 4 Mar 2012 at 1:29

[GoogleCodeExporter]

fixed namespace issues, styleUrl issues in revision 73

Original comment by geocodezip on 4 Mar 2012 at 1:31

[GoogleCodeExporter]

What was the reason for changing the return value of nodeValue to null from an 
empty string ('')?  This change broke the network link processing.

example:
http://www.geocodezip.com/geoxml3_test/v3_geoxml3_kmztest_linkto.html?filename=M
LPMapPortal_network_link_kml.xml

new version:
geoXML3.nodeValue = function(node, defVal) {
  var retStr="";
  if (!node) {
    return (typeof defVal === 'undefined' || defVal === null) ? null : defVal;

old version:
geoXML3.nodeValue = function(node, defVal) {
  var retStr="";
  if (!node) {
    return (typeof defVal === 'undefined' || defVal === null) ? '' : defVal;

Original comment by geocodezip on 4 Mar 2012 at 6:19

[GoogleCodeExporter]

fixed network link issue revision 75

http://www.geocodezip.com/geoxml3_test/v3_geoxml3_kmztest_linkto.html?filename=M
LPMapPortal_network_link_kml.xml

Original comment by geocodezip on 4 Mar 2012 at 6:22

[GoogleCodeExporter]

What is the advantage of fully namespace-compatible XML TagName searches?

I could see adding a flag to force kml namespace checking, but probably would 
need to also add an option to set the default kml namespace.

The other option would be to use "*" for kmlNS, would that be any different 
from using getElementsByTagName?

Original comment by geocodezip on 4 Mar 2012 at 2:41

[GoogleCodeExporter]

Icon scaling doesn't seem quite right.

This example:
http://www.geocodezip.com/geoxml3_test/v3_geoxml3_KML_samples_vis1_test_local.ht
ml
which loads google's KML_Samples.kml file (with the visibility changed, since 
that works now), the "white" icon seems way too big.  I think it should be the 
same size as the default marker.

Original comment by geocodezip on 4 Mar 2012 at 3:18

[GoogleCodeExporter]

In IE8: geoXML3.getElementsByTagName has an issue:
This generates an error:
node.selectNodes(".//*[local-name()='" + tagname + "']");

  Unknown method.
.//*[-->local-name()<--='styleUrl']  geoxml3.js, line 1712 character 66

Original comment by geocodezip on 4 Mar 2012 at 3:26

[GoogleCodeExporter]

Interesting errors on this example:
http://www.geocodezip.com/geoxml3_test/v3_geoxml3_kmztest_linkto.html?filename=h
ttp://www.geocodezip.com/geoxml3_test/florida_kml.xml

XMLHttpRequest cannot load flatfile://kh.google.com:80/styles/. Cross origin 
requests are only supported for HTTP.
Uncaught Error: Error: Failed to load "flatfile://kh.google.com:80/styles/": 
HTTP Status: 0   ZipFile.complete.js:35  
Uncaught Error: NETWORK_ERR: XMLHttpRequest Exception 101  
ZipFile.complete.js:749  

Looks like the kml contains references to icons that look like this:
http://kh.google.com/flatfile?lf-0-icons/airports_new_n.png

and a styleMap that looks like this:
<StyleMap id="15914">
<Pair>
<key>normal</key>
<styleUrl>
flatfile://kh.google.com:80/styles/#15914:G- Low level (w icon) (site) (normal)
</styleUrl>
</Pair>
<Pair>
<key>highlight</key>
<styleUrl>
flatfile://kh.google.com:80/styles/#15914:G- Low level (w icon) (site) 
(highlight)
</styleUrl>
</Pair>
</StyleMap>
<StyleMap id="15582">
<Pair>
<key>normal</key>
<styleUrl>
flatfile://kh.google.com:80/styles/#15582:1-10K (GNIS: US) (site) (normal)
</styleUrl>
</Pair>
<Pair>
<key>highlight</key>
<styleUrl>
flatfile://kh.google.com:80/styles/#15582:1-10K (GNIS: US) (site) (highlight)
</styleUrl>
</Pair>
</StyleMap>

Works with the polys version of geoxml3:
http://www.geocodezip.com/geoxml3_test/v3_geoxml3_kmltest_linktoB.html?filename=
http://www.geocodezip.com/geoxml3_test/florida_kml.xml

Original comment by geocodezip on 4 Mar 2012 at 8:57

[GoogleCodeExporter]

Another case where the xml is trying to make a cross-domain access, and it is 
killing the processing (where it works with the polys version of geoxml3)

http://www.geocodezip.com/geoxml3_test/v3_geoxml3_kmztest_linkto.html?filename=h
ttp://www.geocodezip.com/geoxml3_test/OrlandoNeighborhoods_boundaries_kml.xml

XMLHttpRequest cannot load 
http://go3dexpansion.com/kml/balloonstyle/ClickableNoPlacemark.kml. Origin 
http://www.geocodezip.com is not allowed by Access-Control-Allow-Origin.
Unable to retrieve 
http://go3dexpansion.com/kml/balloonstyle/ClickableNoPlacemark.kml  
geoxml3.js:1279

works with polys branch:
http://www.geocodezip.com/geoxml3_test/v3_geoxml3_kmltest_linktoB.html?filename=
http://www.geocodezip.com/geoxml3_test/OrlandoNeighborhoods_boundaries_kml.xml

or if I copy the external style kml to my server:
http://www.geocodezip.com/geoxml3_test/v3_geoxml3_kmztest_linkto.html?filename=h
ttp://www.geocodezip.com/geoxml3_test/OrlandoNeighborhoods_boundaries0_kml.xml

Seems like if we can't load an external file, we shouldn't necessarily fail 
processing files that depend on it.

Original comment by geocodezip on 4 Mar 2012 at 9:13

[GoogleCodeExporter]

RE: #30
Looks like a faulty problem with IE where it has a prefix, but not a baseName.  
(How can a tag have a prefix but not a name?!)  Probably need a baseName check 
then:

    if      (attr.prefix   === 'xmlns' && attr.nodeValue === namespace && attr.baseName)

On that case, make sure nodeName is going to return 'xmlns'.  In XML, nodeName 
should be the local base name; prefix is the first part of a NS-qualified node 
name; baseName is the last part (similar to the nodeName).

RE: #32
Another blasted IE bug.  Works in Firefox, but not in IE.  Last time I had one 
of those CRC type problems, it was an issue with bit shifting a number with 
32-bits.  (Firefox allows for 64-bits or more for a number; IE uses a 32-bit 
signed integer.)

I'll have to look at this after I'm done with some other tasks, since I'm 
running behind on deadlines.  Though, I will probably hit this bug, anyway, so 
if you can't get to it, I will eventually.

RE: #34
Mostly for correctness, though it did rear its ugly head when I started using 
MSXML6, since IE just assumes NS-qualified stuff for everything.  Probably 
should use 'null' in the second parameter of getElementsByTagNameNS to mean 
'use the default NS no matter what it is'.

Then again, that's what getElementsByTagName does.  We can use that, but be 
sure to use the geoXML3 version, since IE will fail on its own 
getElementsByTagName when using MSXML6.  (Its version will require a NS prefix 
for everything.  Hence the ".//*[local-name()='Tag']" selectNode line in the 
normalized version.)

RE: #38
This was to fix a bug with getBooleanValue, though I was worried the ''/null 
change might impact other things.  Basically, before the fix, if the node 
didn't exists or was blank, it would parseInt, get a NaN, and assume it means 
true.  It should return the default value, which in that case, was 'false'.

I guess it's okay to just change it to "if (nodeContents === '')", since all of 
the boolean truth values require a 0 or 1, anyway.

RE: #40
See comment for #34.

RE: #41
This is odd.  The style.icon.dim.w/h are set to 64 for that icon.  Yet, 
according to icon.img, it doesn't have a width/height.  (This is probably 
because it's a remote icon, and JS access is typically domain-bound.)  So, in 
that case, it should...

Hold on.  I think it's assuming that img.complete means that it actually has 
non-zero values.  So, that processStyleID line (939) should read:

if (icon.img && icon.img.complete && icon.img.width && icon.img.height) {

I'm guessing it's hitting a default somewhere, like the default for a new 
Size() object, if the size is 0,0.

RE: #42
According to some posts I've read, it looks like certain versions of either IE 
or MSXML need to have its selectionLanguage set.  So, this will need to be 
changed on line 1700:

  if (node && typeof node.selectNodes != 'undefined') {
    var owner = node.ownerDocument || node.documentElement && node.documentElement.ownerElement;
    if (owner) owner.setProperty('SelectionLanguage', 'XPath');
    return node.selectNodes(".//*[local-name()='" + tagname + "']");
  }

Optionally, this could also be set once on both xmlParse/fetchXML right before 
the return/callback.  That would prevent repeat setProperty calls.

RE: #43
WTF?!?  What the heck is flatfile://?  I don't see that anywhere in the KML 
spec!

RE: #44
At first, I agreed with you, but I'm thinking: Nothing else except JS and 
geoXML3 is going to be loading that styleUrl.  GMAPI isn't going to check on it 
because it has no concept of KML.  Even if the user specifically loaded that 
styleUrl manually via the geoXML3.parse, it's still JS that is loading it, and 
it's still domain-bound.

If the style file cannot be loaded, the style cannot be accurately represented. 
 Thus, it should still fatally error here.

(If you look at your last two examples, you can see that the polys branch isn't 
displaying it right because it can't load the file.  The internal KML version 
has the correct colors.)

Original comment by sineswi...@gmail.com on 5 Mar 2012 at 9:15

[GoogleCodeExporter]

> Comment #45 on issue 53 by sineswi...@gmail.com: Mega patch for various
> items
> http://code.google.com/p/geoxml3/issues/detail?id=53
>
> RE: #30
>> Getting this error in IE:
>> Line: 1671
>> Error: Unexpected token ':'.
>>
>> .//-->:<--styleUrl
>>
>> This is the line:
>>     if      (attr.prefix   === 'xmlns' && attr.nodeValue === namespace) 
return
>> node.getElementsByTagName(attr.baseName + ':' + tagname);
> Looks like a faulty problem with IE where it has a prefix, but not a
> baseName.  (How can a tag have a prefix but not a name?!)  Probably need a
> baseName check then:
>
>    if      (attr.prefix   === 'xmlns' && attr.nodeValue === namespace &&
> attr.baseName)

That didn't seem to change the behavior.

> On that case, make sure nodeName is going to return 'xmlns'.  In XML,
> nodeName should be the local base name; prefix is the first part of a
> NS-qualified node name; baseName is the last part (similar to the nodeName).
>
> RE: #32
>> Another example that works with revision 72 but doesn't work with the latest:
>>
>> 
http://www.geocodezip.com/geoxml3_test/v3_geoxml3_kmztest_linkto.html?filename=f
reeatvmaps_kmz.zip
>>
>> HTTP/ZIP warning retrieving freeatvmaps_kmz.zip: WARNING: at offset 0x4E3, 
found unexpected signature:
>> 0x74952569
>> geoxml3.js:1270
> Another blasted IE bug.  Works in Firefox, but not in IE.  Last time I had
> one of those CRC type problems, it was an issue with bit shifting a number
> with 32-bits.  (Firefox allows for 64-bits or more for a number; IE uses a
> 32-bit signed integer.)
>
> I'll have to look at this after I'm done with some other tasks, since I'm
> running behind on deadlines.  Though, I will probably hit this bug, anyway,
> so if you can't get to it, I will eventually.
>
> RE: #34
>> Seems to be the kml namespace.
>>
>> This namespace is used in us_states_AK.xml:
>> <kml xmlns="http://earth.google.com/kml/2.2">
>>
>> kmlNS is 'http://www.opengis.net/kml/2.2'
>>
>> if I change getElementsByTagNameNS back to getElementsByTagName, it works.
>>
>> Was there a reason you changed all the references to getElementsByTagName
>> to getElementsByTagNameNS with that specific namespace?
>>
>> It seems to cause issues with legacy files.
>
> Mostly for correctness, though it did rear its ugly head when I started
> using MSXML6, since IE just assumes NS-qualified stuff for everything.
>  Probably should use 'null' in the second parameter of
> getElementsByTagNameNS to mean 'use the default NS no matter what it is'.
>
> Then again, that's what getElementsByTagName does.  We can use that, but be
> sure to use the geoXML3 version, since IE will fail on its own
> getElementsByTagName when using MSXML6.  (Its version will require a NS
> prefix for everything.  Hence the ".//*[local-name()='Tag']" selectNode line
> in the normalized version.)

The local-name() gives me issues in IE8.  I need to test the NS "*" (and null) 
in IE, I don't remember if that worked or not.

Could you point me to some references on the benefits of using the namespace in 
XML parsing?  It sounded like you believed it improved the performance.  I'm 
not sure there is any benefit, particularly if support for several legacy 
namespaces is required and if we need to use it with "*" or null.

>
> RE: #38
>> What was the reason for changing the return value of nodeValue to null from 
an empty string ('')?
>> This change broke the network link processing.
> This was to fix a bug with getBooleanValue, though I was worried the ''/null
> change might impact other things.  Basically, before the fix, if the node
> didn't exists or was blank, it would parseInt, get a NaN, and assume it
> means true.  It should return the default value, which in that case, was
> 'false'.
>
> I guess it's okay to just change it to "if (nodeContents === '')", since all
> of the boolean truth values require a 0 or 1, anyway.

I think it is OK now, I changed the places that were expecting the '' response 
to look for null instead, although it might make more sense if it always 
returns a string, which was the way it worked originally.

>
> RE: #40
> See comment for #34.
>
> RE: #41
>> Icon scaling doesn't seem quite right.
>>
>> This example:
>> 
http://www.geocodezip.com/geoxml3_test/v3_geoxml3_KML_samples_vis1_test_local.ht
ml
>> which loads google's KML_Samples.kml file (with the visibility changed, 
since that 
>> works now), the "white" icon seems way too big.  I think it should be the 
same 
>> size as the default marker.
> This is odd.  The style.icon.dim.w/h are set to 64 for that icon.  Yet,
> according to icon.img, it doesn't have a width/height.  (This is probably
> because it's a remote icon, and JS access is typically domain-bound.)  So,
> in that case, it should...
>
> Hold on.  I think it's assuming that img.complete means that it actually has
> non-zero values.  So, that processStyleID line (939) should read:
>
> if (icon.img && icon.img.complete && icon.img.width && icon.img.height) {
>
> I'm guessing it's hitting a default somewhere, like the default for a new
> Size() object, if the size is 0,0.

That didn't change the behavior, but looking at the image, that image is 64x64, 
it is only the Google Maps and Google Maps API KmlLayer/GGeoXml behavior of 
forcing icons to be 32x32 that made me think it was wrong.  The current 
behavior is probably more standards compliant than Google's KML renders.

>
> RE: #42
>> In IE8: geoXML3.getElementsByTagName has an issue:
>> This generates an error:
>> node.selectNodes(".//*[local-name()='" + tagname + "']");
>>
>>   Unknown method.
>> .//*[-->local-name()<--='styleUrl']  geoxml3.js, line 1712 character 66
>>
> According to some posts I've read, it looks like certain versions of either
> IE or MSXML need to have its selectionLanguage set.  So, this will need to
> be changed on line 1700:
>
>  if (node && typeof node.selectNodes != 'undefined') {
>    var owner = node.ownerDocument || node.documentElement &&
> node.documentElement.ownerElement;
>    if (owner) owner.setProperty('SelectionLanguage', 'XPath');
>    return node.selectNodes(".//*[local-name()='" + tagname + "']");
>  }

Didn't seem to help.

>
> Optionally, this could also be set once on both xmlParse/fetchXML right
> before the return/callback.  That would prevent repeat setProperty calls.
>
> RE: #43
>> Interesting errors on this example:
>> 
http://www.geocodezip.com/geoxml3_test/v3_geoxml3_kmztest_linkto.html?filename=h
ttp://www.geocodezip.com/geoxml3_test/florida_kml.xml
>>
>> XMLHttpRequest cannot load flatfile://kh.google.com:80/styles/. Cross origin 
requests are only supported for HTTP.
>> Uncaught Error: Error: Failed to load "flatfile://kh.google.com:80/styles/": 
HTTP Status: 0   ZipFile.complete.js:35
>> Uncaught Error: NETWORK_ERR: XMLHttpRequest Exception 101  
ZipFile.complete.js:749
>>
>> Looks like the kml contains references to icons that look like this:
>> http://kh.google.com/flatfile?lf-0-icons/airports_new_n.png
> WTF?!?  What the heck is flatfile://?  I don't see that anywhere in the KML
> spec!

Me neither, not sure where it came from, possibly from Google Earth.

>
> RE: #44
> At first, I agreed with you, but I'm thinking: Nothing else except JS and
> geoXML3 is going to be loading that styleUrl.  GMAPI isn't going to check on
> it because it has no concept of KML.  Even if the user specifically loaded
> that styleUrl manually via the geoXML3.parse, it's still JS that is loading
> it, and it's still domain-bound.
>
> If the style file cannot be loaded, the style cannot be accurately
> represented.  Thus, it should still fatally error here.
>
> (If you look at your last two examples, you can see that the polys branch
> isn't displaying it right because it can't load the file.  The internal KML
> version has the correct colors.)

Personally, I would rather have it display with default styles rather
than not display at all if it can't load external styles.
I have been contemplating adding a proxy property to geoxml3 to allow it to deal
with cross-domain requests (allow a proxy to be specified for those).  
But I have been contemplating that for a while and not done it yet.

Original comment by geocodezip on 6 Mar 2012 at 2:04

[GoogleCodeExporter]

Thank you both so much for doing this update! It provides some necessary fixes 
and some desired features.

I started testing this branch as I ran into some unexplainable troubles with 
the polys branch - all related to use of custom markers - which spontaneously 
disappeared on maps. This branch seems to overcome my troubles there. 

A few observations:
- setting of the default style: preferably through an external method. Right 
now the directions are added to the balloon - which is something that may or 
not may be of use.
- size of the icon: whilst I agree that the current implementation is more 
standards compliant than Google KML implementation - it may be desired to force 
icons to a certain size. ( I ran into this issue immediately and redid my maps 
but that may not always be feasible).
- the suggestion of adding a proxy property to geoxml is a very valid one. I 
have implemented my own proxy to handle the cross-domain requests but this 
feature would have made things easier.

As said.. I had problems with the polys branch and this one seems (even in the 
current "under discussion" status) to solve those so I have started to 
implement this version. Thank you for the hard work.

Original comment by sylvia.s...@gmail.com on 13 Mar 2012 at 4:26

[GoogleCodeExporter]

You wrote:
> I started testing this branch as I ran into some unexplainable troubles with 
the 
> polys branch - all related to use of custom markers - which spontaneously
>  disappeared on maps. This branch seems to overcome my troubles there. 

Were you using the "development/nightly" version of the v3 API?  I have seen 
some issues there.  I would be curious to see the problem. Could you provide a 
link or a sample kml that exhibits the problem?

Original comment by geocodezip on 13 Mar 2012 at 5:05

[GoogleCodeExporter]

@geocodezip@gmail.com:
 Sent you an email with details.

Original comment by sylvia.s...@gmail.com on 13 Mar 2012 at 10:35

[GoogleCodeExporter]

you wrote:
> Sent you an email with details.

Thank you.

You are using the "development/nightly" version of the v3 API:
<script type="text/javascript" 
src="http://maps.google.com/maps/api/js?sensor=false">

I think it is related to this issue:
http://code.google.com/p/gmaps-api-issues/issues/detail?id=3908

It works if you change that to v=3.6 (the "Frozen" version):
http://code.google.com/apis/maps/documentation/javascript/basics.html#Versioning

<script type="text/javascript" 
src="http://maps.google.com/maps/api/js?sensor=false&v=3.6">

I will look at addressing it, it seems to be an issue with the canvas 
implementation of markers.  I was hoping that it would be fixed by google.

Do you mind if I post an example using your kml from my domain?

Original comment by geocodezip on 13 Mar 2012 at 11:03