Làm thế nào để mô hình GPS theo dõi tốt nhất để lưu trữ, trực quan hóa và phân tích?


17

Tôi đang suy nghĩ về việc viết phần mềm để đối phó với các Tuyến đường và Điểm tham chiếu GPS (chủ yếu là lưu trữ, hiển thị và tính toán các số liệu như tốc độ, điểm số và một số thống kê đơn giản).

Tôi tự hỏi điều gì sẽ là mô hình dữ liệu mạnh mẽ nhất về mặt khái niệm liên quan đến các điểm theo dõi và đây là một số "ứng cử viên":

  1. Xem Bản nhạc là chuỗi các Điểm theo dõi:

    1.1. Các bản nhạc được coi là "2D", vì các phép chiếu bản đồ là 2D. Điểm theo dõi có thể có hoặc không có độ cao, có thể có hoặc không có dấu thời gian. Độ cao và dấu thời gian được xem là "tính năng bổ sung", "tùy chọn". Đối với các ứng dụng trên mặt đất, độ cao là chức năng trực tiếp của lat / lon (có thể đạt được thông qua DEM);

    1.2. Các bản nhạc được coi là "3D" vì không gian địa lý thực sự là 3D và quỹ đạo của máy thu là 3D (do đó, hình chiếu 2D là một dạng giảm dữ liệu). Dấu thời gian có thể có hoặc không có mặt (bản nhạc có thể được vẽ bằng tay).

    1.3. Các bản nhạc được coi là "4D" (3 không gian + thời gian). Do đó, bản đồ vẽ tay là một trường hợp đặc biệt trong đó độ cao và dấu thời gian có nullhoặc không có mặt, nhưng các thuộc tính Trackpoint luôn "ở đó".

  2. Các bản nhạc được coi là từ điển của các luồng, trong đó tất cả các luồng có độ dài bằng nhau. Có một danh sách các vĩ độ, một danh sách các kinh độ, một danh sách các độ cao, một dấu thời gian, v.v ... Điều này giúp dễ dàng tính toán số liệu thống kê của từng thuộc tính và khái niệm Trackpoint trở nên "ảo" theo nghĩa, vì nó là một mặt cắt ngang của nhiều dòng.

Nếu tôi hiểu đúng, định dạng GPX thông qua 1.1., KML chấp nhận 1.2. (không hỗ trợ dấu thời gian) và API Strava chấp nhận 2. (ở định dạng JSON), nhưng cuối cùng, đây chỉ là các định dạng FILE để tuần tự hóa và lưu trữ, không nhất thiết phải lập mô hình, biểu diễn tính toán và bấm số.

Có bất kỳ hình thức nào là thích hợp hơn, theo nghĩa hướng đối tượng, và tại sao? (Tôi tin rằng việc gõ mạnh và mô hình hợp lý ít nhất sẽ tránh được các thao tác không có ý nghĩa).

EDIT: một số câu hỏi bổ sung "hấp dẫn":

  • Một bản nhạc được vẽ bằng tay có phải là điều tương tự như một tracklog được ghi lại trên thiết bị không? Họ nên có các loại dữ liệu khác nhau?
  • Có nên coi "chính xác" rằng KML lưu trữ độ cao null là 0 không? Không là độ cao và nếu bạn không biết độ cao bạn không nên gán số 0 cho nó, phải không?
  • Có vấn đề gì không, trong một tuyến đường có độ cao, nếu độ cao được trích xuất từ ​​dữ liệu DEM ("ngoại tuyến") hoặc từ dữ liệu GPS hoặc dữ liệu khí áp ("trong trường")? Điều này có nên được gắn cờ trong đối tượng Theo dõi? Lưu vào các thuộc tính Trackpoint khác nhau? Mặc kệ? Chúng có nên là kiểu dữ liệu bộ sưu tập khác nhau không?
  • Nếu tôi chỉnh sửa bản nhạc được ghi bằng thiết bị trong trình chỉnh sửa bản đồ (thêm, di chuyển và xóa điểm) hoặc kết hợp các bản nhạc từ các ngày khác nhau, các dấu thời gian trong các điểm theo dõi phải được xử lý như thế nào? Họ có nên được "tái định cư" thành null? Có nên tạo một đối tượng (bộ sưu tập trackpoint) của một loại khác từ những cái trước không?

3
3. Bài hát là tập hợp các điểm có thuộc tính x, y, z, m [] và thời gian. Một tệp CSV chứa 5 giá trị này cho mỗi điểm được ghi là quá đủ cho một mô hình dữ liệu mạnh mẽ. Nếu bạn cần những thứ ưa thích như <>{}để giúp bạn sắp xếp dữ liệu của mình - và dữ liệu meta - bạn đã làm sai.
nagytech

