Tym razem pod lupę trafia Rejestr Cen Nieruchomości, który bez opłat jest dostępny od 13 lutego tego roku. W pierwszej części pozwolę sobie na zupełnie subiektywną ocenę przydatności RCN dla pracy rzeczoznawcy majątkowego. W częściach następnych już zupełnie obiektywnie pokażę, jak możemy te dane pozyskać oraz analizować. Oczywiście głównie skupimy się na QGIS, ale pokażę też alternatywne opcje.
Iluzja rewolucji, czyli dla kogo tak naprawdę jest RCN?
Sceptycyzm wobec RCN towarzyszył mi od początku — pisałem o tym we wpisie “Gdzie dane spotykają przestrzeń: QGIS i bazy danych w analizie rynku nieruchomości”.
Od tamtej pory nic się nie zmieniło — a przynajmniej nie na lepsze. Problemów jest więcej, ale te pojawiają się najczęściej:
- Częsty brak warunków zawarcia transakcji – bez tej informacji nie można ocenić, czy transakcja ma charakter rynkowy,
- Brak numeru księgi wieczystej – uniemożliwia weryfikację stanu prawnego nieruchomości,
- W przypadku rynku pierwotnego brak informacji o dacie zawarcia umowy pierwotnej (czyli dniu faktycznego ustalenia ceny, a ta może być dużo wcześniejsza niż data przeniesienia własności) zniekształca obraz rynku deweloperskiego.
- Multiplikacja transakcji — gdy nieruchomość składa się z kilku działek ewidencyjnych, wszystkie pojawiają się w bazie, sztucznie zwielokrotniając liczbę pozornie odrębnych transakcji i utrudniając wyciąganie właściwych wniosków.
Zresztą ta multiplikacja wpisów w RCN nie dotyczy tylko działek. Nawet wpis sprzedaży nieruchomości lokalowej wiąże się z równoczesnym wpisem informacji o budynku/budynkach oraz działce/działkach, co znacząco zwiększa szum informacyjny w warstwie działek.
Do tego dochodzą jeszcze incydentalne „kwiatki", o których donoszą zaprzyjaźnieni rzeczoznawcy porównujący RCN z profesjonalnymi bazami: ceny w euro — bez przeliczenia, bez oznaczenia waluty, wpisanie powierzchni sprzedawanej działki wraz z powierzchnią działki drogowej (w której zbywany był tylko udział), czy data wpisu do rejestru zamiast daty samej transakcji. Strukturalne wady to jedno — ale takie niespodzianki to już zupełnie inna kategoria.
Nie należy zapominać, że wpisy do RCN są dokonywane przez pracowników administracji publicznej, którzy z natury swojej roli nie muszą posiadać wiedzy o specyfice rynku nieruchomości ani o potrzebach rzeczoznawców majątkowych. Nakłada się na to ograniczony schemat danych, jaki przewiduje sam system RCN. Skutkuje to tym, że nawet przy najlepszej woli po stronie osób wprowadzających – część istotnych informacji zawartych w akcie notarialnym nie ma gdzie trafić. Efektem jest baza, która z założenia nie jest i nie może być kompletna z punktu widzenia prawidłowej wyceny nieruchomości.
Subiektywne odczucia praktyka to jedno, ale twarde dane mówią same za siebie. Listopadowy raport GUGiK z 2025 r. rzuca światło na realną jakość bazy RCN – wyniki kontroli, dostępne pod tym linkiem, są dla rejestru mało łaskawe: “Kontrola Bazy RCN”
Transparentność rynku dla przeciętnego obywatela — tak promowano zniesienie opłat za RCN. Rzeczywistość wygląda jednak nieco inaczej. Moim zdaniem głównym beneficjentem tej zmiany są podmioty tworzące i udostępniające komercyjnie bazy danych np. bankom czy rzeczoznawcom majątkowym, lub tworzące produkty wycenopodobne (AVM — Automated Valuation Model). Wcześniej podmioty te musiały płacić niemałe pieniądze za dostęp do danych RCN. Potencjalny, nieprofesjonalny uczestnik rynku nieruchomości o aktualnych poziomach cenowych dowie się więcej z portali ogłoszeniowych (gdzie dodatkowo ma zdjęcia). Sam raczej nie przeprowadzi na udostępnionych danych odpowiedniej analizy rynku (bo nawet profesjonaliści mają z tym problem — nie dlatego że brakuje im umiejętności ale ze względu na ułomność samego rozwiązania). Może natomiast dowiedzieć się, za ile deweloper sprzedał dwa miesiące temu mieszkanie (którego cena była ustalona dwa lata wcześniej) i frustrować się, dlaczego jemu nikt nie chce za tyle sprzedać. Jest jednak wartość dodana: będzie mógł w końcu zaspokoić swoją ciekawość i dowiedzieć się, za ile kupił mieszkanie jego sąsiad. Część rzeczoznawców (tych, którzy głównie pracowali na danych RCN) też się pewnie cieszy. Pozostali, którzy pracowali na aktach notarialnych i profesjonalnych/branżowych bazach danych (tworzonych na podstawie aktów notarialnych), cieszą się już mniej, bo widzą zagrożenia z tym związane. Rzeczoznawcom, którzy rozważają rezygnację z profesjonalnych baz danych na rzecz RCN, zalecam bardzo dogłębne przeanalizowanie, czy łatwiejszy dostęp do danych — ale danych gorszych — jest warty narażania się na zwiększone ryzyko stania się podmiotem postępowania z tytułu odpowiedzialności zawodowej. Tym bardziej, że sama PFRM jednoznacznie wskazuje, iż RCN stanowi wyłącznie wstępne źródło informacji, niewystarczające do rzetelnej wyceny.
Oczywiście dostrzegam też pewną przydatność RCN w pracy rzeczoznawcy. Dane te pozwalają na szybkie sprawdzenie, czy w interesującej nas okolicy występowały transakcje; możemy zweryfikować kompletność profesjonalnych baz danych (i ewentualnie potwierdzić poprawność wpisów). W przypadku kiedy działka po dacie aktu notarialnego uległa podziałowi lub zmianie numeru, to w RCN powinniśmy co do zasady znaleźć oryginalną geometrię działki, dzięki której z łatwością ustalimy jej lokalizację (i aktualny numer), nawet jeżeli normalne wyszukiwanie w Geoportalu Krajowym lub odpowiednim powiatowym nie zwraca żadnych wyników.
Rejestr Cen Nieruchomości - wyciskanie wartości z trudnego materiału
Jeśli pomimo opisanych ułomności zdecydujesz się na pracę z danymi RCN — sprawdźmy, jakie mamy opcje analityczne wykraczające poza zwykłe przeglądanie transakcji.
Mapy gęstości RCN
Jednym z nowszych narzędzi, które udostępnił Geoportal Krajowy, jest „mapa gęstości RCN". Narzędzie to umożliwia uzyskanie informacji o cenach średnich lub ilościach transakcji na siatce heksagonalnej o gęstości ~16 km² lub ~1 km². Więcej o tej usłudze można poczytać na stronie aktualności Geoportalu. O samej koncepcji użycia siatki heksagonalnej do tworzenia mapy cen pisałem w artykule dla ŚSRM, który można pobrać 👉[tutaj]
Z narzędzia „mapa gęstości" możemy skorzystać także bezpośrednio w QGIS po podłączeniu usługi WMS.

