Rozdział 6 · Blog

Geolokalizacja projektu w Revicie i pozyskiwanie danych

Automatyzacja startu projektu w Revicie. Geolokalizacja, chmury punktów, import danych o terenie i więcej.

Wprowadzenie

W tym poście postaram się wam przybliżyć dane z jakimi możecie mieć styczność, możliwości ich przetwarzania i wykorzystania w projektowaniu budynków, budowli oraz ich analiz. Na koniec pokażę zarys jak można to zautomatyzować w Revicie i Blenderze.

Ostatnimi czasy dane publiczne stają się coraz bardziej dostępne. Instytucje rządowe, jak i amatorskie gromadzenie i analiza danych daje nam dostęp do niesamowitych zasobów. Wystarczy je przetworzyć by móc stworzyć warunki do projektowania niespotykane dotychczas w naszej branży, bez większych nakładów pracy.

Pamiętam czasy, gdy analiza słońca była robiona za pomocą specjalnej linijki nakładanej na rzut. Unormowana praktyka posiadająca niesamowitą ilość uproszczeń. Potem przeszliśmy na analizy słońca 3D, tworząc nasz projekt w trzecim wymiarze i modelując proste bryły sąsiadów. Niekoniecznie sprawdzaliśmy czy program w którym pracujemy bierze pod uwagę odchylenia względem przesunięć UTC, czy bierze pod uwagę wysokość nad poziomem morza, czy liczy uproszczenie płaszczyznowe, czy krzywizny ziemi… ale na to może będzie inny post.

Powyższy przykład miał pokazać, jakie możliwości stoją przed nami i jak szczegółowo możemy wchodzić w analizy. Oczywiście, bardziej skomplikowane analizy wiążą się z czasem na wprowadzenie/wymodelowanie potrzebnych danych.

NMT, czyli Numeryczny Model Terenu, ale czy na pewno?

Jesteśmy na etapie, kiedy większość danych geograficznych jest publicznie dostępna w internecie. Zaczęło się od DEM-ów (Digital Elevation Model), czyli zobrazowań satelitarnych opisujących wysokość terenu. Kiedy zaczynałem się tym interesować były to skale dosyć trudne, ponieważ jeden piksel obejmował ok. 30 × 30 m terenu. Potem zeszło to do 10 × 10 m. Z takich informacji można było już wyciągać całkiem ciekawe uproszczenie terenu, bez dodatkowych opłat. Przykłady:

• ALOS World 3D - 30m
• NASADEM Global Digital Elevation Model
• USGS 1/3 arc-second Digital Elevation Model - 10m szczegółowości

W pewnym momencie zaczęły powstawać bazy danych, gdzie za pomocą zapytań można było pobierać wysokość nad poziomem morza. Takie strony jak:

• https://www.opentopography.org/
• https://open-elevation.com/
• czy nawet api google maps z informacjami o wysokości terenu npm.

Obecnie DEM-y można spotkać nawet w szczegółowości co 1m. Pozytywnym przykładem są udostępnione przez Polskę paczki wysokościowe pokrywające całe terytorium Polski z punktami rozstawionymi co 1m. DEM-y można podzielić na parę rodzajów:

• raster
• grid

Pierwszy to np. obrazy .tiff gdzie odcień szarości definiuje wysokość. Ograniczeniem jest tu wymiar jednego pixela (np. 30m, 10m, 1m). Przetwarzanie takich danych wymaga np. darmowego oprogramowania jak QGIS. QGIS pozwala załadować takiego tiffa w odpowiednich koordynatach, przyciąć go do potrzebnych nam zakresów, a potem wygenerować z danych rastrowych np. poziomice, siatkę punktów. Grid to np. plik tekstowy z listą liczb, które definiują wysokość nad poziomem morza na siatce co 1m. Żeby użyć tego np. w Revicie trzeba przekonwertować takie dane na plik csv z kolumnami X, Y, Z. To pozwoli nam zaimportować je jako toposurface.

Ale czy to na pewno jest już granica szczegółowości? Oczywiście, że nie. 😉

Chmura punktów

Kolejnym poziomem szczegółowości w moim przekonaniu są surowe dane pomiarowe. Wcześniej były to rzesze geodetów i zaawansowane technologie triangulacji. Teraz też opiera się to o triangulację. Tylko ilość danych wzrosła wykładniczo. Mowa o chmurach punktów. Tutaj możemy sprawdzać dokładność z marginesem błędu do paru centymetrów, lub jak kto woli przy danych lidar z drona lotniczego to na przykładzie geoportalu, który mówi o szczegółowości od 4 punktów/m2 do aż 20 punktów /m2 w przypadku większych miast, przy średnim błędzie wysokości np. do 10cm.

