Как получить профиль высоты для трека GPS?

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

У кого-нибудь есть намеки на самый простой способ сделать это. Два метода, которые я рассматриваю до сих пор:

• Использование Google Elevation API

  Этот API относительно прост в использовании, но все же требует нескольких шагов, которые не являются тривиальными из-за его ограничений использования: максимум 512 выборок, возвращаемых за запрос, и количество точек вдоль пути также ограничено (длиной URL).

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

  Или, если это не подходит для автоматизации, наилучшим подходом может быть предоставление пользователю возможности выбирать точки пересечения на карте вручную.

• Загрузка данных топографической миссии Shuttle Radar Mission (SRTM) и выполнение запроса локально.

  У меня нет такого опыта, поэтому любые предложения о том, насколько это возможно, приветствуются. Насколько большой набор данных? Какое программное обеспечение ГИС требуется, и может ли оно быть написано соответствующим образом? Я бы предпочел не писать алгоритм выборки и интерполяции, это звучит как боль . Какова вероятная эффективность такого подхода? (Мне нужно, чтобы он был довольно быстрым и работал на веб-сервере VPS с ограниченным объемом памяти ...)

Некоторые подробности, которые можно найти в ответе @ MerseyViking о загрузке данных с http://srtm.csi.cgiar.org/SELECTION/inputCoord.asp :

Имеется 72 x 24 фрагмента, каждый размером около 20 МБ, который распаковывается в 72,1 МБ 16-битный TIF-файл (6001 x 6001 пикселей).

Это ~ 120 ГБ, что больше, чем я могу хранить. Оставив его сжатым и игнорируя океаны, вы уменьшите его до 10 Гб, что все еще слишком велико. Загрузка данных по требованию значительно сократила бы необходимое пространство для хранения, но исходный сайт работает медленно (я получал только 10 КБ / с), что делало это довольно непрактичным.

Для локального решения GRASS может быть написан для этого:

# extract raster values at our points
# use cubic convolution for interpolation between DEM locations
v.drape in=my_pts out=pts_srtm_elev type=point rast=srtm_dem method=cubic

Я запустил расширенную версию этого для одного из моих вариантов использования, и производительность v.drape вообще не была проблемой.

gpsvisualizer.com сделает это за вас. Я считаю, что он использует GPSBabel и Google API в фоновом режиме.

Похоже, вам нужно это как общее решение, то есть наличие всех данных о высотах в мире, доступных вам для любой дорожки, которую вы хотите обработать, следовательно, не желая хранить все данные CGIAR локально; упомянутый выше gpsvisualizer.com (@Llaves) может быть вашим лучшим выбором.

Если вам не нужно высокое разрешение, набор данных GTOPO (сетка 1 км) составляет всего ~ 300 МБ для всей планеты; в противном случае доступны наборы данных ASTER GDEM (30 м) и оригинальные SRTM (90 м), но, как вы указали, много данных. (Размер данных ASTER после загрузки можно уменьшить, удалив связанные PDF-файлы, которые часто больше, чем фактические данные о высоте - набор данных для Африки был уменьшен на 40%, когда я сделал это!).

В R вы можете извлечь профиль высот из любого из этих наборов данных довольно быстро - хотя загрузка растра может занять большую часть времени. Это использует небольшую пользовательскую функцию readGPX и gpsbabel для обработки данных GPX:

#Load elevation model and process track:
dem <- raster("E020N40.DEM")
track <- readGPXt("trackfile.gpx")
coordinates(track) <- ~Longitude+Latitude
proj4string(track) <- "+proj=longlat +ellps=WGS84 +towgs84=0,0,0,0,0,0,0 +no_defs"
#Overlay (extract) the elevation data for the track points:
track$profile <- extract(dem, track)
track <- as.data.frame(track)

«track» теперь является таблицей точек GPS с широтой / долготой, другими стандартными данными GPX (скорость, высота GPS и т. д.) и столбцом «profile», который указывает высоту в этой точке.

Данные SRTM легко скачать для данной области, я использую этот сайт в прошлом. Файлы не очень большие, и вы можете получить их в формате TIFF с географической привязкой. Загрузка всего мира может занять некоторое время, но пара плиток занимает довольно большую площадь. Проблема, с которой вы можете столкнуться, связана с горизонтальным разрешением, которое составляет около 90 метров для большей части мира, а вертикальная ошибка может быть довольно большой, с выбросами и областями пропущенных данных.

Набор данных ASTER GDEM представляет собой более позднюю съемку с более высоким разрешением при горизонтальном разрешении ~ 30 м, но качество часто ниже, чем у соответствующих данных SRTM.

Я не знаю, в каком разрешении находятся данные о высотах Google, но я не удивлюсь, если бы они основывались на SRTM, поэтому использование API Google может дать вам результаты, аналогичные использованию локального процесса.

Исходя из ответа @underdark, если это простая веб-система, то GRASS GIS , вероятно, поможет . Я использовал r.profile для создания простых графиков взаимозаменяемости с некоторым успехом, но я не уверен, какой метод интерполяции он использует; это может быть просто ближайший сосед. Изменить : глядя на исходный код ,r.profile использует ближайшего соседа, так что вы можете получить некоторые ступенчатые артефакты.

Другим вариантом может быть написание скрипта Python с использованием GDAL и NumPy , что может быть немного больше работы, но будет хорошим пользовательским решением.

Сначала вы должны указать, какой тип горизонтальной / вертикальной точности вас устраивает.

Но давайте посмотрим на это с практической точки зрения:

• Каждая ячейка SRTM3 имеет ячейки 1200x1200 , каждая ячейка представляет собой двухбайтовое целочисленное значение, представляющее высоту в метрах. Это около 2,75 МБ необработанных несжатых данных.
• Всего 14042 плитки SRTM3. Это приблизительно. 38 ГБ необработанных данных.
• Вы действительно должны охватить весь мир? Я полагаю, что нет особого интереса для отображения профиля высот GPS-трека в центре Сахары, пустыни Гоби или Сибири, поэтому вам экономически невыгодно покрыть его, если вы не имеете денег (кстати: SRTM3 не покрывает весь мир , так что вам не нужно беспокоиться о таких местах, как Гренландия и Антарктида;)).
• С помощью некоторого умного сжатия и кодирования данных вы можете значительно уменьшить размер набора данных. Значения высоты составляют от 0 до 8848, поэтому два оставшихся бита не используются. Вы также можете кодировать возвышения посредством дельта-сжатия, чтобы еще больше уменьшить его. Вы также можете отказаться от некоторой вертикальной точности (скажем, до 2 м, что сэкономит вам один дополнительный бит для каждой ячейки.
• В зависимости от того, для каких типов GPS-треков это будет использоваться (ходьба, езда на велосипеде, вождение ...), вы должны хранить данные в меньших тайлах (скажем, 0,25x0,25 градуса) в виде файлов на диске или строк в таблице базы данных.
• Используйте некоторый умный кэш памяти для тайлов, чтобы вам не нужно было перезагружать часто используемые.
• Вычисление высоты от ячеек является легкой частью всего этого бизнеса.