KML is funny XML

[Stonecherub]

I am using paths to mark a series of faults (cracks) in a volcano.
Each path is saved in its own KML file. I then use Notepad++ as an XML
editor to copy each path out of its file and paste them in sequence
into a master kml file which will then display them all. When I do
this without error, it works just fine.

Also, when I rename a kml file and save it by typing in the extension
because kml is not a type, this file will parse and be displayed.

If I make any error - drop a tag and type it in, pick up an extra tag
and delete it, cut the whole placemark sequence and replace it - the
file cannot be parsed and the error is reported as the second
character of the final line and called "mismatched tag."

Notepad++ identifies unmodified kml files as UNIX - ANSI and I used
the encoding function "Convert to ANSI" on my modified files with no
change.

I'm a geologist and a pretend geek, not a real one. What am I doing
wrong?

[StarTraX]

I think you'll find that this is not a KML problem, but a problem of
Notepad++ which must be doing things behind the scene to generate
invalid KML.
You'll have to debug it by examining the resultant KML in a simple
text editor.

[Jason M]

Possible the conversion is saving a ASCII character out of the valid
range. UTF-8 default XML allows characters in the ASCII range 32-127 +
some special chars like tab, new line, etc.

One quick fix might be just change the XML header to ISO-8859-1:

old: <?xml version="1.0" encoding="UTF-8"?>
new: <?xml version="1.0" encoding="ISO-8859-1"?>

Most likely there is single bad character in your KML file. Maybe end-
of-file marker at the end, etc.

You can validate your KML XML content and identify which line/column
the KML/XML is invalid.

Try http://kmlvalidator.com/home.htm

[Stonecherub]

No converting of characters within Np++ solved the problem nor did
encoding="ISO-8859-1". When I fed the file toward the kmlvalidator,
it responded with, "Unable to read content from FaultsN.kml. Are the
file format and character encoding correct?" Working kml files came
back OK.
Now what?

On Dec 22 2009, 12:52 pm, Jason M wrote:
> Possible the conversion is saving a ASCII character out of the valid
> range. UTF-8 default XML allows characters in the ASCII range 32-127 +
> some special chars like tab, new line, etc.
>
> One quick fix might be just change the XML header to ISO-8859-1:
>
>  old: <?xml version="1.0" encoding="UTF-8"?>
>  new: <?xml version="1.0" encoding="ISO-8859-1"?>
>
> Most likely there is single bad character in your KML file. Maybe end-
> of-file marker at the end, etc.
>
> You can validate your KML XML content and identify which line/column
> the KML/XML is invalid.
>

> Tryhttp://kmlvalidator.com/home.htm

[StarTraX]

Do you want to publish the file - we'll soon tell you what's wrong!

[Stonecherub]

I just uploaded "faultsN.kml" to the files folder. Sorry, I'm learning
the protocols of the forum the hard way. Thanks for the help.

[Jason M]

Ok, now looking at it quickly shows the problem.
Bad XML. Missing end tag for Placemark for placemark named 'fn5'
starting ion line 92.

<Placemark>
<name>fn5</name>
<styleUrl>#msn_ylw-pushpin</styleUrl>
<LineString>
<tessellate>1</tessellate>
<coordinates>
-113.3611482896875,31.88053475257968,0
-113.3609578847226,31.88040026701376,0
-113.3608043773875,31.88025306081973,0
-113.3606628150953,31.88014797554377,0
-113.3605627266177,31.88001517478314,0 </coordinates>
</LineString>
*********************** here is no </Placemark> here
**************************
<Placemark>

[Jason M]

In future you can catch these types of errors by enabling error
checking in Google Earth.
Under Tools/Options/General tab select 'show prompts for all errors'
in KML Error Handling panel.

It would prompt you that you have a mismatched tag but you'd still
need to hunt and peck to find the actual line number where the error
actually is located.

--jason

[Stonecherub]

Stranger and stranger!

I checked "show prompt..." in GE, thanks for the suggestion. In Np++,
I did a search for "placemark" to see that they were paired open/
close. All of them lit up and I did repair the missing close at fn5.
Using "count," I made sure it was an even number.

When I ran this file again, all hell broke loose. The parser reported
"Unknown element <placemark> at line 100," the end of the fn5
(formerly broken) dataset. Line 100 is actually </linestring>, the
next is </placemark> and line 102 is <placemark>. Clicking any of the
command buttons steps me through identical errors in the remaining
datasets at the linestring close tag in each one.

Jason, error handling does give me line numbers, it's just that it
looks to me like these are not errors. My monitor is big enough to
have both NP++ and GE open as I step through the parser.

[Nymor]

Hi,

Not sure what you've done Stonecherub but I took your uploaded file
and added a closing </Placemark> on line 100 (after the </LineString>
on line 99) and everything works fine. From your post above it could
be that you've put the </Placemark> before the </LineString> going by
the line numbers you quoted - although you do seem to have them in the
right order ... but something doesn't match with the fixed version I
have.

I have...

99 </LineString>
100 </Placemark>
101 <Placemark>

This loads in GE with no problems.

Regards
Nymor

[Stonecherub]

I deleted and then re-typed in the three lines with the same results.
This is not worth messing with anymore. More time was spent on fixing
it than on re-building it. Other combined kml files work in my project
and, if I encounter this problem again, I'm going to re-install both
GE and NP++. Thanks, everybody, for all your help.

[Stonecherub]

I deleted and then re-typed in the three lines with the same results.
This is not worth messing with anymore. More time was spent on fixing
it than on re-building it. Other combined kml files work in my project
and, if I encounter this problem again, I'm going to re-install both
GE and NP++. Thanks, everybody, for all your help.

On Jan 8, 9:03 pm, Nymor wrote:

[shannon9585]

If you want to try an alternate text editor (if NotePad is indeed the
part of the problem), I use TextPad to edit my KMLs without any
problems regarding character encoding. It can be downloaded for free
from their website: http://www.textpad.com/.

Just curious, why are you copying and pasting the KML code into one
master file? You can merge all of the individual KML files into one
from within GE itself. Just open all of the files at the same time
and then drag and drop them into one folder, then save the file from
GE. This could be tedious with a lot of files, but I imagine copying
and pasting is just as time consuming.