Analiza cen nieruchomości
O ile poprzednia usługa umożliwiała tylko przeglądanie danych (bez ich pobrania), to za pomocą narzędzia „Analiza cen nieruchomości" możemy filtrować, analizować i pobierać dane w zadanym promieniu odległości od wskazanego punktu. Jak na narzędzie przeglądarkowe radzi sobie zaskakująco dobrze (nawet na dużej ilości transakcji), a analityki w postaci trendu czy histogramu są przydatnymi dodatkami. Całość, w mojej opinii, ma bardziej przemyślany interfejs i działa zdecydowanie sprawniej niż niektóre płatne alternatywy (np. portal z wysokooktanową nazwą), bez sztucznych ograniczeń w ilości eksportowanych danych. Jako analityk uważam, że im więcej danych, tym lepiej, a wszelkie rozwiązania, które na starcie obcinają ilość dostępnych transakcji (i to w płatnej aplikacji), są u mnie automatycznie skreślane.
Rzeczą, którą należy jednak skrytykować w narzędziu „Analiza cen nieruchomości", jest fakt, że dane przestrzenne transakcji nie są eksportowane do Excela. A wystarczyłoby dodać trzy kolumny: jedną na opis geometrii w formacie WKT i dwie na współrzędne centroidu nieruchomości. Niestety eksport jest pozbawiony kontekstu przestrzennego, co czyni go bezużytecznym do pracy w zewnętrznym środowisku GIS (lub wymaga dodatkowych nakładów czasowych na ponowną georeferencję).
Wtyczka POBIERZ DANE GUGIK
Wtyczka autorstwa Łukasza Świątka, udostępniona przez Główny Urząd Geodezji i Kartografii, jest przydatna, kiedy potrzebujemy pobrać dane RCN z określonego obszaru bezpośrednio do QGIS. Dodatkowym bonusem jest automatyczna stylizacja wczytanej warstwy. To jedna z najszybszych metod, żeby zorientować się, co się sprzedało w najbliższym otoczeniu interesującej nas nieruchomości.
GML i Geopaczki
Podejściem, które daje nam największe możliwości analizy, jest pobranie danych RCN w postaci plików GML lub Geopaczki (GeoPackage). Pliki GML dla dużej ilości powiatów możemy pobrać z dedykowanej strony Geoforum, jednak aktualnie pliki te w większości nie są na bieżąco aktualizowane. Najpewniejszym źródłem danych w tym formacie są właściwe ośrodki dokumentacji geodezyjnej i kartograficznej. Ten sposób zamawiania wymaga (ciągle jeszcze) złożenia wniosku (czyli nie jest to natychmiastowe pobranie) i może występować ograniczenie jednoczesnej ilości rekordów. Kilka dni temu zamawiałem w ten sposób RCN z ośrodka w Chrzanowie. Wniosek pozwalał na zamówienie jednocześnie do 1000 transakcji oraz wymagał dnia roboczego na przeprocesowanie. Następnym problemem z plikami GML jest konieczność przetworzenia ich do odpowiedniej struktury bazy danych. W QGIS możemy co prawda otworzyć nieprzetworzone pliki GML, jednak ich struktura zostanie rozbita, a poszczególne tabele (transakcje, działki, lokale, zabudowane, dokumenty) pozostaną bez powiązania pomiędzy sobą. Da się to oczywiście obejść odpowiednim skryptem Pythona, ale wykracza to poza zakres tego wpisu.
Dużo prostsze jest pobranie danych RCN w postaci Geopaczki (GeoPackage) bezpośrednio ze strony Geoportalu Krajowego dla powiatu, województwa albo nawet kraju (jednak wtedy są to dane w formacie GeoParquet — także czytanym przez QGIS). Pamiętać należy, że nawet w przypadku województwa (nie mówiąc już o całym kraju) będziemy mieli do czynienia z milionami rekordów, co może wpłynąć na obniżenie komfortu pracy w programie.
Użycie danych w postaci Geopaczki także wymaga odpowiedniego przetworzenia danych, ale jest to wykonalne narzędziami dostępnymi bezpośrednio w QGIS i nie wymaga pisania skryptu Pythona.
RCN pamięta — nawet jeśli Geoportal zapomniał
Wyobraź sobie sytuację: szukasz działki z aktu notarialnego, ale w Geoportalu nie ma śladu po tym numerze. Działka mogła ulec podziałowi lub zmianie numeracji. W takim przypadku RCN może okazać się nieoceniony — jak już wcześniej wspomniałem, powinien zawierać oryginalną geometrię działki z daty aktu notarialnego, co pozwala jednoznacznie ustalić jej lokalizację i odnaleźć aktualne numery ewidencyjne.
Geopaczka RCN w QGIS — praktyczny poradnik krok po kroku
Mamy już pobraną bazę RCN w postaci Geopaczki. Na przykładzie warstwy „działki" pokażę, jak ją przygotować, by możliwe było przeprowadzenie na niej analizy rynku.
UWAGANiestety rejestr rejestrowi nierówny. W zależności od ośrodka dokumentacji możemy napotkać kilka problemów. 1) Aktualizacja plików trafiających do Geoportalu może mieć różną częstotliwość (przekonamy się w dłuższej perspektywie). 2) Problem z formatem daty. Jeżeli widzimy daty transakcji w postaci 11.10.2011 00:00:00 (UTC), to raczej jest to data prawidłowa. Jeżeli widzimy daty w postaci 28.11.2011 23:00:00 (UTC) lub 19.04.2020 22:00:00 (UTC), to znaczy, że transakcja w rzeczywistości miała miejsce dzień później. Ten problem widziałem w pierwszych udostępnieniach Geopaczek w Geoportalu i wynikał on z uwzględniania czasu letniego lub zimowego w stosunku do czasu uniwersalnego. Teraz może być to rzadszy problem, ale warto go kontrolować. 3) Czasem można spotkać pliki, w których wcale nie ma daty transakcji (vide powiat kędzierzyńsko-kozielski), 4) może się zdarzyć, że zakres danych opisujący transakcję jest mniejszy niż w plikach GML, zamawianych bezpośrednio w ośrodku.
Filtrowanie
Po wczytaniu warstwy „działki" z pliku Geopaczki, aktywujemy filtr (prawym klawiszem myszki otwieramy menu kontekstowe warstwy) i wpisujemy wybrane kryteria. W tym przypadku określamy rodzaj nieruchomości oraz zakres dat:
"nier_rodzaj" = 'nieruchomoscGruntowaNiezabudowana'
AND
"dok_data" > '2024-04-30T00:00:00.000Z'
Powyższe filtry powodują zawężenie zawartości tabeli atrybutów tylko do transakcji obejmujących działki niezabudowane oraz takich, które miały miejsce w okresie ostatnich 24 miesięcy.
Ten krok możemy wykonać na początku lub na końcu. Wykonanie na początku ma ten plus, że dalsze przetwarzanie dotyczy mniejszej ilości danych i jest szybsze. Jednak jeżeli zmienimy koncepcję filtrowania (np. inny okres czasu), to wtedy musimy wykonać ponownie następne kroki. Oczywiście możemy też ustawić więcej filtrów (np. powierzchnia, przeznaczenie, tylko sprzedaże w udziale 1/1) albo dodać te filtry na końcu procesu.