Tutaj znów podam przykład polskiego ministerstwa, które udostępnia dane pomiarowe (lidar) w formacie las. Chmura punktów to coś na kształt obrazka w 3 wymiarach. Zamiast pixeli mamy punkty w 3D. Każdy z punktów może mieć dodatkowe parametry, jak:

• kolor
• klasyfikację - czy jest to budynek, zieleń niska, wysoka, teren, samochód, lampa uliczna…
• dokładność - jak precyzyjny był pomiar tego punktu
• intensywność - intensywność odbicia wiązki lidar
• oraz wiele innych danych bezpośrednich
• dodatkowo dane pośrednie wynikające z analizy punktów i ich relacji względem siebie np.:
  • czy punkty są na jednej płaszczyźnie - może być to ściana?
  • czy punkty nie mają żadnej płaszczyzny a są w grupie - może to drzewo?

To już jest olbrzymia ilość danych z której możemy korzystać. W geoportalu nazywa się to Dane Pomiarowe, ja będę używał uogólnienia, czyli chmura punktów. Chmury możemy podzielić, na przeróżny sposób i w różne grupy, ja skupię się na praktycznym podziale:

• chmury punktów lidar
• chmury punktów fotogrametrii

oraz innym:

• chmury punktów sklasyfikowane
• chmury punktów niesklasyfikowane

Na koniec można dodać, że chmury mogą też być:

• zarejestrowane,
• niezarejestrowane.

Jeżeli słyszycie to pojęcie, to głównie chodzi o ustawienie takiej chmury w konkretnych układach współrzędnych pionowych i poziomych, oraz wyczyszczenie i poprawienie ich z niedociągnięć i błędnych pomiarów. Czyli w uproszczeniu geolokalizacja.

Polski geoportal najczęściej dostarcza nam w pełni scalone dane pomiarowe zawierające podstawowe potrzebne informacje:

• geolokalizację
• kolor
• klasyfikację

Dzięki temu możemy łatwo i szybko dopracować taką chmurę do potrzeb projektowych.

• Wyfiltrować wszystkie budynki i wrzucić je na osobną warstwę, do pomiarów sąsiadów
• Wyfiltrować teren i wygenerować z niego teren 3D (np. revitową toposurface)
• Wyfiltrować zieleń wysoką, przetworzyć dane i sprawdzić, gdzie są wierzchołki drzew (a co za tym idzie, ich lokalizację)
• Za pomocą darmowych narzędzi możemy wyfiltrować wszystkie punkty leżące w granicach naszej działki i usunąć z niej wszystko poza punktami terenu, resztę chmury zostawiając w spokoju.

Do tych zadań idealnie nadaje się narzędzie CloudCompare. Potrafi otwierać chmury punktów z zachowaniem układu odniesienia, czyścić, analizować i przetwarzać dane. Dodatkowo ma podstawowe możliwości klasyfikacji punktów. Z zalet tego programu, które przydają się w procesie projektowym wymieniłbym głównie:

• możliwość klasyfikacji punktów terenu (jeżeli nie ma klasyfikacji)
• możliwość nakładania kolorów ze zdjęć satelitarnych na chmurę punktów (jeżeli brakuje kolorów)
• rejestrację chmur punktów względem siebie

Takie ruchy pozwolą nam podzielić chmurę punktów na lekkie paczki, które można potem podlinkować w pliku Revitowym i mieć kontrolę nad widocznością wszystkiego. Tutaj niestety nie obejdzie się bez płatnego programu Autodesk Recap, który otwiera pliki .las i zapisuje je do formatu .rcp, który można podczytać w Revicie.

Z tak załadowaną chmurą, możemy ją podczytać w odpowiednich koordynatach do naszego projektu i możemy być pewni, że punkty siedzą idealnie w terenie. Z praktyki mogę powiedzieć, że taka chmura świetnie się sprawdza na etapie koncepcji i projektowaniu w kontekście terenu z rzeczywistymi (!!!) obiektami terenu jak zieleń, cieki, budynki, drogi, wzniesienia, rzeźby (nie ma co wymieniać, bo to jest dosłownie wszystko). Przydaje się do uszczegóławiania i modelowania dachów budynków sąsiednich, lub sprawdzania rzeczywistej wysokości attyk i wysokości. Świetnie się sprawdza również w przypadku wizualizacji. Generowania rzeczywistego terenu i analizy wykopów mas ziemnych.

Granice działek

Różne kraje mają różne bazy dostępnych publicznie danych. Jako przykład można podać usługi:

• WMS (Web Map Service) WMTS (Web Map Tile Service),
• WFS (Web Feature Service),
• ATOM,
• INSPIRE (Infrastructure for Spatial Information in Europe).

