Data modeling（数据建模(Data modeling)）¶
Geotemporal series should model a change in an entity's position over time, such as a plane flying from San Francisco to New York City. If your data does not include timestamps, positions, or uniquely-identifying series IDs, geotemporal series may not be appropriate for your use case.
Observation schema¶
Each row in a geotemporal series sync adheres to the same schema, which is defined when the sync is created in Pipeline Builder. A schema minimally includes the following required fields:
| Column | Type | Description |
|---|---|---|
| Series ID | String |
[Required] The identifier for a sequence of observations, referred to by a geotemporal series reference (GTSR). Must be between 1-100 characters long, inclusive. |
| Timestamp | Timestamp |
[Required] The time the observation was emitted from a sensor. This may also be called the event timestamp. |
| Position | GeoPoint |
[Required] The latitude and longitude coordinates of the observation. |
| Altitude | Double |
[Optional] The height of the observation above the surface of the earth, in meters. Where needed for rendering, altitude is assumed to be height above ellipsoid (HAE), in meters. |
Additional data is often recorded alongside the observation, such as a plane reporting its heading or speed. Geotemporal series allow these additional data points to be captured alongside the required geotemporal series columns.
Picking a series ID¶
Within a geotemporal series sync, you should choose a series ID to group observations from the moving entity. The incoming data should include an identifier for a given entity that persists between observations. If no such identifier is provided, you can create an identifier from the data, for example, by concatenating a flight's number, origin, destination, and date. By including the date in the series ID, you ensure that each day's flight is treated as a separate series rather than flights over multiple days being associated with a single series.
The series ID is used to recall the latest point, track, and other properties related to the series. Conflicting series IDs result in poor map renderings or incorrect data.
Live vs static properties¶
Properties on a geotemporal series schema, like speed or heading, are all "live" by default, meaning that they are expected to change on every observation. Usually, properties that do not change, or "static" properties such as a plane's callsign or flag, should be placed on the geotemporal series object type rather than as properties on the geotemporal series itself. On rare occasions, it can be useful to denormalize a static property onto observations to enable search workflows. To support this, geotemporal series enable properties to be marked as "static" instead of "live", communicating to Foundry's geotemporal series database that the properties can be sampled less frequently than "live" properties when compressing or downsampling tracks. Such "static" properties are still required to be specified on every incoming observation, even if they remain unchanged between observations.
中文翻译¶
数据建模(Data modeling)¶
地理时间序列(Geotemporal series)应建模实体位置随时间的变化，例如飞机从旧金山飞往纽约市。如果您的数据不包含时间戳、位置或唯一标识的序列ID(series IDs)，则地理时间序列可能不适合您的使用场景。
观测模式(Observation schema)¶
地理时间序列同步(geotemporal series sync)中的每一行都遵循相同的模式，该模式在流水线构建器(Pipeline Builder)中创建同步时定义。一个模式至少包含以下必需字段：
| 列名 | 类型 | 描述 |
|---|---|---|
| 序列ID(Series ID) | String |
[必需] 观测序列的标识符，通过地理时间序列引用(GTSR)引用。长度必须在1-100个字符之间（含）。 |
| 时间戳(Timestamp) | Timestamp |
[必需] 传感器发出观测的时间。也可称为事件时间戳。 |
| 位置(Position) | GeoPoint |
[必需] 观测的经纬度坐标。 |
| 海拔(Altitude) | Double |
[可选] 观测点在地球表面以上的高度，单位为米。在需要渲染时，海拔默认为椭球体高度(HAE)，单位为米。 |
观测数据通常还会记录其他附加信息，例如飞机报告其航向或速度。地理时间序列允许将这些附加数据点与必需的地理时间序列列一同捕获。
选择序列ID(Series ID)¶
在地理时间序列同步中，您应选择一个序列ID(series ID)来对移动实体的观测进行分组。传入的数据应包含一个在观测之间保持不变的给定实体标识符。如果未提供此类标识符，您可以根据数据创建标识符，例如，通过拼接航班号、出发地、目的地和日期。通过在序列ID中包含日期，您可以确保每天的航班被视为单独的序列，而不是将多天的航班关联到同一个序列。
序列ID用于检索与序列相关的最新点、轨迹及其他属性。冲突的序列ID会导致地图渲染效果不佳或数据错误。
动态属性(Live properties)与静态属性(Static properties)¶
地理时间序列模式上的属性（如速度或航向）默认都是"动态的(live)"，这意味着它们预计会在每次观测时发生变化。通常，不会变化的属性，即"静态的(static)"属性（如飞机的呼号或国籍），应放置在地理时间序列对象类型上，而不是作为地理时间序列本身的属性。在极少数情况下，将静态属性反规范化到观测数据中可能有助于实现搜索工作流。为此，地理时间序列允许将属性标记为"静态的(static)"而非"动态的(live)"，从而告知Foundry的地理时间序列数据库：在压缩或降采样轨迹时，这些属性的采样频率可以低于"动态的(live)"属性。即使这些"静态的(static)"属性在观测之间保持不变，仍需要在每条传入的观测数据中指定它们。