Jak uzyskać profil wysokości dla ścieżki GPS?

Chciałbym uzyskać dość dokładny profil wysokości dla śladu zarejestrowanego za pomocą GPS (który często zawiera bardzo niewiarygodne dane wysokości i czasami wcale, w zależności od modelu).

Czy ktoś ma jakieś wskazówki na temat najprostszego sposobu na zrobienie tego. Dwie techniki, które rozważam do tej pory to:

• Korzystanie z interfejsu Google Elevation API

  Ten interfejs API jest stosunkowo łatwy w użyciu, ale nadal wymaga kilku kroków, które nie są trywialne z powodu jego ograniczeń użytkowania: maksymalnie 512 próbek zwracanych na żądanie, a liczba punktów na ścieżce jest również ograniczona (ze względu na długość adresu URL).

  Oczekuję, że można uprościć filtr upraszczający gpsbabel, aby zredukować ścieżkę do odpowiedniej liczby punktów (żaden punkt nie znajduje się bliżej niż 100 m razem ze względu na rozdzielczość danych wysokości), ale nadal pozostaje problem z mapowaniem ten uproszczony utwór z powrotem na pierwotną ścieżkę, ponieważ długości będą się różnić.

  Lub, jeśli nie jest to odpowiednie do automatyzacji, najlepszym rozwiązaniem może być ręczne wybranie punktów przecięcia na mapie.

• Pobranie danych Shuttle Radar Topography Mission (SRTM) i wykonanie zapytania lokalnie.

  Nie mam z tym doświadczenia, więc wszelkie sugestie dotyczące tego, jak jest to wykonalne, są mile widziane. Jak duży jest zestaw danych? Jakie oprogramowanie GIS jest wymagane i czy można je odpowiednio skryptować? Wolałbym nie pisać algorytmu próbkowania i interpolacji, co brzmi jak ból . Jakie jest prawdopodobne wykonanie takiego podejścia? (Potrzebuję, aby był dość szybki i działał na serwerze VPS o ograniczonej pamięci ...)

Kilka dalszych szczegółów, które należy udzielić odpowiedzi @ MerseyViking dotyczącej ponownego pobierania danych z http://srtm.csi.cgiar.org/SELECTION/inputCoord.asp :

Istnieją 72 x 24 kafelki, każdy o rozmiarze pliku zip 20 MB, który dekompresuje do pliku TIF o długości 72,1 MB (6001 x 6001 pikseli).

To ~ 120 GB, czyli więcej niż mogę przechowywać. Pozostawienie go skompresowanego i zignorowanie oceanów spowoduje zmniejszenie go do może 10 GB, co wciąż jest nieco za duże. Ładowanie danych na żądanie radykalnie zmniejszyłoby potrzebną przestrzeń dyskową, ale witryna źródłowa jest powolna (uzyskiwałem tylko 10 kb / s), co czyni to dość niepraktycznym.

W przypadku rozwiązania lokalnego GRASS może zostać napisany w skrypcie, aby to zrobić:

# 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

Uruchomiłem jego rozszerzoną wersję dla jednego z moich przypadków użycia, a wydajność v.drape nie stanowiła żadnego problemu.

gpsvisualizer.com zrobi to za Ciebie. Wierzę, że używa GPSBabel i Google API w tle.

Wygląda na to, że potrzebujesz tego jako ogólnego rozwiązania, tj. Mając wszystkie dane dotyczące wysokości na świecie dostępne dla każdej ścieżki, którą chcesz przetworzyć, a zatem nie chcesz przechowywać wszystkich danych CGIAR lokalnie; wspomniana powyżej gpsvisualizer.com (@Llaves) może być najlepszym wyborem.

Jeśli nie potrzebujesz wysokiej rozdzielczości, zestaw danych GTOPO (siatka 1 km) to tylko ~ 300 MB dla całej planety; w przeciwnym razie dostępne są zestawy danych ASTER GDEM (30 m) i oryginalne zestawy SRTM (90 m), ale, jak zauważyłeś, dużo danych. (Rozmiar danych ASTER można zmniejszyć po pobraniu, usuwając dołączone pliki PDF, które często są większe niż rzeczywiste dane wysokościowe - zestaw danych Afryki został zmniejszony o 40%, gdy to zrobiłem!).