Są to ujednolicone usługi udostępniania danych geograficznych jak ortofotomapy, granice, plany miejscowe i wiele innych.

Polski Geoportal pozwala na pobranie bazy BDOT10k (Baza Danych Obiektów Topograficznych), z których za pomocą znanego nam QGIS możemy wyciągnąć np. granice działek, lub obrysy istniejących budynków, osie dróg oraz wiele innych informacji, jak punkty lokalizacji przystanków, rodzaje terenów etc. Takie dane możemy potem zaimportować do programów projektowych 2D lub 3D.

QGIS pozwala nam to wizualnie wyfiltrować oraz ustawić w odpowiednich koordynatach. Tzw. reprojekcja z ogólnopolskiego układu współrzędnych na układ, w którym projekt jest opracowywany. A o tym w następnym podpunkcie. Pod tym linkiem widać jakie usługi są dostępne w ramach WMS geoportalu.pl

Geolokalizacja i numery EPSG

Od tego tematu powinniśmy zacząć, ale zawsze lepiej zacząć od czegoś bardziej efektownego. EPSG natomiast to element układanki, który połączy wszystko w całość. Znajomość tego pojęcia ułatwi nam pracę, wyeliminuje podstawowe błędy i przy prawie zerowym nakładzie pracy wprowadzi pierwszą automatyzację procesów.

Kody EPSG powstały w celu standaryzacji nazewnictwa układów współrzędnych. W te kody wchodzą układy współrzędnych prostokątnych płaskich (rzutowania) jak i geograficznych. W Polsce mamy dwa układy odniesienia: starszy PL-ETRF89 i obowiązujący dziś PL-ETRF2000.

Układy współrzędnych płaskich prostokątnych razem z numerami EPSG to:

Wiedza o tym, w jakim układzie znajduje się działka, lub w jakim układzie mamy dane pozwoli nam w bezproblemowy sposób scalić takie dane. Do analizy i przetwarzania takich danych też najlepiej sprawdzi się QGIS. Często zdarzy się, że chmura punktów dostarczana jest w układzie ogólnopolskim, a projekt ustawiony jest w koordynatach szczegółowych np. strefy 6.

Modele Budynków

W temacie budynków będziemy mieli parę opcji generowania modeli 3D. Pierwsza, łatwiejsza, ale czasochłonna opcja, to znalezienie istniejących modeli i ustawianie ich w 3D do granic budynków pozyskanych z usług WFS. To oczywista opcja, ale warto ją wymienić, bo czasem można natknąć się na bardzo dokładne modele obiektów.

Drugą opcją jest pozyskanie danych z geoportalu. Budynki można pobrać w formacie GML w szczegółowości LOD1. Aby móc je wykorzystać w Revicie lub innym programie trzeba je przerobić na natywny format. Dla Revita będzie to najlepiej MASS FAMILY. Dla Blendera np. OBJ. Plik GML ma strukturę XML, więc możemy go odczytać w Pythonie parserem XML. Wyglądałoby to tak:

# python
import numpy as np
from xml.etree import ElementTree as et

FILEPATH = "file.gml"


def unflatten(coords, s=1):
    """gets numbers list
    returns array of points (XYZ)"""
    verts = np.array([(coords[i] * s, coords[i + 1] * s, coords[i + 2] * s) for i in range(0, len(coords), 3)])
    return verts


tree = et.parse(FILEPATH)
polygons = tree.findall(".//{http://www.opengis.net/gml}Polygon")
verts = []
faces = []
for i, p in enumerate(polygons):
    poslist = p.find(".//{http://www.opengis.net/gml}posList")
    text = poslist.text
    coords = [float(i) for i in text.split(" ")]
    points = unflatten(coords)
    start_idx = len(verts)
    end_idx = start_idx + len(points)

    verts.extend(points)
    faces.append([i for i in range(start_idx, end_idx)])

Daje nam to zbiór wierzchołków i poligonów (grupy wierzchołków które tworzą pojedyncze poligony). Z takiego formatu bardzo łatwo już wygenerować obiekt w Blenderze, zapisać jako OBJ i zaimportować do Revita. Lub za pomocą Revit API automatycznie wymodelować obiekty MASS za pomocą tych danych. Plusem tego rozwiązania jest to, że takie budynki są już zlokalizowane w układzie poziomym i pionowym.

Problem dalekich odległości

