2
如何对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？是否应创建与以前类型不同的对象（跟踪点集合）？