如何对GPS轨迹进行最佳建模以进行存储，可视化和分析？

我正在考虑编写处理GPS航迹和航点的软件（主要是存储，显示和计算速度，坡度和一些简单的统计数据）。

我想知道关于跟踪点的概念上最健壮的数据模型应该是什么，下面是一些“候选对象”：

将航迹视为航迹点序列：

1.1。由于地图投影为2D，因此轨迹被视为“ 2D”。跟踪点可能有高程，也可能没有时间戳。高程和时间戳记被视为“附加”，“可选”。对于地面应用，海拔是lat / lon的直接函数（可通过DEM获得）。

1.2。轨道被认为是“ 3D”，因为地理空间实际上是3D，并且接收器的轨迹是3D（因此2D投影是数据缩减的一种形式）。时间戳可能存在或不存在（轨迹可能是手工绘制的）。

1.3。轨道被视为“ 4D”（3个空间+时间）。因此，手绘地图是一种特殊情况，其中高程和时间戳存在null或不存在，但Trackpoint属性始终为“有”。
轨道被视为流的字典，其中所有流的长度相等。这里有一个纬度列表，一个经度列表，一个高程列表，一个时间戳等，这使每个属性的统计信息变得容易计算，并且从某种意义上说，Trackpoint的概念在某种意义上是“虚拟的”许多溪流的横截面。

如果我理解正确，GPX格式采用1.1。KML采用1.2。（不支持时间戳），并且Strava API采用2.（JSON格式），但最终这些只是用于序列化和存储的FILE格式，而不必用于建模，计算表示和数字运算。

在面向对象的意义上，是否存在任何可取的形式，为什么？（我相信，强类型和合理的建模至少可以避免那些没有意义的操作）。

编辑：一些“有趣的”附加问题：

手绘轨迹在概念上与设备记录的轨迹日志是否相同？它们应该是不同的数据类型吗？
KML将空高程存储为零是否应该被视为“正确”？零是高程，如果您不知道高程，则不应该为其指定数字零，不是吗？
在具有高程的轨道中，是否从DEM数据（“离线”）或GPS数据或气压数据（“现场”）中提取高程，这有关系吗？是否应该在Track对象中标记它？是否保存到其他Trackpoint属性？忽略了吗？它们应该是不同的集合数据类型吗？
如果我在地图编辑器中编辑了设备记录的轨道（添加，移动和删除点），或者合并了不同日期的轨道，应如何处理轨道点中的时间戳？是否应该将它们“重置”为null？是否应创建与以前类型不同的对象（跟踪点集合）？

— 赫尔顿·比克
source

3.轨迹是具有x，y，z，m []和时间属性的点的集合。对于捕获的每个点而言，包含这5个值的CSV文件对于强大的数据模型来说绰绰有余。如果你需要花哨的东西一样<>，并{}帮助你组织你的数据-和元数据-你就错了。

— nagytech

我同意一个很好的旧CSV，它代表了GPS记录的一切。但是，GPX格式对于GPS设备非常普遍。该链接可能很有价值，因为GPS和KML都是XML数据格式。stackoverflow.com/questions/1820129/…–

— 皮特

虽然XML很棒，但所有这些（由于@Pete的链接文章中的原因）都不重要。如果有的话，开销只会减慢数字运算的速度，并膨胀数据存储和传输方法。诚然，如果您是一个不受欢迎的妈妈，那么您永远不会有足够的数据来遇到这些问题，并且您的数字处理也不会很紧张。无论哪种方式，您都没有资源来维持运行，从而关闭了金属-因此无法使用XML。

— nagytech

请注意，这个问题与数据的建模和设计（其概念本质的表示）相比，实际的实现更多。到目前为止，这些评论都集中在文件格式上，这与我认为的相去甚远，因为文件格式更多地依赖于实现介质而不是数据本身的性质。

— heltonbiker 2013年

用面向对象的术语，我使用了一个Line类，它可以保存点（纬度，经度，ele，时间，速度，方位等）。并且，从那里代表手工绘制或预期“轨迹”的路线和代表带有时间/速度数据的实际轨迹的轨迹。从概念上讲，我确实认为它们是不同的（由制图员手工绘制和/或提供，与实际轨迹不同）。当然，这些术语只是语义，但使用实型类型会有所帮助（而不只是将它们作为“ Track”混搭在一起）。另外，关于序列化格式，我会考虑使用GeoJSON：en.wikipedia.org/wiki/GeoJSON。