1
Tôi đồng ý với chỉ một CSV cũ tốt, nó đại diện cho mọi thứ mà GPS đang ghi. Nhưng, định dạng GPX khá phổ biến đối với các thiết bị GPS. Liên kết này có thể có giá trị gì đó vì cả GPS và KML đều là định dạng dữ liệu XML. stackoverflow.com/questions/1820129/ trộm
Pete

Mặc dù XML là 'tuyệt vời' và tất cả (vì lý do trong bài đăng được liên kết của @ Pete), không có điểm nào trong số đó có liên quan. Nếu bất cứ điều gì, chi phí không làm gì ngoài việc làm chậm số lượng khủng hoảng, và làm mờ các phương thức lưu trữ và truyền dữ liệu của bạn. Cấp, nếu bạn là một hoạt động mẹ-pop, bạn sẽ không bao giờ có đủ dữ liệu để gặp phải những vấn đề này và việc bẻ khóa số của bạn sẽ không dữ dội. Dù bằng cách nào, bạn sẽ không có tài nguyên để duy trì hoạt động đóng kim loại này - vì vậy hãy loại bỏ XML.
nagytech

1
Lưu ý rằng câu hỏi này có liên quan nhiều đến MODELING và thiết kế dữ liệu (đại diện cho bản chất khái niệm của nó) so với thực hiện thực tế. Các ý kiến ​​cho đến nay tập trung vào các định dạng tệp, từ những gì tôi nghĩ, xa hơn, bởi vì các định dạng tệp phụ thuộc nhiều vào phương tiện thực hiện hơn là bản chất của dữ liệu.
heltonbiker

1
Theo thuật ngữ OO, tôi đã sử dụng một lớp Line có thể giữ các điểm (lat, lng, ele, thời gian, tốc độ, mang, v.v.). Và, từ đó Các tuyến đường biểu thị các "bản nhạc" được vẽ bằng tay hoặc dự định và các Bản nhạc thể hiện một bản nhạc thực tế với dữ liệu thời gian / tốc độ. Về mặt khái niệm, tôi nghĩ rằng chúng khác nhau (được vẽ bằng tay và được cung cấp bởi người vẽ bản đồ, hoặc như vậy, so với một bản nhạc thực tế). Các thuật ngữ chỉ là ngữ nghĩa, chắc chắn, nhưng sử dụng các loại thực sự rất hữu ích (thay vì chỉ kết hợp tất cả lại với nhau dưới dạng "Theo dõi"). Ngoài ra, khi nói đến các định dạng tuần tự hóa, tôi sẽ xem xét GeoJSON: en.wikipedia.org/wiki/GeoJSON .
Charlie Collins

Câu trả lời:


4

Tôi không nghĩ câu hỏi này thực sự có thể được trả lời dứt khoát vì có rất nhiều, rất nhiều cách tiếp cận vấn đề này ..

Tuy nhiên, những suy nghĩ này có thể có liên quan:

Việc lưu trữ dữ liệu tương đối không quan trọng. Dù bạn sử dụng cơ chế nào, Cơ sở dữ liệu, JSON, KML, v.v., nó vẫn là "lưu trữ phẳng".

Điều quan trọng là phần mềm bạn sử dụng và cách bạn thể hiện dữ liệu trong Phần mềm để bạn có thể tiến hành mô hình hóa của mình.

Tốc độ có sẵn theo hai cách, khoảng cách x thời gian hoặc dưới dạng đầu ra từ thiết bị GPS, đó là nơi bạn đang tìm nguồn cung cấp dữ liệu của mình. Do đó thời gian trở nên không liên quan ngoài mục đích thông tin.

Ngoài ra, bạn cũng có thể xem xét thời gian bằng cách sử dụng phần bù từ đầu bản nhạc. Nếu bạn có tốc độ và khoảng cách, thì bạn có thể tính thời gian tại các điểm. (khoảng cách giữa hai điểm có thể được xác định bằng một số phương pháp khác nhau )

Độ cao phải được coi là một phần của Mô hình không gian, chúng có liên quan để xác định toàn bộ thông tin thú vị về bản nhạc, ví dụ, lớp có thể được tính toán để sau đó cho phép bạn hiểu các biến thể tốc độ dọc theo rãnh. Nếu không có điểm số, bất kỳ sự chậm lại hoặc tăng tốc độ nào có thể là do tháo chân ra khỏi máy gia tốc.

Về mặt hợp nhất các bản nhạc và bản vẽ tay, thời gian không mấy liên quan. Bạn có thể áp dụng tốc độ tùy ý để xác định thời gian, ví dụ: thời gian để đi qua một bản nhạc ở một tốc độ nhất định. Nếu bạn đang hợp nhất các bản nhạc cách nhau vài ngày, thì dữ liệu của bạn sẽ không có ý nghĩa, do đó bạn sẽ phải đặt lại các trường thời gian, có thể sử dụng offset tạo thành bản nhạc bắt đầu.

