Bug #524

Misplaced Style tags from gmt2kml

Added by Mark about 3 years ago. Updated over 2 years ago.

Status:ClosedStart date:2014-02-25
Priority:NormalDue date:
Assignee:Remko% Done:

100%

Category:-
Target version:Candidate for next bugfix release
Affected version:5.1.x Platform:Linux

Description

With a Google Support example in my hand which showed that <Style> definitions were placed above (outside) any <Folder> tags, I edited the KML file that gmt2kml created and moved the <Style> sections to the top of the KML file (just under <Document>), and this worked!! See https://maps.google.com/maps?q=http:%2F%2Fwww.erh.noaa.gov%2Fohrfc%2FHAS%2Fimages%2Fgoogle.kml&hl=en&sll=39.406489,-87.397614&sspn=0.998473,1.71524&t=h&z=7

Further experimentation suggests that the <Style> tags need not be at the top of the file, but simply must not be wrapped within <Folder> tags. Apparently, Google Earth tolerates the <Style> tags inside <Folder> tags, but Google Maps does not. Can gmt2kml be changed to produce <Style></Style> sections which are NOT wrapped within <Folder></Folder> tags?

Associated revisions

Revision 13348
Added by Remko over 2 years ago

Place <Style> items outside enclosing <Folder>
This fixes issue #524

History

#1 Updated by Paul about 3 years ago

  • Status changed from New to Feedback

I am not sure this is possible. Remember, you can make a KML file the same way you do PS: Using -O and -K to add various layers. As gmt2kml appends to a growing file, it cannot possibly place the new styles it is adding to a point earlier in the file before the Folder was declared. The only way would be a post-processing step that rearranges the styles etc. Have you tried to open the KML in Google Earth, then save it to a new file and see if that new file is working as expected in the maps? It may be the GE will do the rewriting properly - so could act as a post-processor. It would be nice to know the rules/limitations for KML in Google maps. Perhaps it is simple enough that a post-processor could be written. But not entirely clear what the limitations are from https://developers.google.com/kml/documentation/mapsSupport as it does not state what you found above.

#2 Updated by Mark about 3 years ago

The second paragraph of my original post states that the <Style></Style> tags do NOT need to be moved to the top for this to work in Google Maps. Whether gmt2kml uses "-O" or "-K", or neither, or both, the KML that is produced is something like this:
<Folder>

<Style>

...

</Style>
<Folder>

... <!– kml features here ... –>

</Folder>

</Folder>

If the outer <Folder></Folder> tags (which encapsulate the <Style> tags) were eliminated (indicated by the strikeout font), the KML would work on Google Maps without any postprocessing. These outer <Folder> tags are associated with each feature (i.e., each call to gmt2kml), so it appears that it is something that can be solved within gmt2kml code.

#3 Updated by Paul about 3 years ago

OK, thanks for the feedback. I wonder then if there is a purpose to having Folder tags at all? Or should we add an option to suppress the Folder tags when building KML for Google Maps? While that is easy to do I don't know if that is the right decision...

#4 Updated by Mark about 3 years ago

In 5.1.0, gmt2kml produces <Folder> tags that are nested 3 levels deep (for point features, at least). The innermost <Folder> tags wrap each Point Set. I think these are the only <Folder> tags where it makes sense to keep them.

The intermediate <Folder> tags wrap the file name containing each Point Set. I, personally, don't care to have the public be able to see the filenames I have chosen for my data, so I vote we eliminate the intermediate <Folder> tags – along with the <Name> tag underneath it – because it doesn't provide useful information. I have been able to verify that these intermediate <Folder> tags are not necessary for Google Maps to work properly.

The outermost <Folder> tags, which wrap both the <Style> tags and the Point Set, are not only unnecessary, but prevent Google Maps from working properly when the <Style> tags are encapsulated by <Folder> tags.

My vote would be to eliminate all but the innermost <Folder> tags encompassing each Point Set by default. If so desired, you can add an option to include all 3 levels of nesting, but even so, the <Style> tag must be left out of this nesting. I do not have Google Earth installed on a box where I can test my KML file. So my suggestion is only valid if removing the two outermost <Folder> tags also works in Google Earth.

#5 Updated by Remko almost 3 years ago

  • Assignee set to Remko
  • Affected version changed from 5.1.0 to 5.1.x

I'll assign this one to myself, and test a little bit.

Mark, do you have a little example you can share that did not work on Google Maps?

#6 Updated by Mark almost 3 years ago

Remko, Any point output from gmt2kml fails to work with Google Maps, AFAICT. It would appear from my experimentation that <Style> sections cannot be wrapped within <Folder> tags (to work properly with Google Maps), yet this is the case always with gmt2kml output. This is a busy week for me as significant flooding has returned to our service area, so if you still need an example from me, let me know and I can stay late to dig one up...
Mark

#7 Updated by Remko over 2 years ago

  • Status changed from Feedback to Resolved
  • % Done changed from 0 to 100

This issue was fixed in r13348 for version 5.1.x and r13349 for version 5.2.x
Please test.

#8 Updated by Remko over 2 years ago

  • Status changed from Resolved to Closed

Did not any negative reply. I assume it is fixed. Closing.

Also available in: Atom PDF