Raport Końcowy

1. Wykorzystane narzędzia,instalacja, konfiguracja

PostgreSQL

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.

Instalacja, konfiguracja

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

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.

Wymagania
  • PostgreSQL w wersji 8.2 lub wyższej
  • Kompilator gcc
  • gmake lub make
  • Biblioteka w Proj4 reprojection w wersji 4.5 lub wyższej
  • Biblioteka GEOS geometry w wersji 3.0 lub wyższej
Instalacja i konfiguracja
  • Rozpakowanie pobranej paczki
  • Przejście do powstałego katalogu wykonanie poleceń konfiguracyjnych ./configure, make, make comments, make check w celu sprawdzenia poprawności
  • Instalajca PostGIS poleceniem make install
  • Aktywowanie języka PL/pgSQL polecenie createlang plpgsql [yourdatabase]
  • Załadownie funkcji i obiektów PostGIS psql -d [yourdatabase] -f postgis.sql znajdujących się w [prefix]/share/contrib
  • Załadowanie funkcji przydatnych do manipulowania współrzędnymi pomiędzy systemami psql -d [yourdatabase] -f spatial_ref_sys.sql
  • Załadowanie podpowiedzi do PostGIS psql -d [yourdatabase] -f postgis_comments.sql

Python

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.

Php

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

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/

HTML

Pozwala opisać strukturę informacji zawartych na stronie ( prezentacja wyników).

CSS

Pozwala sformatować informację zawarte na stronie ( prezentacja wyników).

2. OSM a komunikacja publiczna

Linie komunikacji miejskiej

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

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.

Dane dla Krakowa

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

3. Pozyskiwanie danych

Automatyczne

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.

Ręczne wprowadzanie

Więcej informacji o ręcznym wprowadzeniu danych w punkcie 4.

4.Interfejs do prezentacji i obsługi danych w oparciu o diagramy FHF, DFD, STD

Interfejs użytkownika

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 przystanku


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.

Interfejs administratora

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).

Aplikacja służąca dodawaniu nowych linii komunikacyjnych

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 służąca dodawaniu tras linii komunikacyjnych

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)

5. Wdrożenie i utrzymanie

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.

Konfiguracja bazy danych

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.

Konfiguracja części aplikacji odpowiedzialnej za prezencję danych

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";

6. Napotkane problemy

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).

7. Wnioski

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.

8. Rozwój

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.

9. Pliki źródłowe

10. Żrodło

pl/dydaktyka/sbd/2009/projekty/mpk-gis/raport_koncowy.txt · ostatnio zmienione: 2017/07/17 08:08 (edycja zewnętrzna)
www.chimeric.de Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0