— 查理·柯林斯

Answers:

我认为实际上无法确切地回答这个问题，因为有很多方法可以解决这个问题..

但是，这些想法可能是相关的：

数据存储相对不重要。无论使用哪种机制，数据库，JSON，KML等，它仍然是“固定存储”。

重要的是要使用的软件以及如何在软件中表示数据，以便进行建模。

速度可以通过两种方式获得：距离x时间或作为GPS设备的输出，这是您从中获取数据的位置。因此，除了作为信息项之外，时间变得无关紧要。

此外，您还可以通过使用与轨道起点的偏移量来考虑时间。如果您具有速度和距离，则可以计算这些点的时间。（两点之间的距离可以通过多种方法确定）

高程应被视为空间模型的一部分，它们与确定有关轨道本身的一系列有趣信息有关，例如，可以计算坡度，从而使您可以了解沿轨道的速度变化。如果没有坡度，则可能是脚从加速器上移开而导致减速或速度增加。

就合并轨迹和手绘轨迹而言，时间无关紧要。您可以应用任意速度来确定时间，例如，以给定速度穿越轨道多长时间。如果您要间隔几天合并轨道，那么您的数据将毫无意义，因此您必须重置时间字段，可能使用轨道开始处的偏移量。

如果高度未知，则未知，因此不应为零。它也不应为负，因为负高也是有效的高。（在海平面以下的山谷，矿井等中）

是的，可以使用DEMS，可以从它们中提取。足够准确吗？除非精度不是问题，否则不太可能。GPS或气压计提供的海拔高度将是最好的选择。

因此，尝试给您一个接近的答案：

以您喜欢的任何平面格式存储数据，但是我建议，带有PostGIS的 PostGRES是一个不错的选择，它可以很好地处理3D。然后，您可以使用PostGIS中广泛的空间功能来处理/建模数据。

如果使用开发的某种形式的自定义程序，请使用面向对象的方法而不是数组。如果使用数组，则最好使用数据库。

— 马克·库皮特
source

非常感谢您的时间和兴趣，我发现您的回答非常有趣。但是有一点我“不能”同意：速度是规范的变量，而时间却不是。这有很多原因，但是主要是因为速度是距离随时间的导数。如果您得出分段时间段上的分段距离，您将始终获得良好的速度，特别是良好的平均速度（我发现它比即时速度更有用）。另一方面，如果积分速度很高，则积分误差将在少量采样后给出非常错误的结果。

— heltonbiker 2013年

是的，我可以承认这一点。但是，使用GPS轨迹本身会遇到位置误差。这完全取决于您可以获得什么精度。同意，时间是相当准确的，但是由于GPS位置错误，使用该时间也会出错。轨迹点上的一秒间隔仅为一秒，但是在GPS内，其算法很可能会插值以到达估计位置。显然，数据的粒度将对选择的任何分析方法产生重大影响

— Mark Cupitt

非常好说...这就是为什么我已经完全放弃绘制“瞬时速度”，而选择某种“瞬时平均速度”的原因，即：“对于轨迹中的每个给定点，其瞬时平均速度就是平均值最后N分钟的速度。” 它绘制得非常好，并在旅途中提供了适当的速度变化感。但是正确的计算可能很棘手，并且很可能需要大量的计算。

— heltonbiker 2013年

正如在另一个答案中已经提到的，有许多不同的方法。自从我要求“概念上强健的数据模型”以来，经过大量研究，我发现了两个很棒的知识体系，它们为“移动物体”的概念提供了两种截然不同的方法，并且有很多重叠（从某种意义上来说）：

Springer Verlag出版的Gennady和Natalia Andrienko的书，例如出色的运动视觉分析（以及同一出版商的书）。强烈推荐。
ISO / OGC（ISO 191xx规范）的抽象规范（概念图），特别是ISO 19107（空间图），19108（时间图），19111（坐标的空间参照），19141（移动特征）和19148（线性参照）

— 赫尔顿·比克
source