Як отримати профіль висоти для треку на GPS?

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

Хтось має підказки про найпростіший спосіб зробити це. Дві методики, які я розглядаю поки що:

• Використання API Google Elevation

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

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

  Або, якщо це не підходить для автоматизації, найкращим підходом може бути дозволити користувачеві вибирати точки трансекти на карті вручну.

• Завантаження даних маршрутної радіолокаційної місії Shuttle Radar (SRTM) та виконання запиту локально.

  Це щось, з чим я не маю досвіду, тому будь-які пропозиції щодо можливості здійснення цього є бажаними. Наскільки великий набір даних? Яке програмне забезпечення ГІС потрібно, і чи може воно бути написане відповідним чином? Я вважаю за краще не писати алгоритм вибірки та інтерполяції, це звучить як біль . Яка ймовірність виконання такого підходу? (Мені потрібно, щоб він був досить швидким і працював на обмеженій пам'яттю веб-сервері VPS ...)

Деякі додаткові подробиці, щоб розкрити відповідь @ MerseyViking про завантаження даних з http://srtm.csi.cgiar.org/SELECTION/inputCoord.asp :

Є 72 х 24 плитки, кожна розміром з 20-мегабітним поштовим файлом, який розкладається на 72,1 Мб 16-бітовий TIF-файл (6001x6001 пікселів).

Це ~ 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 ви можете витягнути профіль висоти з будь-якого з цих наборів даних досить швидко - хоча завантаження растру може зайняти більшість часу. Для обробки даних GPX використовується невелика спеціальна функція readGPX та gpsbabel:

#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-точок з lat / lon, іншими стандартними даними 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. Це близько cca. 38 Гб необроблених даних.
• Вам справді потрібно охопити весь світ? Я думаю, що для відображення профілю висоти GPS-доріжки посеред Сахари, пустелі Гобі чи Сибіру не так вже й багато цікавого, тому для вас це не є економічно доцільним, якщо ви втратили гроші (BTW: SRTM3 не покриває Весь світ , тому вам не потрібно турбуватися про такі місця, як Гренландія та Антарктида;)).
• За допомогою певного розумного стиснення та кодування даних ви могли значно зменшити розмір набору даних. Значення висоти - від 0 до 8848, тому два біта, що залишилися, не використовуються. Ви також можете кодувати висоти через дельта стиснення, щоб ще більше зменшити її. Ви також можете відмовитись від вертикальної точності (до, скажімо, 2 м, яка потім економить один додатковий біт для кожної комірки.
• Залежно від того, для яких типів треків GPS це буде використовуватися (ходьба, їзда на велосипеді, їзда на машині ...), ви повинні зберігати дані у менші плитки (скажімо, 0,25x0,25 градусів) у вигляді файлів на диску або рядків у таблиці бази даних.
• Використовуйте кілька розумних кеш-пам'яті для плиток, щоб не потрібно перезавантажувати часто використовувані.
• Розрахунок висоти від осередків - легка частина всього цього бізнесу.