Misplaced Style tags from gmt2kml
|Target version:||Candidate for next bugfix release|
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?
#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:
... <!– kml features here ... –>
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.
#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.
#6 Updated by Mark about 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...