Nếu độ cao không được biết, nó không được biết, do đó nó không nên bằng không. Nó cũng không nên âm, vì độ cao âm cũng là độ cao hợp lệ. (Trong một thung lũng dưới mực nước biển, hố mỏ, v.v.)

Có, DEMS có sẵn, Có bạn có thể trích xuất từ ​​họ. Liệu có đủ chính xác? Không thể, trừ khi độ chính xác không phải là một vấn đề. GPS hoặc barometric cung cấp Độ cao sẽ là tốt nhất bạn có thể nhận được.

Vì vậy, để thử và cung cấp cho bạn một câu trả lời gần:

Lưu trữ dữ liệu ở bất kỳ định dạng phẳng nào bạn muốn, nhưng tôi muốn giới thiệu, PostGRES với PostGIS là một tùy chọn tốt, nó xử lý 3D độc đáo. Sau đó, bạn có thể sử dụng các hàm không gian mở rộng trong PostGIS để thao tác / mô hình hóa dữ liệu của mình.

Nếu bạn sử dụng một số dạng chương trình tùy chỉnh mà bạn phát triển, hãy sử dụng cách tiếp cận Hướng đối tượng thay vì mảng. Nếu bạn sử dụng mảng, bạn cũng có thể sử dụng cơ sở dữ liệu.


1
Cảm ơn bạn rất nhiều vì thời gian và sự quan tâm của bạn, tôi thấy câu trả lời của bạn rất thú vị. Nhưng với một điều tôi "không thể" đồng ý: tốc độ đó là biến số chính tắc, trong khi thời gian thì không. Điều này vì nhiều lý do, nhưng chủ yếu là vì tốc độ là đạo hàm của khoảng cách theo thời gian. Bạn sẽ luôn có được tốc độ tốt và đặc biệt là tốc độ trung bình tốt (mà tôi thấy là hữu ích hơn tốc độ tức thời), nếu bạn tạo ra khoảng cách phân khúc theo thời gian phân khúc. Mặt khác, nếu bạn tích hợp tốc độ, lỗi tích hợp sẽ cho kết quả rất sai sau một số mẫu ngắn.
heltonbiker

2
Vâng, tôi có thể thừa nhận điểm đó. tuy nhiên, bản thân việc sử dụng Bản nhạc GPS có thể bị lỗi vị trí. Tất cả là vấn đề về độ chính xác mà bạn có thể nhận được. Đồng ý, Thời gian khá chính xác, nhưng bạn cũng sẽ gặp lỗi khi sử dụng lỗi đó do lỗi vị trí GPS. Một khoảng thời gian một giây trên các điểm theo dõi chỉ là, một giây, nhưng bên trong GPS, thuật toán của nó có thể được nội suy bằng mọi cách để đến một vị trí ước tính. Rõ ràng độ chi tiết của dữ liệu sẽ có tác động lớn đến bất kỳ phương pháp phân tích nào được chọn
Mark Cupitt

Rất tốt ... Đó là lý do tại sao tôi đã từ bỏ âm mưu "tốc độ tức thời" hoàn toàn, với một loại "tốc độ trung bình tức thời" nào đó, đó sẽ là: "với mỗi điểm nhất định trong một quỹ đạo, tốc độ trung bình tức thời của nó là trung bình tốc độ của N phút cuối cùng. " Nó vẽ rất đẹp, và mang lại cảm giác thích hợp về sự thay đổi tốc độ trong một chuyến đi. Nhưng tính toán thích hợp có thể là khó khăn và có lẽ là một chút tính toán chuyên sâu.
heltonbiker

0

Như đã đề cập trong một câu trả lời khác, có nhiều cách tiếp cận khác nhau. Vì tôi đã hỏi về "các mô hình dữ liệu mạnh mẽ về mặt khái niệm", sau rất nhiều nghiên cứu, tôi đã tìm thấy hai cơ thể tri thức tuyệt vời cung cấp hai cách tiếp cận khá khác nhau cho khái niệm "đối tượng chuyển động" và có nhiều sự trùng lặp (theo nghĩa tốt):

  1. Các cuốn sách từ Gennady và Natalia Andrienko, được xuất bản bởi Springer Verlag, ví dụ như Phân tích hình ảnh tuyệt vời của phong trào (trong số những người khác từ cùng một nhà xuất bản). Rất khuyến khích.
  2. Các thông số kỹ thuật trừu tượng (lược đồ khái niệm) của ISO / OGC (định mức ISO 191xx), đặc biệt ISO 19107 (Lược đồ không gian), 19108 (Lược đồ tạm thời), 1911 (Tham chiếu không gian theo tọa độ), 19141 (Tính năng di chuyển) và 19148 (Tham chiếu tuyến tính)
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.