Я думаю о написании программного обеспечения для работы с GPS-треками и путевыми точками (в основном, для хранения, отображения и расчета таких показателей, как скорость, оценка и некоторые простые статистические данные).
Интересно, какой должна быть наиболее концептуально надежная модель данных относительно трекпоинтов, и вот несколько «кандидатов»:
Рассматривая треки как последовательности трекпоинтов:
1.1. Треки считаются «2D», поскольку проекции карты являются 2D. Точки могут иметь или не иметь высоту, могут или не иметь отметку времени. Высота и отметка времени считаются «дополнениями», «необязательными». Для наземных применений высота является прямой функцией широты / долготы (доступной через DEM);
1.2. Треки считаются «трехмерными», поскольку географическое пространство, действительно, является трехмерным, а траектория приемника - трехмерной (таким образом, двумерная проекция является формой сокращения данных). Отметка времени может присутствовать или не присутствовать (дорожка могла быть нарисована вручную).
1.3. Треки считаются "4D" (3 пространственных + время). Таким образом, карта, нарисованная от руки, является особым случаем, когда отметка и отметка времени присутствуют
nullили иным образом отсутствуют, но свойства Trackpoint всегда «там».Треки считаются словарями потоков, где все потоки имеют одинаковую длину. Существует список широт, список долгот, список высот, одна из отметок времени и т. Д. Это позволяет легко рассчитать статистику для каждого свойства, и концепция Trackpoint в некотором смысле становится «виртуальной», поскольку она является поперечное сечение многих потоков.
Если я правильно понял, формат GPX принимает 1.1., KML принимает 1.2. (без поддержки меток времени), и Strava API принимает 2. (в формате JSON), но в конце концов это просто форматы FILE для сериализации и хранения, не обязательно для моделирования, вычислительного представления и обработки чисел.
Есть ли какая-либо форма, которая является предпочтительной, в объектно-ориентированном смысле, и почему? (Я считаю, что строгая типизация и разумное моделирование по крайней мере позволят избежать операций, которые не имеют смысла).
РЕДАКТИРОВАТЬ: некоторые "интригующие" дополнительные вопросы:
- Является ли нарисованный вручную трек КОНЦЕПТУАЛЬНО тем же, что треклог, записанный устройством? Должны ли они быть разных типов данных?
- Следует ли считать «правильным», что KML хранит нулевые высоты как ноль? Ноль - это возвышение, и если вы не знаете высоту, вам не следует присваивать ей числовой ноль, не так ли?
- Должно ли иметь значение, на трассе с отметкой, если отметка извлекается из данных матрицы высот («автономно»), из данных GPS или барометрических данных («в поле»)? Должно ли это быть помечено в объекте Track? Сохранено в разных свойствах Trackpoint? Игнорируется? Должны ли они быть разными типами коллекций?
- Если я отредактирую дорожку, записанную на устройстве, в редакторе карт (добавляя, перемещая и удаляя точки) или комбинируя дорожки с разными датами, как следует обрабатывать временные метки в точках? Должны ли они быть "сброшены" до нуля? Нужно ли создавать объект (коллекцию трекпоинтов) другого типа из предыдущих?
источник
<>и{}для организации ваших данных - и метаданных - вы делаете это неправильно.Ответы:
Я не думаю, что на этот вопрос можно ответить однозначно, так как есть много, много способов подойти к этому ..
Тем не менее, эти мысли могут быть актуальны:
Хранение данных относительно неважно. Какой бы механизм вы ни использовали, Database, JSON, KML и т. Д., Он все равно остается «плоским хранилищем».
Важно то, какое программное обеспечение вы используете и как вы представляете данные в программном обеспечении, чтобы вы могли проводить моделирование.
Скорость доступна двумя способами: расстояние х время или как вывод от устройства GPS, откуда вы берете свои данные. Поэтому время становится неактуальным, кроме как как информационный элемент.
Кроме того, вы также можете учитывать время, используя смещение от начала дорожки. Если у вас есть скорость и расстояние, то вы можете рассчитать время в точках. (расстояние между двумя точками можно определить разными способами )
Высоту следует рассматривать как часть пространственной модели, она важна для определения целого массива интересной информации о самой трассе, например, можно рассчитать уклон, который затем позволяет понять изменения скорости вдоль трассы. Если нет уклона, любое замедление или увеличение скорости могли быть связаны с удалением ноги из акселератора.
С точки зрения слияния треков и нарисованных от руки треков время не имеет большого значения. Вы можете применять произвольные скорости, чтобы определить время, например, как долго проходить трек с заданной скоростью. Если вы объединяете треки с интервалом в несколько дней, ваши данные просто не будут иметь смысла, поэтому вам придется сбросить временные поля, возможно, используя смещения от начала трека.
Если высота не известна, она не известна, поэтому она не должна быть нулевой. Он также не должен быть отрицательным, поскольку отрицательные возвышения также являются действительными возвышениями. (В долине ниже уровня моря, в шахте и т.д.)
Да, DEMS доступны, Да, вы можете извлечь из них. Будет ли достаточно точным? Маловероятно, если точность не является проблемой. GPS или барометрические, обеспеченные высотами, будут лучшим, что Вы можете получить.
Итак, чтобы попытаться дать вам ответ, который идет близко:
Храните данные в любом удобном для вас формате, но я бы порекомендовал PostGRES с PostGIS - хороший вариант, он прекрасно справляется с 3D. Затем вы можете использовать обширные пространственные функции в PostGIS для манипулирования / моделирования ваших данных.
Если вы используете какую-то форму собственной программы, которую вы разрабатываете, используйте объектно-ориентированный подход, а не массивы. Если вы используете массивы, вы также можете использовать базу данных.
источник
Как уже упоминалось в другом ответе, существует много разных подходов. Поскольку я попросил «концептуально устойчивые модели данных», после многих исследований я обнаружил две большие области знаний, которые обеспечивают два совершенно разных подхода к концепции «движущихся объектов» и имеют много общего (в хорошем смысле):
источник