devdattaT / kml-samples

Automatically exported from code.google.com/p/kml-samples
0 stars 0 forks source link

Time on nested features is not defined #296

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
Which products are relevant to this feature request?

 Google Earth 5.0
 KMLStandard

What should this feature enhancement do?

Time is defined on Features on Google KML Reference and OGC KML 2.2
standard but time on nested features is not defined.

Given the definition of the visibility tag in AbstractFeatureType a
definition of time can be extrapolated to the following definition which is
validated by direct observation with various test case examples in Google
Earth.

    In order for a feature to be visible, all of its ancestors must
    be visible and that feature must be visible given visibility
    flags and temporal conditions up the chain to top-most feature.

    Features with no time properties basically inherit the time of
    its ancestors if they have time constraints.

Implementations of KML readers may be non-compatible behavior with respect
to time without a clear definition of how to handle nested time.

see
http://code.google.com/apis/kml/documentation/kmlreference.html#timeprimitive
see http://www.opengeospatial.org/standards/kml [OGC KML 2.2.0 Chapter 15]

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

This example shows how temporal visibility is inherited.

    [2    .   3]            timespan of outer-most container
[1       .    .   .     .    6]     timespan of placemark #1
    [2    .   4]            effective temporal visilbity of placemark #1
             [3   .     5]      timespan of inner-most container
[1       .    .   .     .    6]     timespan of placemark #2
             [3   4]                effective temporal visilbity of placemark #2

<kml xmlns="http://www.opengis.net/kml/2.2">
    <Document>
        <name>multi nested inherited time</name>
        <TimeSpan>
            <begin>2007-01-14T02:00:00Z</begin>
            <end>2007-01-14T04:00:00Z</end>
        </TimeSpan>
        <Placemark>
            <name>test point #1</name>
        <!-- the effective timespan of this feature T02..04 -->
            <TimeSpan>
                <begin>2007-01-14T01:00:00Z</begin>
                <end>2007-01-14T06:00:00Z</end>
            </TimeSpan>
            <Point>
                <coordinates>-122.536226,37.86047,0</coordinates>
            </Point>
        </Placemark>
        <Folder>
            <name>inner folder</name>
            <TimeSpan>
                <begin>2007-01-14T03:00:00Z</begin>
                <end>2007-01-14T05:00:00Z</end>
            </TimeSpan>
            <Placemark>
                <name>test point #2</name>
        <!-- the effective timespan of this feature T03..04 -->
                <TimeSpan>
                    <begin>2007-01-14T01:00:00Z</begin>
                    <end>2007-01-14T06:00:00Z</end>
                </TimeSpan>
                <Point>
                    <coordinates>-122.537116,37.85961000000001,0</coordinates>
                </Point>
            </Placemark>
        </Folder>
    </Document>
</kml>

Are there any currently known workarounds that produce the same, or
similar, result?

Work-around is not to have nested times in KML and add times intervals to
folders only or features only. Mixing time time in both Containers and
child features may have undefined results.

Original issue reported on code.google.com by gjmath...@gmail.com on 24 Aug 2009 at 9:54

GoogleCodeExporter commented 8 years ago

Original comment by api.roman.public@gmail.com on 11 Sep 2009 at 10:42

GoogleCodeExporter commented 8 years ago
Looking deeper into the OGC KML Specification documentation specifically the 
"KML 2.2
– An OGC Best Practice" document reveals the correct behavior of inherited 
time.

"... the value of the following Feature elements shall be inherited by all 
Feature
members of a hierarchy unless overruled by the presence of such elements locally
[list includes TimePrimitive]. Inheritance of these elements continues to any 
depth
of nesting, but if overruled by a local declaration, then the new value is 
inherited
by all its children in turn."

Source: http://portal.opengeospatial.org/files/?artifact_id=23689

While this was not implemented correctly in Google Earth 5.0.x, it was however 
fixed
in 5.1.3509.4636 (beta). It is no longer a Google Earth defect but the Google's 
KML
Reference <http://code.google.com/apis/kml/documentation/kmlreference.html> 
should
reflect this paragraph from the OGC document so misinterpretations can be 
avoided.

There are no inheritance rules defined in the KML Reference documentation yet 
the KML
specification allows Containers and Features to include elements like Time that 
are
inherited or overridden.

Original comment by gjmath...@gmail.com on 31 Oct 2009 at 8:31

GoogleCodeExporter commented 8 years ago
[deleted comment]
GoogleCodeExporter commented 8 years ago
[deleted comment]
GoogleCodeExporter commented 8 years ago
Only resolution needed for this issue is adding the paragraph from "KML 2.2
– An OGC Best Practice" document [described in last post] into Google's KML 
Reference to clearly define inheritance rules in KML.

This issue has been documented in the KML Reference Addendum
http://kml4earth.appspot.com/kmlErrata.html#Inheritance

Original comment by kml4earthguy on 27 Feb 2012 at 8:30