Depolama, görselleştirme ve analiz için GPS izlerini en iyi nasıl modelleyebilirim?

GPS Tracks ve Waypoints (çoğunlukla hız, derece ve bazı basit istatistikler gibi metrikleri depolama, görüntüleme ve hesaplama) ile başa çıkmak için yazılım yazmayı düşünüyorum.

İz noktaları ile ilgili en kavramsal olarak en sağlam veri modeli olması gerektiğini merak ediyorum ve işte bazı "adaylar":

Parkurları, Parkur Noktaları dizisi olarak değerlendirmek:

1.1. Harita projeksiyonları 2D olduğu için parkurlar "2D" olarak kabul edilir. İz noktalarında yükseklik olabilir veya olmayabilir, zaman damgası olabilir veya olmayabilir. Yükseklik ve zaman damgası "ekstralar", "isteğe bağlı" olarak kabul edilir. Karasal uygulamalar için, yükseklik lat / lon'un doğrudan bir fonksiyonudur (DEM yoluyla elde edilebilir);

1.2. Coğrafi alan, gerçekten de 3D olduğu ve alıcının yörüngesi 3D olduğu için izler "3D" olarak kabul edilir (2D projeksiyon bu nedenle bir veri azaltma şeklidir). Zaman damgası mevcut olabilir veya olmayabilir (parça elle çizilmiş olabilir).

1.3. İzler "4D" (3 uzamsal + zaman) olarak kabul edilir. Böylece, elle çizilmiş bir harita, yükseklik ve zaman damgasının olduğu özel bir durumdur.null mevcut veya başka türlü mevcut olmadığı , ancak İz Noktası özellikleri her zaman "oradadır".
Parçalar, tüm akışların eşit uzunluklara sahip olduğu akışların sözlükleri olarak kabul edilir. Enlemlerin bir listesi, boylamlar listesi, yükseklik listesi, zaman damgalarından biri, vb. Vardır. Bu, her bir mülkün istatistiklerini hesaplamayı kolaylaştırır ve Trackpoint kavramı, bir anlamda "sanal" hale gelir. birçok dere kesiti.

Doğru anladıysam GPX formatı 1.1'i, KML 1.2'yi benimser. (zaman damgası için destek olmadan) ve Strava API 2'yi (JSON biçiminde) benimser, ancak sonunda bunlar sadece modelleme, hesaplama temsili ve sayı kırma için değil, serileştirme ve depolama için sadece FILE formatlarıdır.

Nesneye yönelik anlamda tercih edilen herhangi bir form var mı ve neden? (Güçlü yazım ve mantıklı modellemenin en azından mantıklı olmayan işlemlerden kaçınacağına inanıyorum).

EDIT: bazı "ilgi çekici" ek sorular:

Elle çizilmiş bir parça KESİNLİKLE cihazda kaydedilmiş bir tracklog ile aynı şey midir? Farklı veri türlerinde olmalılar mı?
KML'nin sıfır yükseklikleri sıfır olarak depolaması "doğru" olarak mı düşünülmelidir? Sıfır bir yükselti IS ve yükselişi bilmiyorsanız, ona sıfır sıfır atamamalısınız, değil mi?
Yüksekliğin olduğu bir yolda, yükseklik DEM verilerinden ("çevrimdışı") veya GPS verilerinden veya barometrik verilerden ("alanda") çıkarılırsa önemli mi? Bu Track nesnesinde işaretlenmeli mi? Farklı İzleme Noktası özelliklerine kaydedildi mi? Yok Sayılan? Farklı toplama veri türleri olmalı mı?
Cihazda kaydedilmiş bir izi bir harita düzenleyicide düzenlerim (nokta ekler, taşır ve kaldırır) veya farklı tarihlerde izler birleştirirsem, iz noktalarındaki zaman damgaları nasıl ele alınmalıdır? "Sıfırlanmalı" mı? Öncekilerden farklı türde bir nesne (iz noktası toplama) oluşturulmalı mıdır?

— heltonbiker
kaynak

3. Parçalar x, y, z, m [] ve zaman özelliklerine sahip noktaların bir toplamıdır. Yakalanan her nokta için bu 5 değeri içeren bir CSV dosyası, sağlam bir veri modeli için fazlasıyla yeterlidir. Verilerinizi ve meta verilerinizi düzenlemenize yardımcı olmak için <>ve gibi süslü şeylere ihtiyacınız {}varsa, bunu yanlış yapıyorsunuz.

