Closed GoogleCodeExporter closed 9 years ago
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
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
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
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
Then it is the docs that need fixing.
Original comment by yer...@gmail.com
on 31 Aug 2010 at 10:44
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
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
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
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
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
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
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:
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
Original issue reported on code.google.com by
api.roman.public@gmail.com
on 25 Nov 2008 at 7:54