Я думаю о написании программного обеспечения для работы с 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? Игнорируется? Должны ли они быть разными типами коллекций?
- Если я отредактирую дорожку, записанную на устройстве, в редакторе карт (добавляя, перемещая и удаляя точки) или комбинируя дорожки с разными датами, как следует обрабатывать временные метки в точках? Должны ли они быть "сброшены" до нуля? Нужно ли создавать объект (коллекцию трекпоинтов) другого типа из предыдущих?
<>
и{}
для организации ваших данных - и метаданных - вы делаете это неправильно.