— nagytech

Sadece iyi bir eski CSV'ye katılıyorum, GPS'in kaydettiği her şeyi temsil ediyor. Ancak, GPX biçimi GPS cihazları için oldukça yaygındır. Hem GPS hem de KML XML veri formatları olduğundan bu bağlantı bir değere sahip olabilir. stackoverflow.com/questions/1820129/…

— Pete

XML 'harika' ve tümü (@ Pete'in bağlantılı gönderisindeki nedenlerden dolayı) bu noktaların hiçbiri alakalı değildir. Herhangi bir şey varsa, yükü sayı çatırtısını yavaşlatmaktan başka bir şey yapmaz ve veri depolama ve iletim yöntemlerinizi şişirir. Eğer bir mom-n-pop operasyonuysanız, bu sorunlarla karşılaşmak için asla yeterli veriye sahip olmayacaksınız ve sayı sıkışıklığınız yoğun olmayacak. Her iki durumda da, metali kapatarak çalışmayı sürdürecek kaynaklara sahip olmayacaksınız - bu yüzden XML uzakta.

— nagytech

Bu sorunun gerçek uygulamadan MODELING ve verilerin tasarımı (kavramsal özünün temsili) ile ilgisi olduğunu unutmayın. Şimdiye kadar yapılan yorumlar, dosya formatlarına odaklanıyor, bu da düşündüğümden daha uzakta, çünkü dosya formatları, verilerin kendisinin doğasından ziyade uygulama ortamına bağlı.

— heltonbiker

OO terimleriyle, noktaları tutabilecek bir Line sınıfı kullandım (lat, lng, ele, zaman, hız, yön, vb.). Ve oradan Elle çizilmiş veya amaçlanan "parkurları" temsil eden güzergahlar ve zaman / hız verileri ile gerçek bir parkuru temsil eden Parkurlar. Kavramsal olarak farklı olduklarını düşünüyorum (elle çizilmiş ve / veya bir haritacı tarafından veya böyle bir parça gerçek bir parça tarafından sağlanan). Terimler sadece anlambilimseldir, ancak gerçek türleri kullanmak yararlı olmuştur (hepsini bir "Parça" olarak birleştirmek yerine). Ayrıca, serileştirme formatları söz konusu olduğunda, GeoJSON: en.wikipedia.org/wiki/GeoJSON'u düşünürüm .

— Charlie Collins

Yanıtlar:

Bu soruya yaklaşmanın pek çok yolu olduğu için aslında kesin olarak cevaplanabileceğini sanmıyorum.

Ancak, bu düşünceler ilgili olabilir:

Veri depolama nispeten önemsizdir. Kullandığınız mekanizma ne olursa olsun, Veritabanı, JSON, KML, vb, hala "düz depolama" dır.

Önemli olan, modellemenizi yapabilmeniz için kullandığınız yazılım ve Yazılımdaki verileri nasıl temsil ettiğinizdir.

Hız iki yolla kullanılabilir: mesafe x süre veya verilerinizi nereden kaynakladığınız bir GPS cihazından çıkış olarak. Bu nedenle zaman, bilgilendirici bir öğe olarak önemsiz hale gelir.

Ayrıca, parçanın başlangıcından itibaren bir uzaklık kullanarak da zamanı düşünebilirsiniz. Hız ve mesafeye sahipseniz, noktaları noktalarda hesaplayabilirsiniz. (iki nokta arasındaki mesafe birkaç farklı yöntemle belirlenebilir )

Yükseklik, Mekansal Modelin bir parçası olarak düşünülmelidir, bunlar parçanın kendisi hakkında ilginç bir dizi bilginin belirlenmesi ile ilgilidir, örneğin, bir parçadaki hız değişimlerini anlamanıza izin veren derece hesaplanabilir. Derece yoksa, ayağın gaz pedalından çıkarılmasından kaynaklanan herhangi bir yavaşlama veya hız artışı olabilir.

Parkurlar ve elle çizilmiş parkurların birleştirilmesi açısından, zamanın önemi azdır. Süreyi, örneğin bir parkurun belirli bir hızda ne kadar süre geçeceğini belirlemek için rastgele hızlar uygulayabilirsiniz. Parkurları birkaç gün aralıklarla birleştiriyorsanız, verileriniz mantıklı olmayacaktır, bu nedenle zaman alanlarını sıfırlamanız gerekecek, muhtemelen parçanın başlangıcındaki ofsetleri kullanmanız gerekecektir.

Yükseklik bilinmiyorsa, bilinmemektedir, bu nedenle sıfır olmamalıdır. Negatif yükselmeler de geçerli yükselmeler olduğu için negatif olmamalıdır. (Deniz seviyesinin altındaki bir vadide, maden ocağı vb.)

Evet, DEMS mevcuttur, evet onlardan ayıklayabilirsiniz. Yeterince doğru olacak mı? Doğruluk bir sorun olmadığı sürece, olası değildir. GPS veya barometrik olarak Yükseklikler alabileceğiniz en iyi olacaktır.

Size yaklaşan bir cevap vermeyi denemek için:

, Sizin gibi herhangi bir düz biçimde depolayın ama öneriyoruz Postgres'e ile PostGIS o güzel 3D kolları, iyi bir seçenektir. Daha sonra verilerinizi değiştirmek / modellemek için PostGIS'teki kapsamlı uzamsal işlevleri kullanabilirsiniz.

Geliştirdiğiniz bir tür özel program kullanıyorsanız, diziler yerine Nesne Tabanlı bir yaklaşım kullanın. Diziler kullanıyorsanız, bir veritabanı da kullanabilirsiniz.

— Mark Cupitt
kaynak

İlginiz ve zamanınız için çok teşekkür ederim, cevabınızı çok ilginç buldum. Ama bir şeyle "kabul edemem": hız kanonik değişkendir, zaman olmaz. Bu birçok nedenden ötürü, ama esas olarak hız, zaman içindeki mesafenin türevidir. Segment süresi boyunca segment mesafesini türetirseniz, her zaman özel olarak iyi hız ve iyi ortalama hız elde edersiniz (ki bu anlık hızdan daha yararlı buldum). Öte yandan, hızları entegre ederseniz, entegrasyon hatası az sayıda numuneden sonra çok yanlış sonuçlar verecektir.

— heltonbiker

Evet, bu noktayı kabul edebilirim. ancak, GPS Parkurlarının kullanımı kendi içinde konum hatalarına bağlıdır. Her şey hangi doğruluğa sahip olabileceğinizle ilgilidir. Anlaşıldı, Zaman oldukça doğru, ancak GPS konumlandırma hataları nedeniyle bunu kullanarak hatalar alacaksınız. İz noktalarındaki bir saniyelik aralıklar sadece bir saniyedir, ancak GPS içinde algoritmaları tahmin edilen bir konuma gelmek için yine de enterpolasyon yapıyor olabilir. Açıkçası, verilerin ayrıntı

— düzeyinin

Çok iyi koymak ... Bu yüzden zaten zaten "anlık hız" çizmek vazgeçtim, bir tür "anlık ortalama hız" için gidiyor, şöyle olur: "bir yörüngede verilen her nokta için, anlık ortalama hızı ortalama son N dakikanın hızı. " Çok güzel bir şekilde çizer ve bir yolculuk boyunca uygun hız değişimleri hissi verir. Ancak uygun hesaplama zor olabilir ve büyük olasılıkla biraz hesaplama yoğunluğuna sahiptir.

— heltonbiker

Başka bir cevapta daha önce de belirtildiği gibi, birçok farklı yaklaşım var. "Kavramsal olarak sağlam veri modelleri" istediğimden beri, bir çok araştırmadan sonra "hareketli nesneler" kavramına iki farklı yaklaşım sağlayan iki büyük bilgi gövdesi buldum ve çok fazla örtüşme var (iyi anlamda):

Springer Verlag tarafından yayınlanan Gennady ve Natalia Andrienko'nun kitapları, örneğin Hareketin mükemmel Görsel Analitiği (aynı yayıncının diğerleri arasında). Şiddetle tavsiye edilir.
Özet Özellikler ISO / OGC (ISO 191xx normlar), özel olarak ISO 19107 (Mekansal Şeması), 19108 (Temporal Şeması), 19111 (Koordinatlar tarafından Mekansal başvuruda), 19141 (Moving Özellikleri) ve 19148 (Lineer Alınan Referans) ait (kavramsal şemalar)

— heltonbiker
kaynak