Pojawia się jeden problem dosyć znany w środowiskach grafików 3D. Im dalej wierzchołek jest położony od punktu [0,0,0], tym jego wyświetlanie zaczyna być coraz bardziej “przybliżone”. Jest to problem radzenia sobie komputerów z liczbami po przecinku. Komputer zawsze uogólnia liczby po przecinku do swojej interpretacji dlatego czasami może się zdarzyć, że np. porównując liczby 0,003 == 0,003 okaże się, że są różne, ponieważ dla komputera 0,003 = 0,003000000000000001. Rozwiązaniem tego problemu byłoby pobranie informacji o lokalizacji internal origin lub project base point i przesunięcie wszystkich wierzchołków o dany wektor, aby wstawiały się nie poprzez shared coordinates, a poprzez bliższy punkt wstawienia.

Ostatnie rozwiązanie, jakie mógłbym zaproponować wymaga trochę więcej wiedzy technicznej, ale jest najdokładniejsze. Geometrię budynków moglibyśmy wygenerować z chmury punktów. Na pomoc przychodzi tutaj sporo algorytmów do analiz przestrzennych, ale w skrócie myślowym możemy to rozdzielić na poniższe zadania:

• wydzielamy z chmury punktów punkty klasyfikowane jako budynki.
• analizujemy, które punkty należą do jakich płaszczyzn, i dzielimy je na grupy według płaszczyzn,
• mając płaszczyzny i punkty należące do płaszczyzn wyszukujemy punkty graniczne (leżące na krawędziach każdej z grup). Dzięki temu mamy przybliżone krawędzie danego obiektu i płaszczyzny.
• czyścimy punkty, które leżą na jednej prostej lub w jakiejś małej odległości od niej. Zostają nam wtedy wierzchołki
• łączymy wierzchołki, które leżą blisko siebie, nadajemy im numer i przypisujemy do płaszczyzn.
• finalny wynik daje nam te same zbiory wierzchołków i poligonów jak we wcześniejszym skrypcie.

Ta opcja daje nam dużo bardziej szczegółowe budynki. Jeżeli brakuje nam szczegółowości, wówczas możemy użyć lidaru, drona, aparatu lub smartfonu, aby wygenerować dodatkowe chmury punktów za pomocą np. darmowego programu Meshroom (fotogrametria to przetwarzanie zdjęć z aparatów i smartfonów na chmurę punktów). Mając chmurę punktów możemy ją połączyć z chmurą dostarczoną z geoportalu, zagęszczając dokładność i uzupełniając braki. Takie połączenie chmury bez koordynatów z chmurą z koordynatami nazywamy rejestracją chmury. Łączy się to też z wyczyszczeniem takiej chmury z błędnych pomiarów.

Zdjęcia satelitarne

Czy uwierzycie, jeżeli wam powiem, że jest taki format zapisu obrazu, który pozwala na geolokalizację tego obrazu w koordynatach? Wyobraźcie sobie, że dostajecie mapę planu miejscowego / skan mapy do celów opiniodawczych od inwestora / zdjęcie satelitarne działki lub dowolną inną mapę. Wrzucacie ją do waszego programu i zawsze wkleja się idealnie we właściwe miejsce? Idealnie w skali? Bez żadnych zniekształceń?

Tak jest to możliwe, nie zawsze, nie dla wszystkich programów, ale jest możliwy zapis geolokalizacji dla obrazu. Możemy to zrobić np. dla plików PDF, lub TIFF. Takie pliki tiff nazywamy wtedy GeoTiff.

Kiedy pobieracie zdjęcie satelitarne z portalu rządowego, to najczęściej ma ono już ustawione swoje koordynaty i system w jakim został zapisany. Wrzucając takiego tiff’a np. do programu QGIS wystarczy mu ustawić w jakim układzie został zapisany (np. EPSG:2180) i od razu wkleja się we właściwe miejsce. Bez żadnych zniekształceń, bez przesunięć. Idealnie.

Drugim atutem zdjęć satelitarnych są dane. Dla nas może być przydatny kolor. W przypadku chmury punktów, która nie ma zapisanych danych kolorystycznych możemy przełożyć kolory ze zdjęcia satelitarnego na daną chmurę punktów. Taką możliwość daje np. Cloud Compare.

Łączymy wszystko i automatyzujemy

Najciekawszym elementem tej układanki jest to, że większość tych zadań można skrócić do jednego przycisku np. w Revicie. Potrzebujemy wprowadzić tylko parę parametrów:

• lokalizację (koordynaty)
• promień widoczności (w jakim zasięgu pobierać dane)
• opcjonalnie poligon/region z granicami działki

Resztę, czyli pobranie terenu, chmury punktów, granic działek, budynków i ortofotomapy oraz ustawienie ich we właściwym układzie współrzędnych, załatwia skrypt. Projektant dostaje gotowy kontekst w kilka minut zamiast kilku dni.