Agregacja
Teraz, kiedy w tabeli atrybutów zostały już tylko nieruchomości niezabudowane, musimy rozwiązać problem multiplikacji wpisów w przypadku transakcji, w których następowała sprzedaż kilku działek. Użyjemy do tego narzędzia AGREGACJA, które znajdziemy w panelu algorytmów przetwarzania (processingu). Po uruchomieniu narzędzia wskazujemy pole, w którym znajduje się unikalny identyfikator transakcji 1️⃣, a następnie wybieramy odpowiednie funkcje agregujące 2️⃣ dla wszystkich pól tabeli atrybutów oraz znak separatora 3️⃣ (jeżeli nie chcemy, żeby był nim przecinek). Z funkcji agregujących interesują nas przede wszystkim funkcje opisane poniżej:
| lp. | funkcja agregująca | opis |
|---|---|---|
| 1. | concatenate | funkcja odpowiada excelowej funkcji „złącz teksty" |
| 2. | concatenate_unique | funkcja złączenia tekstów, która łączy tylko unikalne wartości |
| 3. | first_value | funkcja, która przy łączeniu rekordów tabeli atrybutów przenosi wartość tylko pierwszego rekordu |
| 4. | sum | funkcja sumuje wartość wskazanego pola wszystkich łączonych rekordów |
Zadaniem narzędzia AGREGACJA jest sprawdzenie, czy dla danego rekordu tabeli atrybutów wskazany identyfikator transakcji powtarza się w innych rekordach. Jeżeli odpowiedź jest przecząca, to rekord pozostaje bez zmian. Jeżeli wartość się powtarza (co oznacza, że wszystkie rekordy dzielące ten sam identyfikator są częścią tej samej transakcji), algorytm scala wszystkie te rekordy w jeden nowy rekord. Za pomocą funkcji agregujących wskazujemy, co ma się stać z zawartością poszczególnych pól w tych rekordach. Nie podam tutaj informacji, jak zmapować każde z tych pól — podpowiem tylko, że dla większości odpowiednie jest ustawienie concatenate_unique lub first_value. Dla prawidłowego ustawienia pól należy przeanalizować sposób wpisywania danych do rejestru cen w danym starostwie i specyfikę tych pól (np. jak są wpisywane udziały w drogach dojazdowych i jak to wpływa na ostateczną cenę). Pole „nier_cena_brutto" niesie informację o całej transakcji, więc ustawiamy je na first_value. Pole „dzi_cena_brutto" będzie dotyczyło tylko ceny pojedynczej działki (jeżeli podano), więc użyjemy funkcji sum. Generalnie zastosowanie odpowiedniej funkcji agregującej zależy od tego, jaką ostatecznie informację chcemy uzyskać. Np. jeżeli zastosujemy funkcję sum dla pola „dzi_pow_ewid" (które zawiera powierzchnię ewidencyjną działki), to uzyskamy łączną powierzchnię wszystkich działek, którą możemy wykorzystać do porównania z polem „nier_pow_gruntu" np. dla weryfikacji poprawności wpisu. Jeżeli jednak do tego pola zastosujemy funkcję concatenate, to otrzymamy informację o powierzchni każdej z działek wchodzących w skład nieruchomości, wypisane po przecinku. Należy tu jednak pamiętać, że jeżeli chcemy zastosować funkcję tekstową concatenate do wartości numerycznych np. „dzi_pow_ewid", to musimy wcześniej te wartości zmienić na tekst 4️⃣ i ustawić odpowiedni typ danych dla pola wyjściowego 5️⃣.