W R możesz wyodrębnić profil elewacji z dowolnego z tych zestawów danych dość szybko - chociaż ładowanie rastra może zająć większość czasu. Do przetwarzania danych GPX wykorzystuje małą niestandardową funkcję readGPX i 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)

„ślad” jest teraz tabelą punktów GPS z lat / lon, innymi standardowymi danymi GPX (prędkość, wysokość GPS itp.) oraz kolumną „profil”, która wskazuje wysokość w tym punkcie.

Dane SRTM można łatwo pobrać dla danego obszaru, korzystałem z tej strony w przeszłości. Pliki nie są ogromne i można je uzyskać jako georeferencyjne pliki TIFF. Pobieranie całego świata może chwilę potrwać, ale kilka kafelków obejmuje dość duży obszar. Problem może dotyczyć rozdzielczości poziomej, która dla większości świata wynosi około 90 metrów, a błąd pionowy może być dość duży, z pikami i obszarami brakujących danych.

Zestaw danych ASTER GDEM to nowsza ankieta o wyższej rozdzielczości przy ~ 30 m rozdzielczości poziomej, ale jakość jest często niższa niż odpowiadające dane SRTM.

Nie wiem, w jakiej rozdzielczości znajdują się dane elewacji Google, ale nie zdziwiłbym się, gdyby było oparte na SRTM, więc użycie Google API może dać podobne wyniki jak w przypadku procesu lokalnego.

Zgodnie z odpowiedzią @underdark, jeśli ma to być prosty system internetowy, GRASS GIS jest prawdopodobnie dobrym rozwiązaniem. Użyłem r.profile do robienia prostych wykresów niewidzialności z pewnym sukcesem, ale nie jestem pewien, jakiej metody interpolacji używa; może to być najbliższy sąsiad. Edycja : Patrząc na kod źródłowy , r.profileużywa najbliższego sąsiada, więc możesz dostać artefakty wchodzące po schodach.

Inną opcją może być napisanie skryptu w języku Python przy użyciu GDAL i NumPy , co może być nieco więcej pracy, ale byłoby dobrym rozwiązaniem niestandardowym.

Najpierw należy określić, z jakiego rodzaju precyzji poziomej / pionowej będziesz zadowolony.

Ale spójrzmy na to z praktycznego punktu widzenia:

• Każda płytka SRTM3 ma 1200 x 1200 komórek , każda komórka jest dwubajtową liczbą całkowitą reprezentującą wysokość w metrach. To około 2,75 MB surowych nieskompresowanych danych.
• Istnieje 14042 płytki SRTM3. To jest cca. 38 GB surowych danych.
• Czy naprawdę potrzebujesz objąć cały świat? Wyobrażam sobie, że wyświetlanie profilu wysokości śladu GPS w środkowej części Sahary, pustyni Gobi lub Syberii nie jest zbyt interesujące, więc nie jest to ekonomicznie opłacalne, jeśli masz go w kasie (BTW: SRTM3 nie obejmuje cały świat , więc nie musisz się martwić o takie miejsca jak Grenlandia i Antarktyda;)).
• Dzięki pewnej sprytnej kompresji i kodowaniu danych można znacznie zmniejszyć rozmiar zestawu danych. Wartości wysokości wynoszą od 0 do 8848, więc dwa pozostałe bity nie są używane. Można również zakodować rzędne za pomocą kompresji delta, aby jeszcze bardziej ją zmniejszyć. Możesz także zrezygnować z części precyzji pionowej (powiedzmy 2 m, co następnie oszczędza ci jeden dodatkowy bit dla każdej komórki.
• W zależności od tego, jakie rodzaje śladów GPS będą używane (spacery, jazda na rowerze, jazda ...), powinieneś przechowywać dane w mniejszych kafelkach (powiedzmy 0,25 x 0,25 stopnia) jako pliki na dysku lub wierszach w tabeli bazy danych.
• Używaj sprytnej pamięci podręcznej pamięci dla kafelków, aby nie trzeba przeładowywać często używanych.
• Obliczanie wysokości z komórek jest łatwą częścią całego biznesu.