Aplikacja do przewidywania
pożarów lasów
Generowanie zaawansowanych raportów z użyciem postGIS oraz wyodrębnienie części aplikacji na funkcję (Google Cloud Function) wraz z poprawą procesu testowania.
Aplikacja do przewidywania
Dlaczego?
Aby przewidywać skutkki pożarów lasów w USA i Kanadzie.
Co?
Określenie skali ryzyka wystąpienia klęski żywiołowej oraz potrzeby podjęcia działań prewencyjnych.
Jak?
Wykorzystaniu sztucznej inteligencji i platformy obliczeniowej do tworzenia raportów na podstawie analizy dokumentów państwowych.
Opis
Aplikacja non-profit do gromadzenia i analizy danych, której celem jest przewidywanie skutków pożarów lasów w USA i Kanadzie. Aplikacja generuje zaawansowane raporty, przy wykorzystaniu sztucznej inteligencji do analizy obszernych dokumentów państwowych oraz platformy obliczeniowej z wtyczką postGIS umożliwiającą interpretację, oraz zapisywanie danych geograficznych wprost do bazy danych. Na podstawie wygenerowanych raportów określa się skalę ryzyka, wynikającego z wystąpienia klęski żywiołowej oraz podjęcie działań prewencyjnych.
- Zakres
Frontend & Backend Development, Architektura, Infrastruktura chmurowa, Bazy danych, QA
- Branża
Ochrona środowiska, Zarządzanie kryzysowe, Informatyka (IT), Analiza danych, Badania i rozwój
- Region / Kraj:
USA / Kanada
Problem
Każdego roku w wyniku samozapłonu lub nieodpowiedzialnych działań człowieka płoną hektary lasów na granicy Kanady i Stanów Zjednoczonych. Straty poniesione wskutek klęsk żywiołowych są dokumentowane przez organy państwowe i przechowywane w zbiorach danych statystycznych oraz na specjalnie tworzonych mapach terenu. Dzięki przeprowadzeniu skomplikowanych wyliczeń możliwe jest przewidzenie skutków wystąpienia zagrożenia w przyszłości, np. oszacowania liczby gatunków, które mogą zginąć na danym obszarze w ewentualnej katastrofie.
Problem
Rozwiązanie
Szeregi głównego twórcy aplikacji zasilił nasz zespół developerski, do którego należały 2 zadania.
Pierwszym było generowanie zaawansowanych raportów. Na podstawie bieżących i historycznych danych statystycznych oraz map terenu wyciągano szczegółowe dane dla każdego przypadku katastrofy. Aby stało się to możliwe i szybkie do wykonania rozbito architekturę monolityczną na wzorzec microserwisowy z użyciem funkcji. W tym celu połączono PostgreSQL z Node.js, który pełnił rolę “obserwatora” oraz przeniesiono do chmury Google dodatkowo stosując podejście serwerless.
Drugim zadaniem było rozwijanie aplikacji do zbierania danych z formularzy i generowania raportów końcowych w pdf. Aby zadbać o poprawność danych wpisywanych w formularzu, zespół stworzył mechanizm do sprawdzenia oraz poprawy granic projektu. Mapy były przedstawiane w postaci GeoJSON, tak aby obliczenia były szybkie i bezbłędne. Co więcej, wykonano mechanizm do generowania maili dla przypisanych zadań do urzędnika oraz przypomnień o zakończeniu zadania, gdy te od dłuższego czasu było niezakończone.
Aby móc określić, czy funkcja licząca źródła możliwych katastrof generuje poprawne wyniki, trzeba było zmienić sposób testowania. Wcześniej sprawdzano, czy funkcja liczy mapy, lecz przy możliwych błędach process testów funkcyjnych oraz integracyjnych nie zatrzymywał CI i zawsze wymagane było ręczne sprawdzenie obliczeń. Dzięki wprowadzeniu testów jednostkowych, funkcjonalnych i integracyjnych z asercjami sprawdzano, czy wynik jest również poprawny z wartością oczekiwaną w perspektywie pojedynczych elementów, funkcjonalnych jak i całego systemu.
Rezultaty
projektu
projektu
Rezultaty projektu
Skrócenie czasu pracy urzędników państwowych z pół roku do pół godziny przy opracowywaniu raportów z dostępnych danych statystycznych, dzięki opracowaniu i zastosowaniu algorytmów.
Zmniejszenie o 40% kosztów i przyśpieszenie działania aplikacji, dzięki stworzeniu aplikacji serverless, wykonującej obliczenia na mapach w środowisku Google Cloud Functions
Zwiększenie jakości, szczegółowości i szybkości przeprowadzanych testów, dzięki zmianie sposobu testowania – testy jednostkowe, funkcjonalne i integracyjne z asercjami. A także zmniejszenie kosztów na GitHubie Actions, ponieważ po zmianie nie trzeba było uruchamiać 4 unitów maszyny wirtualnej – wystarczył 1.