Pozostałe oprogramowanie
Wstęp
Jednym z bardziej istotnych problemów kartograficznych przy tworzeniu map w skali 1:50 000 i 1: 100 000 jest dokonanie generalizacji pojedynczych budynków do bardziej ogólnych obiektów – obszarów zabudowanych. Tradycyjnie dokonywano tego ręcznie, w oparciu o określone reguły, ale też i subiektywne odczucia kartografa. Obecnie jednak, gdy coraz częściej słyszymy o wielorozdzielczych i wieloreprezentacyjnych bazach danych, pojawia się problem automatycznej i powtarzalnej generalizacji.
Szwajcarska firma Kappasys opracowała dodatkowe funkcje do bazy PostGIS, dzięki którym możliwe stało się przeprowadzenie takiej generalizacji przy pomocy oprogramowania Open Source. Dostarczone są w postaci zwykłych skryptów w języku PL/SQL, dzięki czemu nie musimy nic kompilować ani instalować w systemie operacyjnym – wystarczy wykonać je w bazie, by uzyskać dostęp do funkcji.
Instalacja
Skrypty SQL dostępne są do pobrania ze strony Kappasys: http://www.kappasys.org/cms/index.php?id=65&L=5
Należy ściągnąć obydwa skrypty – cleanGeometry oraz aggregatePolygons. Następnie wykonujemy skrypty (użytkownik musi mieć prawa superużytkownika bazy, domyślnie jest to postgres):
psql -d <baza> -U-h <serwer> -f cleanGeometry.sql
psql -d <baza> -U-h <serwer> -f aggregatePolygons.sql
Postgres powinien odpowiedzieć „CREATE FUNCTION“ oraz „CREATE AGGREGATE“. Od tego momentu zyskujemy dostęp do funkcji.
Użycie
Funkcja może być wywołana przy użyciu dowolnego interfejsu bazy danych, a więc linii komend, programu pgAdmin, wtyczki PostGIS Manager czy własnego programu.
Składnia funkcji jest następująca:
SELECT aggregatepolygons (<kolumna geometrii>,<odległość>,<kształt ortogonalny>) FROM
Pierwszy argument jest to po prostu nazwa kolumny geometrii tabeli, w której znajdują się budynki, np. the_geom. Drugi – to maksymalna odległość między budynkami, poniżej której będą traktowane jako należące do jednego obszaru zabudowanego. Trzeci argument jest typu Boolean, czyli może mieć wartość true albo false i określa, czy wynikowe poligony mają mieć kształt geometryczny z dużą ilością kątów prostych, czy też dowolny. Przy wartości true wynik będzie bardziej zbliżony do reprezentacji na mapie topograficznej, zaś przy false będzie przypominał CORINE Land Cover. Poniżej przedstawiam przykładowe wyniki generalizacji dla różnych ustawień – z opcją ortogonalną i bez, przy różnych odległościach między budynkami.
Wyniki generalizacji za pomocą funkcji aggregatePolygons.
Jeżeli budynki mają przypisany atrybut określający ich wielkość, przeznaczenie itp. można dodać do zapytania klauzulę GROUP BY i otrzymać osobne poligony dla np. budynków przemysłowych i mieszkalnych lub jedno i wielorodzinnych.
[warning]Generalizacja tą metodą przebiega bardzo wolno i pożera dużą część zasobów procesora, dlatego stanowczo niewskazane jest używanie funkcji aggregatepolygons() w widokach albo dynamicznych Query Layers. [/warning]
Pod tą nazwą kryje się pakiet programów do obróbki i wizualizacji danych LiDAR. Rozwijany przez US Department of Agriculture Forest Service, jest pomyślany przede wszystkim do zastosowań w leśnictwie. Pakiet jest całkowicie bezpłatny i można go używać bez ograniczeń. Zasadniczo jest programem closed source, jednak na początku 2011 roku na portalu SourceForge pojawił się kod źródłowy dwóch modułów: CloudMetrics i GridMetrics. Pakiet jest skompilowany dla systemu Windows.
Pakiet składa się z trzech zasadniczych części:
- FUSION, graficznego programu do zarządzania danymi i wizualizacji 2D,
- LDV, przeglądarki chmury punktów i produktów pochodnych w 3D,
- LTK, zestawu narzędzi obsługiwanych z linii komend do przetwarzania chmur punktów.
Zakres dostępnych analiz jest bardzo szeroki. Ponieważ FUSION/LDV ma ambicję być pakietem kompletnym, znajdziemy tam zarówno narzędzia z zakresu zarządzania danymi (konwersja ASCII/LAS, przycinanie, łączenie), typowych analiz na chmurach punktów (selekcja pierwszych i ostatnich odbić, filtracja gruntu, tworzenie rastrów) oraz specyficzne dla zastosowań leśnych: określanie zwarcia drzewostanu, statystyki dla kołowych powierzchni próbnych.
FUSION/LDV może odczytywać dane LiDAR w formatach ASCII i LAS, oprócz tego posiada własny binarny format LDA. Dla danych rastrowych posiada swój format PLANS DTM, który niestety nie jest odczytywany przez GDAL. Dostępne są narzędzia umożliwiające konwersję formatu DTM do tekstowego ASC.
Do pakietu dołączony jest podręcznik w formacie PDF, zawierający charakterystykę programu i opis dostępnych narzędzi. Wywołanie każdego z narzędzi LTK bez żadnych argumentów (albo z błędnymi) spowoduje wyświetlenie prawidłowej składni i dostępnych opcji. Oprócz tego możemy skorzystać z internetowych tutoriali, dostarczonych wraz z przykładowymi danymi.
Największą siłą FUSION są niesamowicie szerokie możliwości rasteryzacji chmury punktów. W module GridMetrics dostępnych jest 60 statystyk, które mogą zostać obliczone na podstawie samej wysokości lub wysokości i intensywności odbicia. Również liczba dostępnych narzędzi selekcji danych jest imponująca.
Oprócz tych plusów zdarzają się też, oczywiście, minusy. Najpoważniejszym z nich jest kiepski algorytm filtracji gruntu, który wprawdzie usuwa roślinność, ale zupełnie nie radzi sobie z budynkami:
Wyniki filtracji gruntu w FUSION – od lewej: chmura oryginalna, filtracja w FUSION, filtracja producenta. Dane OpenTopography.org
Po drugie, narzędzie to nie dokonuje klasyfikacji chmury punktów, lecz zwyczajnie wycina te zakwalifikowane jako nie-grunt. Jest to może wygodne w przypadku tworzenia DEMu, ale pogarsza możliwości wymiany z innymi aplikacjami. Interoperacyjność jest w ogóle słabą stroną FUSION: formaty LDA i DTM są specyficzne tylko dla tego pakietu, co wymusza częste używanie narzędzi do konwersji. Wreszcie – brak możliwości przetwarzania strumieniowego, co oznacza konieczność załadowania wszystkich punktów z pliku do pamięci RAM przed rozpoczęciem analizy.
Pomimo tych wad, FUSION/LDV jest niesamowicie użytecznym programem dla wszystkich, którzy zamierzają wykorzystać dane LiDAR w projektach przyrodniczych. Pod względem możliwości oceny struktury roślinności zostawia bowiem daleko w tyle inne programy, skupione na tworzeniu DEMów. Ten ostatni jednak lepiej wykonać korzystając z innych narzędzi – na przykład LAStools.
Strona domowa pakietu: http://forsys.cfr.washington.edu/fusion.html
LAStools jest pakietem umożliwiającym wykonanie podstawowych operacji na chmurach punktów skaningu laserowego. Został zbudowany w oparciu o opensource’ową (licencja LGPL) bibliotekę LASlib. Same narzędzia są dystrybuowane jako darmowe do celów naukowych i innych niekomercyjnych.
O ile biblioteka LASlib jest wieloplatformowa, tak jedynie część z LAStools posiada kod źródłowy do kompilacji w systemach innych niż Windows. Na szczęście skompilowane programy .exe dają się bez problemu uruchomić z wykorzystaniem Wine, jeśli z Microsoftem nam nie po drodze.
Programy potrafią odczytać chmurę punktów zapisaną w formacie ASCII, LAS, oraz specyficznym dla LASlib – LAZ, czyli LAS skompresowany ZIPem.
Z LAStools możemy skorzystać na dwa sposoby: z linii komend oraz za pośrednictwem prostego GUI (lastool.exe). GUI daje dostęp do większości narzędzi, umożliwia przeglądanie systemu plików, nagłówków plików LAS oraz zasięgów poszczególnych plików. Niestety nie wszystkie parametry są konfigurowalne z jego poziomu. Interfejs lastool prezentuje się następująco:
A oto co można zrobić z użyciem LAStools:
– przeglądać chmurę punktów z użyciem prostej przeglądarki lasview,
– tworzyć rastry z chmury punktów na podstawie wysokości, intensywności, kąta skanowania, liczby odbić na potrzeby analiz (formaty ASC i BIL) lub wizualizacji (pozostałe formaty) – za pomocą programu lasgrid,
– ograniczyć liczbę punktów do 1 w każdej komórce zadanej wielkości – lasthin,
– podzielić dużą chmurę na kwadratowe kafelki – lastile,
– sklejać dane z różnych szeregów lub plików zawierających osobno pierwsze i ostatnie odbicie – lassort,
– utworzyć poligony z zasięgu punktów używając concave hull – lasboundary,
– łączyć chmury z różnych plików i zapisać je w jednym lub wielu plikach wyjściowych – lasmerge,
– konwertować pliki LAS/LAZ na ASCII – las2txt i na Shapefile (MultiPointZ) – las2shp,
– wyciągać dane o zadanych kryteriach (numer odbicia, klasyfikacja, wysokość, zasięg…) i zapisywać w nowych plikach – las2las,
– tworzyć rastrowe DEMy z rzeczywistymi wartościami lub ich wizualizacje (mapy hipsometryczne, cieniowane) – las2dem, poziomice – las2iso i TINy (w formacie ESRI) – las2tin,
– wycinać punkty zawierające się wewnątrz zadanych poligonów, bądź zaliczyć je do zadanej klasy – lasclip,
– porównywać wysokości punktów LiDAR z punktami kontrolnymi – lascontrol,
– normalizować chmurę punktów (zamienić wysokości nad poziomem morza na wysokości nad poziomem gruntu – wymaga to wcześniejszej klasyfikacji), za pomocą narzędzia lasheight,
– dokonywać klasyfikacji gruntu z użyciem algorytmu Axelssona – lasground,
– usuwać z chmury punkty o identycznych współrzędnych x,y lub x,y,z – lasduplicate,
– kompresować i dekompresować pliki do/z formatu LAZ – laszip,
– tworzyć indeks przestrzenny 3D dla chmury punktów, przyspieszający przeglądanie – lasindex.
Do każdego narzędzia jest dołączona dokumentacja w postaci tekstowego pliku README, zawierającego opis dostępnych parametrów i kilka przykładowych przypadków użycia.
Liczba dostępnych funkcji jest więc całkiem spora, a szybkość i stabilność działania zadowalająca. Szczególnie interesującym narzędziem w pakiecie jest lasground – jakość klasyfikacji jest znacznie lepsza niż w przypadku podobnego pakietu FUSION/LDV, a program jest zdecydowanie łatwiejszy w użyciu niż mocno przestarzały ALDPAT lub moduły v.lidar.* z GRASS. Przykładowe wyniki klasyfikacji i filtracji przedstawiam poniżej – niech wyniki mówią same za siebie.
Przekrój przez sklasyfikowaną chmurę punktów. Dane OpenTopography.org
Porównanie wyników klasyfikacji gruntu – od lewej: chmura oryginalna, filtracja w LAStools, filtracja producenta. Dane OpenTopography.org
LAStools można ściągnąć ze strony domowej. Dla użytkowników dostępna jest również grupa dyskusyjna i profil na Facebooku.
Kto w pionierskich czasach powszechnego dostępu do Internetu w Polsce próbował tworzyć własną stronę internetową (na przykład w kultowym edytorze Pajączek), pamięta zapewne, że każdą z podstron zapisywało się w oddzielnym pliku .html. Na prostej stronie nie stanowiło to specjalnego problemu, ale jak trzeba było dokonać aktualizacji większego serwisu i żadnego takiego pliku nie pominąć – było już gorzej. Ciężko również wyobrazić sobie, jak w takim systemie mogłyby funkcjonować rzeczy tak dziś oczywiste: system komentarzy czy forum.
Współcześnie sprawa ma się zupełnie inaczej: kod html jest generowany dynamicznie, według szablonu, z jednego źródła, któremu na imię baza danych.
Czytaj całość
GRASS. Czyli Ten, Od Którego Się Wszystko Zaczęło w świecie wolnego oprogramowania GIS. Jedni uciekają przed nim gdzie pieprz rośnie, uznając za niezwykle trudnego do opanowania. Inni – nie wyobrażają sobie pracy bez niego. Jaki GRASS jest naprawdę?
Program powstał w 1982, czyli przyszłym roku skończy 30 lat istnienia! Dla porównania, pierwsza wersja Windows – jeszcze nie jako samodzielny system, ale nakładka na DOS – została opublikowana trzy lata później. Skąd w ogóle wziął się ten pakiet?
Otóż GRASS, tak jak system GPS czy koncepcja sieci Internet, wywodzi się z amerykańskiej armii. Rozwijany przez Construction Engineering Research Laboratory służył głównie celom planowania przestrzennego (za Wikipedią). W 1995 roku armia przestała się nim interesować i system “poszedł do cywila”, a konkretnie – zainteresowali się nim naukowcy z Baylor University. Wkrótce stał się programem typu open source, udostępnianym na licencji GNU GPL, a dzięki jego modułowej budowie liczba funkcji zaczęła szybko rosnąć, uwzględniając najnowsze odkrycia w dziedzinie GIS. Pomimo sędziwego, jak na program komputerowy wieku jest wciąż rozwijany, a jego najnowsza wersja stabilna nosi numer 6.4 i została opublikowana we wrześniu 2010.
Do czego dziś może przydać się GRASS? Nie ma co ukrywać: trzon programu niewiele się zmienił od początków jego istnienia, a archaiczny model danych (o którym za chwilę) znacznie utrudnia używanie systemu. Jednak spośród dostępnych darmowych programów GIS jedynie GRASS jest prawdziwym kombajnem, umożliwiającym wykonywanie zaawansowanych analiz i modeli przestrzennych. Analizy sieciowe, struktury krajobrazu, tworzenie powierzchni kosztów, modelowanie hydrodynamiczne – to wszystko dla GRASSa jest przysłowiowy “pikuś”. Wiele modułów zostało stworzonych przez naukowców i jest niezwykle przydatnych w pracy naukowej właśnie.
Gdzie więc tkwi haczyk? W modelu danych, który powinien dostać etykietkę “Zabytek techniki”. Jest on podobny do – wywodzącego się zresztą z tych samych czasów – starego ARC/INFO Workstation (nie mylić z współczesnym ArcInfo!) z wektorami “Coverage” i rastrami “GRID”. Do zapisania choćby jednej warstwy potrzebna jest GRASSowi cała struktura katalogów, która przedstawia się następująco:
GISDBASE – nadrzędny katalog, w którym trzymane są wszystkie dane GRASS. Może być specjalnie wydzielony lub nie,na przykład w systemie Linux może to być /home/nazwa_użytkownika.
Lokacja (LOCATION) – jest to katalog zawierający dane o takim samym zasięgu, układzie współrzędnych i – w przypadku rastrów – rozdzielczości. Wszelkie dane, które mają się znaleźć w lokacji, muszą być transformowane do jednego układu! Nie ma tutaj możliwości transformacji “w locie”, tak jak w przypadku współczesnych programów GIS. Rozdzielczość rastra musi być ustawiona według tej warstwy, która ma piksel najmniejszy. Powoduje to, że chcąc używać jednocześnie ortofotomapy lotniczej (piksel 25 cm) oraz modelu wysokości SRTM (piksel 90 m) – musimy zapisać ten drugi zupełnie bezproduktywnie z 25-centymetrową rozdzielczością…
MAPSET – jest podzbiorem lokacji, opisywany jako “kolekcja map dla jednego terytorium lub projektu”. Innymi słowy jest to jakiś wyodrębniony zestaw warstw, znajdujących się w jednej lokacji (a więc o tym samym zasięgu, układzie i rozdzielczości). Możemy też osobnych MAPSETów nie używać i trzymać wszystkie dane w jednym, domyślnie tworzonym “PERMANENT”.
Paskudne, nieprawdaż? Na pocieszenie dodam, że zupełnie jak w przypadku ARC/INFO Coverage – wektory zapisywane są w modelu topologicznym, co jest zupełnie niemożliwe w przypadku plików Shapefile. Czyli każda granica np. działki jest zapisywana tylko raz, nie ma problemu z nieprzylegającymi czy nakładającymi się poligonami i tak dalej. Sam import, a następnie eksport z GRASSa pozwala pozbyć się problemów z topologią w naszych danych.
O tym, jak używać GRASSa w praktyce i do czego może się on przydać – w następnych wpisach!
Do poczytania:
http://grass.fbk.eu/ – oficjalna strona projektu
http://www.wgug.org/ – Wrocławska Grupa Użytkowników GRASS
Jeśli zdecydujemy się wykorzystać GRASS w praktyce, możemy to zrobić na kilka sposobów. Pakiet ten – w odróżnieniu od większości dostępnego oprogramowania GIS – posiada bowiem kilka interfejsów. Każdy z nich ma swoją specyfikę, swoje wady i zalety.
Jeśli wpiszemy w oknie terminala komendę “grass”, zostaniemy najpierw poproszeni o wybór lokacji i mapsetu (o nich mowa była w poprzednim wpisie). W tym miejscu można też utworzyć nową lokację, jeśli jeszcze nie mamy żadnej – definiując jedynie układ współrzędnych. Na określenie zasięgu i rozdzielczości rastra będzie jeszcze czas. Następnie ujrzymy trzy okienka…
Najbardziej rzucającym się w oczy jest “Menadżer warstw GRASS GIS”. To swoiste centrum dowodzenia – tutaj dodajemy warstwy do wyświetlenia i wybieramy funkcje analiz przestrzennych. Drugie okienko – to “GRASS GIS Map Display” (nie ma to jak niekompletne tłumaczenie…), które służy do wizualizacji, pomiarów odległości/powierzchni, generowania profili itd. Można tu dostrzec pewne podobieństwo do znanego i lubianego (albo przeklinanego) GIMP’a, który również lubuje się w mnożeniu okien… A całość prezentuje się tak:
Omawiany interfejs nosi nazwę wxPython GUI. Zastępuje on poprzednią wersję, eliminując kilka poważnych minusów (na przykład zlikwidowano przycisk “odśwież” w oknie wizualizacji, który trzeba było kliknąć po każdej zmianie w Menadżerze – okropność!), ale nie jest jeszcze w 100% gotowy. Stąd też różne komunikaty o błędach, pojawiające się… no właśnie – gdzie?
W konsoli.
Tak – konsola GRASS, ta żywa skamielina, wciąż jest dostępna. Powróćmy na chwilę do okna terminala…
I ukaże się naszym oczom oryginalny interfejs GRASSa, towarzyszący mu od samego początku. Czarne tło, białe litery i tak dalej. W konsoli tej możemy wpisywać komendy odpowiadające poszczególnym funkcjom analizy. Po co w ogóle zaprzątać sobie tym głowę?
- bo czasami można szybciej wpisać komendę, niż grzebać w menu lub
- napisać skrypt, który zautomatyzuje nasze działania.
No bo kto by chciał np. powtarzać tą samą operację dla wielu warstw? Kilka arkuszy mapy można jeszcze od biedy przerobić w ten sposób. A jakby tak trafiła nam się długa seria czasowa danych z satelity o krótkim czasie rewizyty? Siąść i płakać, albo właśnie napisać skrypt. Do tego celu potrzebna jest właśnie znajomość składni komend GRASS.
wxPython i konsola to jednak nie wszystko. Można jeszcze podpiąć GRASS do Quantum GIS. Wówczas praca z pakietem staje się znacznie łatwiejsza, bo po zaimportowaniu danych do lokacji można korzystać z niego zupełnie jak z ArcToolbox – wystarczy kliknąć ikonę “Narzędzia GRASS”, a pojawi się coś do złudzenia przypominającego właśnie Toolboxa. W porównaniu do ArcGIS 10 nawet lepsze, bo z możliwością wyszukiwania funkcji 🙂 Obecnie każda wersja QGIS posiada wbudowaną obsługę GRASS. Niestety, jest i poważna wada takiego rozwiązania: brak niektórych funkcji i parametrów. Wówczas pozostaje otworzyć konsolę (Narzędzia GRASS -> shell) i wpisać pożądaną komendę, lub użyć wxPython.
I tak oto pokrótce prezentują się możliwości skorzystania z dobrodziejstw GRASS GIS. Najłatwiejszy wydaje się sposób ostatni, jednak trzeba pamiętać o jego ograniczeniach. Tak czy siak, składnię warto znać – albo przynajmniej mieć dokumentację pod ręką. Przyda się w najmniej oczekiwanym momencie!
Szkolenia GIS i QGIS
Szkolenia podstawowe i dedykowane w formie zdalnej oraz stacjjonarnej
