Ogromne dane lasera w chmurze punktów w PostGIS - przechowywanie i przetwarzanie

Zastanawiam się, jak można przechowywać ogromne zbiory danych chmury punktów skanowanych laserowo w PostGIS, mając na uwadze aspekt czasowy ich przetwarzania. Wiem, Pointw PostGIS istnieje obiekt geometrii . Ale o ile wiem, zapisuje każdy punkt w nowym tupelu, co może sprawić, że wyszukiwanie dowolnego punktu będzie bardzo powolnym procesem, jeśli zgromadzonych zostanie kilka milionów lub więcej z nich.

Znalazłem artykuł HSR Universtiy of Applied Sciences Rapperswill, omawiający ten temat. Sugeruje to trzy sposoby przechowywania takich danych: Whole data in one tupel, Each point in one tupellub Splitting Data into Blocksktóre odwołują info-stoły, trzymając wystaje z każdego bloku. Ponieważ trzeci sposób wydaje się najbardziej przydatny do lokalizowania przechowywanych punktów, zastanawiam się, czy ktoś już zrobił z nim jakieś doświadczenia?

Artykuł można znaleźć tutaj: http://wiki.hsr.ch/Datenbanken/files/pgsql_point_cloud.pdf

Wreszcie natknąłem się na projekt na github, który wydaje się zajmować sposobami chmury punktów w PostgeSQL. Niestety niewiele informacji na ten temat w sieci. Więc to samo pytanie tutaj: czy ktoś już ma z tym jakieś doświadczenia? Czy nadaje się do takich celów?

Projekt można znaleźć tutaj: https://github.com/pramsey/pointcloud

Z przyjemnością usłyszę o innych sugestiach, pomysłach lub doświadczeniach, jeśli takie istnieją. Ale muszę przyznać, że preferowane są rozwiązania niekomercyjne.

postgis postgresql lidar

— knutella
źródło

Czy możesz podać ogólne pojęcie o tym, co rozumiesz przez „ogromne” i jakiego rodzaju informacji z chmury punktów potrzebujesz? Tj. Tylko XYZ i intensywność, które mogą być np. Przechowywane w zablokowanym MultipointZM lub innych danych atrybutów, które prawdopodobnie wymagają, aby Point uzyskał unikalne wartości dla każdego oddzielnego pomiaru punktu?

— Torsti,

przechowuję lidar w wielopunktowych 10x10 metrach według klasyfikacji. Używamy tylko podstawowych wartości Z

— simplexio

@AndreSilva Celem jest wygenerowanie profili powierzchni drogi z danych. Na razie przekształciliśmy punkty w siatki DEM i użyliśmy PostGIS do przechowywania ich jako bloków rastrowych, a SAGA do utworzenia z nich ostatecznie profili. Działa w celach testowych, ale oznacza również utratę dokładności poprzez rasterowanie danych przed importem bazy danych. Również eksport komórek siatki przyciętych podanymi liniami profilu przebiega bardzo powoli w PostGIS (dzięki ST_Union). Byłoby miło, gdybyś mógł polecić narzędzia do podobnych zadań.

— knutella

@til_b: No, to jest dokładnie to, co mówiłam o ... dobry znaleźć :)

— knutella

