Dla zapewnienia popularności komunikacji publicznej istotne znaczenie ma głównie jakość oferty przewozowej (takt kursowania, pewność przesiadki, taryfa przewozowa). Drugim wyznacznikiem są przyzwyczajenia mieszkańców i dostępność komunikacyjna przystanków komunikacji publicznej. Dziś chciałbym przedstawić proponowaną metodykę obliczenia izochron dostępności komunikacyjnej przystanków kolejowych w województwie śląskim (zarówno tych dostępnych obecnie, obsługiwanych w przeszłości, jak i projektowanych)

Wprowadzenie

Pojęcie dostępności komunikacyjnej transportu publicznego definiowane jest jako czas potrzebny na dotarcie do przystanku komunikacji publicznej z miejsca zamieszkania. Czas oczekiwania na sam pojazd też ma wpływ na odbiór dostępności. W związku z tym np. w Wielkiej Brytanii przyjmowane są wartości odpowiadające 8 minutom marszu z prędkością 4,8km/h dla autobusu i do 12 minut dla pociągu [1] Przykłady niemieckie wskazują że powyżej 400 m drogi dojścia, może dojść do zmiany decyzji co do środka transportu. W naszych rozważaniach dla województwa śląskiego założymy że czas dotarcia do przystanku kolejowego nie może przekraczać 15 minut. Dodatkowo należy wziąć pod uwagę lokalizację punktu definiowanego jako węzeł początkowy dla izochrony czasu dojścia. Tu w mojej analizie przyjąłem następujące parametry:

  • dla przystanku kolejowego – wejście na perony, przejście w poziomie szyn
  • dla stacji kolejowej – główne/najpopularniejsze wejście na stację kolejową

Kolejno poczyniłem założenia co do prędkości poruszania się dorosłego pieszego:

  • po drogach krajowych i wojewódzkich – 3km/h
  • po drogach powiatowych, gminnych i lokalnych   – 4 km/h
  • po dedykowanych ciągach pieszych – 5 km/h

Po przygotowaniu założeń możemy przystąpić do zebrania potrzebnych danych przestrzennych. W tym przypadku zaprezentuję jak wykonać całość na danych dostępnych publicznie, głównie w oparciu OpenStreetMap.

Dane źródłowe

Zestaw danych sieciowych

Podstawowym zbiorem danych w moim przypadku będzie ekstrakt danych OpenStreetMap dla województwa śląskiego, pobrany ze strony geofabrik.de. Pobrany plik osm.pbf jest dobrym materiałem dla konwertera osm2po (w pliku konfiguracyjnym osm2po.config definiujemy opisane wyżej prędkości i typy dróg branych pod uwagę.). Jest on oparty o środowisko Java, a więc stosunkowo łatwym do uruchomienia na dowolnej platformie i to ten program jest moim pierwszym wyborem. Innym dostępnym konwerterem jest osm2pgrouting. Efektem pracy osm2po są dwa pliki .sql gotowe do zaimportowania do bazy danych PostgreSQL/PostGIS – xxx_2po_4pgr.sql oraz xxx_2po_vertex.sql. Pierwszy z nich zawiera informacje o odcinkach sieci drogowej, drugi zaś o węzłach sieci.

Lokalizacje przystanków kolejowych

Następny krok to pozyskanie lokalizacji stacji i przystanków kolejowych. Dla celów tego artykułu zaprezentuje dziś metodę najmniej efektywną, ale jednocześnie taką która wymaga najmniej wiedzy o przetwarzaniu danych OpenStreetMap. Skorzystajmy z usługi dostępnej pod adresem https://overpass-turbo.eu/ 

Overpass Turbo - Kreator

Overpass Turbo – Kreator

Po wczytaniu strony wybieramy okno Kreator i wpisujemy zapytanie – „railway=station” OR „railway=halt” in „województwo śląskie”, a następnie wybieramy Stwórz i wykonaj kwerendę. W jej wyniku do okna mapy zaczytane zostaną punkty,które następnie eksportujemy do formatu GeoJSON.  Tak pozyskany plik wczytujemy do QGIS.

Overpass Turbo - Eksport

Overpass Turbo – Eksport

