PosgtgreSQL jest do wolnodostępny system zarządzania bazą danych. Został wykorzystany w celu przechowywanie i swobodnego dostępu do danych. W projekcie został wykorzystany system w wersji 8.4.2.
Należy pobrać pakietów źródłowe, paczki binarne z strony producenta http://www.postgresql.org/download/. Polecane jest korzystanie z pakietów źródłowych w celu uniknięcia problemu z zależnościami pomiędzy pakietami. Instalację należy przeprowadzić według opisu znajdującego się http://www.postgresql.org/docs/8.4/interactive/install-requirements.html, również znajdują się tam wszystkie wymagane pakiety.
PostGIS dodaje wsparcie do przechowywanie danych geograficznych w obiektowo-relacyjnej bazie danych PostgreSQL . Dodatkowo udostępnia narzędzia ułatwiające manipulację danymi. Jest to zatem GIS (Geographic Information System) służący do przechowywanie, gromadzenia i manipulowania danymi. Został m.in wykorzystany do konstruowania zapytań o przystankach znajdujących w określonym promieniu. Należy pamiętać o wykorzystaniu SRID'u 4326 obowiązującego w Polsce. W projekcie został wykorzystany PostGIS w wersji 1.4.2.
Ten uniwersalny język skryptowy wykorzystywany jest w module importującym dane z OpenStreetMap. W związku z tym, że sporo bibliotek (w tym używana do połączenia z bazą danych psycopg) nie zostało jeszcze przeportowancych do standardu 3.0, wykorzystano starszą „linię” 2.6 interpretera. Poza wspomnianym modułem psycopg2, używanym do połączenia z bazą danych, skrypt wykorzystuje również moduł xml.sax, będący częścią biblioteki standardowej, do parsowania plików XML.
Jest to język skryptowy działający po stronie serwera służący do dynamicznego generowania stron internetowych. W projekcie został wykorzystany jako „pośrednik” do interakcji pomiędzy klientem a bazą danych. Wykorzystano Php w wersji 5.32. Pakiet można pobrać z strony http://www.php.net/downloads.php. Istnieje możliwość skorzystania z XAMPP który zawiera Php, Apache, Perl. Przydatny do testowania aplikacji.
JavaScript obiektowy język skryptowy stworzony do zapewniania interaktywności pomiędzy klientem a aplikacją. W aplikacji wykorzystano framework Jquery, który należy dołączyć do aplikacji. Dostępny jest pod adresem http://docs.jquery.com/Downloading_jQuery. Do pozyskiwania informacji z serwera bez przeładowywania strony wykorzystano technologię AJAX i JSON. W projekcie wykorzystano także API do GoogleMaps w wersji V.3 dostępne na stronie producenta http://code.google.com/apis/maps/documentation/v3/
Pozwala opisać strukturę informacji zawartych na stronie ( prezentacja wyników).
Pozwala sformatować informację zawarte na stronie ( prezentacja wyników).
Informacje o komunikacji publiczna w OpenStreetMap zapisane są przy wykorzystaniu znacznika Relation:route: http://wiki.openstreetmap.org/wiki/Relation:route Pozwala on na zapisanie informacji o typie połączenia (key:route): autobusowym (value:bus) i tramwajowym (value:tram). Ważną informacją (choć niestety nieobowiązkową przy wprowadzaniu) jest nazwa linii (key:ref). OSM prawdopodobnie zakłada, że linie komunikacji miejskiej w obu kierunkach wyglądają jednakowo, w związku z czym nie ma znacznika opowiadającego za kierunek linii. Stanowi to (dla Krakowa) pewien problem, co można by rozwiązać np. poprzez dodanie do numeru linii litery - 173a, 173b. Niestety w chwili obecnej w danych dla Krakowa takiego rozróżnienia nie ma.
W skład relacji powinny wchodzić również przystanki. Najnowsze API 0.6 nie uwzględnia możliwości numerowania przystanków - powinny być one umieszczone w relacji w odpowiedniej kolejności. Niestety w przypadku danych dla Krakowa przystanki funkcjonują zupełnie niezależnie od linii komunikacji miejskiej, co uniemożliwiło import części danych (o czym innej części raportu).
Inne informacje, jakie może zawrzeć dla odpowiednich linii, to rozróżnienie operatorów ją obsługujących czy też możliwość korzystania z niej przez niepełnosprawnych.
Przystanki w OSM występują w oparciu o tag highway:bus_stop http://wiki.openstreetmap.org/wiki/Tag:highway%3Dbus_stop Poza informacją o nazwie (tag:name) pozwala na określenie kierunku (towards), w którym zmierza autobus z danego przystanku.
Aktualne informacje o naniesionych na mapę liniach krakowskiej komunikacji miejskiej można znaleźć na stronie: http://wiki.openstreetmap.org/wiki/WikiProject_Poland/Ma%C5%82opolska
W związku z tym, że ręczne wprowadzenie danych o całej krakowskiej sieci komunikacji miejskiej stanowiłoby nie lada problem stworzony został moduł importujący odpowiednie informacje z OSM. Mimo, że ilość danych dotyczących krakowskiego MPK nie jest zbyt duża (i nie do końca poprawnie zebrana - więcej na ten temat w dalszej części raportu), to moduł pozwala na zebranie części potrzebnych nam informacji.
Parsowanie pliku XML wykonywane jest w oparciu o model zdarzeniowy - przy użyciu interfejsu SAX (ang. Simple API for XML czyli Proste API dla XML-a), dostępnego w bibliotece standardowej Pythona. Podyktowane to zostało przede wszystkim sporymi rozmiarami pliku wyjściowego z OSM, co w przypadku chyba wygodniejszego modelu DOM (ang. Document Object Model) mogłoby stanowić nie lada problem.
Samo użycie modułu jest dość intuicyjne:
src % ./test.py
Usage: test.py [options]
Options:
-h, --help show this help message and exit
-f FILENAME, --file=FILENAME
name of input XML file, default: map.osm
-d DBNAME, --dbname=DBNAME
database name, default: db_gis_project
-u DBUSER, --user=DBUSER
database username, default: kml
-c, --create creates db structure
-p, --print prints data from xml file
-i, --import imports data from xml file to database
--update_distance updates time of transfer between small_stops
To, czego potrzebujemy, to wyeksportowany z OSM plik XML oraz baza danych z rozszerzeniem PostGIS. Skrypt pozwala na wyświetlenie informacji dotyczących połączeń i przystanków zawartych w pliku XML, stworzenie struktury bazy danych oraz import danych z pliku do bazy. Dodatkową funkcją jest „–update_distance” - wyszukuje ona najbardziej oddalone od siebie „części przystanków” (small_stop) i oblicza czas potrzebny na przemieszczenie się w ich obrębie (na podstawie dystansu między nimi i prędkości poruszania się).
Przykład wyświetlenia danych (fragment):
Linie tarmwajowe Linia: 4 Identyfikator: 223307 Węzły: [u'477002182', u'477002183', u'470643346', u'470643342'] Droga 22424924 z wezlow: nie ma drogi w bazie:( Droga 28593666 z wezlow: nie ma drogi w bazie:( Droga 28593667 z wezlow: nie ma drogi w bazie:( Przystanki tramwajowe (u'206372224', u'Basztowa LOT', u'50.0663142', u'19.9394981') (u'261677483', u'Wawel', u'50.0545631', u'19.9395643') (u'378365430', u'\u015awi\u0119tej Gertrudy', u'50.0586702', u'19.9410279') (u'378365902', u'Miodowa', u'50.0533232', u'19.9488683') (u'378365907', u'Starowi\u015blna', u'50.0568776', u'19.9455381') (u'378365918', u'Starowi\u015blna', u'50.0571036', u'19.9459501')
Informacje, jakie jesteśmy w stanie „wydobyć” z OSM to nazwy i położenia przystanków oraz „drogi” (ways) i „węzły” (nodes), z których składają się poszczególne linie (opisane w OSM jako relacje). Dane te zakodowane są w standardzie UTF-8 i w takiej właśnie formie zapisywane w bazie danych. Niestety, w związku z pewnymi brakami w bazie OSM (o których później), tylko informacje o przystankach mogły być zaimportowane do bazy i wykorzystane w pozostałej części projektu.
Więcej informacji o ręcznym wprowadzeniu danych w punkcie 4.
Umożliwia użytkownikowi wyszukiwanie przystanków po wprowadzeniu części nazwy (opcja domyślna). Kolejną opcją jest wyszukiwanie przystanków znajdujących się w określonym promieniu. Odbywa się to po wybraniu opcji Przystanki w okolicy. Użytkownik klika na mapę w celu wybrania środka okręgu. Następnie należy wprowadzić promień poszukiwaniach. Jednostka długości to metr. Jeżeli powyższe zapytania dały wynik pozytywny to użytkownik po kliknięciu w odnośnik ma możliwość edycji danego przystanku. Ostatnia opcja to pokazanie trasy danej linii. Na mapie zaznaczana jest trasa komunikacyjna wraz z istniejącymi przystankami.
Edycja istniejącego przystanku (rys. poniżej). Użytkownikowi po wybraniu przystanku do edycji wyświetlany jest formularz w celu skorygowania wiadomości w bazie danych. Zmiany wprowadzone przez użytkownika muszą zostać zaakceptowane przez administratora. Współrzędne przystanku można poprawić klikając na mapę w miejsce nowego położenia, informacja o długości i szerokości geograficznej jest automatycznie uaktualniana w polu formularza.
Administrator docelowo ma mieć możliwość importu i eksportu danych . Po kliknięciu zakładki dodaj przystanek, pojawia się formularz dzięki któremu możliwe jest dodanie nowego przystanku do bazy danych. Zmiany zapisywane są od razu. Z kolei w dziale sugestie użytkowników istnieje możliwość zaakceptowania zmian proponowanych przez użytkowników. W tym celu należy zaznaczyć odpowiednie sugestie, a następnie wysłać zapytanie do serwera. Kolejne opcje służą do edycji istniejących przystanków „Usun przystanek” i „Edycja przystanku” zmiany widoczne są natychmiast. (rys. poniżej).
Celem aplikacji jest umożliwienie użytkownikowi w prosty sposób dodawanie nowych linii. Sposób obsługi jest następujący. Administrator wybiera z rozwijanej listy interesujący przystanek następnie naciska przycisk Dodaj. Przystanek pojawia się na liście przystanków danej linii. Jeżeli istnieje niepewność gdzie znajduje się przystanek należy nacisnąć przycisk Pokaz. Po zaznaczenie przystanków z drugiej listy można je usunąć naciskając przycisk Usun. Po skończonej edycji należy wysłać formularz do serwera.
Aplikacja działa na podobnej zasadzie jak aplikacja do dodawania nowych linii. Jako numer linii należy wpisać id linii w bazie danych. Jest to wartość pomiędzy nawiasami „( )”. (rys. poniżej)
Warunkiem koniecznym poprawnego działania aplikacji jest posiadanie serwera wraz z oprogramowaniem zamieszczonym w 1 punkcie. Serwer musi być posiadać opcję umożliwiającą zastosowanie ModRewrite w pliku .htaccess. Służy to do posługiwania się adreasami URL przyjaznym użytkownikom.
Należy uruchomić skrypt „create_db” który jako parametr przyjmuję nazwę nowej tabeli. Należy również wskazać miejsce gdzie znajdują się pliki SQL powiązane z PostGIS.
echo $1; createdb $1; createlang plpgsql $1; psql -d $1 -f /usr/local/pgsql/share/contrib/postgis.sql ; psql -d $1 -f /usr/local/pgsql/share/contrib/spatial_ref_sys.sql ; psql -d $1 -f /usr/local/pgsql/share/contrib/postgis_comments.sql ;
Po pomyślnym stworzeniu nowej tabeli, należy utworzyć pustą tabelę używając komend zawartych w projekcie logicznym.
W tej części należy dostosować plik include.php. Znajdują się w nim informacje konfiguracyjne dotyczące połączenia z bazą danych.
$name="post_test"; $password=""; $name_db="aa2"; $help="pgsql:host=localhost port=5432 dbname=$name_db user=$name password=$password";
Większość problemów, z jakimi zetknięto się podczas tworzenia projektu, dotyczyła wykorzystania danych dostępnych w OpenStreetMap. Mimo, że baza danych dotycząca krakowskiej komunikacji miejskiej jest dość obszerna, to jednak nie jest ona należycie przygotowana. Podstawowym problemem jest brak powiązania istniejących relacji autobusowych (i tramwajowych) z przystankami. Sam OSM daje taką możliwość, jednak jego krakowscy użytkownicy (poza nami samymi w celach testowych) nie korzystali z tej możliwości. Tym sposobem import istniejących linii oraz dróg stał się niemożliwy: nie można było określić przystanków początkowych i końcowych linii. W związku z tym pierwszym krokiem, jaki należałoby uczynić, jest uzupełnienie tychże danych. Sam parser jest do tego (częściowo) przygotowany.
Kolejny, wspomniany wcześniej problem, to nieuwzględnienie przez twórców możliwości różnic w trasie przejazdu w poszczególnych kierunkach. Oznacz to, że należałoby albo wprowadzić dodatkowe taki, albo rozróżnić w nazwie (np. poprzez a/b) kierunek relacji.
Można również odnieść wrażenie, że moduł eksportujący dane z OSM ma pewne niedociągnięcia - eksportując dane dotyczące jakiegoś obszaru może okazać się, że są one niekompletne. W relacjach znajdują się bowiem drogi (ways), ale brak jest informacji o ich przebiegu.
Jeśli chodzi o problemy typowo techniczne, to pewne problemy pojawiły się podczas przetwarzania danych zakodowanych poprzez moduł pygresql w Pythonie, w związku z czym wykorzystano psycopg2, który radzi sobie z tym bez problemów (wysyła dane jako „escape strings”, poprzedzone prefiksem E).
Zrealizowany projekt został zakończony połowicznym sukcesem. Cześć aplikacji oparta o prezencję danych udało się nam zrealizować w 100 %. Użytkownik uzyskał możliwość podglądu danych dotyczących funkcjonowania komunikacji miejskiej w Krakowie. Administrator ma możliwość prostego i intuicyjnego wprowadzania danych przez wizualny edytor. Niestety nie udało się nam do końca zrealizować importu i eksportu danych zawartych w www.openstreetmap.org. Napotkane problemy zostały szczegółowo opisane w punkcie 6 raportu końcowego. Podsumowując udało się stworzyć aplikację uniwersalną, która jest w stanie pracować w różnych miastach, a nie tylko w Krakowie. Użycie PostGIS pozwoliło w łatwy sposób konstruować zapytania geolokacyjne. Uważamy że należy dalej rozwijać tematyką związaną z komunikacją miejską, dlatego że pozwoli to użytkownikom w łatwy sposób uzyskać informacje o funkcjonowaniu transportu publicznego.
Rozważając perspektywy rozwoju projektu można wyróżnić kilka potencjalnych kierunków dalszych prac. Jedną z możliwość jest skupienie się na lepszym przystosowaniu systemu do wykorzystania na urządzeniach mobilnych. Zastosowana obecnie w systemie wersja API Google Maps umożliwia bardzo łatwą lokalizację na mapie urządzeń, które są świadome swojego położenia (iPhone, telefony z systemem Google Android lub Windows Mobile/Phone). Zatem, kolejnym krokiem w tym kierunku mogłoby być wyświetlanie kontekstowych informacji o liniach i przystankach w zależności od położenia użytkownika, tak aby włączając stronę projektu ma urządzeniu mobilnym można było od razu zorientować się odnośnie znajdujących się w okolicy przystanków oraz tras.
Inna możliwością rozwoju systemu jest stworzenie na jego bazie zupełnie innej warstwy informacyjnej. Warstwę tę może stanowić np informacja o rozmieszczeniu bankomatów czy też innych, istotnych z punktu widzenia określonej grupy docelowej przydatnych miejsc. Ta droga rozwoju jest o tyle prostsza od pozostałych iż z punktu widzenia administratora systemu wymaga właściwie zaznaczania na mapie pojedynczych punktów a nie całych ścieżek.
Odrębną warstwę informacyjną można również zbudować wykorzystując cały dostępny potencjał systemu. Zamiast wyświetlania tras komunikacyjnych mogłyby to być warte przejścia trasy widokowe, ścieżki kulturalne lub spacerowe, co przy uwzględnieniu liczby turystów odwiedzających Kraków i daniu im np. możliwości głosowania na najlepsze trasy mogłoby rozwinąć się w ciekawy, niezależny projekt.
Jeżeli chodzi o możliwości rozwoju systemu związane z trasami komunikacyjnymi bardzo pożądaną funkcjonalnością była by możliwość zaplanowania tras łączących dowolne punkty w mieście. Użytkownik miałby wpływ na punkty pośrednie oraz możliwość wybrania najszybszej lub najkrótszej opcji, których to inteligentne wyliczenie należałoby do zadań systemu.
