Как лучше всего моделировать треки GPS для хранения, визуализации и анализа?


17

Я думаю о написании программного обеспечения для работы с GPS-треками и путевыми точками (в основном, для хранения, отображения и расчета таких показателей, как скорость, оценка и некоторые простые статистические данные).

Интересно, какой должна быть наиболее концептуально надежная модель данных относительно трекпоинтов, и вот несколько «кандидатов»:

  1. Рассматривая треки как последовательности трекпоинтов:

    1.1. Треки считаются «2D», поскольку проекции карты являются 2D. Точки могут иметь или не иметь высоту, могут или не иметь отметку времени. Высота и отметка времени считаются «дополнениями», «необязательными». Для наземных применений высота является прямой функцией широты / долготы (доступной через DEM);

    1.2. Треки считаются «трехмерными», поскольку географическое пространство, действительно, является трехмерным, а траектория приемника - трехмерной (таким образом, двумерная проекция является формой сокращения данных). Отметка времени может присутствовать или не присутствовать (дорожка могла быть нарисована вручную).

    1.3. Треки считаются "4D" (3 пространственных + время). Таким образом, карта, нарисованная от руки, является особым случаем, когда отметка и отметка времени присутствуют nullили иным образом отсутствуют, но свойства Trackpoint всегда «там».

  2. Треки считаются словарями потоков, где все потоки имеют одинаковую длину. Существует список широт, список долгот, список высот, одна из отметок времени и т. Д. Это позволяет легко рассчитать статистику для каждого свойства, и концепция Trackpoint в некотором смысле становится «виртуальной», поскольку она является поперечное сечение многих потоков.

Если я правильно понял, формат GPX принимает 1.1., KML принимает 1.2. (без поддержки меток времени), и Strava API принимает 2. (в формате JSON), но в конце концов это просто форматы FILE для сериализации и хранения, не обязательно для моделирования, вычислительного представления и обработки чисел.

Есть ли какая-либо форма, которая является предпочтительной, в объектно-ориентированном смысле, и почему? (Я считаю, что строгая типизация и разумное моделирование по крайней мере позволят избежать операций, которые не имеют смысла).

РЕДАКТИРОВАТЬ: некоторые "интригующие" дополнительные вопросы:

  • Является ли нарисованный вручную трек КОНЦЕПТУАЛЬНО тем же, что треклог, записанный устройством? Должны ли они быть разных типов данных?
  • Следует ли считать «правильным», что KML хранит нулевые высоты как ноль? Ноль - это возвышение, и если вы не знаете высоту, вам не следует присваивать ей числовой ноль, не так ли?
  • Должно ли иметь значение, на трассе с отметкой, если отметка извлекается из данных матрицы высот («автономно»), из данных GPS или барометрических данных («в поле»)? Должно ли это быть помечено в объекте Track? Сохранено в разных свойствах Trackpoint? Игнорируется? Должны ли они быть разными типами коллекций?
  • Если я отредактирую дорожку, записанную на устройстве, в редакторе карт (добавляя, перемещая и удаляя точки) или комбинируя дорожки с разными датами, как следует обрабатывать временные метки в точках? Должны ли они быть "сброшены" до нуля? Нужно ли создавать объект (коллекцию трекпоинтов) другого типа из предыдущих?

3
3. Треки - это набор точек с атрибутами x, y, z, m [] и временем. Файл CSV, содержащий эти 5 значений для каждой захваченной точки, более чем достаточно для надежной модели данных. Если вам нужны такие причудливые вещи, как <>и {}для организации ваших данных - и метаданных - вы делаете это неправильно.
nagytech

1
Я согласен с просто старым добрым CSV, он представляет все, что записывает GPS. Но формат GPX довольно распространен для устройств GPS. Эта ссылка может чего-то стоить, так как и GPS, и KML являются форматами данных XML. stackoverflow.com/questions/1820129/…
Пит

Хотя XML «великолепен» и все (по причинам, указанным в сообщении @ Pete), ни один из этих пунктов не имеет значения. Во всяком случае, накладные расходы не делают ничего, кроме как замедляют обработку чисел и раздувают ваши методы хранения и передачи данных. Конечно, если вы работаете в mom-n-pop, у вас никогда не будет достаточно данных, чтобы столкнуться с этими проблемами, и ваше сокращение числа не будет интенсивным. В любом случае, у вас не будет ресурсов для поддержания работы на таком близком расстоянии - так что XML далеко.
nagytech

1
Обратите внимание, что этот вопрос имеет гораздо большее отношение к МОДЕЛИРОВАНИЮ и дизайну данных (представление его концептуальной сущности), чем к реальной реализации. Пока комментарии сосредоточены на форматах файлов, что, на мой взгляд, еще дальше, потому что форматы файлов больше зависят от среды реализации, чем от природы самих данных.
Хелтонбайкер

1
В терминах ОО я использовал класс Line, который может содержать точки (lat, lng, ele, время, скорость, азимут и т. Д.). И, оттуда, Маршруты, которые представляют нарисованные от руки или намеченные «дорожки» и Треки, которые представляют фактическую дорожку с данными времени / скорости. Концептуально я ДУМАЮ, что они разные (нарисованные от руки и / или предоставленные картографом или что-то подобное, в сравнении с реальной трассой). Конечно, термины - это просто семантика, но использование реальных типов было полезным (вместо того, чтобы просто смешивать все вместе как «дорожку»). Кроме того, когда речь идет о форматах сериализации, я бы рассмотрел GeoJSON: en.wikipedia.org/wiki/GeoJSON .
Чарли Коллинз

