Instalacja Ubuntu/Kubuntu na Asus Zenbook 434

Takie wpisy nie pojawiały się tutaj już od dawna (w ogóle mało co się ostatnio pojawia, zwłaszcza że większość mojej sieciowej aktywności przeniosłem do Twittera). Pomimo to postanowiłem zamieścić kilka wskazówek dotyczących instalacji GNU/Linux w wersji Ubuntu/Kubuntu na względnie nowym laptopie, jakim jest Asus Zenbook 434. Porady dotyczą modelu z procesorem i7, 16 GB RAM i dyskiem SSD 1TB, ale powinny stosować się także do innych wersji. Dotyczyć także będą instalacji dual boot, czyli postawienia linuksa obok windowsa.

 

Zenbook UX434 to bardzo sympatyczny, niewielki sprzęt o przyzwoitej konfiguracji i niesamowitym ekranie 14 i „screen body ratio” 92% (czyli ekranie obejmującym 92% powierzchni pokrywy, co oznacza, że ramki są tu naprawdę niewielkie).

Niezwykłym elementem jest screenpad, czyli touchpad/gładzik laptopa mający formę niewielkiego, dodatkowego ekranu 5,65 cala, który może zawierać skróty do programów, dodatkową klawiaturę numeryczną lub po prostu miejsce, na które zrzucamy okna programów działających w tle. Więcej informacji o sprzęcie znajdziecie w recenzjach, których nie brakuje w sieci (np. tutaj).

Komputer jest naprawdę malutki i poręczny. Przypomina niewielkie netbooki sprzed lat, najczęściej o słabej konfiguracji i ekranach 10-11 cali, lecz jest nieporównanie potężniejszy i ma całkiem spory, 14 calowy ekran. Na zdjęciu powyżej leży obok mojego starego, także 14 calowego laptopa Lenovo IdeaPan U430. Jak widać obudowa ASUSa zbiera niestety odciski palców, co jest chyba największym, póki co, minusem tego sprzętu, jaki udało mi się zaobserwować.

Próba instalacji Ubuntu (jeszcze w wersji 19.10, choć na dniach pojawiła się już wersja 20.4) na domyślnych ustawieniach komputera raczej się nie powiedzie. Wystartowanie systemu z pendrive (w wersji live) nie sprawia jednak żadnych problemów:

Jak widać uruchamia się nawet screenpad, jednak w sposób zaskakujący, z przekręconą o 90 stopni osią ekranu. W trybie live działa właściwie wszystko, poza touchpadem (dlatego do instalacji lepiej będzie podłączyć mysz) i poza systemem logowania za pomocą biometrycznego rozpoznawania twarzy (Windows Hello). Pomimo to nie da się w tym momencie zainstalować Ubuntu na twardym dysku. System tego dysku po prostu nie widzi. Dlatego konieczna będzie zmiana ustawień UEFI. Zanim to nastąpi musicie koniecznie zaktualizować BIOS do wersji powyżej 300. Można to zrobić z poziomu całkiem przyjaznego narzędzia ASUSa służącego do konfiguracji i aktualizacji systemu. BIOS aktualizuje się wówczas całkowicie automatycznie i nie trzeba nigdzie grzebać. Po prostu uruchomcie narzędzie i wejdźcie w zakładkę aktualizacji. Gdy aktualizacja się zakończy, wejdźcie w ustawienia UEFI/BIOS.

Aby wejść do ustawień UEFI/BIOS powinniście włączyć komputer i wcisnąć f2. Gdyby Wam się nie udało, możecie uruchomić UEFI spod Windows, wpisując w systemową wyszukiwarkę UEFI lub BIOS i pozwalając mu uruchomić się ponownie z ekranem „Opcje zaawansowane”. Tu wybierzcie „Rozwiąż problemy” i „Ustawienia oprogramowania układowego UEFI”.

Powinien pojawić się panel ustawień:

W którym wybieracie „Adbanced” – „SATA Configuration”. A w ustawieniach dysku zamieniacie domyślny „Intel RST Premium With Intel Optane System Acceleration” na „AHCI”:

Po zatwierdzeniu tej zmiany system Windows będzie próbował uruchomić się ponownie, ale pokaże błąd i będzie próbował samodzielnie się naprawić. W tym miejscu spróbujcie wymusić na nim uruchomienie w trybie bezpiecznym, a później ponowne uruchomienie w trybie normalnym. Będzie wam potrzebny kod dla odblokowania funkcji szyfrowania dysku BitLocker. System poda wam adres strony, na której uzyskacie swój kod. Można to zrobić z drugiego urządzenia lub choćby telefonu. Albo przygotować sobie kod wcześniej logując się na swoim koncie Microsoft (account.microsoft.com/devices/recoverykey). Najlepiej zapiszcie go sobie, bo przyda wam się jeszcze kilkukrotnie.

Kiedy już system Windows uruchomi się normalnie, z jego poziomu możecie wydzielić sobie osobną partycję, którą przeznaczycie dla Ubuntu. Uruchamiacie linuksa w trybie live by sprawdzić, czy już wykrywa już dysk twardy komputera. Jeśli tak, zainstalujcie system. Podczas instalacji wybierzcie opcję samodzielnego ustawienia partycji dla linuksa. W wolnym miejscu, wydzielonym już spod Windows warto ustawić partycję systemową „/” (ja dałem 30 GB), SWAP (czyli partycję wymiany, ja dałem 3 GB) oraz partycję „/home”, na którą przeznaczcie resztę wydzielonego miejsca. Nie usuwajcie żadnych partycji (poza przeznaczoną na linuksa powinny być jeszcze UEFI, Windows i partycja Recovery). Po zainstalowaniu systemu wszystko powinno działać out of the box. Nawet ScreenPan, w którym wcześniej nie działały funkcje dotykowe. Jest on wykrywany po prostu jako dodatkowy ekran. Należy jedynie skonfigurować jedynie wyświetlanie. W tym celu Obraz ScreenPada należy obrócić o 90 stopni i ustawić w kreatorze pod ekranem głównym laptopa:

Tak to wygląda w ustawieniach Plasmy KDE, w Gnomie Ubuntu będzie podobnie. W takim ustawieniu możecie zrzucać sobie na ten ekran okna dodatkowych aplikacji, lub np. okna narzędziowe programów graficznych czy multimedia. W KDE możecie pokombinować z umieszczeniem tutaj elementów Plasmy (np. uruchamiania aplikacji).

Oczywiście, jeśli chcecie aby komputer zużywał mniej energii, po prostu dodatkowy ekran wyłączcie. Będzie wówczas działał jak tradycyjny Touchpad.

Jedynym elementem, który nie działa out-of-the-box jest system biometrycznego rozpoznawania twarzy. Jeżeli wam na nim zależy, możecie pokombinować z Howdy. Jest to opensource’owy zamiennik Windows Hello. Ponieważ jednak deweloperzy Howdy sami stwierdzają, że „This package is in no way as secure as a password and will never be”, ja sam dałem sobie z nim spokój i korzystam z logowania hasłem.

Musicie pamiętać, że za każdym razem, gdy w linuksie zmienią się istotne ustawienia (np. zaktualizuje się kernel lub spróbujecie grzebać w GRUB), to podczas uruchamiania Windowsa, konieczne będzie podanie kodu BitLockera. Przy normalnym użytkowaniu, czy aktualizacjach systemu, nie będzie to konieczne i będzie można zupełnie normalnie przełączać się pomiędzy systemami.

Reklama

MyPaint – nowa wersja programu, nowa wersja rekonstrukcji

Jakiś czas temu zorientowałem się, że program MyPaint zmienił swój interfejs. Zamiast wielo-panelowego, nawiązującego do klasycznego Gimpa pojawił się jedno-okienkowy, typowy dla większości podobnych programów.

