Narzędzia i analiza danych
Podstawy dziennikarstwa danych
Cztery etapy pracy z danymi
Dlaczego ta struktura jest uniwersalna
Niezależnie od tematu, skali i narzędzi — każdy projekt data journalism przechodzi przez te same cztery etapy: pozyskiwanie → czyszczenie → analiza → wizualizacja. Różni się czas, różni się głębokość, różnią się narzędzia, ale logika jest zawsze taka sama. Zrozumienie tej struktury jest ważniejsze od znajomości dowolnego konkretnego narzędzia, bo to ona pozwala myśleć systematycznie.
W praktyce proces jest iteracyjny: w trakcie analizy odkrywacie, że trzeba wrócić do czyszczenia; przy wizualizacji okazuje się, że potrzebna jest dodatkowa zmienna, po którą musicie wrócić do pozyskiwania. To nie jest porażka, to jest realna praca z danymi.
Etap 1: pozyskiwanie danych
Najwięcej projektów upada właśnie tu — nie dlatego, że pozyskiwanie jest trudne technicznie, ale dlatego, że dane, których spodziewamy się, często nie istnieją w formie gotowej do analizy, są rozproszone między instytucjami, dostępne tylko w formatach trudnych do obróbki, albo wymagają formalnego wniosku z 14-dniowym oczekiwaniem.
Hierarchia metod (od najłatwiejszej):
- Oficjalne portale statystyczne — GUS/BDL, NBP, Eurostat, Bank Światowy. Metodologicznie rzetelne, regularnie aktualizowane, bezpłatne.
- Portale rządowe i BIP — dane niepublikowane w centralnych bazach, często na poziomie lokalnym.
- API — GUS BDL i NBP udostępniają bezpłatne, dobrze udokumentowane API pozwalające automatycznie pobierać dane.
- Wniosek o informację publiczną — gdy dane istnieją, ale nie są publikowane. 14 dni ustawowego terminu.
- Web scraping — ostateczność. Technicznie dopuszczalny, ale obarczony ryzykiem prawnym i technicznym.
- Własne zbieranie (ankiety, crowdsourcing) — najbardziej pracochłonne, wymaga metodologii.
Zasada: zaczynajcie zawsze od najprostszej metody. Scraping i API to ostateczności, nie punkt startu. Jeśli dane są na dane.gov.pl w CSV, nie piszcie scrapera.
Etap 2: czyszczenie danych
Czyszczenie pochłania 50–80% całego czasu projektu. Ta liczba zawsze wywołuje zaskoczenie — i zawsze okazuje się realistyczna. Dane surowe są niemal zawsze brudne: braki, niespójności, błędy kodowania, nieoczekiwane formaty.
Typowe problemy
- Braki wartości — puste komórki, „NA”, „:“, „…” (GUS używa różnych konwencji w zależności od powodu braku)
- Niespójne nazwy — „Warszawa” / „m. st. Warszawa” / „Warszawa (stolica)“
- Błędy kodowania — „Łódź” jako „ŕódź” (UTF-8 vs Windows-1250)
- Różne formaty dat i jednostek — 2024-01-15 vs 15.01.2024; EUR vs PLN
- Różne definicje tej samej zmiennej w różnych źródłach (np. bezrobocie rejestrowane vs BAEL)
- Scalone komórki i kolorowe formatowanie w Excelu — technicznie utrudniają odczyt
- Zbędne wiersze nagłówkowe i stopki — typowe w plikach rządowych
Pułapka: „Invalid Date — Thu Jan 01 1970 01:00:00”
To symptom, który zobaczycie w OpenRefine, kiedy klikniecie Edit cells → Common transforms → To date na kolumnie, której parser nie umie zinterpretować. „1 stycznia 1970, 01:00 GMT+1” to uniksowy znacznik zero (epoch) — pokazuje się, kiedy funkcja toDate() dostaje pusty ciąg albo format, którego nie rozpoznaje.
Fix: jawna konwersja z formatem. W Transform… wpiszcie wyrażenie GREL:
- Dla dat ISO (“2026-01-01”):
value.toDate("yyyy-MM-dd") - Dla dat polskich z kropkami (“01.01.2026”):
value.toDate("dd.MM.yyyy") - Dla mieszanych formatów:
value.toDate("yyyy-MM-dd", "dd.MM.yyyy", "dd/MM/yyyy")
Zasada diagnostyczna: jeśli wszystkie wiersze pokazują 1970, problem jest w formacie; jeśli niektóre — problem jest w danych (puste komórki, spacje na końcu, przypadkowy wiersz sumaryczny w środku danych).
Dwie żelazne zasady
- Nigdy nie nadpisujcie surowych danych. Pracujcie na kopii, oryginał w niezmienionej postaci. Dzięki temu, gdy odkryjecie błąd w połowie czyszczenia, nie musicie pobierać danych od nowa.
- Dokumentujcie każdą decyzję czyszczenia. Inaczej za miesiąc nie będziecie pamiętać, dlaczego usunęliście te 47 wierszy.
Minimalna dokumentacja czyszczenia
- Źródło — pełna nazwa, URL, data pobrania (bazy są aktualizowane; ta sama zmienna może mieć za rok inne wartości)
- Zakres — jakie lata, jednostki terytorialne, zmienne i dlaczego
- Usunięte lub zmodyfikowane kolumny / obserwacje
- Napotkane problemy i sposób rozwiązania — np. „brak danych dla Mazowieckiego w 2021 — obserwacja pominięta”, „wartości > 100% w kolumnie ‘odsetek’ uznano za błędy wpisywania, zastąpiono NA”
OpenRefine automatycznie loguje wszystkie operacje jako plik JSON, który można wyeksportować i dołączyć do dokumentacji projektu — najłatwiejszy sposób, żeby spełnić zasadę transparentności bez ręcznego spisywania kroków.
The Guardian i The New York Times publikują swoje metodologie jako osobny dokument towarzyszący artykułowi. To nie jest luksus — to standard.
Etap 3: analiza danych
Zacznijcie zawsze od podstaw
Nawet jeśli docelowa analiza ma być zaawansowana, pierwsze pytania są banalne:
- Ile obserwacji? (wierszy)
- Jaki zakres wartości każdej zmiennej? (min, max)
- Średnia i mediana? (jeśli bardzo się różnią — jest wartość odstająca lub skośny rozkład)
- Skośność rozkładu — decyduje o wyborze skali na wykresie (patrz niżej)
- Ile braków i gdzie?
- Czy są wartości ewidentnie błędne? (wiek 999, pensja ujemna, procent > 100)
To właśnie tu wyłapuje się większość błędów w danych. Trywialne technicznie, kosztowne przy pominięciu.
Mediana vs średnia — pierwszy sygnał o rozkładzie
Jeśli średnia jest wyraźnie wyższa od mediany, macie prawoskośny rozkład — kilka dużych wartości ciągnie średnią w górę. W dziennikarstwie:
- „Typowy” opisany medianą, nie średnią
- Wykresy dla prawoskośnych zmiennych często potrzebują skali logarytmicznej albo podziału kwantylowego, a nie liniowego
Skośność liczbowa (Skewness w jamovi):
- ≈ 0 → rozkład symetryczny
- > 1 → wyraźnie prawoskośny
- < −1 → wyraźnie lewoskośny
Dopiero potem
- Porównania między grupami / regionami / okresami
- Trendy w czasie
- Korelacje między zmiennymi
- Rankingi
Dwie zasady interpretacji
- Korelacja to nie przyczynowość. Korelacja 0,7 jest dopiero punktem wyjścia, nie punktem dojścia. Zapytajcie: czy to znaczy, że A powoduje B? Czy może C powoduje oba? Czy próbka nie jest zbyt mała, żeby twierdzić cokolwiek?
- Pytajcie ekspertów: „czy ta liczba ma sens?“ Epidemiolog, ekonomista, prawnik wykryje anomalię niewidoczną dla laika w 10 minut.
Typowe błędy interpretacyjne
- Mylenie różnic bezwzględnych i względnych. „+100 przypadków” znaczy co innego w gminie z 1000 mieszkańców a w mieście z 5 milionami. Używajcie wskaźników na 100 tys. mieszkańców.
- Ignorowanie zmian metodologii. Nagły „skok” w danych może wynikać ze zmiany definicji, a nie zmiany zjawiska. Zmiana definicji bezrobocia potrafi obniżyć wskaźnik o kilka punktów procentowych bez żadnej realnej poprawy na rynku pracy.
- Pomijanie kontekstu historycznego. COVID, reformy, akcesja UE, zmiany granic administracyjnych — wydarzenia, które zaburzają trendy i wymagają komentarza.
Etap 4: wizualizacja
Dobór typu wykresu do pytania
| Pytanie | Pierwszy wybór | Gdy zawodzi |
|---|---|---|
| Jak coś zmieniało się w czasie? | Wykres liniowy | Slope chart, obszarowy |
| Jak porównać kilka kategorii? | Wykres słupkowy (poziomy) | Dot plot przy wielu kategoriach |
| Dwie wartości na kategorię? | Split bars (dwa słupki obok siebie) | Slope chart |
| Strukturę całości? | Słupkowy skumulowany | Treemap, waflowy |
| Jak zjawisko rozkłada się w przestrzeni? | Mapa choropleth | Kartogram |
| Rozkład zmiennej? | Histogram | Wykres gęstości |
| Związek między zmiennymi? | Scatter plot | Wykres bąbelkowy (3+ zmienne) |
Split bars, stacked bars, diverging bars — kiedy co
Dla pytań typu „jak wyglądają dwie wartości per kategoria?“ (np. przyjazd vs wyjazd, kobiety vs mężczyźni) macie trzy opcje:
- Split bars (dwa słupki obok siebie) — najbardziej czytelne bezpośrednie porównanie. Domyślny wybór.
- Stacked bars (jeden słupek z dwoma segmentami) — dobry, kiedy suma też jest informacją, a nie tylko sam podział. Trudniejszy do porównania między kategoriami.
- Diverging bars (wartości dodatnie w prawo, ujemne w lewo) — tylko kiedy sam znak (netto przyjazd / netto wyjazd) jest istotą historii. Datawrapper sam ostrzega przed nadużywaniem — diverging zgubi skalę, jeśli saldo jest małe względem gross flows.
Zasady dobrej wizualizacji
- Tytuł komunikuje wniosek, nie opisuje zmiennej. „Odsetek kobiet z badaniem cytologicznym, 2023, województwa” to opis. „Różnica między województwami sięga 40 punktów procentowych” to komunikat.
- Oś Y od zera dla wykresów słupkowych. Odstępstwo = małe różnice wyglądają dramatycznie.
- Skala log albo kwantyle dla danych silnie prawoskośnych. Zawsze podpisana w notce wykresu.
- Kolory intuicyjne, spójne, dostępne dla daltonistów (palety ColorBrewer).
- Źródło pod wykresem — bez źródła wykres nie jest dziennikarstwem.
- Minimalizm informacyjny — siatki, cienie, 3D, nadmiar etykiet: usuwać.
- Sprawdzajcie podgląd mobilny — 60 %+ polskich czytelników jest na telefonie.
Wizualizacja to argument wizualny, nie ilustracja. Dobry wykres prezentuje tezę uczciwie, czytelnie i możliwie do zweryfikowania. Manipulacja skalą lub selektywny dobór to nieuczciwość taka sama, jak w tekście.
Narzędzia dla każdego etapu
Zestaw dla początkujących (bez kodowania)
Pełny, wystarczający do realizacji projektu zaliczeniowego i większości codziennej pracy redakcyjnej:
| Etap | Narzędzie | Do czego |
|---|---|---|
| Pozyskiwanie | dane.gov.pl, GUS BDL | Punkt startowy dla polskich danych publicznych |
| Google Sheets (IMPORTHTML, IMPORTDATA) | Pobieranie prostych tabel ze stron WWW | |
| Tabula, Camelot | Ekstrakcja tabel z PDF (np. dane z BIP) | |
| Browser Developer Tools (F12) | Podejrzeć, jak strona pobiera dane z API | |
| Czyszczenie | OpenRefine | Standard do czyszczenia bez kodu (do ~50 tys. wierszy) |
| Google Sheets / LibreOffice Calc | Proste operacje, filtrowanie, pivot tables | |
| Analiza | jamovi | Statystyki opisowe, testy, regresje bez kodu — standard dla projektów kursowych |
| Google Sheets (pivot tables) | Proste agregacje, kiedy zestaw jest mały | |
| JASP | Alternatywa dla jamovi, z naciskiem na statystykę bayesowską | |
| Wizualizacja | Datawrapper | Standard w redakcjach |
| Flourish | Interaktywne wykresy, animowane mapy, scrollytelling | |
| RAWGraphs | 30+ typów wykresów, w tym niestandardowe |
Nie ma żadnej potrzeby opanowywania Pythona czy R, żeby tworzyć wartościowe dziennikarstwo danych. Narzędzia graficzne mają ograniczenia (trudniej automatyzować powtarzalne operacje, trudniej z bardzo dużymi zbiorami) — ale dla projektów o skali seminaryjnej są w pełni adekwatne.
Szczegółowe poradniki do jamovi i Datawrapper znajdziecie w handoutach towarzyszących:
Zestaw dla zaawansowanych (kodowanie)
Jeśli ktoś w grupie ma kompetencje lub chce je rozwinąć:
| Etap | Python | R |
|---|---|---|
| Pozyskiwanie | requests (API), BeautifulSoup (HTML), Scrapy (framework scrapingowy) |
httr2, rvest |
| Czyszczenie | pandas |
dplyr, tidyr (tidyverse) |
| Analiza | pandas, statsmodels, scikit-learn |
stats (base), tidyverse |
| Wizualizacja | matplotlib, seaborn, plotly |
ggplot2, plotly |
| Publikacja | Jupyter Notebooks | RStudio / Positron + Quarto |
QGIS — bezpłatny, open-source GIS używany przez National Geographic, WHO i wiele redakcji do profesjonalnych map.
Quarto — pozwala tworzyć artykuły, raporty i strony internetowe bezpośrednio z kodu R lub Python, łącząc tekst, kod i wyniki w jednym dokumencie. GitHub Pages umożliwia hostowanie bezpłatnie.
Dlaczego open source
- Koszty: Python, R, QGIS, OpenRefine, jamovi, Datawrapper (podstawowa wersja) — wszystkie bezpłatne. Cała redakcja może być wyposażona bez opłat licencyjnych.
- Transparentność: kod źródłowy publicznie dostępny. Można sprawdzić, jak działa algorytm. To ważne, gdy narzędzie tworzy treść, która ma być wiarygodna.
- Reprodukowalność: analiza w Pythonie / R może być uruchomiona przez każdego, kto ma dane i środowisko. Standard, którego The Guardian i ProPublica używają publikując kod razem z artykułami.
- Społeczność: rozbudowana dokumentacja, tysiące tutoriali, aktywne fora (StackOverflow, Cross Validated).
- Niezależność: zmiana polityki cenowej jednego dostawcy nie paraliżuje całej redakcji.
Pięć pułapek dziennikarstwa danych
Każda z tych pięciu pułapek ma ten sam kształt: dane są poprawne, ale historia wokół nich wprowadza w błąd. To nie jest problem techniczny — to kwestia uczciwości narracji.
Pułapka 1: korelacja jako przyczynowość
Co to znaczy: dwie zmienne mogą rosnąć lub spadać razem (korelacja), nie mając ze sobą żadnego związku przyczynowego. Klasyka: korelacja między spożyciem czekolady per capita a liczbą laureatów Nobla — oba wynikają z zamożności, nie z „mądrości” czekolady.
Popularne formy w dziennikarstwie:
- „Wzrost A zbiegł się ze wzrostem B” — technicznie prawda, ale sugeruje przyczynowość
- „Od kiedy wprowadzono X, Y wzrósł” — post hoc ergo propter hoc
- Pominięcie zmiennej ukrytej (confounder) — trzeciej, która wpływa na obie
- Odwrotna przyczynowość — może to B powoduje A, nie odwrotnie
Czerwone flagi w nagłówku: „powoduje”, „prowadzi do”, „wywołuje” bez badania eksperymentalnego.
Jak pisać uczciwie: „wiąże się z”, „idzie w parze z”, „towarzyszy” — i zapytajcie eksperta o mechanizm.
Pułapka 2: cherry-picking
Co to znaczy: selektywny dobór danych potwierdzających z góry postawioną tezę.
Popularne formy:
- Manipulacja punktem startowym — „od 2020 roku…“ dobrane, żeby wyglądało spektakularnie
- Wybór tylko korzystnych lat, regionów, grup
- Pominięcie wartości odstających bez uzasadnienia (czasem słusznie — ale wtedy trzeba to powiedzieć)
- Ukrycie przeciwnych dowodów — „znaleźliśmy trzy studia potwierdzające”, nie wspominając o pięciu sprzecznych
Test uczciwości: czy mogę pokazać te same dane w pełnym zakresie czasowym i nadal mam tę samą historię? Jeśli nie — to nie mam historii.
Pułapka 3: wykres, który oszukuje
Co to znaczy: wykres manipulujący percepcją, nawet jeśli liczby są prawdziwe. To najczęstsza pułapka, bo popełnia się ją nieświadomie — Excel, Datawrapper i inne narzędzia same proponują ustawienia, które wyolbrzymiają różnice.
Popularne formy:
- Oś Y nie zaczyna od zera — małe różnice wyglądają dramatycznie
- Skala logarytmiczna bez wyraźnego oznaczenia
- Niekonsekwentne osie między wykresami w jednym artykule
- Wykres kołowy z 8+ kategoriami — kąty nierozróżnialne
- Trójwymiarowe wykresy słupkowe — zniekształcają proporcje
- Złe użycie kolorów — czerwono-zielone skale nieczytelne dla ok. 8% mężczyzn
- Mylące agregaty w mapach — duże obszary dominują wizualnie mimo małych populacji
Regułka: domyślnie oś od zera; wyjątek (np. skala log dla danych silnie prawoskośnych) wymaga podpisu w nocie wykresu.
Pułapka 4: agregacja ukrywa różnice
Średnia krajowa to wygodna wymówka, żeby nie patrzeć dalej.
- Średnia kraj ≠ średnia region ≠ średnia miasto — każdy poziom opowiada inną historię
- Liczba bezwzględna czy wskaźnik? Warszawa ma najwięcej przestępstw bo ma najwięcej ludzi — na 100 tys. mieszkańców wygląda przeciętnie
- Tempo zmian: „wzrost o 100%“ z 2 przypadków do 4 to nie to samo, co wzrost o 50% z 2 mln do 3 mln
- Zbyt małe próbki — duże błędy statystyczne. „Mazowieckie na 1. miejscu” oparte na 12 obserwacjach to plotka, nie analiza
Praktyczna reguła dla waszych projektów: jeśli jednostką jest kraj/region/miasto, zawsze sprawdźcie wskaźnik per capita obok liczby bezwzględnej. Wybór między nimi to decyzja redakcyjna — ale musicie znać oba.
Pułapka 5: oficjalne ≠ prawdziwe
Dane publiczne są zazwyczaj wiarygodne — ale „oficjalne” nie znaczy „bezbłędne” ani „neutralne”.
- Zmiany metodologii wyglądają jak zmiany zjawiska: nowa definicja bezrobocia = „nagły spadek”, który wynika z arkusza, nie z rynku pracy
- Dane rejestrują to, co zostało zmierzone: ciemna liczba w statystykach przestępczości, nieraportowane przypadki przemocy domowej, szara strefa w PKB. Brak danych o grupie ≠ brak problemu w tej grupie.
- Dane są nieaktualne: GUS publikuje z opóźnieniem kilku miesięcy do lat — sprawdzajcie datę odniesienia, nie datę publikacji
- Różne instytucje mierzą to samo inaczej: inflacja GUS vs inflacja NBP vs koszyk Eurostatu — trzy różne liczby, wszystkie poprawne
Co robicie z tym w praktyce: czytacie notę metodologiczną (zawsze jest), porównujecie z drugim źródłem, zapisujecie datę odniesienia w artykule.
Przykład pipeline’u: od dane.gov.pl do opublikowanego wykresu
Pełny przykład, który omawiamy na wykładzie. Używamy go jako modelu workflow, nie treści — wasz temat będzie wymagał własnych decyzji.
Dane
Źródło: dane.gov.pl, dataset 3595 — „Bazy ruchu granicznego”, dostawca: Komenda Główna Straży Granicznej. Licencja CC0, aktualizacja miesięczna.
Konkretny plik: „Baza ruchu granicznego STYCZEŃ–MARZEC 2026” — CSV ok. 2,3 MB, 18 190 wierszy.
Struktura: jeden wiersz = jedno przejście graniczne × dzień × kategoria podróżnych × kierunek. 24 kolumny: Placówka SG, Przejście, Rodzaj przejścia, Odcinek, Oddział SG, Data, Kto (kod), Kierunek, szczegóły odprawy, Razem.
Pytanie badawcze: Jak zmieniał się ruch na poszczególnych odcinkach granicy zewnętrznej Polski w Q1 2026 — i gdzie przyjazdów cudzoziemców jest więcej niż wyjazdów?
Etap 1: pozyskanie
- Wejście na stronę datasetu 3595, zasób „STYCZEŃ–MARZEC 2026”
- Sprawdzenie metadanych: data aktualizacji, licencja CC0, opis przygotowany przez WIiS BAS KGSG
- Pobranie CSV (nie XLSX — CSV jest prostszy i otwiera się w OpenRefine bez konwersji), zapisanie pod nazwą
raw_ruch_graniczny_2026_Q1.csv - Surowy plik zostaje nietknięty — wszystkie modyfikacje robimy na kopii
Etap 2: czyszczenie w OpenRefine
Kluczowe operacje:
- Text facet na kolumnie Odcinek → widać 7 odcinków (5 zewnętrznych + TPKG z Niemcami i Litwą — nie 5, jak można by założyć)
- Text facet na kolumnie Kto → odkrywamy kody (C, RP) — dodajemy kolumnę Kto_pelne z czytelnymi opisami
- Konwersja Data na typ date przez explicite Transform z
value.toDate("yyyy-MM-dd")(zobacz wyżej pułapka Invalid Date) - Numeric facet na Razem → wyłapujemy wartości zerowe i ekstremalne
- Export → CSV pod nazwą
clean-ruch-graniczny-2026-Q1.csv
Co odkrywamy podczas czyszczenia:
- Wiele kolumn jest praktycznie pusta dla danego typu przejścia (Załogi statków rybackich tylko na granicach morskich). To nie są braki — to znaczenie „nie dotyczy”.
- Kody Kto wymagają zajrzenia do dokumentacji Straży Granicznej, zanim użyjemy ich w publikacji.
- Granice wewnętrzne (TPKG) występują obok zewnętrznych — decydujemy, czy je zostawiamy, czy filtrujemy.
Historia operacji OpenRefine (plik JSON) jest eksportowana i dołączona do dokumentacji projektu.
Etap 3: analiza w jamovi
Wczytujemy clean-ruch-graniczny-2026-Q1.csv, ustawiamy typy pomiaru (Odcinek, Kierunek, Kto_pelne → Nominal; Razem → Continuous).
Statystyki, które zawsze liczymy:
- Frequencies → N Outcomes dla Odcinek, Rodzaj przejścia, Kierunek, Kto_pelne → ile wierszy na kategorię
- Descriptives dla Razem z Split by → Odcinek → średnia, mediana, min/max dla każdej granicy
- Descriptives → Plots → histogram + boxplot Razem per odcinek
- Contingency Tables z Odcinek × Kierunek, pole Counts na Razem → krzyżowa tabela sum
Co odkrywamy:
- Rozkład Razem silnie prawoskośny (skewness 3,26): kilka dużych przejść (Warszawa-Okęcie, Medyka) dominuje nad resztą
- Asymetria kierunku: na granicach wewnętrznych (DE, LT) wyjazd ≈ 0 — TPKG rejestruje tylko wjazdy. Bez tego rozróżnienia „saldo migracji” wyszłoby absurdalnie
- Saldo cudzoziemców przyjazd − wyjazd na granicach zewnętrznych: minus 21 tys. na Ukrainie, plus 17 tys. na Białorusi, plus 8 tys. na granicy z Federacją Rosyjską. Każda z tych trzech liczb to potencjalny artykuł.
Z analizy wyszły trzy różne pytania wizualizacyjne, nie jedno. Dla demonstracji bierzemy pytanie 2 (saldo cudzoziemców).
Etap 4: wizualizacja w Datawrapper
Wybór typu: split bars (dwa oddzielne słupki per odcinek: przyjazd i wyjazd, obok siebie). Nie diverging (zgubiłby skalę ruchu, bo saldo jest ~1 % gross flows); nie stacked (wymagałby mentalnej arytmetyki).
Pipeline:
- Przygotowanie: w jamovi eksportujemy tabelę kontyngencji cudzoziemców → CSV z 5 wierszami (granice zewnętrzne) i kolumnami Odcinek, przyjazd, wyjazd, saldo
- Upload do Datawrapper
- Check & describe: przyjazd, wyjazd jako liczby; Odcinek jako etykieta
- Visualize → Split bars: dwa słupki per odcinek, paleta daltonizm-friendly, sortowanie malejąco po sumie, etykiety bezpośrednio na słupkach
- Annotate: tytuł komunikujący wniosek („Ruch cudzoziemców w obie strony, ale na Ukrainie saldo lekko ujemne”), źródło („Straż Graniczna, dane.gov.pl, dataset 3595”), nota metodologiczna („granice wewnętrzne DE/LT wyłączone — TPKG rejestruje tylko wjazdy”)
- Publish & embed: link + kod embed
Uwaga pedagogiczna
Zauważcie, co ten pipeline robi:
- Surowe dane zostały zachowane w niezmienionej postaci, czyszczenie na kopii
- Każda decyzja czyszczenia udokumentowana przez historię operacji OpenRefine
- Analiza zaczyna się od eksploracji, nie od efektownej metody
- Ekstremalna skośność Razem zmusza do użycia skali log lub kwantylów w późniejszych wykresach — to decyzja wymuszona przez dane, nie estetyka
- Wybór split bars wynika z analizy, a nie pierwotnego pomysłu
- Wykres nie jest ozdobą, tylko argumentem: ruch głównie na Ukrainie, saldo ujemne
- Ograniczenia (TPKG na DE/LT) komunikowane otwarcie — nie ukrywane
Tego poziomu konkretności szukamy przy waszych projektach.
AI w warsztacie dziennikarza danych
Co AI potrafi (i robi dobrze)
- Pisanie i debugowanie kodu — Python, R, SQL. Opisujecie zadanie, AI proponuje kod, poprawia gdy nie działa.
- Konwersja formatów — PDF → CSV, HTML → tabela, kiedy standardowe narzędzia zawodzą.
- Wykrywanie niespójności — kolumna z setkami wartości, gdzie „Mazowieckie”, „mazowieckie” i „Mazowiecke” to prawdopodobnie ta sama kategoria.
- Szybkie szkice wizualizacji — prosicie o wykres w ggplot2 / matplotlib, dostajecie działający kod.
- Streszczenia dokumentów — długie metodologie, raporty, PDF-y, które musicie zrozumieć.
Czego AI nie robi
- Nie weryfikuje wyników — to wasza rola. AI może wygenerować błędny kod z przekonaniem równym poprawnemu.
- Nie rozumie kontekstu dziedzinowego — nie wie, że „NA” w medycynie może oznaczać „not applicable” lub pierwiastek sodu, że „0” w statystyce przestępczości może oznaczać brak rejestracji, nie brak zjawiska.
- Może propagować błędy na dużą skalę — systematyczny błąd powielony przez tysiące rekordów jest trudny do wychwycenia bez ręcznej weryfikacji próbki.
- Nie pamięta kontekstu metodologicznego — jeśli GUS zmienił definicję w 2019, AI może bezrefleksyjnie porównać dane sprzed i po.
AI + RODO
- Nigdy nie wklejajcie danych osobowych do ChatGPT / Claude / Gemini bez analizy prawnej. Zewnętrzne API mogą naruszać RODO.
- Alternatywy dla wrażliwych danych:
- Modele lokalne (Ollama, LM Studio) — działają offline na waszym komputerze
- Enterprise edition z gwarancjami (Microsoft Copilot Enterprise, ChatGPT Enterprise) — niektóre redakcje je mają
- Anonimizujcie dane przed wysłaniem, jeśli to tylko możliwe
Zasada ogólna
AI przyspiesza pracę, ale nie zastępuje krytycznego myślenia. Każdy wygenerowany kod wymaga zrozumienia. Każda wygenerowana analiza wymaga weryfikacji. Każda wygenerowana wizualizacja wymaga sprawdzenia, czy mówi prawdę.
Zasada praktyczna: używajcie AI jak bardzo zdolnego, ale świeżego asystenta, który nie zna dziedziny. Oczekujcie kodu, nie decyzji.
Dalsza lektura
Wizualizacja
- Cole Nussbaumer Knaflic, Storytelling with Data — wizualizacja jako narracja, z przykładami przed/po
- Alberto Cairo, The Truthful Art — jak nie wprowadzać czytelnika w błąd
- Datawrapper Academy — academy.datawrapper.de
Dane i metodologia
- Philip Meyer, Precision Journalism — fundament teoretyczny gatunku, wciąż aktualny
- Data Journalism Handbook — datajournalism.com, darmowy online
- Dane.gov.pl — dane.gov.pl, polski centralny katalog otwartych danych
Narzędzia
- OpenRefine, openrefine.org — oficjalne tutoriale
- jamovi, jamovi.org — dokumentacja i Learning Statistics with jamovi (darmowa)
- Quarto, quarto.org — dokumentacja i przykłady
- QGIS, qgis.org — w tym kursy QGIS Academy
Redakcje do śledzenia
- ProPublica — propublica.org; publikują dane i kod
- The New York Times — The Upshot — nytimes.com/section/upshot
- The Guardian — Datablog — theguardian.com/data
- FiveThirtyEight — fivethirtyeight.com
- OKO.press (Polska) — regularne analizy oparte na danych publicznych