Ja zdecydowałem się na dodanie do istniejącego zbioru przystanków projektowanych: Chorzów Uniwersytet i Bytom Północny, przystanków o które lobbują ruchy miejskie w konurbacji śląskiej (np. Zabrze Kopernika), a także na usunięcie ze zbioru przystanków kolejek wąskotorowych. Dla niektórych punktów zmieniona zostanie lokalizacja punktu zależnie od typu punktu (przystanek/stacja). Następnie przy pomocy narzędzia Zarządzanie bazami dokonujemy importu zbioru do tabeli PostGIS.

Import warstwy wektorowej do PostGIS

Import warstwy wektorowej do PostGIS

Dane o rozmieszczeniu ludności

Przyznam wam szczerze, tu jest najgorzej. Idealnym zbiorem byłby wyciąg z rejestru PESEL złączony ze zbiorem punktów adresowych. Wtedy każdemu punktowi adresowemu odpowiadałaby dokładna informacja o mieszkańcach. Wystarczyłoby zaagregować punkty adresowe znajdujące się w zasięgu naszej izochrony 15 minut i zsumować liczbę mieszkańców. Niestety, nie ma tak dobrze. Dlatego w naszej analizie będziemy używać danych udostępnionych przez Główny Urząd Statystyczny w ramach Portalu Geostatystycznego.  Bezpośrednio na stronie tego portalu możemy znaleźć link do zbioru Rozmieszczenie ludności w siatce 1x1km – Portal Geostatystyczny. W głębokim ukryciu w tym samym portalu znajdują się zbiory dotyczące rozmieszczenia ludności w rejonach i obwodach statystycznych. Lektura plików generowanych przez usługę ATOM naprowadziła mnie na właściwy zbiór w formacie SHP (EPSG:2180).

Portal geostatystyczny – Obwody spisowe

Gęstość zaludnienia na podstawie zbioru BREC

Zbiór z informacją o rozmieszczeniu ludności w obwodach spisowych pozwoli nam oszacowanie ludności potencjalnie zamieszkującej ten obszar w sposób przybliżony, z pewnym nadmiarem, wynikającym ze zliczania całego obwodu. Każda inna metoda nie oparta o rzeczywiste, punktowe dane o rozmieszczeniu ludności byłaby zaledwie „wymyślaniem danych”. W związku z tym przyjęta została metoda o najmniejszym obciążeniu obliczeniowym.

Importu dokonamy w sposób identyczny jak dla lokalizacji przystanków przy pomocy narzędzia Zarządzanie bazami w QGIS.

Obliczenia

Nasze obliczenia będziemy wykonywać w nakładce na bazę danych PostGIS o nazwie pgRouting. Wspomniałem już że wynikiem pracy osm2po były dwa pliki odpowiadające tabelom – odcinków i węzłów sieci. W pierwszej kolejności, dla ułatwienia dalszej naszej pracy wyszukajmy węzeł sieci najbliższy naszemu punktowi dla stacji.przystanku. Skorzystamy w tym celu z operatora przestrzennego <-> który wykonuje obliczenia odległości oraz sortuje wyniki przy pomocy operacji KNN.  A więc sortujemy każdy punktów wg zmierzonej odległości ORDER BY a.name, a.geometry <-> b.geom_vertex. Jeszcze jedna uwaga względem <->. Operuje on na indeksach przestrzennych, wielokrotnie przyśpieszając wykonanie wyszukiwania odległości i sortowania wyników. Warto o tym pamiętać. Tak przygotowaną listę węzłów traktujemy klauzulą DISTINCT ON (a.name) a więc dla każdego unikalnego a.name wybieramy pierwszy z listy węzłów – ten z najmniejszą odległością.

CREATE TABLE pgr.rail_nodes AS
SELECT DISTINCT ON (a.name) a.name, a.geometry, b.id AS node, a.geometry <-> b.vertex AS distance
FROM public.transport a, pgr.sl_vert b ORDER BY a.name, a.geometry <-> b.vertex;

Węzły sieci do obliczeń – średnica okręgu proporcjonalna do odległości

Funkcja Driving distance