Jednocześnie analiza pomiarów lidarowych pokazała, że sytuacja terenowa w Rozprzy jest znacznie bardziej skomplikowana niż wcześniej myśleliśmy.  Zakończył się także etap analiz specjalistycznych. Spłynęły wyniki szczegółowych studiów paleośrodowiskowych, dzięki czemu wiemy znacznie więcej o tym co rosło w pobliży grodziska, jakie zwierzęta przebywały w pobliżu, jak wyglądał stan wód. Pojawiła się więc konieczność znaczącej modyfikacji starszej rekonstrukcji, o której pisałem tutaj. Praca trwa…

Ilustracje będą częścią artykułu podsumowującego wyniki badań fosy.

Jak wyglądał gród w Rozprzy?

Po dwóch etapach badań w Rozprzy pojawiła się potrzeba przygotowania graficznej rekonstrukcji wyglądu grodu w Rozprzy. W wyniku naszych badań okazało się, że rekonstrukcja założenia wczesnośredniowiecznego jest w zasadzie niemożliwa. Udało się zarejestrować przekrój wału tej warowni i w kilku miejscach zarejestrować obecność wczesnośredniowiecznych nawarstwień, jednak zdecydowana większość zachowanych do dzisiaj struktur oraz reliktów związana jest z późnośredniowieczną rezydencją rycerską w typie motte, czyli wzniesionego na kopcu ziemnym dworu, być może o wieżowej formie. Podstawą do rekonstrukcji były wyniki wykopalisk, badań paleośrodowiskowych oraz rozpoznania geofizycznego i zdjęć lotniczych z 2015 r. Najnowsze prace, z bieżącego roku, wnoszą niewielkie korekty w kwestii rekonstrukcji środowiska w otoczeniu gródka.

Postanowiłem więc zamienić się na trochę w grafika, co zdarza mi się ostatnio zupełnie sporadycznie, z braku czasu na graficzne zabawy. Rekonstrukcję zrobiłem w programie MyPaint. Pracowałem na laptopie z wykorzystaniem tabletu graficznego Wacom. Za podkład posłużyło jedno ze zdjęć wykonanych z drona w zeszłym roku, na którym doskonale czytelny jest przebieg fos, nasyp drogi, zasięg „podgrodzia” oraz przebieg paleokoryt Luciąży. Widać też nasz przekop przez fosę oraz samochody ekspedycji i odwiedzających nas wówczas licznie gości.

Zdjęcie stało się warstwą w MyPaint, na której wpierw pojawił się zgrubny szkic rekonstrukcji założenia:

Który w dalszym etapie zaczął nabierać kształtów:

Trzeba zaznaczyć, że sama wieża w Rozprzy się nie zachowała. Udało się zarejestrować jedynie wkop, który związany był już chyba z jej rozbiórką, w którym zalegała glina, polepa, kamienie fr. spalonego drewna. Podejrzewamy, że były to właśnie elementy pochodzące z rozbiórki tej konstrukcji. Na obrazku wieżę zrobiłem w wersji szachulcowej. W taką rekonstrukcję nie bardzo wierzy prof. Anna Maciniak – Kajzer, która rekonstrukcję oglądała, a na gródkach tego typu zna się bardzo dobrze. Zasugerowała mi więc zmianę na konstrukcję zrębową, znacznie w XIV wieku częściej spotykaną. Będę musiał znaleźć na to nieco czasu…Oczywiście rozplanowanie pozostałych budynków jest w znacznej mierze hipotetyczne. Dysponujemy co prawda wynikami badań wykopaliskowych, w tym z lat 60. XX wieku (na te podstawie wrysowałem jeden z budynków we wschodniej części założenia oraz towarzyszący mu płot w konstrukcji międzysłupowej – ich relikty odkryła A. Chmielowska) oraz wynikami badań geofizycznych (te pozwalają dopatrywać się kilku budynków w południowej części założenia oraz przebiegu wałów ziemnych), jednak całość należy traktować jako w znacznym stopniu „wizję artystyczną”. Potwierdzony dobrze jest przebieg fos, położenie bramy zachodniej, drewniane konstrukcje u podnóża stożka i ogólny układ przestrzenny. Potwierdzenie w znaleziskach mają zalegające w fosach gałęzie, czy wręcz całe konary drzew, które prawdopodobnie pełniły funkcje zasieku, niskie ziemne wały, może bardziej przeciwpowodziowe niż obronne oraz przebiegające od wschodu paleokoryta. Na jednym z nich znalazły się konstrukcje moczydła do lnu. Zakończone dopiero co badania trzeciego etapu wskazują, że kolejne moczydło znalazło się także na korycie przebiegającym tuż przy wschodnim stoku ostańca terasy, na którym wzniesiono warownię. Samo koryto było w tym okresie nieco węższe i aktywne (na obrazku wrysowałem je jako zarastające starorzecze, sugerując się wczesnymi datami radiowęglowymi z odwiertów). Obrazek trzeba więc będzie w kilku szczegółach zmienić, ale ogólny kształt warowni, o dość złożonej strukturze przestrzennej, pozostaje aktualny.