Ответы:


4

Я не думаю, что на этот вопрос можно ответить однозначно, так как есть много, много способов подойти к этому ..

Тем не менее, эти мысли могут быть актуальны:

Хранение данных относительно неважно. Какой бы механизм вы ни использовали, Database, JSON, KML и т. Д., Он все равно остается «плоским хранилищем».

Важно то, какое программное обеспечение вы используете и как вы представляете данные в программном обеспечении, чтобы вы могли проводить моделирование.

Скорость доступна двумя способами: расстояние х время или как вывод от устройства GPS, откуда вы берете свои данные. Поэтому время становится неактуальным, кроме как как информационный элемент.

Кроме того, вы также можете учитывать время, используя смещение от начала дорожки. Если у вас есть скорость и расстояние, то вы можете рассчитать время в точках. (расстояние между двумя точками можно определить разными способами )

Высоту следует рассматривать как часть пространственной модели, она важна для определения целого массива интересной информации о самой трассе, например, можно рассчитать уклон, который затем позволяет понять изменения скорости вдоль трассы. Если нет уклона, любое замедление или увеличение скорости могли быть связаны с удалением ноги из акселератора.

С точки зрения слияния треков и нарисованных от руки треков время не имеет большого значения. Вы можете применять произвольные скорости, чтобы определить время, например, как долго проходить трек с заданной скоростью. Если вы объединяете треки с интервалом в несколько дней, ваши данные просто не будут иметь смысла, поэтому вам придется сбросить временные поля, возможно, используя смещения от начала трека.

Если высота не известна, она не известна, поэтому она не должна быть нулевой. Он также не должен быть отрицательным, поскольку отрицательные возвышения также являются действительными возвышениями. (В долине ниже уровня моря, в шахте и т.д.)

Да, DEMS доступны, Да, вы можете извлечь из них. Будет ли достаточно точным? Маловероятно, если точность не является проблемой. GPS или барометрические, обеспеченные высотами, будут лучшим, что Вы можете получить.

Итак, чтобы попытаться дать вам ответ, который идет близко:

Храните данные в любом удобном для вас формате, но я бы порекомендовал PostGRES с PostGIS - хороший вариант, он прекрасно справляется с 3D. Затем вы можете использовать обширные пространственные функции в PostGIS для манипулирования / моделирования ваших данных.

Если вы используете какую-то форму собственной программы, которую вы разрабатываете, используйте объектно-ориентированный подход, а не массивы. Если вы используете массивы, вы также можете использовать базу данных.


1
Большое спасибо за ваше время и интерес, я нашел ваш ответ очень интересным. Но с одной вещью я не могу согласиться: эта скорость является канонической переменной, а время - нет. Это по многим причинам, но в первую очередь потому, что скорость является производной расстояния от времени. Вы всегда получите хорошую скорость и особенно хорошую среднюю скорость (которая, как я обнаружил, более полезна, чем мгновенная скорость), если вы вычислите расстояние сегмента за время сегмента. С другой стороны, если вы интегрируете скорости, ошибка интеграции даст очень неправильные результаты после короткого числа выборок.
Хелтонбайкер

2
Да, я могу согласиться с этим. однако использование GPS-треков само по себе подвержено ошибкам определения местоположения. Все дело в том, какую точность вы можете получить. Согласитесь, время довольно точное, но вы также получите ошибки, связанные с позиционными ошибками GPS. Интервалы в одну секунду на точках трека - это всего лишь одна секунда, но внутри GPS его алгоритмы могут в любом случае интерполироваться для достижения расчетной позиции. Очевидно, что детализация данных будет иметь большое влияние на любой выбранный метод анализа
Марк Купитт

Очень хорошо сказано ... Вот почему я уже совсем отказался от построения «мгновенной скорости», перейдя к некоторой «мгновенной средней скорости», которая будет: «для каждой данной точки траектории ее мгновенная средняя скорость - это средняя скорость за последние N минут. " Это очень хороший сюжет, и дает соответствующее ощущение изменения скорости на протяжении поездки. Но правильный расчет может быть сложным и, скорее всего, требует немного вычислительных ресурсов.
Хелтонбайкер

0

Как уже упоминалось в другом ответе, существует много разных подходов. Поскольку я попросил «концептуально устойчивые модели данных», после многих исследований я обнаружил две большие области знаний, которые обеспечивают два совершенно разных подхода к концепции «движущихся объектов» и имеют много общего (в хорошем смысле):

  1. Книги Геннадия и Натальи Андриенко, изданные Springer Verlag, например, превосходная визуальная аналитика движения (среди прочих от того же издателя). Настоятельно рекомендуется.
  2. В Абстрактные спецификации (концептуальные схемы) ISO / OGC (ISO 191хх нормы), специально ISO 19107 (Пространственное Schema), 19108 (Temporal Schema), 19111 (пространственной привязки по координатам), 19141 (Перемещение объектов) и 19148 (линейных координат)
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.