O tym jak próbowałem zautomatyzować pobieranie danych z IMGW

Dane publiczne IMGW

We wrześniu 2023, w ramach nauki Pythona, zacząłem pracę nad projektem, upraszczającym pobieranie danych publicznych IMGW z serwisu https://danepubliczne.imgw.pl/. Zadanie wydawałoby się proste, bo czym jest połączenie się z API, pobranie danych i zapisanie ich do pliku? Jak się okazało, rzeczywistość był bardziej złożona. Aż chce się zacytować Boromira, “One does not simply walk into Mordor”.

Repozytorium mojego projektu znajdziecie na GitHubie: https://github.com/Daldek/IMGWTools

API

Większość serwisów, z których korzystałem udostępnia dane przez API. Najczęściej wystarczy zdefiniować kilka podstawowych parametrów, przesłać zapytanie do serwera i et voilà, dostajemy to o co prosiliśmy. Niestety, IMGW ograniczyło tę możliwość wyłącznie do pobierania aktualnych pomiarów, bez dostępu do danych historycznych.

Żeby nie było tak łatwo, na niczego nieświadomych użytkowników zastawiono kilka pułapek. Chcecie pobrać dane synoptyczne? Nie ma problemu! Podajcie tylko nazwę stacji lub jej identyfikator i dostaniecie najświeższe informacje. Chcecie tak samo pobrać dane hydrologiczne lub meteorologiczne? Wstrzymajcie swoje konie, bo od teraz akceptujemy tylko identyfikator.

Jeżeli myślicie, że łatwiej będzie z analizą odpowiedzi otrzymanej z serwera, to jesteście w błędzie. Część danych jest zwracana jako słownik, część jako jednoelementowa lista zawierająca słownik. Może chociaż format przekazywanych danych będzie wspólny? W HTMLu nie przekażemy wam danych w najnowszej wersji API dla hydro. Dlaczego? Bo nie.

Niestety, ten brak konsekwencji jest tylko zapowiedzią tego co nas czeka za chwilę.

Dane plikowe

Wszystkie dane historyczne są przekazywane jako pliki csv (właściwie to zip z csv w środku). IMGW podzieliło je, podobnie jak te dostępne przez API, na 3 kategorie:

  1. Dane aktynometryczne.
  2. Dane hydrologiczne.
  3. Dane meteorologiczne.

Poza tym, na stronie znajdziemy jeszcze kilka innych folderów, z biuletynem PSHM, rocznikami oraz, najciekawszy, “test”.

Dane hydrologiczne

Przeanalizujmy to co jest dla mnie najciekawsze, czyli sposób w jaki IMGW udostępnia nam dane hydrologiczne.

Dane hydrologiczne są dostępne w podziale na dobowe, miesięczne oraz połączone półroczne i roczne pliki. Znajdziemy w nich zakres od 1951 roku do 2023. Do 2022 roku pliki są dość jednolite — nazewnictwo zaczyna się od skrótu interwału, np. “codz”, a następnie rok i miesiąc lub zmienna (jeżeli dotyczy). Co z 2023? Z nazwy wyrzucono numer miesiąca, więc misternie napisany w Pythonie kod, trzeba dostosować do tej drobnej, acz istotnej zmiany.

A w środku? Eh, źle się dzieje w państwie duńskim. Festiwal niekonsekwencji, ponieważ niektóre kolumny mają informacje zapisane jako ciągi znaków, czyli coś co Python mógłby zinterpretować jako tekst. Zapisywanie identyfikatora lub roku raczej tego nie wymaga, nie? Inne dane są już dobrych typów, czyli int lub float. A co, jeżeli nie ma obserwacji? Tutaj możemy się spodziewać braku wpisu w kolumnie, wartości 99.9, albo 9999 ewentualnie 99999.999, co oczywiście zostało wyczerpująco opisane w osobnym pliku. Do tego jeszcze dodajmy spacje poprzedzające identyfikatory stacji. Rok 2023 prezentuje się lepiej, ale za to zmieniono separator kolumn z przecinka na średnik. Kolejna pętla “if-elif-else” ląduje w kodzie.

Warto jeszcze wspomnieć o tym, że pliki dzienne i miesięczne zawierają wszystkie 3 mierzone parametry, czyli przepływ, stan wody oraz jej temperaturę. Pliki półroczne i roczne są podzielone na kolejne 3 kategorie, żeby nie łączyć ze sobą wszystkich parametrów. Jeżeli dobrze się im przyjrzycie, to zobaczycie, że w 2023 brakuje jednej kolumny.

Dane meteorologiczne

Jeżeli w danych hydro źle się działo, to tutaj jest obraz nędzy i rozpaczy. Na pierwszy widzimy, że dane dodatkowo podzielono na klimatologiczne, opadowe i synoptyczne. Po wejściu głębiej, okazuje się, że część plików pogrupowano w wielolecia. Konwencja nazewnictwa plików wydaje się być podobna do tej znanej z hydro, ale to tylko pozory. W przypadku plików “zip” wydawałoby się, mamy jasną sytuację. Nazwa zaczyna się od roku, następnie jest… miesiąc? Czasem tak, czasem jest oznaczenie typu danych. To samo oznaczenie może znajdować się równie dobrze na 3. miejscu, ale z tym też bywa różnie, bo może się tam znajdować oznaczanie rodzaju stacji. W danych synoptycznych, “drugie miejsce” jest, wydawałoby się, losową wartość liczbową, która na pewno ma jakieś znacznie, którego ja po prostu jeszcze nie odkryłem.

Niestety, ale skutecznie uniemożliwiło mi to zautomatyzowanie pobierania tych danych. Zresztą, po rozpakowaniu zawartość tych zipów też zmienia sposób nazywania plików. To nam daje 2 osobne funkcje, które złożą nam nazwę pliku w całość.

Zgubiliście się w tym opisie? Bardzo dobrze, bo ja też.

Co robić i jak żyć?

Projekt rozwijam od ponad roku z przerwą, aż tegoroczna powódź w dorzeczu Odry zmotywowała mnie do jego kontynuacji. W tym czasie zacząłem również studia podyplomowe z hydrologii na URK, co dostarcza dodatkowej motywacji do kontynuowania prac.

Pomimo problemów udało mi się rozwiązać większość z nich, choć największym wyzwaniem pozostają dane meteo. Mam nadzieję, że IMGW kiedyś zorganizuje je w bardziej przejrzysty sposób — to byłoby prawdziwym wybawieniem dla wszystkich użytkowników.

Osobną kwestią jest też ich wiarygodność, tzn. na ile są one oczyszczone z błędów i czy nadają się one do wykorzystania w projektach. Z tego co słyszałem to odpowiedź brzmi “nie“, ponieważ “dane są największym skarbem instytutu” jak to rzekomo miał stwierdzić pewien profesor.

De Bever Piotr

Autor bloga, z wykształcenia geodeta, hydrolog, modelarz hydrauliczny i GISowiec

Leave a Reply