Warsztaty Strati5

Mniej lub bardziej stali czytelnicy bloga na pewno zdążyli się zorientować w tym, że to co autora zajmuje szczególnie, to różnego rodzaju nowoczesne formy dokumentacji archeologicznej. Od dłuższego czasu dążę do tego, by wdrażać w praktyce coś, co niektórzy nazywają „paperless archaeology” lub po prostu dokumentacją cyfrową. W zakresie dokumentacji graficznej udało się wypracować pewien sposób postępowania, który właściwie całkowicie eliminuje konieczność używania papieru i ołówka (co było moim tematem wystąpienia w ramach tegorocznej konferencji CAA). Analogicznie sytuacja ma miejsce w zakresie dokumentacji opisowej. Po pierwszych próbach ze stosowaniem arkuszy kalkulacyjnych (jako swoistej uproszczonej bazy danych) i ręcznego wklejania danych do programu Stratify, z pomocą przyszedł mi prof. Jerzy Tyszkiewicz, matematyk i informatyk oraz specjalista od arkuszy kalkulacyjnych. W wyniku tej współpracy, w której ja byłem stroną zamawiającą i testującą, zaś szanowny Matematyk stroną kreującą (we współpracy ze swoim kolegą po fachu, czyli Jackiem Sroką), powstał Strati5 – arkusz kalkulacyjny zdolny do ścisłej współpracy z programem Stratify.

Cała koncepcja polega na zastosowaniu arkusza opartego wyłącznie o formuły, bez żadnych makr, zdolnego do pracy na bardzo licznych platformach, zarówno systemowych, jak i w ramach licznych przecież aplikacji arkuszowych. Programik działa więc na Windowsie, Linuksie, Maku, Androidzie i iOS w ramach Excela, Open/Libre Office, WPS Office czy arkusza Google. Działając na tym ostatnim narzędziu zyskujemy możliwości pracy grupowej: arkusz może wypełniać jednocześnie kilka osób. Możemy go więc odpalać na komputerach oraz na urządzeniach przenośnych, w tym tabletach i telefonach komórkowych.

