Parsing does not support namespace

[GoogleCodeExporter]

Hello,

I think there is a problem when using a kml file using namespace like the 
attached example.
After searching a bit, I guess I found the problem in this piece of code :


if (!!GeometryNodes && (GeometryNodes.length > 0)) {
          for (var gn=0;gn<GeometryNodes.length;gn++) {
             if (!GeometryNodes[gn].parentNode ||
                 !GeometryNodes[gn].parentNode.nodeName) {

             } else { // parentNode.nodeName exists
               var GeometryPN = GeometryNodes[gn].parentNode;
               Geometry = GeometryPN.nodeName;

        // Extract the coordinates
        // What sort of placemark?
        switch(Geometry) {
          case "Point":
...
}

When kml document uses namespaces, the nodeName is not "Point", but 
"namespace:Point".
Instead of using the nodeName, the localName attribute whould fix the problem.

This problem prevent usage of namespaces which are regular though.

Original issue reported on code.google.com by gilian.h...@gmail.com on 8 Jan 2015 at 10:43

Attachments:

• test.kml

[GoogleCodeExporter]

Why do you need to do that?

Original comment by geocodezip on 8 Jan 2015 at 11:08

[GoogleCodeExporter]

Hello,

We produce kml data using the java API 
http://labs.micromata.de/projects/jak.html, that produces by default xml with 
namespace.
Presence of namespace in the kml causes the parsing to fail because of the 
Geometry = GeometryPN.nodeName; that get the nodeName including namespace, 
causing the switch to use the "default" block.
As the rest of geoxml3 code supports namespace, it seems simple to me fo fix
Geometry = GeometryPN.nodeName
by changing it to Geometry = GeometryPN.localName;

I tested it and it seems ok to me.
Is it ok for you ?

Original comment by djeanpr...@gmail.com on 8 Jan 2015 at 11:14

[GoogleCodeExporter]

Is there a chance you would consider fixing this issue, or do you think it's 
worthless ?
Thanks.

Original comment by djeanpr...@gmail.com on 8 Jan 2015 at 4:54