Zastanawiam się nad pisaniem oprogramowania do obsługi śladów GPS i punktów trasy (głównie przechowywania, wyświetlania i obliczania wskaźników, takich jak prędkość, ocena i kilka prostych statystyk).
Zastanawiam się, jaki powinien być najbardziej niezawodny pod względem koncepcyjnym model danych dotyczących punktów śledzenia, a oto kilka „kandydatów”:
Traktując ślady jako sekwencje punktów śladu:
1.1 Ścieżki są uważane za „2D”, ponieważ rzuty mapy są 2D. Punkty trasy mogą mieć wysokość, ale nie mieć znacznika czasu. Wysokość i sygnatura czasowa to „dodatki”, „opcjonalne”. W zastosowaniach naziemnych wysokość jest bezpośrednią funkcją lat / lon (możliwa do uzyskania przez DEM);
1.2 Ścieżki są uważane za „3D”, ponieważ przestrzeń geograficzna jest w rzeczywistości 3D, a trajektoria odbiornika to 3D (projekcja 2D jest zatem formą redukcji danych). Znacznik czasu może być lub nie być obecny (ścieżka mogła zostać narysowana ręcznie).
1.3 Utwory są uważane za „4D” (3 przestrzenne + czas). Dlatego ręcznie rysowana mapa jest szczególnym przypadkiem, w którym wysokość i znacznik czasu są
nulllub nie są obecne, ale właściwości Trackpoint są zawsze „tam”.Ścieżki są uważane za słowniki strumieni, w których wszystkie strumienie mają równą długość. Istnieje lista szerokości geograficznych, lista długości geograficznych, lista wysokości, jedna ze znaczników czasu itp. Ułatwia to obliczanie statystyk każdej właściwości, a koncepcja Trackpoint staje się w pewnym sensie „wirtualna”, ponieważ jest to przekrój wielu strumieni.
Jeśli dobrze zrozumiałem, format GPX przyjmuje 1.1., KML przyjmuje 1.2. (bez obsługi znacznika czasu), a Strava API przyjmuje 2. (w formacie JSON), ale ostatecznie są to tylko formaty PLIKÓW do serializacji i przechowywania, niekoniecznie do modelowania, reprezentacji obliczeniowej i dzielenia liczb.
Czy jest jakaś forma preferowana w sensie obiektowym i dlaczego? (Uważam, że silne pisanie na klawiaturze i rozsądne modelowanie przynajmniej pozwoliłoby uniknąć operacji, które nie mają sensu).
EDYCJA: niektóre „intrygujące” dodatkowe pytania:
- Czy ręcznie narysowany ślad KONCEPTUALNIE jest tym samym, co zapisany na urządzeniu ślad? Czy powinny one należeć do różnych typów danych?
- Czy należy uznać za „poprawne”, że KML przechowuje zerowe rzędne jako zero? Zero JEST wysokością, a jeśli nie znasz wysokości, nie powinieneś przypisywać do niej zera numerycznego, prawda?
- Czy w przypadku toru z elewacją nie powinno mieć znaczenia, czy wysokość jest pobierana z danych DEM („offline”), czy z danych GPS lub danych barometrycznych („w terenie”)? Czy należy to oznaczyć w obiekcie Track? Zapisano w różnych właściwościach Trackpoint? Zignorowany? Czy powinny to być różne typy danych kolekcji?
- Jeśli edytuję ścieżkę zarejestrowaną przez urządzenie w edytorze map (dodawanie, przenoszenie i usuwanie punktów) lub łączę ścieżki z różnych dat, jak należy obsługiwać znaczniki czasu w punktach na ścieżce? Czy należy je „zresetować” do wartości zerowej? Czy należy utworzyć obiekt (zbiór trackpointów) innego typu niż poprzednie?
źródło
<>i,{}aby pomóc Ci uporządkować swoje dane - i metadane - robisz to źle.Odpowiedzi:
Nie sądzę, aby na to pytanie można było ostatecznie odpowiedzieć, ponieważ istnieje wiele sposobów podejścia do tego problemu.
Jednak te myśli mogą być istotne:
Przechowywanie danych jest stosunkowo nieistotne. Niezależnie od używanego mechanizmu, bazy danych, JSON, KML itp., Nadal jest to „płaskie przechowywanie”.
Ważne jest oprogramowanie, którego używasz, oraz sposób reprezentowania danych w oprogramowaniu, abyś mógł przeprowadzić modelowanie.
Prędkość jest dostępna na dwa sposoby, odległość x czas lub jako dane wyjściowe z urządzenia GPS, z którego pobierasz dane. Dlatego czas staje się nieistotny inaczej niż jako element informacyjny.
Dodatkowo możesz również wziąć pod uwagę czas, używając przesunięcia od początku ścieżki. Jeśli masz prędkość i dystans, możesz obliczyć czasy w punktach. (odległość między dwoma punktami można określić na wiele różnych sposobów )
Wzniesienie należy uznać za część modelu przestrzennego, mają one znaczenie dla ustalenia całej masy interesujących informacji o samym torze, na przykład można obliczyć nachylenie, które następnie pozwala zrozumieć zmiany prędkości wzdłuż toru. Jeśli nie ma nachylenia, jakiekolwiek spowolnienie lub zwiększenie prędkości mogło być spowodowane usunięciem stopy z pedału przyspieszenia.
Jeśli chodzi o łączenie ścieżek i ręcznie rysowanych ścieżek, czas nie ma większego znaczenia. Możesz zastosować dowolne prędkości, aby określić czas, na przykład, jak długo przemierzać ścieżkę przy danej prędkości. Jeśli łączysz ścieżki w odstępie kilku dni, twoje dane po prostu nie będą miały sensu, więc będziesz musiał zresetować pola czasu, prawdopodobnie używając przesunięć od początku ścieżki.
Jeśli wysokość nie jest znana, nie jest znana, dlatego nie powinna wynosić zero. Nie powinno być również ujemne, ponieważ rzędne ujemne są również ważnymi rzędnymi. (W dolinie poniżej poziomu morza, kopalni itp.)
Tak, DEMS są dostępne, Tak, możesz je z nich wyciągnąć. Czy będzie wystarczająco dokładne? Mało prawdopodobne, chyba że dokładność nie stanowi problemu. GPS lub barometryczny Pod warunkiem, że wysokość będzie najlepsza, jaką możesz uzyskać.
Więc spróbuj odpowiedzieć na to pytanie:
Przechowuj dane w dowolnym płaskim formacie, który ci się podoba, ale polecam PostGRES z PostGIS to dobra opcja, ładnie radzi sobie z 3D. Następnie możesz użyć rozległych funkcji przestrzennych w PostGIS do manipulowania / modelowania danych.
Jeśli używasz jakiejś formy niestandardowego programu, który opracowujesz, użyj podejścia obiektowego, a nie tablic. Jeśli korzystasz z tablic, równie dobrze możesz użyć bazy danych.
źródło
Jak już wspomniano w innej odpowiedzi, istnieje wiele różnych podejść. Ponieważ poprosiłem o „solidne koncepcyjnie modele danych”, po wielu badaniach znalazłem dwa wielkie zasoby wiedzy, które zapewniają dwa zupełnie różne podejścia do koncepcji „obiektów ruchomych” i mają wiele nakładających się (w dobrym tego słowa znaczeniu):
źródło