Arkusz zawiera komórki uporządkowane w sposób odpowiadający kolejnym polom programu Stratify, dzięki czemu zgromadzone dane można zaimportować do Stratify i w kontynuować analizę stratygraficzną i kreować diagram Harrisa. Do tego wbudowane w niego formuły ostrzegają przed przypadkowym i niezamierzonym nadaniem tej samej nazwy jednostki stratygraficznej kilku różnym jednostkom (co jest szczególnie ważne, gdy nie opisujemy jednostek w kolejności (np. kolejnych liczb), a mniej lub bardziej przypadkowo (co może wynikać z różnych uwarunkowań terenowych). Oprócz opisu samej jednostki stratygraficznej, w programie umieszczamy też informacje o relacjach między nimi. Istnieje też możliwość grupowania jednostek (np. w ramach zwartych obiektów) i uwzględniania relacji pomiędzy grupami. Do tego program (podobnie jak Stratify) ostrzega nas gdy niechcący stworzymy zapętlającą się relację stratygraficzną (tzn. jednostka będzie jednocześnie nad i pod inną jednostką). Takie rzeczy potrafią się zdarzać na stanowiskach o złożonej stratygrafii. Dokładniejszy opis działania programu znajdziecie tutaj.

W przyszłym tygodniu odbędzie się warsztat dotyczący Strati5, a zorganizowany przez Laboratorium Cyfrowe Humanistyki Uniwersytetu Warszawskiego. Termin to 19 kwietnia, godzina 17.30, Laboratorium Cyfrowe Humanistyki UW, ul. S. Banacha 2c (budynek CeNT-1), II piętro, moduł B. Warsztat będzie współprowadzony przeze mnie oraz Jerzego Tyszkiewicza. Ponieważ będzie obecny współautor kodu programu, możliwe będzie zgłoszenie dodatkowych funkcjonalności (np. automatycznej edycji kart jednostek stratygraficznych, o ile ktoś ich potrzebuje). Informacje o warsztacie są dostępne tutaj. Są jeszcze wolne miejsca, więc serdecznie zapraszam.

Przypomnę, że podobny warsztat przeprowadzony będzie także w Gdańsku podczas konferencji polskiego oddziału CAA Sea of Data. Konferencja odbędzie się 1-3 czerwca.

Jeśli w Ubuntu nie działa wam Photoscan

W nowej wersji Ubuntu (15.10) nie działa nowy Agisoft Photoscan (wersja 1.2.2). Program się nie uruchamia. Najprostszym wyjściem jest używanie starszej wersji aplikacji. Na pewno działa 1.1.6.

Wyjaśnieniem problemu jest komunikat, który pojawia się, gdy spróbujemy uruchomić program z konsoli:

Problemem są biblioteki Qt programu. Rozwiązaniem problemu jest po prostu usunięcie bibliotek programu i zmuszenie go w ten sposób z korzystania z bibliotek systemowych. Trzeba więc trwale usunąć pliki znajdujące się w katalogu „photoscan-pro” (w wersji podstawowej programu ten katalog pewnie nazywa się inaczej): libQtCore.so.4, libQtGui.so.4, libQtNetwork.so.4, libQtOpenGL.so.4.

Po ich usunięciu program uruchamia się z wykorzystaniem tych bibliotek zainstalowanych w systemie. I działa:

Ostrowite w tym roku zakończyliśmy

Trudne warunki eksploracji spowodowały, że otworzyliśmy zaledwie 2, 5 ara powierzchni, rejestrując dwa piece wapiennicze z okresu rzymskiego, kilka jam osadniczych zarówno z okresu rzymskiego, jak i wczesnego średniowiecza oraz osiem grobów szkieletowych. Nie udało nam się w tym roku zarejestrować kolejnych grobów ciałopalnych kultury pomorskiej.

W piecu wapienniczym oprócz mnóstwa polepy z rozbiórki kopuły pieca, węgli drzewnych oraz resztek wapiennego wsadu znaleźć można na przykład takie ładne fragmenty naczyń.

W badaniach w Ostrowitem spotkać można było przedstawicieli zakonu Lordów Sitów. Zajmujących się sitowaniem…

Nasze wielkie rozczarowanie. Wspaniała jama, o wymiarach zbliżonych do grobowych, o zarysie grobowym i nawet podobnym do „grobowego” wypełnisku sugerowała możliwość odkrycia dziewiątego w tym roku grobu. Jama położona była na osi północ – południe, nietypowej dla grobów szkieletowych w Ostrowitem, co jeszcze bardziej potęgowało naszą ciekawość.

Niestety, w jamie były jedynie nieliczne fragmenty ceramiki (głównie pradziejowej ale także nieco wczesnośredniowiecznej), piękny przęślik z bursztynu, nieco drobnych fragmentów polepy i sporo niewielkich kamieni, wyraźnie spękanych pod wpływem wysokiej temperatury. Jeśli kości, to wyłącznie drobne fragmenty zwierzęcych. Grobu nie było…

Oto nasz przęślik… Prawda, że ładny?

I tak żegnamy się z Ostrowitem z wnętrza pieca. Wapienniczego…

Ortofotografie z Photoscan i Qgis – porównanie

W trakcie prac w Ostrowitem wykonujemy masę dokumentacji elektronicznej. Można podzielić ją na dwie grupy: dokumentację 2D i 3D. Część ortofotografii 2D przygotowywana jest w Gimpie (później georeferowana w Qgis), część zaś bezpośrednio za pomocą modułu georeferencyjnego Qgis, z wykorzystaniem pomiarów tachimetrem lub GPS RTK. W przypadku fotogrametrii trójwymiarowej posługujemy się głównie programem PhotoScan firmy Agisoft. Zazwyczaj jednak sporządzenie modelu ostatecznie kończy się wyeksportowaniem go do ortofotografii, co bardzo wygodnie robi się w Photoscanie dzięki funkcji punktów georeferencyjnych oraz obsłudze naszych rodzimych układów odniesienia (92 i 2000). Przy okazji wykonywania dokumentacji zaistniała możliwość porównania wyników obu procedur, a więc ortofotografii uzyskanych w module georeferencyjnym Qgis oraz wyeksportowanych z PhotoScan. Wyniki będę prezentował jako zrzuty z okna mapy Qgis.

Na początek georeferowane w Qgis zdjęcie dwóch grobów szkieletowych z wczesnego średniowiecza.

I te same groby na ortofotografii z Photoscan.

Różnice nie są przy tej skali specjalnie duże. Kiedy jednak powiększymy obrazek…

Qgis.

PhotoScan.

Widać już pewne różnice dotyczące rozdzielczości, a także drobne różnice w oddaniu geometrii obiektu. W przypadku georeferowania w Qgis mamy do czynienia ze zniwelowaniem zniekształcenia fotografii wynikającego z perspektywy. Przy fotografowaniu obiektów o pewnej formie przestrzennej, a więc nie idealnie płaskich powierzchni, pojawiają się pewne błędy. W PhotoScan zgeoreferowany model jest rzeczywiście rzucany do ortofotografii w danym układzie odniesienia.

Różnica rozdzielczości jest bardziej widoczna przy dokładniejszej skali:

Qgis.

PhotoScan.

PhotoScan robi model i jego teksturę z całego pakietu fotografii. W Qgis posłużyłem się pojedynczym zdjęciem. Efektem jest znaczna różnica rozdzielczości, doskonale czytelna pomimo użycia tego samego aparatu w obu przypadkach.

Ortofotomapy z PhotoScan są więc znacznie lepszej jakości. Jest jednak jeszcze jeden aspekt tej sprawy: czasochłonność. Dla wykonania ortofotografii w Qgis wystarczy pojedyncze zdjęcie. Program przelicza ją w czasie krótszym niż minuta. PhotoScan wymaga zestawu zdjęć. Model, który posłużył do wykonania ortofotografii w tym wpisie powstał na podstawie około 60 fotografii. Na moim laptopie stworzenie modelu wymagało ponad 3 godzin pracy programu…

Qgis 2.10 już się objawił

Przed chwilą pojawiła się u mnie nowa wersja Qgis 2.10. Na stronie projektu nie ma jeszcze oficjalnej informacji i changeloga. Sam jeszcze nie sprawdziłem, czy pojawiły się jakieś nowości. Ale wygląda na to, że nowa wersja już jest:

Testuję PhotoScan (na Linuksie)

PhotoScan firmy Agisoft stał się ostatnio standardem w zakresie fotogrametrii 3D w archeologii. Rosjanie zdobyli rynek przebojem oferując znacznie niższe ceny niż producencie dotychczas dominujących na tym rynku programów komercyjnych oraz znacznie przyjemniejszy interfejs i „workflow” niż w przypadku  większości rozwiązań open source. Po pierwszych próbach z różnymi narzędziami, w tym Arc3D, Photosynth czy Hypr3D zatrzymałem się 123D Catch od Autodesk. Niekoniecznie dlatego, że produkował najlepsze chmury punktów, ale dlatego, że proces ich otrzymywania jest zautomatyzowany i w całości odbywa się poza moim komputerem. Miało to spore znaczenie na moim starym MacBooku, który na dwóch rdzeniach Core2Duo, przy 2 GB RAMu ledwo zipał próbując samemu wyliczać chmurę z użyciem narzędzi działających lokalnie.

Z nowym laptopem (nowy był rok temu, ale nadal to czterordzeniowy i7, karta od NVidii i 8GB RAMu, więc nie jest tragicznie) da się już zrobić coś więcej. Postanowiłem więc wypróbować rosyjski wynalazek. Zwłaszcza, że udostępniono wersję działającą pod Linuksem, która w dodatku nie wymaga instalacji.

Tak wygląda produkcja modelu średniowiecznej jamy z Ostrowitego.

I obciążenie systemu w trakcie pracy.

Model przed teksturowaniem.

Oraz po zakończeniu teksturowania. Odnoszę wrażenie, że jakość tekstury to szczególnie mocna strona programu.

Porównanie modelu zrobionego w 123D Catch (po lewej) i PhotoScanie (po prawej). W obu przypadkach wykorzystano wyeksportowane pliki obj. DO wyświetlenia chmury użyto oczywiście Meshlaba.

Zbliżenie detalu – fragmenty ceramiki naczyniowej. Po lewej 123D Catch, po prawej PhotoScan. Jakość tekstury w drugim przypadku jest znacznie wyższa.

I podgląd chmury punktów (po lewej 123D Catch, po prawej PhotoScan) – gęstość punktów jest wyższa w przypadku 123D Catch.

I siatka trójkątów.

Inny przykład – grób 50 z Ostrowitego. Pokazuję go dlatego, że w tym przypadku 123D Catch miał olbrzymie kłopoty ze stworzeniem poprawnego modelu. Po lewej 123D Catch, po prawej PhotoScan. Różnica jakościowa, zwłaszcza w zakresie tekstury, w przypadku modelu PhotoScanu jest ewidentna.

Gęstość chmury w przypadku 123D Catch (po lewej) jest znacznie wyższa. Jednak program miał spore problemy z właściwym skonstruowaniem modelu. W przypadku PhotoScan punktów jest mniej, ale kształt jamy został zrekonstruowany znacznie lepiej.

Być może dla pełnego porównania powinienem te same modele złożyć także n.p. w Arc3D, by sprawdzić jak wygląda postęp w przypadku tego narzędzia. Jak znajdę nieco czasu, to pewnie to zrobię.

Wkrótce rozpoczynamy sezon wykopaliskowy. Wygląda na to, że okazji do dalszych prób z programem będzie jeszcze wiele.

Tworzenie NMT z chmury punktów LAS w SAGA GIS

By móc pracować w nich z efektami skanowania LiDAR konieczne jest stworzenie na bazie chmur punktów (zazwyczaj zapisywanych obecnie w formacie LAS) rastrowych Numerycznych Modeli Terenu zarówno w postaci modeli powierzchni czy też pokrycia terenu, jak i rzeźby. Dla uzyskania tej drugiej opcji (co przecież jest największą zaletą skanowania LiDAR), konieczne jest odfiltrowanie roślinności i zabudowy.

Programów umożliwiających takie działania jest oczywiście sporo. Wiele z nich to bardzo drogie, komercyjne oprogramowanie. Dlatego skupimy się na darmowym, otwartoźródłowym SAGA GIS.

Krok 1: importujemy chmurę punktów LAS

Modules-File-Shapes-Import-Import LAS files

Istotne jest by zaznaczyć opcję „classification”. Pozostałe opcje wedle uznania – do stworzenia modelu rzeźby terenu nie będą potrzebne.

W ten sposób oprzemy się na istniejącej klasyfikacji chmury punktów. W przypadku plików z programu ISOK nie zawsze może być ona najlepsza dla celów archeologicznych, ale z moich prywatnych doświadczeń wynika, że zazwyczaj wystarcza.

Krok 2 (opcjonalny): podgląd chmury punktów.

Modules – Shapes – Point Cloud – Visualisation – Point Cloud Viewer

SAGA posiada moduł podglądu chmury punktów. Nie daje ona tylu możliwości co specjalistyczne programy obsługujące dane LiDAR, ale wystarczy do podejrzenia tego, co nam się udało zaimportować 😉

Krok 3: Odfiltrowanie roślinności i zabudowy.

Modules – Shapes – Point Clouds – Tools – Point Clouds Reclassifier/Subset Extractor

W oknie dialogowym musimy wybrać:

– w rubryce Point Cloud wybieramy chmurę, nad którą pracujemy.

– w rubryce Attribute: classification

– w rubryce Mode of operation: Extract Subset

– w rubryce old value możemy wpisać „2”

W efekcie otrzymamy chmurę punktów odwzorowujących ukształtowanie powierzchni. W przeglądarce chmury będzie wyglądała tak: Jak widać nieco więcej tutaj dziur, wynikających z odfiltrowania powierzchni.

Krok 4: griding – tworzenie rastra NMT.

Modules – Grid – Gridding – Interpolation from points – Triangulation

W oknie dialogowym:

– w rubryce Points wybieramy chmurę po odfiltrowaniu roślinności i budynków (domyślnie ma rozszerzenie nazwy subset_classification).

– w rubryce Atribute wybieramy „z” (czyli wysokość)

Po zatwierdzeniu pojawi się kolejne okno dialogowe:

Tutaj w rubryce Cellsize wpisujemy „1”. Po zatwierdzeniu rozpocznie się proces triangulacji, który może trwać nawet kilka godzin. Jest to oczywiście uzależnione od ilości punktów (dla terenów zalesionych trwa to krócej, bo wyeliminowanie roślinności zmniejsza liczbę punktów) i jakości komputera. Zwykle można w tym czasie zrobić sobie kawę. Albo nawet dwie… albo obiad…

Alternatywnie można zamiast triangulacji użyć funkcji:

Modules – Shapes – Point Clouds – Conversion – Poin Cloud to Grid

Zwykle trwa to nieco szybciej niż triangulacja.

Krok 5 – zapis uzyskanego rastra

Modules – File – Grid – Export – Export ESRI Arc/Info grid (o ile chcemy mieć plik z rozszerzeniem .asc czytany przez większość programów GIS, w tym Qgis). Opcjonalnie możemy importować do geotiff. Lub do dowolnego rastrowego formatu, jaki nam do głowy przyjdzie. Akurat te dwa pierwsze są najczęściej używane…

Niekiedy zamiast triangulacji warto zastosować inną metodę gridingu. W przypadku niektórych terenów zalesionych, po odfiltrowaniu roślinności, liczba punktów, które są podstawą obliczenia rastra NMT jest znacznie mniejsza od wyjściowej (n.p. najczęściej stosowanej w programie ISOK 4 pkt. na 1m kwadratowy). Po wykonaniu triangulacji efekt końcowy może być daleko niezadowalający, jak w tym przypadku:

Fragment NMT z zastosowaniem cieniowania (hillshading). Widać wyraźne, duże trójkąty, wynikające z triangulacji pomiędzy zbyt „luźno” rozłożonymi punktami.

W takiej sytuacji można zastosować np. metodę krigingu (ordinary kriging), która dobrze się sprawdza w podobnych sytuacjach (zob. dawny wpis o tworzeniu NMT z planów warstwicowych).

Efekt końcowy jest wyraźnie lepszy.

W skrajnych przypadkach może okazać się, że oparcie się na istniejącej klasyfikacji chmury nie będzie wystarczająco korzystne. Konieczna będzie reklasyfikacja chmury. Ale o tym może innym razem…