Folder <visibility> doesn't cascade to its child Placemarks

[GoogleCodeExporter]

Which products are affected?
Google Earth

What steps will reproduce the problem?
1. Copy the below KML to Earth
2. Observe that placemark 'B' is visible despite its parent folder having
<visibility>0</visibility>

What is the expected output or behavior? What do you see instead?
'B' should be invisible

What application versions (if any) are you using?
GoogleEarth 4.3

Which operating systems and browsers are affected?
All

Please provide any additional information (code snippets/links) below.

<?xml version="1.0" encoding="UTF-8"?>
<kml xmlns="http://www.opengis.net/kml/2.2">
  <Document>
    <Folder>
      <visibility>1</visibility>
      <Placemark>
        <name>A</name>
        <visibility>1</visibility>
        <Point>
          <coordinates>0,0</coordinates>
        </Point>
      </Placemark>
    </Folder>
    <Folder>
      <visibility>0</visibility>
      <Placemark>
        <name>B</name>
        <visibility>1</visibility>
        <Point>
          <coordinates>1,0</coordinates>
        </Point>
      </Placemark>
    </Folder>
  </Document>
</kml>

Original issue reported on code.google.com by api.roman.public@gmail.com on 25 Nov 2008 at 7:54

[GoogleCodeExporter]

Any update on this? The google earth behaviour is still incorrect according to 
the
KML docs.

Original comment by yer...@gmail.com on 7 Apr 2010 at 11:38

[GoogleCodeExporter]

I am experiencing this issue with Google Earth version 5.1.3533.1731, any news 
on a
possible fix?

Original comment by corey.wa...@flinders.edu.au on 29 Apr 2010 at 1:10

[GoogleCodeExporter]

See also http://code.google.com/p/earth-issues/issues/detail?id=435

Original comment by gjmath...@gmail.com on 22 May 2010 at 8:58

[GoogleCodeExporter]

This is working as intended. Visibility has always been overridden on the child 
element level, and changing this would break existing code.

Original comment by manomark...@gtempaccount.com on 31 Aug 2010 at 10:24

• Changed state: WontFix

[GoogleCodeExporter]

Then it is the docs that need fixing.

Original comment by yer...@gmail.com on 31 Aug 2010 at 10:44

[GoogleCodeExporter]

Is there any chance that the situation could be special-cased for items loaded 
from NetworkLinks, then?  My application has a large number of items loaded 
into folders by category.  New items are frequently loaded using a 
NetworkLinkUpdate Create.  It would be nice if an item loaded into a folder 
that was turned off would default to being turned off, so that the user only 
has to turn off a category once instead of every time an item is created.

Original comment by dhirv...@gmail.com on 1 Sep 2010 at 10:59

[GoogleCodeExporter]

It is unlikely there will be a special case to change this behavior, as a lot 
of existing KML relies on it working the way it does:  A physical left-panel 
click in the Client will trigger a cascading visibility/hidden result to it's 
children, but as far as KML goes all items will display according to either 
their defaults or your manual overrides.

Therefore if you want your Placemarks to be hidden by default, whether in a 
NetworkLink or otherwise, you will need to add <visibility>0</visibility> to 
them.

Original comment by jli...@google.com on 1 Sep 2010 at 11:08

[GoogleCodeExporter]

A lot of existing KML relies, then, on applications not following 
specifications, and not following common sense. IMHO it is the docs that are 
correct and anything else should be updated to follow them.

Or, if this is unacceptable, how about a flag option in the KML that turns on 
the sensible behaviour?

Original comment by yer...@gmail.com on 2 Sep 2010 at 4:11

[GoogleCodeExporter]

From a compliance point of view this is a bug but documenting it as an intended 
"feature" should be acceptable to most.

From the OGC KML spec section 9.1.3.2.1 "In order for a 
kml:AbstractFeatureGroup to be visible, the kml:visibility tag of all its 
ancestors shall also be set to 1 or true" so the Placemark 'B' in above example 
should *NOT* be visible unless its parent folder is checked.

If you update Google Earth reference docs please note in the docs that GE 
violates the strict OCG KML spec and is non-compliant wrt this rule.

Original comment by gjmath...@gmail.com on 2 Sep 2010 at 5:21

[GoogleCodeExporter]

Thanks for noting this discrepancy.  In this case, it seems the OGC KML Spec is 
in error.  We will plan to work with the OGC to rectify it (via their open 
processes for revising/correcting OGC standards) for future versions of the 
spec.  

Original comment by jli...@google.com on 2 Sep 2010 at 8:43

[GoogleCodeExporter]

It is my sincerest hope that the 400+ members of the OGC outvote Google on 
changing the standards on this issue.
The use of Folders to manipulate Placemarks is of the utmost importance.
To be obliged to code <gx:update><change> for each and every child placemark 
(when there are 100+ Placemarks, and the number evolves) is a maintenance 
nightmare.
The fact that Google KML visibility functions in a different manner from the 
Listview  in the pannels defies logic.
Here's to hoping before my project gets unmanageable....

Original comment by mn.lindr...@gmail.com on 3 Jul 2011 at 9:39

[GoogleCodeExporter]

Maybe the issue above got rejected because it wasn't the best example.

<?xml version="1.0" encoding="UTF-8"?>
<kml xmlns="http://www.opengis.net/kml/2.2">
  <Document>
      <visibility>0</visibility>
      <Placemark>
        <name>A</name>
        <Point>
          <coordinates>-0.119824,51.511129</coordinates>
        </Point>
      </Placemark>
  </Document>
</kml>

In this example, however, the ancestor clearly has visblity not true and 
Placemark named "A" should not be shown. The distinction here is that Placemark 
"A" does not explicitly have <visibility>1</visibility> and only is "visible" 
by the default value of "1" assigned to visbility of a feature.

Google Earth implements visiblity such that visiblity on a child element 
overrides visbility even if the visibility is not explicitly defined and this 
violates the spec so either the OGC publishes an addendum to KML spec noting 
the correction or the Google Earth documentation note that it breaks the spec 
in this manner.

Original comment by kml4earthguy on 24 Mar 2013 at 10:50

Attachments:

• visibility.kml

[GoogleCodeExporter]

This issue has been added to the "unofficial" KML Errata.
http://kml4earth.appspot.com/kmlErrata.html#visibility

At least this is a placeholder to document such inconsistencies.

Whether visibility as implemented in Google Earth is right or wrong is not as 
important as it contradicts the official KML Spec.

Original comment by gjmath...@gmail.com on 10 Apr 2013 at 9:21