Google My Maps incompatibility

[atomsmith]

I noticed that Google My Maps will not import KML generated by SharpKML ("The file contains invalid or unsupported data, or the file is too large to parse.") However, it will import the same KML data that has been imported and then exported through the desktop version of Google Earth.

This seems to be caused by the "kml:" namespace prefix that SharpKML adds to every element. Stripping off these prefixes using a text editor makes the file acceptable to Google My Maps. Can the prefix generation be made optional?

[samcragg]

Have you tried serializing the root object as a Kml element, which will include the namespace for you so the other elements aren't prefixed with kml: (there's an example here which shows how to serialize it)

If you're still stuck post some code and I'll try to help

[atomsmith]

I tried the technique you suggested, but I still get the namespace prefixes. This code takes the KML out of my input KMZ file, and serializes it back out again:

KmzFile kmzMain = KmzFile.Open(System.IO.File.OpenRead(strInputFilename));
KmlFile kmlMain = kmzMain.GetDefaultKmlFile();

Serializer serializer = new Serializer();
Kml root = kmlMain.Root as Kml;
serializer.Serialize(root);
using (StreamWriter strmOut = new StreamWriter(strOutputFilename, false, Encoding.UTF8))
{
    strmOut.Write(serializer.Xml);
}

[samcragg]

Do you have a small sample KMZ file that reproduces the issue that you're allowed to share - I'm guessing the namespaces that are being read are different to what the library is expecting so it's trying to preserve that information when serializing it.

[atomsmith]

Sure. Here is a KMZ exported from desktop Google Earth and the KML (with namespace prefixes) that results from running the code in my earlier comment.

SharpKml_Sample.zip

[samcragg]

Thanks for that, it looks like the input has the KML namespace declared twice, which we're trying to preserve when serializing and is causing problems:

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

Let me take a look and see how we can handle that, so far not having much luck with the XmlWriter to get it to do the right thing (the easy option would be to not serialize the xmlns:kml attribute, but I believe we have to retain all element/attributes from the original file)

[samcragg]

This is now fixed in 3.0.5 (well, it works on my machine 😇) - thanks for your help reporting and providing sample data that was able to reproduce the problem!

[atomsmith]

Looks good here, too. Thanks for the quick response.