W pgRouting od wersji 2.1 możliwe jest podanie wielu początkowych węzłów dla obliczenia w jednym przebiegu. Będziemy z tego korzystać. Niestety funkcje pgRouting mają jedną wyjątkowo nieprzyjemną cechę. Korzystają z tzw. inner queries. Funkcja pgr_drivingdistance wymaga jako wejścia argumentu typu string, podzapytania właśnie – selecta z tabeli odcinków sieci. Przykładowe wywołanie funkcji może wyglądać tak: pgr_drivingdistance('SELECT id, source, target, cost FROM pgr.osm_2po_4pgr'::text,ARRAY[numer_wezla_startowego], 0.25, false).  Pozostałe argumenty to macierz (ARRAY[]) numerami węzłów (wprzypadku jednego wezła, typu powinien być int), wartość kosztu ( u nas jest to czas w godzinach), oraz czy funkcjama brać pod uwagę kierunkowość dróg. Funkcja zwraca jako wynik numer wiersza, numer węzła startowego „from_v,” numer węzła końcowego „node”, „edge” czyli dany odcinek sieci, „cost” i „agg_cost” – koszt pokonania tego odcinka sieci, oraz łączny koszt od początku grafu. Zauważcie, że nie zwraca w wyniku operacji żadnej geometrii. Dlatego w naszym wypadku dodajemy alias foo, a następnie wykonujemy złączenie LEFT JOIN względem identyfikatora krawędzi – odcinka sieci. Dodatkowo pominiemy w naszym select wartość kosztu pojedyńczego odcinka.
CREATE TABLE pgr.izo_edge AS
SELECT seq,from_v,node,edge,agg_cost,l.geom_way
FROM pgr_drivingdistance('SELECT id, source, target, cost FROM pgr.osm_2po_4pgr'::text,
ARRAY[417671, 436503, 135216], 0.25::double precision, false) fooLEFT JOIN pgr.osm_2po_4pgr l ON l.id = foo.edge;

Czas pokonania odcinków sieci

Węzeł startowy

Dla wygody wizualizacji wykonamy drugie, bardzo podobne zapytanie, zmieniając tylko dołączaną geometrię – punkty węzłowe. Są to węzły na końcach pokonanych odcinków.

CREATE TABLE pgr.izo_point AS
SELECT seq,from_v,node,agg_cost,l.geom_vertex
FROM pgr_drivingdistance('SELECT id, source, target, cost FROM pgr.osm_2po_4pgr'::text, ARRAY[417671, 436503, 135216], 0.25::double precision, false) fooLEFT JOIN pgr.osm_2po_vertex l ON l.id = foo.node

Obszary

Ostatnim etapem naszej pracy będzie zaagregowanie zbioru punktów względem atrybutu from_v, (używamy GROUP BY oraz ST_Collect), dla ułatwienia umieszczone wewnątrz tzw. CTE – WITH nazwa AS (podzapytanie).  Następnie w zapytaniu głównym używamy tak przygotowanych kolekcji do wykonania operacji ST_ConcaveHull (otoczka wklęsła), przyłączenia  nazwy przystanku z tabeli rail_nodes (używamy LEFT JOIN). Kolejna część naszego zapytania (WHERE ST_Intersects) odpowiada za wyszukanie tych obwodów spisowych które mają część wspólną z naszą izochroną. GROUP BY zapytania głównego zadba o zaagregowanie wszystkich obwodów spisowych (SUM(l.total_pop)). W związku z tym że operacje agregowania są dość kosztowne obliczeniowo, zaś ConcaveHull zależne jest również od parametru target_percent (im niższy tym dłuższy czas wykonania), chwilę musimy poczekać na wyniki. O ile dla funkcji driving_distance i 270 punktów startowych wywołanie trwało ok. 5.5 s, to w przypadku tego zapytania w moim przypadku trwało ponad 140 s.

CREATE TABLE pgr.potencjal AS
WITH kawalki AS
(SELECT ST_Collect(vertex) as geom, from_v FROM pgr.rail_iso_vertices GROUP BY from_v)

SELECT z.from_v, r.name, SUM(l.total_pop) AS pop, ST_ConcaveHull((z.geom),0.7) AS geometry
FROM pgr.ludnosc_brec l, kawalki z LEFT JOIN pgr.rail_nodes r ON z.from_v = r.node
WHERE ST_Intersects(l.geometry, z.geom) GROUP BY z.from_v, r.name, z.geom;

Pozostaje nam zwizualizować tak przygotowany zestaw danych.

Dostępność komunikacyjna przystanków

Bibliografia:

  1. Majewski B., Beim M.: Dostępność komunikacji publicznej w Poznaniu. „Rozwój Regionalny i Polityka Regionalna” nr 3 (2008) str. 115 
  2. Mikiewicz D., Mackiewicz M,, Nycz T.: Mastering PostGIS, Packt, 2017.

Serdecznie dziękuję p. Michałowi Mackiewiczowi, oraz dr Andrzejowi Soczówce za cenne uwagi przydatne w trakcie opracowania tego tekstu