Zadałem sobie to samo pytanie i złożyłem kilka elementów, aby uzyskać działający prototyp. Jak dotąd działa świetnie , bez problemów ze skalowalnością od kilku milionów do setek milionów punktów z około 20 atrybutami każdy. Przy tak wielu punktach znalezienie punktów w obszarze zajmuje kilkaset milis . Filtrowanie według znacznika czasu zajmuje dokładnie tyle samo czasu (dla mnie dokładny czas akwizycji). Ogólnie perf są takie same lub lepsze niż w „Linii zarządzania danymi LiDAR; od populacji baz danych przestrzennych do wizualizacji aplikacji internetowych” Dane są kompresowane do DB (około 1: 2

Odpowiedzi:

W twoim pytaniu jest dużo. Krótka odpowiedź brzmi: tak, w PostGIS można całkowicie przechowywać dane z ogromnej chmury punktów i wykorzystywać je do przetwarzania. Stworzyliśmy tak pełny system, który to robi.

Ten film jest trochę nieaktualny ze względu na swoje liczby, ale mieliśmy TB danych mobilnych / naziemnych i lotniczych w postgis dostępnych za pośrednictwem pytona do przetwarzania w zapleczu oraz z interfejsem internetowym umożliwiającym przeglądanie i pobieranie danych 3D. https://vimeo.com/39053196

To naprawdę sprowadza się do tego, jak zdecydujesz się przechowywać dane w PostGIS i jak będziesz mieć do nich dostęp. Dobrym rozwiązaniem dla danych lotniczych może być połączenie danych w jakiś sposób i wykorzystanie wydajności dla wielu punktów. Jednak jeśli pracujesz z danymi mobilnymi lub naziemnymi, gdzie gęstość punktów może wynosić między 500-30000 + punktów na metr kwadratowy, to podejście nie działa. Następnie sprowadza się do spojrzenia na sprzęt i oczekiwaną liczbę równoczesnych użytkowników. Szczegóły na ten temat można znaleźć w niektórych naszych artykułach http://www.mendeley.com/profiles/conor-mc-elhinney/

— Conor
źródło

Cześć, dzięki za tak wiele szczegółowych informacji. Ides / testy oferowane w twoich artykułach wydają się bardzo przydatne! Zajmie mi to trochę czasu, aby to wszystko przejrzeć, ale jak zobaczyłem przy pierwszym czytaniu, już zapewniają całe obejścia. Wielkie dzięki za dodanie! Również wideo i przeglądarka komputerowa w przeglądarce są dość interesujące i wydają się działać bardzo dobrze i płynnie! Niestety dostałem krótkoterminowe ręce od innych rzeczy. Mam jednak nadzieję, że niedługo będę kontynuować dane na komputerze.

— knutella

Projekt Glimpse ma naprawdę fajną wersję demo: ncg.nuim.ie/glimpse/auth/login.php

— Kozuch

(Odpowiedź jest oparta na powyższych komentarzach moich i innych; naprawdę tego nie testowałem)

Przechowuj punkty jako MultiPointZM. Najlepszy rozmiar siatki prawdopodobnie będzie zależał od wzorców dostępu i trzeba na tym trochę przetestować. Zwykła siatka z indeksem przestrzennym powinna sprawić, że zapytania będą dość szybkie. Jeśli dostęp do 3D jest ważny, MultiPointZM może być oparty na blokach 3D (1) zamiast siatki płaszczyzny 2D, a następnie (jeśli masz PostGIS> = 2.0), możesz użyć &&& do szybkich zapytań 3D.

Można również przechowywać wzór siatki w osobnej tabeli, co może być przydatne np. Podczas aktualizacji danych i sprawdzania, czy bloki MultiPointZM pozostają w swoich granicach po edycji itp.

Przechowywanie znaczników czasu lub innych danych byłoby możliwe tylko dla bloku na raz, ale niektóre dane binarne / kategorie mogłyby być przechowywane przez dezagregację każdego bloku według atrybutu, jeśli nie ma zbyt wielu kategorii i / lub atrybutów.

Jeśli w końcu będziesz musiał przechowywać dane jako osobny PointZM, to klucz obcy w tabeli siatki + indeks B-drzewa sprawi, że ładowanie tylko określonych punktów (prawdopodobnie) będzie znacznie szybsze niż tylko bezpośrednie przejście do tabeli, nawet w przestrzeni indeks.

(1) Jeśli zakres wartości Z jest niewielki (w końcu to droga), prawdopodobnie nie ma to sensu.

— Torsti
źródło

Myślę, że twoje „podsumowanie” trafia całkiem dobrze jako zakończenie wcześniej omawianych propozycji. Jak powiedziałeś, „właściwy” sposób ładowania takich danych musi zostać ustalony w zależności od potrzeb i proponowanych rozwiązań. Okazało się, że nie jest to niemożliwe dzięki tak wielu pomysłom. Dało mi to wiele inspiracji do dalszej pracy nad tym zagadnieniem. Wielkie dzięki!

— knutella