• Tidak ada hasil yang ditemukan

Change Requests | OGC

N/A
N/A
Protected

Academic year: 2017

Membagikan "Change Requests | OGC"

Copied!
3
0
0

Teks penuh

(1)

All Fields marked with

*

are mandatory.

Change Request

#:

87

Assigned OGC

Document #:

10-112

Name:

*

Thomas Lane

Organization:

*

Lockheed Martin

Email:

*

[email protected]

Document

Name/Version:

*

KML / 2.2.0

OGC Project

Document:

*

07-147r2

If this is a revision of a previous submission and you have a Change Request Number, then check here:

Enter the CR number here:

Enter the Revsion Number that you are revising here:

Title:

*

Refine Granularity of Timestamps

Source:

*

kml2.2swg

Work item code:

Category:

*

B (Addition of feature)

(2)

Reason for

change:

*

The work I am doing with KML would benefit from the ability to timestamp content in increments of less than a second, since the information I wish to represent on the model changes more than once per second.

Since I would benefit greatly from this change, other people and groups probably would, too. There are numerous potential uses of KML content that would be inconvenienced by the inability to differentiate events that occurred during the same second, but not at the same time.

Summary of

change:

*

Probably the simplest way to accomplish this would be to add a tag type that can be part of a <Timestamp>/<Timespan>, or

perhaps a tag that can be part of a

<when>/<begin>/<end>, that would provide added

granularity in specifying the time of a particular bit of content.

I would propose a maximum granularity of nanoseconds, since I can't imagine anyone needing more granularity than that.

Therefore, I would also propose that the tag be called

<nanoseconds>, and contain the number of nanoseconds into the second specified in the <when> tag. Perhaps, along the same lines, there could be <milliseconds> or <microseconds> tags.

Alternatively, the time specification format that goes into a <when> tag could be expanded to allow the optional inclusion of pieces of seconds (perhaps it could be optionally followed by Nnnnnnnnnn where nnnnnnnnn is the 9-digit number of nanoseconds).

Consequences if

not approved:

It will be impossible, in KML, to differentiate the time of items specifying events that occurred during the same second, but not at the same time. This precludes playing such events back like a movie, or implementing a KML display application capable of playing such events back like a movie, from the KML.

(3)

affected:

Supporting

Documentation:

Comments:

Status:

Assigned

Disposition:

Re

f

ered and Posted

Referensi

Dokumen terkait

This table also specifies the UML model data type, source of values and multiplicity of each listed parameter, plus the meaning to servers when each optional parameter is not

semantics are to be communicated over the service. The following items should be addressed in an Application Profile. a) Identify information resource types that can be requested.

An alternative location scheme is to use linearly referenced locations, where a location is specified as being at a certain distance along (and perhaps offset from) a linear

For example, an SPS may wish to allow a particular user to perform one operation but not a different operation, while other users could request both. Summary

The proposed resolution is to add optional metadata properties (corresponding to sub-elements of ISO 19139 MD_Metadata) to messages and time slices that each have a narrower scope,

A WFS request could then potentially contain both BBOX and FILTER parameters to allow for filtering of spatially constrained data during a BBOX request. In the event that a FILTER

However, if a specific application has information needs to be modelled and exchanged which are beyond the scope of the CityGML data model, this application data can also

For example, a KML geometry element that encodes a simple polygon could render through a styling service that interprets usage-specific styling instructions and returns an