Po wykonaniu powyższego kroku otrzymamy tabelę, w której liczba rekordów będzie odpowiadać liczbie transakcji.
Dodatkowe pola i stylizacja
W tym etapie dobrze jest użyć KALKULATORA PÓL, żeby dodać pole z wyliczoną ceną jednostkową. Możemy także pójść dalej i wyliczyć np. współczynniki kształtu (o których możemy poczytać we wpisie “Kształt ma znaczenie, czyli współczynniki kształtu w wycenie nieruchomości”) lub inne parametry nieruchomości, jakich akurat potrzebujemy. To też dobry czas, żeby nadać odpowiednią stylizację naszej nowo utworzonej warstwie. Podpowiem, że dobrze się sprawdza ustawienie pełnego koloru, ale z kryciem na poziomie 10%–20%. Dzięki temu będziemy widzieć warstwy poniżej, ale też od razu zauważymy, która nieruchomość sprzedała się ponownie w analizowanym okresie czasu.
Relacje
Ten krok jest opcjonalny, ale pomaga w uporządkowaniu danych. Jeżeli się na niego decydujemy, dobrze zapoznać się z koncepcją relacyjnych baz danych oraz primary key (klucz główny) i foreign key (klucz obcy).
…Relacyjna baza danych to zbiór danych zorganizowanych w tabele, które są ze sobą powiązane relacjami. Dzięki temu można efektywnie wyszukiwać, łączyć i zarządzać informacjami bez duplikowania danych. Aby takie powiązanie było możliwe, tabele muszą posiadać kolumny z danymi, które stanowią wspólny łącznik: Klucz Główny (Primary Key): To unikalna kolumna w tabeli „nadrzędnej" (np. ID województwa), która jednoznacznie identyfikuje każdy rekord. Klucz Obcy (Foreign Key): To kolumna w tabeli „podrzędnej" (np. ID województwa wpisane przy powiecie), która wskazuje na konkretny klucz główny w drugiej tabeli. Relacja 1:1 (jeden do jednego) lub N:1 (wiele do jednego) jest realizowana w QGIS za pomocą opcji „Złączenia" (Joins). Głównym wymaganiem jest to, aby obie tabele posiadały kolumnę z danymi (klucze), które umożliwiają wyszukanie informacji w jednej tabeli, a następnie fizyczne dołączenie ich do widoku drugiej tabeli. Na przykład, mając tabelę z nazwami powiatów i drugą z nazwami województw – w relacji N:1 każdemu powiatowi odpowiada tylko jedno województwo. W przypadku relacji odwrotnej 1:N (jeden do wielu) każdemu rekordowi w bazie danych (w tym przykładzie jest to jedno województwo) odpowiada wiele rekordów w drugiej tabeli (wiele powiatów). Ten rodzaj relacji realizujemy w QGIS za pomocą opcji „Relacje" (Relations) w ustawieniach projektu. Pozwala to na logiczne powiązanie danych, co jest widoczne np. podczas przeglądania formularzy obiektów.
Naszym zadaniem jest powiązanie tabeli stworzonej przez AGREGACJĘ z pierwotną warstwą z RCN „transakcje_działki" (lub „działki"). Żeby to zrobić, wybieramy projekt z paska menu 1️⃣ -> wchodzimy we właściwości projektu 2️⃣ -> wybieramy zakładkę „relacje" 3️⃣ -> nadajemy nazwę relacji 4️⃣ -> wskazujemy warstwę nadrzędną (w naszym przypadku warstwę wynikową narzędzia AGREGACJA) oraz powiązaną („transakcje_działki" lub „działki") 5️⃣ -> wskazujemy pole wiążące obie warstwy (klucz główny, klucz obcy — w naszym przypadku to pole „tran_lokalny_id_iip") 6️⃣

Efekt końcowy
Po wykonaniu powyższych kroków otrzymamy bazę danych, w której każdy rekord odpowiada jednej transakcji, ale możemy też zobaczyć składowe transakcji, jeżeli transakcja składała się z kilku działek. Np. używając narzędzia INFORMACJE O OBIEKCIE i klikając na zagregowaną transakcję, zobaczymy też w panelu powiązane rekordy składowych działek. Możemy teraz przeprowadzać na takiej bazie analizy przestrzenne lub wyeksportować ją do Excela.
Automatyzacja
Zrozumienie manualnego procesu to fundament, który pozwala na kolejny krok – budowę automatycznych przepływów pracy. W tym przypadku świetnie sprawdzi się MODELARZ GRAFICZNY, który pozwala zamienić dzisiejsze kroki w gotowe narzędzie „jeden klik". Co prawda wykracza to poza ramy tego artykułu, ale zachęcam do samodzielnego sprawdzenia tej ścieżki.
Podsumowanie
Rejestr Cen Nieruchomości nie jest rewolucją, którą obiecywano — i nie zastąpi profesjonalnych baz danych ani rzetelnej analizy aktu notarialnego. Ma konkretne wady i konkretne zastosowania. Ale przy odpowiednim przetworzeniu — i świadomości jego ograniczeń — można z niego wyciągnąć realną wartość.