Michail Tziotis - Postgraduate Diploma Thesis - An Intermodal ...

ΔΘΝΗΚΟ ΜΔΣ΢ΟΒΗΟ ΠΟΛΤΣΔΥΝΔΗΟ 

ΓΗΑΣΜΖΜΑΣΗΚΟ ΠΡΟΓΡΑΜΜΑ ΜΔΣΑΠΣΤΥΗΑΚΩΝ ΢ΠΟΤΓΩΝ 

“ΓΔΩΠΛΖΡΟΦΟΡΗΚΖ” 

ΜΔΣΑΠΣΤΥΙΑΚΗ ΔΡΓΑ΢ΙΑ: 

ΓΖΜΗΟΤΡΓΗΑ ΔΝΟ΢ ΢ΥΔΓΗΑ΢ΣΖ ΣΑΞΗΓΗΩΝ ΜΔ ΜΜΜ 

ΓΗΑ ΣΟΤ΢ ΔΠΗ΢ΚΔΠΣΔ΢ ΣΖ΢ ΑΘΖΝΑ΢ 

ΔΠΗΒΛΔΠΩΝ: ΣΗΜΟΛΔΩΝ ΢ΔΛΛΖ΢ – ΚΑΘΖΓΖΣΖ΢ Δ.Μ.Π. 

ΜΗΥΑΖΛ ΣΕΗΩΣΖ΢ 

ΓΔΚΔΜΒΡΙΟ΢ 2010

v MT2.1.1el /20110310

THESIS: 

National Technical University of Athens 

Postgraduate Studies Programme on 

“Geoinformatics” 

DEVELOPMENT OF AN INTERMODAL JOURNEY PLANNER 

FOR THE VISITORS OF ATHENS 

SUPERVISOR: TIMOLEON SELLIS – PROF. N.T.U.A. 

MICHAIL TZIOTIS 

DECEMBER 2010

Διπλωματικι Εργαςία Δθμιουργία Ενόσ Σχεδιαςτι Ταξιδιϊν Με ΜΜΜ Για Τουσ Επιςκζπτεσ Τθσ Ακινασ. 

i


ΜΗΝ ΕΚΤΥΠΩΝΕΤΕ ‘Η ΦΩΤΟΤΥΠΕΙΤΕ 

ΑΝ ΔΕΝ ΕΙΝΑΙ ΑΠΑΡΑΙΤΗΤΟ 

ii


iii


΢ύνοψη 

Η Εργασία που αναλύεται στο παρόν τεύχος αποτελεί την Διπλωματική Εργασία για το Μεταπτυχιακό 

Πρόγραμμα ΢πουδών ―Γεωπληροφορική‖ τού Εθνικού Μετσόβιου Πολυτεχνείου. 

Αντικείμενο της Εργασίας ήταν η δημιουργία ενός ΢χεδιαστή Σαξιδιών Με Μέσα Μαζικής 

Μεταφοράς (Intermodal Journey Planner), που να απευθύνεται κατά κύριο λόγο στους επισκέπτες 

της πόλης. Για τον λόγο αυτό η σχετική εφαρμογή σχεδιάστηκε ώστε να είναι αρκετά απλή στην 

χρήση και να μπορεί να δίνει με λίγα βήματα και γρήγορα μια πολύ καλή καθοδήγηση, ενώ ως 

γλώσσα του περιβάλλοντος χρήσης επιλέχθηκε η Αγγλική. 

Η εφαρμογή παρέχεται μέσω ενός web interface και στηρίζεται σε open source λογισμικά. Η 

δημιουργία της στάθηκε ως πλαίσιο για την απόκτηση γνώσης σχετικά με την γλώσσα 

προγραμματισμού Java, την δημιουργία web sites και εφαρμογών, την πλοήγηση με χρήση γράφων, 

όπως επίσης και με την λογική της ανάπτυξης λογισμικού ανοικτού κώδικα και των μεθοδολογιών 

λειτουργίας μιας κοινότητας ανάπτυξης τέτοιου λογισμικού. 

Λέξεις Κλειδιά: 

΢χεδιαστής Σαξίδι Διαδρομή Αθήνα Επισκέπτης Μέσα Μαζικής Μεταφοράς ΜΜΜ Γράφος 

Διπλωματική Γεωπληροφορική Open Trip Planner Tsoop Flex 

iv


v


Abstract 

The Project that is being described in this volume is a Thesis for the ―Geoinformatics‖ 

Postgraduate Studies Programme of the National Technical University of Athens. 

Goal of the Project was the implementation of an Intermodal Journey Planner for Athens‘ region, 

targeting its foreign visitors. Thus, the service was designed to be easy in use and capable to 

provide a good routing solution with only a few steps. Additionally, the language of the user 

interface is English. 

The service is provided by a web interface and is based mainly on open source software. Its 

development was the frame for the acquisition of knowledge regarding Java, Web Sites‘ Creation, 

Rich Internet Applications, Routing, Data Manipulation, as also regarding open source software 

development and team collaboration. 

Keywords: 

Intermodal Journey Planner Route Athens Visitor Mass Transit Graph Thesis Post Graduate 

Geoinformatics OpenTripPlanner Tsoop Flex 

vi


vii


1 ΕΙΣΑΓΩΓΗ ............................................................................................................................. 1 

1.1 

1.2 

1.3 

1.4 

ΣΧΕΔΙΑΣΤΕΣ ΤΑΞΙΔΙΩΝ. ........................................................................................................... 1 

Η ΑΥΞΑΝΟΜΕΝΗ ΣΗΜΑΝΤΙΚΟΤΗΤΑ ΤΩΝ ΣΧΕΔΙΑΣΤΩΝ ΤΑΞΙΔΙΩΝ. .................................................. 3 

ΑΝΤΙΚΕΙΜΕΝΟ ΤΗΣ Ε΢ΓΑΣΙΑΣ. .................................................................................................. 4 

Ο΢ΓΑΝΩΣΗ ΚΕΙΜΕΝΟΥ. .......................................................................................................... 5 

2 ΥΡΑ΢ΧΟΥΣΕΣ ΑΝΑΛΟΓΕΣ ΕΦΑ΢ΜΟΓΕΣ, ΣΤΗΝ ΑΘΗΝΑ ΚΑΙ ΑΛΛΟΥ. .................................... 7 

2.1 ΛΙΓΗ ΙΣΤΟ΢ΙΑ. ....................................................................................................................... 7 

2.2 ΡΑ΢ΟΥΣΙΑΣΗ ΥΡΑ΢ΧΟΥΣΩΝ ΑΝΤΙΣΤΟΙΧΩΝ ΕΦΑ΢ΜΟΓΩΝ. ........................................................... 10 

2.2.1 TRANSPORT FOR LONDON (EFA APPLICATION) ..................................................................... 10 

2.2.2 EFA (ELEKTRONISCHE FAHRPLANAUSKUNFT). ....................................................................... 12 

2.2.3 GOOGLE TRANSIT (ΣΕ ΔΙΑΦΟ΢ΕΣ ΡΕ΢ΙΟΧΕΣ ΑΝΑ ΤΟΝ ΚΟΣΜΟ). ................................................ 14 

2.2.4 RATP (ÎLE-DE-FRANCE). ................................................................................................... 17 

2.2.5 ΑΔΑΜΑΣ (ΑΘΗΝΑ) ......................................................................................................... 22 

2.2.6 ΡΥΛΗ Δ΢ΟΜΟΛΟΓΗΣΗΣ ΡΕ΢ΙΦΕ΢ΕΙΑΣ ΑΤΤΙΚΗΣ .......................................................... 25 

2.2.7 YOUDRIVE (ΑΘΗΝΑ). ....................................................................................................... 28 

2.3 ΓΕΝΙΚΕΣ ΡΑ΢ΑΤΗ΢ΗΣΕΙΣ – ΔΙΑΦΟ΢ΟΡΟΙΗΣΗ ΤΗΣ ΡΑ΢ΟΥΣΑΣ ΥΡΗ΢ΕΣΙΑΣ. ...................................... 31 

3 ΘΕΩ΢ΗΤΙΚΟ ΥΡΟΒΑΘ΢Ο. – ΒΑΣΙΚΕΣ ΡΛΗ΢ΟΦΟ΢ΙΕΣ. ....................................................... 35 

3.1 Γ΢ΑΦΟΙ. ............................................................................................................................ 35 

3.1.1 ΟΙ ΕΡΤΑ ΓΕΦΥ΢ΕΣ ΤΟΥ KÖNIGSBERG. ................................................................................... 37 

3.1.2 ΤΟ Ρ΢ΟΒΛΗΜΑ ΤΗΣ ΔΙΑΔ΢ΟΜΗΣ ΜΕ ΤΟ ΜΙΚ΢ΟΤΕ΢Ο ΚΟΣΤΟΣ. ............................................... 39 

3.2 ΑΛΓΟ΢ΙΘΜΟΙ ΕΡΙΛΥΣΗΣ. ....................................................................................................... 40 

3.2.1 ΓΕΝΙΚΑ ΡΕ΢Ι ΑΛΓΟ΢ΙΘΜΩΝ................................................................................................ 40 

3.2.2 ΕΥ΢ΕΤΙΚΕΣ (HEURISTICS). ................................................................................................... 40 

3.3 ΑΛΓΟ΢ΙΘΜΟΙ ΓΙΑ ΤΗΝ ΕΥ΢ΕΣΗ ΤΗΣ ΒΕΛΤΙΣΤΗΣ ΔΙΑΔ΢ΟΜΗΣ ΑΡΟ ΚΟΜΒΟ ΣΕ ΚΟΜΒΟ. .................... 41 

3.3.1 ΓΕΝΙΚΑ. .......................................................................................................................... 41 

3.3.2 Ο ΑΛΓΟ΢ΙΘΜΟΣ ΤΟΥ DIJKSTRA. .......................................................................................... 42 

3.3.3 Ο ΑΛΓΟ΢ΙΘΜΟΣ Α* (A-STAR). ........................................................................................... 44 

3.3.4 Ο ΑΛΓΟ΢ΙΘΜΟΣ/ΤΕΧΝΙΚΗ ‘CONTRACTION HIERARCHIES’ (‘ΣΥΝΑΙ΢ΕΤΙΚΕΣ ΙΕ΢Α΢ΧΙΕΣ’). ................. 48 

3.4 

ΤΟ ΔΙΚΤΥΟ ΜΜΜ ΤΗΣ ΑΘΗΝΑΣ. .......................................................................................... 54 

viii


4 ΑΡΑΙΤΗΣΕΙΣ ΚΑΙ ΣΧΕΔΙΑΣΜΟΣ ΥΡΗ΢ΕΣΙΑΣ. ....................................................................... 57 

4.1 ΤΙ ΕΙΝΑΙ ΚΑΙ ΣΕ ΡΟΙΟΥΣ ΑΡΕΥΘΥΝΕΤΑΙ Η ΥΡΗ΢ΕΣΙΑ. ................................................................. 57 

4.2 ΒΑΣΙΚΕΣ Α΢ΧΕΣ ΤΟΥ ΣΧΕΔΙΑΣΜΟΥ. ......................................................................................... 58 

4.3 Τ΢ΟΡΟΙ ΚΑΙ ΜΕΣΑ ΡΑ΢ΟΧΗΣ ΤΗΣ ΥΡΗ΢ΕΣΙΑΣ. .......................................................................... 60 

4.4 Τ΢ΟΡΟΙ ΚΑΙ Ε΢ΓΑΛΕΙΑ ΥΛΟΡΟΙΗΣΗΣ. ...................................................................................... 61 

4.5 ΟΙΚΟΝΟΜΙΚΑ ΘΕΜΑΤΑ. ....................................................................................................... 61 

4.6 ΟΝΟΜΑΣΙΑ ΤΗΣ ΥΡΗ΢ΕΣΙΑΣ. ................................................................................................. 62 

4.7 ΡΕ΢ΙΓ΢ΑΦΗ ΤΗΣ ΥΡΗ΢ΕΣΙΑΣ ΠΣΟΝ ΑΦΟ΢Α ΤΟΝ Χ΢ΗΣΤΗ. .......................................................... 62 

4.7.1 ΓΕΝΙΚΑ. .......................................................................................................................... 63 

4.7.2 Ο ΧΑ΢ΤΗΣ. ...................................................................................................................... 64 

4.7.3 ΕΡΙΛΟΓΕΣ ΤΑΞΙΔΙΟΥ. ......................................................................................................... 64 

4.7.4 ΑΡΟΤΕΛΕΣΜΑΤΑ. ............................................................................................................. 66 

4.8 ΡΕ΢ΙΓ΢ΑΦΗ ΤΗΣ ΥΡΗ΢ΕΣΙΑΣ ΠΣΟΝ ΑΦΟ΢Α ΤΗΝ ΑΝΑΡΤΥΞΗ. ..................................................... 67 

5 ΔΕΔΟΜΕΝΑ. ...................................................................................................................... 69 

5.1 ΔΕΔΟΜΕΝΑ ΔΙΚΤΥΟΥ ΜΜΜ. ............................................................................................... 69 

5.1.1 Ρ΢ΩΤΟΓΕΝΗ ΔΕΔΟΜΕΝΑ ΜΜΜ. ....................................................................................... 72 

5.1.2 GENERAL TRANSIT FEED SPECIFICATION (GTFS) ΚΑΙ ΔΗΜΙΟΥ΢ΓΙΑ ΤΟΥ FEED. ............................. 77 

5.2 ΔΕΔΟΜΕΝΑ ΟΔΙΚΟΥ ΔΙΚΤΥΟΥ. ............................................................................................. 107 

5.2.1 ΓΕΝΙΚΑ. ........................................................................................................................ 107 

5.2.2 OPEN STREET MAP (OSM). ............................................................................................ 107 

5.2.3 ΡΑ΢ΑΤΗ΢ΗΣΕΙΣ. ............................................................................................................. 109 

5.3 ΔΗΜΙΟΥ΢ΓΙΑ Γ΢ΑΦΟΥ. ....................................................................................................... 110 

6 ΥΛΟΡΟΙΗΣΗ ΣΥΣΤΗΜΑΤΟΣ. ............................................................................................. 111 

6.1 Ε΢ΓΑΛΕΙΑ ΡΟΥ Χ΢ΗΣΙΜΟΡΟΙΗΘΗΚΑΝ. .................................................................................. 111 

6.1.1 JAVA. ........................................................................................................................... 112 

6.1.2 ECLIPSE. ....................................................................................................................... 114 

6.1.3 APACHE SUBVERSION. .................................................................................................... 114 

6.1.4 APACHE MAVEN. ........................................................................................................... 115 

6.1.5 APACHE TOMCAT. .......................................................................................................... 115 

6.1.6 APACHE HTTP SERVER. .................................................................................................. 116 

6.1.7 ALIVEPDF. ................................................................................................................... 116 

6.1.8 OPEN STREET MAP (OSM). ............................................................................................ 117 

6.1.9 POSTGRESQL. ............................................................................................................... 117 

6.1.10 GOOGLE MAPS – GOOGLE MAPS API. ............................................................................ 118 

6.1.11 GOOGLE GEOCODING API. ............................................................................................ 120 

6.1.12 GOOGLE DIRECTIONS API. ............................................................................................ 121 

6.1.13 

ADOBE FLEX 4, ADOBE FLASH BUILDER 4. ........................................................................ 121 

ix


6.1.14 OPENTRIPPLANNER (OTP). ........................................................................................... 123 

6.1.15 ΒΑΣΙΚΟΙ ΣΥΜΜΕΤΟΧΟΙ. ................................................................................................. 124 

6.1.16 ΚΥ΢ΙΑ ΧΑ΢ΑΚΤΗ΢ΙΣΤΙΚΑ ΤΟΥ OTP. .................................................................................. 125 

6.1.17 ΤΑ ΤΜΗΜΑΤΑ ΡΟΥ ΑΡΟΤΕΛΟΥΝ ΤΟΝ OPEN TRIP PLANNER. ............................................... 128 

6.2 ΔΟΜΗ ΣΥΣΤΗΜΑΤΟΣ. ........................................................................................................ 134 

6.3 ΛΕΙΤΟΥ΢ΓΙΕΣ Χ΢ΗΣΤΗ. ........................................................................................................ 135 

6.3.1 ΓΕΝΙΚΑ ΓΙΑ ΤΗΝ ΕΦΑ΢ΜΟΓΗ Χ΢ΗΣΤΗ. ................................................................................ 135 

6.3.2 ΛΕΙΤΟΥ΢ΓΙΚΗ ΢ΟΗ ΤΗΣ ΕΦΑ΢ΜΟΓΗΣ Χ΢ΗΣΤΗ. ..................................................................... 137 

6.3.3 ΛΕΙΤΟΥ΢ΓΙΚΗ ΑΝΑΛΥΣΗ ΤΗΣ ΕΦΑ΢ΜΟΓΗΣ Χ΢ΗΣΤΗ. .............................................................. 138 

6.4 ΤΕΧΝΙΚΗ ΡΕ΢ΙΓ΢ΑΦΗ. ........................................................................................................ 161 

6.4.1 ΓΕΝΙΚΑ. ........................................................................................................................ 164 

6.4.2 ΛΕΙΤΟΥ΢ΓΙΕΣ ΣΤΟΝ HTTP SERVER. .................................................................................... 164 

6.4.3 ΛΕΙΤΟΥ΢ΓΙΕΣ ΣΤΟΝ TOMCAT SERVER. ................................................................................ 165 

6.4.4 ΛΕΙΤΟΥ΢ΓΙΕΣ ΡΟΥ Ρ΢ΑΓΜΑΤΟΡΟΙΟΥΝΤΑΙ ΜΕ Χ΢ΗΣΗ ΤΩΝ ΥΡΗ΢ΕΣΙΩΝ ΡΟΥ ΡΑ΢ΕΧΟΝΤΑΙ ΑΡΟ ΤΗΝ 

GOOGLE. .................................................................................................................................. 166 

6.4.5 ROUTING ENGINE. ......................................................................................................... 167 

6.4.6 ΕΥ΢ΕΣΗ ΕΝΑΛΛΑΚΤΙΚΩΝ Γ΢ΑΜΜΩΝ. ................................................................................. 181 

6.4.7 ΣΥΝΟΡΤΙΚΟ ΔΙΑΓ΢ΑΜΜΑ ΤΗΣ ΔΟΜΗΣ ΤΟΥ ΣΥΣΤΗΜΑΤΟΣ ΚΑΙ ΤΩΝ ΣΥΝΔΕΣΕΩΝ. ....................... 188 

6.4.8 Ρ΢ΟΓ΢ΑΜΜΑΤΙΣΤΙΚΗ ΔΟΜΗ ΤΗΣ ΕΦΑ΢ΜΟΓΗΣ Χ΢ΗΣΤΗ & ΣΥΝΔΕΣΕΙΣ. .................................... 189 

7 ΡΑ΢ΑΔΕΙΓΜΑ Χ΢ΗΣΗΣ. .................................................................................................... 217 

8 ΣΥΜΡΕ΢ΑΣΜΑΤΑ – ΣΚΕΨΕΙΣ - ΕΡΟΜΕΝΑ ΒΗΜΑΤΑ. ...................................................... 229 

8.1 ΓΕΝΙΚΑ. ........................................................................................................................... 229 

8.2 ΡΕ΢ΙΒΑΛΛΟΝ ΕΦΑ΢ΜΟΓΗΣ. ................................................................................................ 230 

8.3 Ρ΢ΟΤΑΣΕΙΣ ΤΑΞΙΔΙΟΥ. ........................................................................................................ 231 

8.3.1 ΔΕΔΟΜΕΝΑ ΔΙΚΤΥΟΥ ΜΜΜ. .......................................................................................... 231 

8.3.2 Χ΢ΗΣΙΜΟΡΟΙΟΥΜΕΝΟΙ ΧΑ΢ΤΕΣ. ....................................................................................... 233 

8.3.3 ΑΛΓΟ΢ΙΘΜΟΙ ΑΝΑΖΗΤΗΣΗΣ Ρ΢ΟΤΑΣΕΩΝ ΤΑΞΙΔΙΟΥ. ............................................................. 233 

8.4 

ΒΕΛΤΙΩΣΕΙΣ – ΜΕΛΛΟΝΤΙΚΕΣ ΕΡΕΚΤΑΣΕΙΣ. ............................................................................. 237 

x


xi


1Εισαγωγή 

1.1 ΢χεδιαστές Σαξιδιών. 

Σα τελευταία χρόνια, η ανάπτυξη των υπολογιστικών συσκευών και των επικοινωνιών, σε συνδυασμό 

με τις τεχνολογίες εντοπισμού θέσης, έχουν δώσει σημαντική ώθηση στα συστήματα πλοήγησης. 

Κατά κανόνα, τα συστήματα αυτά αφορούν 

το οδικό δίκτυο και τις μετακινήσεις με το 

αυτοκίνητο. ΋μως, έχει υπάρξει εξέλιξη και σε 

συστήματα που αφορούν την μετακίνηση 

πεζή, με ποδήλατο, ή ακόμη και με τις 

σιδηροδρομικές και αεροπορικές 

μεταφορές. 

΢ε όλες αυτές τις περιπτώσεις επιλύεται 

ένας γράφος, στον οποίο κόμβοι μπορεί 

να είναι π.χ. οι διασταυρώσεις, τα 

σημεία ενδιαφέροντος, οι σιδηροδρομικοί 

σταθμοί, τα αεροδρόμια, κοκ, ενώ σύνδεσμοι μπορεί να είναι οι δρόμοι, οι 

σιδηροδρομικές και αεροπορικές συνδέσεις, κ.α.. 

1


΢ε κάθε σύνδεσμο ορίζονται βάρη, είτε σε αριθμητική μορφή, όπως είναι η απόσταση, ο χρόνος 

διέλευσης, το οικονομικό κόστος, κτλ, είτε σε ποιοτική μορφή, όπως είναι η ασφάλεια διέλευσης, η 

δυνατότητα διέλευσης για διάφορες κατηγορίες χρηστών, ή ακόμη και το ταξιδιωτικό ενδιαφέρον. 

Οι ΢χεδιαστές Σαξιδιών (Trip Planners, ή Journey Planners), κάνουν χρήση διάφορων αλγόριθμων 

(Dijkstra, A* [Α-Star], κ.α.) έτσι ώστε να ελαχιστοποιούν το συνολικό κόστος, σε συνδυασμό με τους 

όποιους περιορισμούς τίθενται. Π.χ. το ζητούμενο σε ένα ταξίδι με αυτοκίνητο μπορεί να είναι ο 

περιορισμός του χρόνου ταξιδιού, με αποφυγή πιθανόν των οδών όπου πρέπει να πληρωθούν διόδια. 

Εικόνα 1: Επίλυση ενός γράφου με τον αλγόριθμο του Dijkstra, με χρήση λογισμικού που οπτικοποιεί 

την διαδικασία επίλυσης κατά βήμα. Πηγή: http://www.uweschmidt.org. 

Πέρα από την «μηχανή» επίλυσης του σχετικού γράφου, ένας ΢χεδιαστής Σαξιδιού αποτελείται 

συνήθως κι από κάποιο ή κάποια περιβάλλοντα χρήστη (π.χ. σε υπολογιστή, σε κινητό τηλέφωνο), 

διάφορους geolocators για την εύρεση διευθύνσεων και σημείων ενδιαφέροντος, ενώ μπορεί να 

παρέχει ακόμη και συνδέσεις σε διευθύνσεις που διευκολύνουν την πραγματοποίηση του 

προτεινόμενου ταξιδιού, όπως είναι π.χ. για την αγορά εισιτηρίων ενός μεταφορικού μέσου. 

2


΢τα πλαίσια της ενοποίησης και ολοκλήρωσης των τεχνολογιών κι υπηρεσιών, οι ΢χεδιαστές Σαξιδιών 

εξελίσσονται συνεχώς, είτε με το να ενσωματώνουν άλλες υπηρεσίες, είτε με το ενσωματώνονται 

αυτοί οι ίδιοι σε κάποιες άλλες, γενικότερες, π.χ. σε ταξιδιωτικά portals. 

Γίνεται φανερό πως, για την όσο το δυνατόν αποτελεσματικότερη λειτουργία ενός ΢χεδιαστή 

Σαξιδιών, μεγάλη σημαντικότητα έχουν τα δεδομένα που αυτός χρησιμοποιεί, τόσο ως προς την 

μορφή τους, όσο και ως προς την πληρότητά τους και την εγκυρότητά τους. 

1.2 Η Αυξανόμενη ΢ημαντικότητα των ΢χεδιαστών Σαξιδιών. 

Η εξέλιξη της τεχνολογίας, ιδίως στον τομέα των τηλεπικοινωνιών και κατ‘ επέκταση στην 

φορητότητα των τεχνολογικών συσκευών και των παρεχόμενων υπηρεσιών, έχει δώσει εκρηκτική 

ώθηση σε πάρα πολλούς τομείς. ΢ε αυτό έχει συνεισφορά και η ολοένα και μεγαλύτερη εξοικείωση 

του πληθυσμού με την τεχνολογία, κάτι το οποίο γίνεται και αντίστροφα, καθώς η εξέλιξη της 

τεχνολογίας δεν την κάνει αυτήν κατά ανάγκη πολυπλοκότερη, αλλά σε αρκετές περιπτώσεις 

φιλικότερη. 

Η βελτίωση της δυνατότητας δορυφορικού εντοπισμού της θέσης, τόσο λόγω της μεγαλύτερης 

ευαισθησίας των δεκτών, του περιορισμού του μεγέθους τους και του κόστους κτήσης τους, όσο και 

λόγω της άρσης της επιλεκτικής διαθεσιμότητας (selective availability), δημιούργησε τις συνθήκες 

στις οποίες βρήκαν πρόσφορο έδαφος να παρουσιαστούν και να διεισδύσουν σε μεγάλο κοινό οι 

΢χεδιαστές Σαξιδιών για τις μετακινήσεις με αυτοκίνητο. 

Τπήρξαν υλοποιήσεις και πριν την χρήση του GPS, με εφαρμογές που είχαν αναπτυχθεί για PCs και 

συνεισέφεραν στην ανάπτυξη σχετικών αλγορίθμων (π.χ MS AutoRoute), όμως η αποδοχή από το 

κοινό δεν ήταν ιδιαίτερα μεγάλη. Αφενός γιατί απαιτούνταν η γνώση χρήσης HY, αφετέρου γιατί ο 

προσχεδιασμός της διαδρομής δεν είναι το ίδιο ελκυστικός και το ίδιο αποτελεσματικός με την κατά 

την οδήγηση πλοήγηση. 

Η χρήση των ΢χεδιαστών Σαξιδιών στο αυτοκίνητο βοήθησε & εξακολουθεί να βοηθάει αρκετούς 

ανθρώπους να κινηθούν πιο εύκολα, γρήγορα, με μεγαλύτερη άνεση και ίσως και ασφάλεια, στα 

οδικά δίκτυα που έχουν γιγαντωθεί τόσο ώστε να είναι σε αρκετές περιπτώσεις δύσκολη, όχι μόνο η 

απομνημόνευση της γενικής μορφής αυτών και αρκετών χαρακτηριστικών τους σημείων, αλλά και η 

ίδια η διαδικασία επιλογής της συντομότερης διαδρομής, ότι συνεισφέρει δηλαδή στην πλοήγηση με 

χρήση του ανθρώπινου εγκεφάλου. 

Ψφέλεια από τους ΢χεδιαστές Σαξιδιών δεν υπάρχει όμως μόνο για τον κάθε άνθρωπο ξεχωριστά, 

αλλά και συνολικά για το σύστημα μεταφορών. Αφενός γιατί όταν μεγάλο κομμάτι του πληθυσμού 

πηγαίνει από ένα σημείο σε κάποιο άλλο, ακολουθώντας την συντομότερη διαδρομή, περιορίζεται η 

3


μη ωφέλιμη φόρτιση του δικτύου, η κατανάλωση καυσίμων, και η εκπομπή ρύπων, αλλά κι 

αφετέρου, γιατί με την μετάδοση πληροφοριών τροχαίας κίνησης σε πραγματικό χρόνο, γίνεται 

δυνατόν ολοένα και περισσότερο να επιτυγχάνεται καλύτερη διαχείριση της κυκλοφορίας. 

΢την σημερινή εποχή έχει γίνει φανερό ότι η δημιουργία νέων δρόμων, ειδικά εντός αστικών 

περιοχών, ελάχιστα έχει να προσφέρει στην βελτίωση των μετακινήσεων, και με πολύ μεγάλο 

μάλιστα κόστος, καθώς οι απαλλοτριώσεις και οι πιθανότατες κατεδαφίσεις είναι πανάκριβες, έως 

κοινωνικά απαγορευτικές. Αντί λοιπόν της δημιουργίας νέων δρόμων, γίνεται προσπάθεια για την 

βελτιστοποίηση της απόδοσης των υφιστάμενων, κυρίως μέσω της τεχνολογίας. Έτσι είναι προφανής, 

σύμφωνα και με τα προηγούμενα, η συνεισφορά των ΢χεδιαστών Σαξιδιών στην προσπάθεια αυτή. 

Η μεγαλύτερη βελτιστοποίηση της απόδοσης του οδικού δικτύου, και κυρίως του συνολικού δικτύου 

μεταφορών, είχε γίνει από πολύ παλιά φανερό όμως ότι επιτυγχάνεται με την ευνόηση της χρήσης 

των Μέσων Μαζικής Μεταφοράς. ΢το σημείο αυτό ακριβώς είναι που έρχονται να συνεισφέρουν 

σημαντικά οι ΢χεδιαστές Σαξιδιών με ΜΜΜ, πολύ περισσότερο συνεπώς από ότι οι αντίστοιχοι για τα 

αυτοκίνητα. 

Η πολυπλοκότητα των δικτύων των Μέσων Μαζικής Μεταφοράς έχει γιγαντωθεί σε αντιστοιχία με 

αυτή των οδικών δικτύων, καθιστώντας έτσι δύσκολη την αποδοτικότερη αξιοποίηση τους από τον 

πληθυσμό. 

Ακόμη, ο σωστός σχεδιασμός ενός ταξιδιού με ΜΜΜ είναι περισσότερο κρίσιμος σε σχέση με τον 

αντίστοιχο για ταξίδι με αυτοκίνητο, καθώς τα ΜΜΜ έχουν δρομολόγια, κάτι που σημαίνει ασυνέχεια 

στην δυνατότητα μετακίνησης. Αν δηλαδή κάποιος χάσει ελάχιστα λεπτά σε ένα σκέλος του ταξιδιού, 

αυτό μπορεί να του κοστίσει πολύ περισσότερο στον συνολικό χρόνο, καθώς πιθανότατα θα 

δημιουργηθούν σημαντικά μεγαλύτεροι χρόνοι αναμονής για τα ΜΜΜ των επόμενων σκελών του 

ταξιδιού. 

1.3 Αντικείμενο Σης Εργασίας. 

Η Εργασία που αναλύεται στο παρόν τεύχος πραγματοποιήθηκε ως Διπλωματική Εργασία για το 

Μεταπτυχιακό Πρόγραμμα ΢πουδών ―Γεωπληροφορική‖ του Εθνικού Μετσόβιου Πολυτεχνείου. 

Αντικείμενό της είναι η δημιουργία και η λειτουργία ενός ΢χεδιαστή Σαξιδιών για τις μετακινήσεις με 

Μέσα Μαζικής Μεταφοράς (ΜΜΜ) στην περιοχή της Αθήνας. Απευθύνεται κυρίως σε επισκέπτες της 

Πόλης και για αυτό έχει υλοποιηθεί υιοθετώντας την Αγγλική γλώσσα για την επικοινωνία με τον 

χρήστη. Μελλοντική εξέλιξη μπορεί να περιέχει φυσικά κι άλλες γλώσσες. Ας σημειωθεί ότι οι 

επισκέπτες μιας Πόλης σαν την Αθήνα βασίζονται πολύ περισσότερο στην χρήση των ΜΜΜ για τις 

4


μετακινήσεις τους από ότι οι μόνιμοι κάτοικοι, αφού συνήθως δεν διαθέτουν κατά την επίσκεψη το 

αυτοκίνητό τους, ενώ και η ενοικίαση αυτοκινήτων στις αστικές περιοχές είναι περιορισμένη. 

Η επικοινωνία με τον χρήστη γίνεται μέσω ενός web interface, στο οποίο μπορεί εύκολα να έχει 

κάποιος πρόσβαση από ηλεκτρονικό υπολογιστή, ή και από κινητό τηλέφωνο με σχετικά εξελιγμένο 

browser και σύνδεση mobile Internet. Από την αρχή της εκπόνησης, και με δεδομένο το σε ποιους 

απευθύνεται, τέθηκε ως πλαίσιο να διαθέτει η εφαρμογή ένα απλό περιβάλλον χρήσης, από το οποίο 

με λίγα βήματα και σε σύντομο χρόνο να λαμβάνει κάποιος μια πολύ καλή πρόταση διαδρομής, με 

λεπτομερή επεξήγησή της. 

Είναι προφανές ότι δεν υπάρχει ιδιαίτερος λόγος ένας επισκέπτης σε μία Πόλη να πρέπει να μπει 

στην διαδικασία εκμάθησης μιας, έστω και λίγο, πολύπλοκης εφαρμογής. Επίσης, τα σημεία που τον 

ενδιαφέρουν είναι σχετικά περιορισμένα, ενώ δεν τον νοιάζει αν η λύση που του προτείνεται είναι η 

τελειότερη δυνατή, καθώς την συγκεκριμένη διαδρομή θα την πραγματοποιήσει ίσως για μία μόνο 

φορά. 

1.4 Οργάνωση Κειμένου. 

Σο παρόν κείμενο, το οποίο παρουσιάζει και αναλύει την εκπονηθείσα Εργασία, ακολουθεί στη 

συνέχεια την εξής δομή: 

΢το Κεφάλαιο 2 γίνεται παρούσιαση υφιστάμενων εφαρμογών που λειτουργούν ανά τον κόσμο 

και σχετίζονται με την σχεδίαση ταξιδιών με Μέσα Μαζικής Μεταφοράς. ΢το τέλος 

παρουσιάζονται εφαρμογές που λειτουργούν για την Αθήνα, και επισημαίνονται τα σημεία τα 

οποία έρχεται να υιοθετήσει, επεκτείνει, ή κυρίως να καλύψει εξαρχής η υφιστάμενη Εργασία. 

΢το Κεφάλαιο 3 γίνεται μία αναφορά στο θεωρητικό υπόβαθρο πάνω στο οποίο βασίζεται η 

Εργασία. Περισσότερο παρουσιάζεται σαν συνοπτική συγκέντρωση όλων των σχετικών θεμάτων, 

για ενθύμιση στον αναγνώστη, καθώς το παρόν Κείμενο απευθύνεται σε αναγνώστη που είναι 

ήδη γνώστης του γενικού έστω πλαισίου αυτών. 

΢το Κεφάλαιο 4 γίνεται η περιγραφή των απαιτήσεων από την Τπηρεσία της Εργασίας, δηλαδή 

του Λειτουργικού ΢χεδιασμού της, γίνεται αναφορά στις επιλογές που πραγματοποιήθηκαν και 

5


με ποιό σκεπτικό έγιναν αυτές, π.χ. διαθεσιμότητα δεδομένων κτλ., ενώ αναφέρονται και 

μελλοντικές επεκτάσεις που λήφθηκαν υπόψη. 

΢το Κεφάλαιο 5 γίνεται παρουσίαση των θεμάτων που σχετίζονται με τα δεδομένα. 

Περιγράφεται το πρότυπο GTFS, και το πως από τα πρωτογενή δεδομένα του Οργανισμού 

Αστικών ΢υγκοινωνιών δημιουργήθηκε ένα τέτοιο GT Feed για τα ΜΜΜ της Αθήνας. Γίνεται 

εκτενής αναφορά, τόσο για τα προβλήματα που υπάρχουν, όσο και για τους τρόπους 

αντιμετώπισής τους, παράλληλα με την ανάπτυξη της λογικής που ακολουθήθηκε. Επίσης, 

παρουσιάζονται ανάλογα και τα δεδομένα που αφορούν το οδικό δίκτυο της περιοχής, το οποίο 

χρησιμοποιείται κι αυτό μαζί με τα προηγούμενα για την δημιουργία του γράφου του 

΢υστήματος. 

΢το Κεφάλαιο 6 γίνεται αρχικά μία σύντομη περιγραφή των εργαλείων, τεχνολογιών και 

προτύπων που χρησιμοποιήθηκαν για την υλοποίηση της Τπηρεσίας, και στην συνέχεια 

αναλυέται με αρκετό βαθμό λεπτομέρειας η ανάπτυξη της Τπηρεσίας. Επίσης, στο Κεφάλαιο 

αυτό γίνεται αναφορά του πως η Εφαρμογή διαμορφώθηκε ανάλογα με την αξιολόγηση των 

αποτελεσμάτων και τον επανασχεδιασμό των σχετικών τμημάτων της Εφαρμογής ώστε αυτά να 

προκύπτουν καλύτερα. 

΢το Κεφάλαιο 7 παρουσιάζεται ένα παράδειγμα χρήσης της Τπηρεσίας. 

΢το Κεφάλαιο 8, που είναι και το επιλογικό του Κειμένου, αναφέρονται συμπεράσματα, όπως 

επίσης σκέψεις και προτάσεις για την βελτίωση, αλλά και εξέλιξη, της Τπηρεσίας. 

΢το τέλος παρατίθενται βιβλιογραφικές, και όχι μόνο, αναφορές, όπου ο αναγνώστης μπορεί να 

ξεκινήσει την αναζήτησή του για περισσότερες πληροφορίες σχετικά με διάφορα θέματα που 

αναφέρονται στο παρόν Κείμενο. 

6


2Τπάρχουσες Ανάλογες 

Εφαρμογές, στην Αθήνα και 

Αλλού. 

2.1 Λίγη Ιστορία. 

΢αν πρώτο πρόβλημα σχετικό με την πλοήγηση σε ένα δίκτυο θεωρείται το ―Επτά Γέφυρες του 

Königsberg‖, το οποίο τέθηκε το 1735 από τον Leonard Euler [Αναφορά #38: Euler Leonard 

(1741)), Solutio problematis ad geometriam situs pertinentis, Commentarii academiae 

scientiarum Petropolitanae] και το οποίο τον οδήγησε στην ανάπτυξη της θεωρίας των Γράφων. 

Περισσότερες πληροφορίες για το πρόβλημα δίνονται σε επόμενο σημείο του Κειμένου, στην 

παράγραφο 3.1.1. 

Ο Αλγόριθμος του Dijkstra, ο οποίος δημοσιεύθηκε το 1959 [Αναφορά #39: Dijkstra Edsger Wybe 

(1959), A note on two problems in connexion with graphs, Numerische Mathematik 1: 269–271] 

και χρησιμοποιείται και σήμερα ως η βάση για κάθε Journey ή Route Planner, είναι το επόμενο 

βήμα, το οποίο έκανε πιο άμεση την σύνδεση του προβλήματος της εύρεσης μιας διαδρομής σε έναν 

7


Γράφο με τα υπολογιστικά συστήματα. Περισσότερες πληροφορίες για τον Αλγόριθμο του Dijkstra 

μπορεί κανείς να βρει επίσης στην σχετική παράγραφο (3.3.2) του Κειμένου. 

Αρχικά ο σχεδιασμός ενός ταξιδιού με διάφορα μέσα γινόταν, ελλείψει και της σχετικής ελάχιστης 

τεχνολογίας, καθαρά με την χρήση του ανθρώπινου εγκεφάλου. Άλλωστε τα μέσα συγκοινωνίας δεν 

ήταν πάρα πολλά, τα δρομολόγια ήταν εξίσου λίγα, και η ανάγκη για συχνή πραγματοποίηση 

διαφορετικών ταξιδιών, με συνδυασμό μάλιστα διαφόρων μέσων, ήταν αρκετά περιορισμένη. 

Σις ανάγκες για τον σχεδιασμό ενός ταξιδιού τις κάλυπταν κατά κανόνα μερικοί χάρτες, κάποιοι 

πίνακες δρομολογίων, και φυσικά κάποιο υπάλληλοι των συγκοινωνιακών εταιρειών, οι οποίοι 

προσπαθούσαν να ενημερώσουν και να βοηθήσουν, είτε πίσω από ένα γκισέ, είτε πίσω από ένα 

τηλεφωνικό κέντρο. 

΢ημαντική τομή στην εξυπηρέτηση του επιβατικού κοινού για τον σχεδιασμό ενός ταξιδίου θεωρείται 

η δημιουργία του πρώτου διαγραμματικού χάρτη για το metro του London, ο οποίος σχεδιάστηκε 

από τον Harry Beck το 1933. Ο Beck ήταν υπάλληλος του Τπόγειου ΢ιδηροδρόμου, και πρώτος 

αυτός συνειδητοποίησε ότι οι επιβάτες δεν νοιάζονταν για τις φυσικές θέσεις των σταθμών και τις 

διαδρομές, παρά μόνο για την τοπολογία, δηλαδή πως μπορούν να φτάσουν από έναν σταθμό σε 

έναν άλλον, και τι εξυπηρετεί ο κάθε σταθμός. Η πρόσεγγιση του Becker είναι όμοια με αυτή των 

διγραμμάτων ηλεκτρικών κυκλωμάτων, αν και πηγή έμπνευσής του για τον σχεδιασμό ήταν τα 

διαγράμματα για τα υπόγεια συστήματα αποχέτευσης. 

Εικόνα 2: Ο πρώτος Διαγραμματικός Φάρτης του Harry Beck (1933) για το Metro του London. 

8


Ο τρόπος απεικόνισης ενός μεταφορικού συστήματος που εισήγαγε ο Becker, σταδιακά έγινε ο 

τρόπος απεικόνισης όλων των πολύπλοκων δικτύων ανά τον κόσμο, ενώ ειδικά ο χάρτης του London 

έχει γίνει πλέον εμβληματικός και πηγή έμπνευσης διάφορων καλλιτεχνικών έργων. 

Οι πρώτοι ηλεκτρονικοί ΢χεδιαστές Σαξιδίων ήταν εφαρμογές που αποτελούσαν μέρος ενός 

συστήματος κρατήσεων για μεταφορές υψηλής αξίας, όπως είναι π.χ. οι αερομεταφορές και οι 

σιδηροδρομικές μεταφορές ποιότητας. Οι πρώτες αυτές εφαρμογές CRS (Computer Reservations 

Systems) χρησιμοποιούσαν mainframe βάσεις δεδομένων και OLTP συστήματα (OnLine Transaction 

Processing). Φαρακτηριστικά αναφέρονται οι εφαρμογές Sabre (Semi-Automatic Business 

Research Environment, αρχικά για την American Airlines), Amadeus (αρχικά για τις Air France, 

Lufthansa, Iberia, SAS), Galileo (αρχικά ως Apollo της United Airlines, συμμετείχε και η Ολυμπιακή 

ως αντιπρόσωπος), Worldspan (από την συνένωση του PARS της TWA και του DATAS II της DELTA) 

και η Rail Journey Information System, η οποία αναπτύχθηκε από την British Rail. Οι μετεξελίξεις 

αυτών των συστημάτων λειτουργούν ακόμη και σήμερα, έχοντας υπηρεσίες και για άλλους τομείς, 

όπως οι κρατήσεις ξενοδοχειακών δωματίων και η ενοικίαση αυτοκινήτων. 

Με την ανάπτυξη της τεχνολογίας, και ιδιαίτερα όσο αυτή διαχεόταν ολοένα και περισσότερο προς 

τον απλό άνθρωπο, αναπτύχθηκαν σταδιακά νέα κανάλια, άμεσης μάλιστα επικοινωνίας, μεταξύ του 

(υποψήφιου) επιβάτη και των συστημάτων σχεδιασμού ταξιδίων και κράτησης εισιτηρίων. Σέτοια νέα 

κανάλια είναι π.χ. οι προσωπικοί υπολογιστές, τα SMS, και πιο πρόσφατα οτιδήποτε είναι 

διασυνδεδεμένο μέσω internet, όπως π.χ. τα κινητά τηλέφωνα. 

΢τις αρχές της δεκαετίας του 2000 έγιναν διαθέσιμοι οι πρώτοι web planners που αφορούσαν 

αστικές συγκοινωνίες μητροπολιτικών περιοχών, όπως είναι π.χ. ο planner του Transport For London 

(παράγραφος 2.2.1). Σην ίδια περίπου εποχή η υπηρεσία Traveline παρείχε multimodal σχεδιασμό 

ταξιδίων για ολόκληρο το Ηνωμένο Βασίλειο. 

΢ταδιακά οι σχεδιαστές ταξιδίων άρχισαν να γίνονται διαθέσιμοι από ολοένα και περισσότερες 

εταιρείες μεταφορών, με επόμενο βήμα κάθε φορά να είναι η συνένωση συστημάτων, ώστε να 

συμπεριλαμβάνονται περισσότερες εταιρείες, περισσότερα μέσα, και μεγαλύτερες περιοχές. 

Λόγω της ραγδαίας γιγάντωσης αυτών των συστημάτων, ολόενα και περισσότερο γίνεται φανερή η 

ανάγκη υιοθέτησης προτύπων, αλλά και δημιουργίας κατανεμημένων συστημάτων, όπου κάθε 

επιμέρους σύστημα θα είναι υπεύθυνο για τον λεπτομερή σχεδιασμό μόνο ενός τμήματος του 

ταξιδίου. Ήδη έχουν δημιουργηθεί κάποια σχετικά πρωτόκολλα, όπως είναι το EU Spirit, το 

JourneyWeb, το Delpfi, αλλά και το Xephos, ενώ κάποιοι σχεδιαστές λειτουργούν στην ουσία ως 

metaplanners, αξιοποιούν δηλαδή τα Interfaces διαφόρων σχεδιαστών και συνδυάζουν τα 

αποτελέσματα. 

9


2.2 Παρουσίαση Τπαρχουσών Αντίστοιχων Εφαρμογών. 

΢τη συνέχεια γίνεται μια σύντομη παρουσίαση εφαρμογών για τον ΢χεδιασμό Σαξιδιών με ΜΜΜ σε 

ένα αστικό περιβάλλον, από την Ελλάδα κι από άλλες χώρες. Οι εφαρμογές που παρουσιάζονται 

είναι ενδεικτικές, καθώς υπάρχει αυτή την στιγμή μεγάλος αριθμός τέτοιων εφαρμογών, 

προσβάσιμες μέσω του WWW. Σο μεγάλο πλήθος τους είναι αποτέλεσμα της έντονης 

διαφορετικότητας που υπάρχει στις δομές και τη λειτουργία των δικτύων ΜΜΜ, όπως επίσης και στις 

ανάγκες του επιβατικού κοινού κάθε πόλης. Έτσι, η κάθε εφαρμογή μπορεί και να βασίζεται σε 

κάποιον σχετικό κορμό υλοποίησης, περιέχει όμως αρκετά στοιχεία προσαρμογής. 

2.2.1 Transport For London (EFA application) 

To Transport For London (Tfl) είναι ο φορέας που ιδρύθηκε το έτος 2000 και είναι υπεύθυνος για τις 

μεταφορές της πόλης, υλοποιώντας τις στρατηγικές που επιλέγονται, και παρέχοντας τις σχετικές 

υπηρεσίες. 

Οι υπηρεσίες αυτές αφορούν: 

Σα αστικά λεωφορεία, 

Σον υπόγειο σιδηρόδρομο, 

Σο Docklands Light Railway (DLS), 

Σον υπέργειο σιδηρόδρομο, 

Σο Tramlink, 

Σις μετακινήσεις με πλοιάρια, 

Σον σταθμό υπεραστικών λεωφορείων Victoria. 

΢τα πλαίσια της εξυπηρέτησης του επιβατικού κοινού λειτουργεί το site http://site www.tfl.gov.uk, 

στο οποίο μπορεί κανείς να βρει πλήθος πληροφοριών σχετικά με το δίκτυο, την λειτουργία του, τα 

δρομολόγια, τα είδη και τις τιμές των εισιτηρίων/καρτών, διάφορους χάρτες, κ.α.. 

Μία πολύ χρήσιμη λειτουργία είναι ο Journey Planner, ο οποίος έκανε την εμφάνισή του το 2002 και 

παρέχεται σε αρκετές γλώσσες, μεταξύ των οποίων και τα Ελληνικά. 

Ο Journey Planner αποτελεί εφαρμογή του EFA της εταιρίας Mentz Datenverarbeitung GmbH, και 

περιέχει όλα τα μέσα που διενεργούν αστική συγκοινωνία και προαναφέρθηκαν, όπως επίσης μπορεί 

να σχεδιάσει λαμβάνοντας υπόψη την μετακίνηση με ποδήλατο ή την χρήση αναπηρικού αμαξιδίου. 

10


Τπάρχει ένα πολύ απλό interface, με 

την επιλογή της προέλευσης και του 

προορισμού ως κείμενα, όπου ο 

χρήστης μπορεί να επιλέξει όμως την 

πιο σύνθετη δημιουργία ταξιδιού, 

βάζοντας περισσότερες παραμέτρους. 

Η αναζήτηση θέσεων προέλευσης και 

προορισμού μπορεί να γίνει μέσω 

λέξεων που να αφορούν τα ονόματα 

στάσεων και σταθμών, διευθύνσεις, ή 

σημεία ενδιαφέροντος, όχι όμως μέσω 

κάποιου χάρτη. 

Η παραμετροποίηση, μεταξύ άλλων, 

έχει να κάνει με το αν η σχεδίαση 

ταξιδιού θα δίνει την ταχύτερη 

διαδρομή, αυτή με τις λιγότερες 

μετεπιβιβάσεις, ή αυτή με το λιγότερο 

περπάτημα. Επίσης, με την επιλογή 

ενός ενδιάμεσου προορισμού, με το 

ποια μέσα επιθυμείται να 

χρησιμοποιηθούν, με τον αν μπορούν 

να χρησιμοποιηθούν σκάλες στους 

σταθμούς ή όχι, κ.α.. Ο χρήστης 

μπορεί να ορίσει τις τιμές για το 

μέγιστο περπάτημα, ή την μέγιστη 

ποδηλασία. 

Αφού ο χρήστης κάνει τις επιλογές που 

επιθυμεί, σε επόμενο βήμα του 

παρουσιάζεται μια λίστα με τις 

προτάσεις ταξιδιού, και με επιλογές για 

προβολή προγενέστερων ή 

μεταγενέστερων επιλογών. 

΢ε επόμενο βήμα, γίνεται αναλυτική 

παρουσίαση της πρότασης ή των 

προτάσεων που έχει επιλέξει ο χρήστης. 

Εικόνα 4: ΢υνοπτικά οι διάφορες προτάσεις 

ταξιδίου από μία αναζήτηση στον Journey 

Planner του Tfl. 

Εικόνα 3: Οι διάφορες επιλογές στον ΢χεδιαστή Σαξιδιών 

του TfL. 

11


΢το βήμα αυτό, μπορεί κανείς να δει σχηματικά 

το προτεινόμενο ταξίδι, να δει σε ένθετο χάρτη 

τις περιοχές γύρω από τις στάσεις, να τυπώσει 

την πρόταση, ή να την αποστείλει σε κάποια 

διεύθυνση email. Επίσης, παρέχονται 

πληροφορίες σχετικά με την ζώνη εισιτηρίων, 

και τα πιθανά έργα π.χ. που εκτελούνται και 

μειώνουν την αξιοπιστία ή το επίπεδο 

εξυπηρέτησης. 

Αξιοσημείωτο είναι πως το TfL παρέχει τα 

στοιχεία του σε διάφορες μορφές (text files, 

KML files, κτλ), για ενσωμάτωση σε sites 

άλλων. 

2.2.2 EFA (Elektronische 

Fahrplanauskunft). 

O Journey Planner του TfL είναι η 

χαρακτηριστικότερη εφαρμογή του EFA, το 

οποίο είναι προϊόν της εταιρίας Mentz 

Datenverarbeitung GmbH. 

Η εταιρία δραστηριοποιείται πολλά χρόνια στην ανάπτυξη λογισμικού για ΜΜΜ. Ιδρύθηκε το 1972 

και το 1979 παρουσίασε το DIVA, λογισμικό κυρίως για την διαχείριση δρομολογίων. Σο 1988 

παρουσίασε το EFA, το οποίο είναι ένας Intermodal Journey Planner. 

Αρχικά τα προϊόντα αυτά ανεπτύχθησαν για τους υπολογιστές Nixdorf, όμως τα πρώτα χρόνια της 

δεκαετίας ‘90 έγινε μετάβαση στο Unix, και μετέπειτα, το 1998, στο λειτουργικό Windows. 

To 2001 έγινε ανάληψη της δημιουργίας ενός ΢χεδιαστή Σαξιδιού για την βρετανική πρωτεύουσα, ο 

οποίος τέθηκε σε λειτουργία το 2002. Η συγκεκριμένη υλοποίηση είναι η μεγαλύτερη σε μέγεθος που 

έχει γίνει για το EFA. Άλλες μικρότερου μεγέθους υλοποιήσεις έχουν γίνει σε διάφορες περιοχές του 

κόσμου: στην Αυστραλία, στην Αυστρία, στην Γερμανία, στην Ιταλία, στην Ελβετία, στα Ηνωμένα 

Αραβικά Εμιράτα, τις ΗΠΑ, και στην υπόλοιπη Βρετανία. 

Ας σημειωθεί ότι το EFA δεν είναι μόνο ένας ΢χεδιαστής Σαξιδιών. Αυτός είναι ένα module σε ένα 

πακέτο που περιλαμβάνει διάφορα χαρακτηριστικά και δυνατότητες. Σα βασικότερα από αυτά είναι 

τα εξής: 

Εικόνα 5: Εμφάνιση λεπτομερειών για μία 

πρόταση ταξιδίων του Journey Planner του Tfl. 

12


΢χεδιαστής Σαξιδιών μέσω Web. 

΢χεδιαστής Σαξιδιών για τηλεφωνικά κέντρα εξυπηρέτησης κοινού. 

Η βασική διαφοροποίηση του ως προς τον διατιθέμενο απευθείας στον κοινό ΢χεδιαστή είναι πως 

πρόκειται για εφαρμογή με λιτότερο περιβάλλον και για χρήστες-γνώστες, με μεγαλύτερη όμως 

απόδοση. 

Εικόνα 6: Ο ΢χεδιαστής Σαξιδιών για τηλεφωνικά κέντρα του EFA. 

Διαχείριση πληροφοριών που αφορούν ΑΜΕΑ. 

Διαχείριση πληροφοριών που αφορούν συμβάντα μη κανονικής λειτουργίας. 

Δημιουργία προσωπικών πινάκων δρομολογίων (ανά στάση π.χ.). 

Εκτίμηση σε πραγματικό χρόνο της διέλευσης ενός οχήματος, πέρα από τον 

προγραμματισμό, με χρήση ΢υστημάτων Εντοπισμού Θέσης. 

Παροχή υπηρεσιών μέσω κινητών τηλεφώνων. 

΢χεδιασμό διαδρομών με αυτοκίνητο, ποδήλατο, ή πεζή. 

Σο EFA υποστηρίζει τα πρωτόκολλα DELPHI, EU-Spirit, και JourneyWeb σχετικά με την κατανεμημένη 

πληροφορία που χρησιμοποιούν οι ΢χεδιαστές Σαξιδιών. 

13


2.2.3 Google Transit (΢ε διάφορες περιοχές ανά τον κόσμο). 

Η Google είναι εταιρία που δεν χρειάζεται ιδιαίτερες συστάσεις, καθώς δραστηριοποιείται σε ένα 

ευρύ φάσμα υπηρεσιών μέσω Internet, οι οποίες μάλιστα κατά κανόνα παρέχονται δωρεάν στην 

βασική τους μορφή (π.χ. Μηχανή Αναζήτησης, Gmail, YouTube). 

Μία από τις πλέον γνωστές και χρησιμοποιούμενες υπηρεσίες είναι η παροχή χαρτών και 

φωτοχαρτών για ολόκληρο τον πλανήτη, είτε μέσω του Google Maps, είτε μέσω του Google Earth. 

Με την χρησιμοποίηση ιδιαίτερα του Google Maps API, οι χάρτες της Google αποτελούν το 

υπόβαθρο για πάρα πολλές εφαρμογές ανά τον κόσμο, με μεγάλη ποκιλία θεμάτων, καθώς μάλιστα 

δίνεται η δυνατότητα αξιοποίησης λειτουργιών πέρα από το απλό χαρτογραφικό υπόβαθρο, όπως 

είναι π.χ. η εύρεση διαδρομών, το geocoding, κ.α.. 

Μία από τις υπηρεσίες της Google που βασίζεται στo Google Μaps είναι και το Google Transit. 

Μέσω της υπηρεσίας αυτής είναι δυνατόν να βρίσκει κανείς προτεινόμενες διαδρομές για να τις 

πραγματοποιήσει όχι μόνο πεζή ή με το αυτοκίνητο, αλλά και με Μέσα Μαζικής Μεταφοράς. 

Οι περιοχές κάλυψης αυξάνονται συνεχώς, με αυτή την στιμή να συμπεριλαμβάνονται περίπου 450 

πόλεις ανά τον κόσμο. Σα συγκοινωνιακά στοιχεία για κάθε πόλη προσφέρονται από τους ίδιους τους 

φορείς που είναι υπεύθυνοι για την λειτουργία των αστικών συγκοινωνιών, μέσω ενός προγράμματος 

συμμετοχής. 

΢τα πλαίσια αυτού του προγράμματος, ο όποιος νδιαφερόμενος συγκοινωνιακός φορέας χρειάζεται 

να υλοποιήσει ένα feed δεδομένων σύμφωνα με το format που έχει υιοθετήσει η Google, το οποίο 

ονομάζεται General Transit Feed Specification (GTFS, πρώην Google Transit Feed Specification) και 

το οποίο εξετάζεται σε επόμενο Κεφάλαιο. Ας σημειωθεί προς το παρόν ότι το format αυτό έχει γίνει 

πλέον το de facto πρότυπο για όλες τις σχετικές εφαρμογές. 

΢τη συνέχεια κι αφού κάνει τους δικούς του ελέγχους, ο φορέας χρειάζεται να έρθει σε επαφή με την 

Google, έτσι ώστε τo feed να είναι προσβάσιμο και να συμμετέχει στο Google Transit. Για κάποιο 

διάστημα στην άρχη τα συγκεκριμένα δεδομένα δεν είναι διαθέσιμα παρά μόνο στον ίδιον τον 

φορέα, έτσι ώστε αυτός να μπορέσει να διεξάγει επιπλέον ελέγχους. ΋ταν πλέον τα δεδομένα 

κριθούν ικανοποιητικά για την ποιότητα και πληρότητά τους, τότε συμμετέχουν στην κανονική 

χρήση. Κάθε feed έχει μία ημερομηνία λήξης της εγκυρότητάς του, και ο ίδιος ο φορέας είναι 

υπεύθυνος για την ανανέωσή του. 

Σο περιβάλλον χρήσης του Google Transit είναι αρκετά απλό κι εύχρηστο, και δανείζεται στοιχεία 

από το Google Maps. Αυτό είναι μεγάλο πλεονέκτημα, καθώς έτσι παρέχει ένα περιβάλλον χρήστη 

σχετικά οικίο σε πάρα πολύ μεγάλο πληθυσμό. 

14


Εικόνα 7: Σο περιβάλλον του Google Transit με αποτελέσματα από αναζήτηση για αστική μετακίνηση 

στο Amsterdam. ΢τα αριστερά της εικόνας παρουσιάζονται 4 διαφορετικές προτάσεις, κι από κάτω, 

λεπτομέρειες για την επιλεγμένη από αυτές. 

Άλλο μεγάλο πλεονέκτημα είναι ότι το ίδιο το περιβάλλον, πέρα από το ότι μοιάζει με το Google 

Maps, όσο αυξάνονται οι πόλεις που καλύπτονται, τόσο αυτό μαθαίνεται από περισσότερο κόσμο. 

Έτσι, κάποιος μπορεί να αναζητήσει μια πρόταση διαδρομής σε μία άλλη πόλη, σε μία άλλη χώρα, 

που θα επισκεφτεί ή ήδη επισκέφτεται, χρησιμοποιώντας ένα εργαλείο που το έχει 

ξαναχρησιμοποιήσει στο παρελθόν. Λαμβάνοντας υπόψη ότι οι υπηρεσίες της Google παρέχονται σε 

αρκετές γλώσσες, τότε η εξάπλωση του Google Transit είναι φανερό ότι θα γίνεται με ολοένα και πιο 

γρήγορους ρυθμούς. 

΋σο μάλιστα θα προστίθενται νέες περιοχές κάλυψης, το Google Transit θα γίνεται όλο και 

περισσότερο ένας intermodal trip planner, καθώς θα καλύπτονται αστικές, προαστιακές, αλλά και 

υπεραστικές μετακινήσεις. 

Σο μειονέκτημά του όμως είναι ότι δεν μπορεί να ακολουθήσει εύκολα τις ιδιομορφίες κάθε 

διαφορετικής πόλης, κι επίσης είναι πάρα πολύ απίθανο να προσαρμοστούν σταδιακά οι λειτουργίες 

των αστικών συγκοινωνιών, επηρεαζόμενες ώστε να συγκλίνουν στην λειτουργία πάνω στην οποία 

έχει δομηθεί το Google Transit. 

Κατά αυτόν τον τρόπο, ως φαίνεται, το Google Transit θα αποτελεί στο μέλλον την εφαρμογή που 

θα χρησιμοποιεί σε πρώτη προσέγγιση κάποιος για να κινηθεί μεταξύ διαφορετικών συστημάτων 

15


συγκοινωνιών, όπως π.χ. από μία πόλη σε μία άλλη, αλλά και μέσα σε μία άγνωστη για αυτόν πόλη. 

΋μως, όταν πλέον αυτός ο κάποιος θα χρειάζεται περισσότερο εξειδικευμένη πληροφόρηση, τότε θα 

χρησιμοποιεί τις εφαρμογές των φορέων συγκοινωνιών των επιμέρους τμημάτων διαδρομής, ή της 

πόλης στην οποία θα κινείται. 

Αν δηλαδή κάποιος θα θέλει να μετακινηθεί π.χ. από ένα σημείο στο Amsterdam προς ένα σημείο 

στo Hamburg, τότε θα χρησιμοποιεί αρχικά το Google Transit ώστε να του δωθούν οι γενικές οδηγίες 

και να εκτιμήσει χρόνους (π.χ. tram μέχρι τον κεντρικό σιδηροδρομικό σταθμό του Amsterdam, 

τρένο μέχρι τον αντίστοιχο σταθμό του Hamburg, κι έπειτα λεωφορείο μέχρι το ξενοδοχείο), αλλά 

στη συνέχεια θα χρησιμοποιεί τις εξειδικευμένες εφαρμογές για τις αστικές συγκοινωνίες στις δύο 

πόλεις και την υπεραστική μετακίνηση μεταξύ αυτών. 

Με την χρησιμοποίηση των εξιδεικευμένων εφαρμογών ο χρήστης θα έχει πιθανόν εγκυρότερη, αλλά 

και περισσότερη πληροφόρηση, όπως σχετικά με έκτατες τροποποιήσεις διαδρομών και 

δρομολογίων, με τιμή ή/και αγορά εισιτηρίων, οδηγίες για 

μετεπιβιβάσεις κ.α.. 

Είναι προφανές πάντως ότι μία εφαρμογή όπως της Google, η οποία 

απευθύνεται σε παγκόσμιο κοινό, θα θέτει συνεχώς τον κορμό 

λειτουργίας γύρω από τον οποίο θα πρέπει να περιστρέφονται οι 

υπόλοιπες εφαρμογές, κύρια ώστε να εξασφαλίζεται η μεγιστοποίηση 

της αρχικής γνώσης χρήσης. 

Ας σημειωθεί ότι η υπηρεσία της Google παρέχεται προασρμοσμένη και 

για κινητά τηλέφωνα, έτσι ώστε να γίνεται καλύτερη απεικόνιση σε 

μικρή οθόνη. 

Η εφαρμογή βρίσκεται στην εξής διεύθυνση: www.google.com/transit. 

Εικόνα 8: Φαρακτηριστική 

εικόνα από το Google 

Transit σε οθόνη κινητού. 

16


2.2.4 RATP (Île-de-France). 

Η RATP είναι ο φορέας για τις αστικές και μέρους των 

προαστιακών (RER) συγκοινωνιών στην περιοχή του Paris. 

Ιδρύθηκε το 1948, κι έχει υπό την εποπτεία του τις γραμμές 

metro, εν μέρει τις γραμμές RER, το σύνολο των 

λεωφορειακών γραμμών, και τις 3 από τις 4 γραμμές tram, με 

τα υπόλοιπα συγκοινωνιακά στοιχεία να είναι υπό την 

εποπτεία της SNCF. 

΢τα πλαίσια της εξυπηρέτησης του επιβατικού κοινού 

λειτουργεί σχετικό site σε 7 γλώσσες, το οποίο περιλαμβάνει μεταξύ άλλων και trip planner για την 

περιοχή κάλυψης (Île-de-France). Ο trip planner προσφέρεται σε δύο εκδοχές. 

Η πρώτη εκδοχή βασίζεται αμιγώς σε κείμενο, καθώς κάποιος εισάγει το μέρος εκκίνησης και το 

μέρος τερματισμού, επιλέγοντας το πότε επιθυμεί να μετακινηθεί και με ποιά μέσα. 

17


Εικόνα 9: Σο περιβάλλον χρήσης για τον trip planner της RATP με βάση το κείμενο. 

Ας σημειωθεί ότι η αναζήτηση των σημείων εκκίνησης και τερματισμού μπορεί να γίνει είτε με την 

διεύθυνση, είτε με την ονομασία σταθμού, είτε με την ονομασία της περιοχής. Επίσης παρέχεται η 

δυνατότητα διατήρησης bookmarks. 

Σα αποτελέσματα παρουσιάζονται κι αυτά σε μορφή κειμένου, με μικρό ένθετο χάρτη, είτε για την 

περιοχή αναχώρησης, είτε για την περιοχή άφιξης, σε διάταξη που διευκολύνει την εκτύπωση. 

18


Εικόνα 10: Αποτελέσματα του trip planner της RATP. 

19


Πέρα όμως από τον trip planner σε μορφή κειμένου, η RATP παρέχει έναν διαδραστικό (Interactif) 

trip planner, ο οποίος είναι ιδιαίτερα εύχρηστος κι αρκετά εντυπωσιακός. 

Εικόνα 11: Ο διαδραστικός χάρτης/trip planner της RATP. 

Λειτουργεί σαν μία Flash εφαρμογή, με έναν χάρτη που απεικονίζει τους σταθμούς metro, RER, 

tram, και τις ζώνες εισιτηρίων. 

Σο μειονέκτημα είναι βεβαίως ότι έτσι δεν παρέχεται η δυνατότητα να εντοπίσει κανείς κάτι πέρα 

από τους σταθμούς του δικτύου. Θα πρέπει δηλαδή να γνωρίζει ήδη τους σταθμούς οι οποίοι 

εξυπηρετούν τα σημεία εκκίνησης και τερματισμού. Επίσης, δεν παρέχεται καθοδήγηση με χρήση 

των λεωφορειακών γραμμών, αν και υπάρχει άλλος διαδραστικός χάρτης που παρουσιάζει το δίκτυό 

τους. 

΢τα θετικά και των δύο συστημάτων είναι η δυνατότητα εμφάνισης κι εκτύπωσης των αναλυτικών 

δρομολογίων ανά σταθμό ή/και γραμμή, όπως επίσης των έκτακτων συμβάντων/τροποποιήσεων, 

γεγονός που βοηθά ιδιαίτερα στον προγραμματισμό μίας μετακίνησης. Επίσης, παρέχεται 

πληροφόρηση για τις επόμενες αφίξεις οχημάτων σε σταθμό ή στάση. 

Η παροχή των περισσότερων υπηρεσιών γίνεται και με χρήση κινητού τηλεφώνου, είτε iPhone, είτε 

Android, με προσαρμογή ώστε να υπάρχει περιορισμός του όγκου των διακινούμενων δεδομένων, 

αλλά και καλύτερη απεικόνιση σε μικρή οθόνη. 

20


Εικόνα 12: Η εφαρμογή RATP Premium σε iPhone. 

Η εφαρμογή ονομάζεται ―Ma RATP dans la poche‖ και είναι διαθέσιμη σε δύο εκδόσεις, την RATP 

Lite που παρέχεται δωρεάν, και την RATP Premium που παρέχεται έναντι μικρού τιμίματος ($ 0.99). 

Δεν ήταν δυνατό να γίνει χρήση των εφαρμογών αυτών, και δεν είναι ξεκάθαρες οι διαφορές μεταξύ 

των δύο εκδόσεων. Πιθανόν η δωρεάν έκδοση να μην παρέχει χάρτες και την δυνατότητα 

προσαρμογής ανάλογα με την τρέχουσα θέση (geolocalisation), όπως επίσης να μην εμφανίζει 

στοιχεία σε πραγματικό χρόνο για τις αφίξεις. 

Η διεύθυνση του site της RATP είναι η εξής: www.ratp.fr, 

ενώ υπάρχει τμήμα που απευθύνεται στους επισκέπτες της περιοχής, με πλήθος επεξηγήσεων, 

προτεινόμενων τουριστικών αξιοθεάτων, κτλ. 

21


2.2.5 ΑΔΑΜΑ΢ (Αθήνα) 

Ο ΟΑ΢Α είναι ο φορέας που έχει υπό την εποπτεία του τις αστικές συγκοινωνίες της ευρύτερης 

περιοχής της Αθήνας. 

΢το site του Οργανισμού φιλοξενείται η εφαρμογή ΑΔΑΜΑ΢, το όνομα της οποίας προέρχεται από τα 

αρχικά των λέξεων: ‗Αττική Δικτυακή εφαρμογή Αριστοποίησης Μετακινήσεων με Αστικές 

΢υγκοινωνίες‘. Σο έργο υλοποιήθηκε στο πλαίσιο του Επιχειρησιακού Προγράμματος 

«Ανταγωνιστικότητα» του Γ‘ ΚΠ΢ (Πρόγραμμα Σεχνολογικών Επιδεικτικών Έργων ΠΕΠΕΡ) και 

συγχρηματοδοτήθηκε από την Ευρωπαϊκή Ένωση και τη 

Γενική Γραμματεία Έρευνας & Σεχνολογίας. Ο φορέας 

υλοποίησης του ΑΔΑΜΑ΢ είναι η εταιρεία THESA ΑΕ, με 

συνεργαζόμενο φορέα την εταιρεία MDM AEE. 

Αν και λειτουργεί αρκετά χρόνια, στην αρχική σελίδα 

αναφέρεται ότι βρίσκεται σε δοκιμαστική λειτουργία. 

Σο περιβάλλον της εφαρμογής είναι αμιγώς κειμένου. Ο 

xρήστης έχει την δυνατότητα να επιλέξει την Αφετηρία και 

τον προορισμό μέσα από ιεραρχημένα Combo Boxes. Έτσι, 

δίνεται η δυνατότητα περιορισμένης επιλογής, ανάμεσα 

από Γραμμές-΢τάσεις, Οδούς και ΢τάσεις, ΢ημεία 

Ενδιαφέροντος, ή Διασταυρώσεις. 

Οι οδοί που διατίθενται είναι αυτές στις οποίες υπάρχουν 

στάσεις, γεγονός που σημαίνει ότι ο χρήστης θα πρέπει να 

γνωρίζει ήδη τις περιοχές εκκίνησης και τερματισμού, ώστε 

να είναι σε θέση να προσδιορίσει ποιές οδοί με διερχόμενα 

Μέσα Μαζικής Μεταφοράς βρίσκονται κοντά. 

Επίσης, κατά αυτόν τον τρόπο πρέπει ο ίδιος να επιλέξει 

στάσεις αφετηρίας και προορισμού, δεν του παρέχει 

δηλαδή η εφαρμογή λύσεις που να περιέχουν όλες τις 

γειτονικές στάσεις, εκτός αν κάνει αναζήτηση με κάποιο από τα παρεχόμενα σημεία ενδιαφέροντος 

που πιθανόν να είναι κοντά του. 

Σα σημεία ενδιαφέροντος χωρίζονται σε διάφορες κατηγορίες (π.χ. Κινηματογράφοι, Εκκλησίες), 

όμως δεν είναι πλήρη σε όλες τις κατηγορίες. 

Εικόνα 13: Εισαγωγή/αναζήτηση 

Αφετηρίας-Σερματισμού στην 

εφαρμογή ΑΔΑΜΑ΢. 

22


Σα αποτελέσματα που δίνονται δεν διαθέτουν καθόλου χαρτογραφική πληροφόρηση, όπως επίσηε 

δεν παρέχεται πληροφόρηση για την διάρκεια του ταξιδιού, την διάρκεια κάθε επιμέρους κλάδου, τις 

τιμές των εισιτηρίων. Σα μόνα διατιθέμενα στοιχεία είναι αυτά των γραμμών, των στάσεων 

επιβίβασης/αποβίβασης, και του μήκους της διαδρομής που χρειάζεται να γίνει πεζή. 

Δίνεται μία κύρια και διάφορες εναλλακτικές προτάσεις, όμως στις εναλλακτικές υπάγονται και 

αυτές που είναι απλά χρήση άλλης λεωφορειακής γραμμής μεταξύ δύο ίδιων στάσεων. 

23


Εικόνα 14: Φαρακτηριστική εικόνα προτεινόμενων διαδρομών από την εφαρμογή ΑΔΑΜΑ΢. 

Η εφαρμογή παρέχεται μόνο στην Ελληνική γλώσσα, και βρίσκεται στη web διεύθυνση: tp.oasa.gr. 

24


2.2.6 ΠΤΛΗ ΔΡΟΜΟΛΟΓΗ΢Η΢ ΠΕΡΙΥΕΡΕΙΑ΢ ΑΣΣΙΚΗ΢ 

Η Περιφέρεια Αττικής παρέχει μία διαδικτυακή πύλη (portal) σχετικά με την δρομολόγηση στην 

περιοχή της. Δημιουργήθηκε στα πλαίσια του «Ενοποιημένου ΢υστήματος ΢υνδυασμένων 

Μεταφορών στην Περιφέρεια» και εντάχθηκε στο μέτρο 2.4 «Περιφερειακά Γεωγραφικά ΢υστήματα 

Και Καινοτόμες Ενέργειες» του Επιχειρησιακού Προγράμματος «Κοινωνία της Πληροφορίας», 

χρηματοδοτούμενο κατα 80% από κοινοτικούς πόρους. Η πύλη προσφέρεται τόσο στην Ελληνική, 

όσο και στην Αγγλική γλώσσα. 

Η δρομολόγηση αφορά τα Μέσα Μαζικής Μεταφοράς, αλλά και τις μετακινήσεις με ΙΦ αυτοκίνητο. 

Επίσης, υπάρχει η δυνατότητα συνδυασμού αυτών, καθώς αν η διαδρομή μέχρι την πλησιέστερη 

στάση ή σταθμό είναι μεγαλύτερη από 500 m, τότε οι προσφερόμενες λύσεις είναι συνδυασμός 

μετακίνησης με αυτοκίνητο και ΜΜΜ, κι όχι πεζή και ΜΜΜ. 

Ας σημειωθεί ότι η πύλη παρέχει και πληροφόρηση σχετικά με τις επικρατούσες συνθήκες 

κυκλοφορίας, κι άλλες χρήσιμες πληροφορίες που συνδέονται με τις μετακινήσεις, όπως είναι π.χ. τα 

εφημερεύοντα φαρμακεία και νοσοκομεία, ή ο καιρός. 

Σο περιβάλλον χρήσης είναι αρκετά καλά δομημένο, όμως λόγω της πληθώρας αντικειμένων κι 

επιλογών γίνεται δύσχρηστο, ιδιαίτερα λόγω της αργής λειτουργίας των διαφόρων ενεργών στοιχείων. 

Αρκετά αργή είναι επίσης γενικότερα η απόκριση, όπως π.χ. η ενημέρωση του χάρτη, γεγονός 

βεβαία που οφείλεται σε αργή σύνδεση με τον server. 

Η επιλογή αφετηρίας και τερματισμού μπορεί να γίνει είτε με την διεύθυνση, είτε με τις 

συντεταγμένες (σπάνια χρήσιμο), είτε με βάση κάποια διασταύρωση, μία στάση, ή ένα σημείο 

ενδιαφέροντος. 

25


Εικόνα 15: Φαρακτηριστικό στιγμιότυπο από την Πύλη Δρομολόγησης της Περιφέρειας Αττικής. 

26


Σο σημεία ενδιαφέροντος είναι κατανεμημένα σε κατηγορίες και υποκατηγορίες (π.χ. Πολιτισμός > 

Μουσείο). Δεν παρέχεται απευθείας λίστα με τα αντικείμενα, αλλά πρέπει κανείς να πληκτρολογήσει 

το όνομα και, αφού η εφαρμογή κάνει αλφαριθμητική έυρεση, 

να εμφανιστεί λίστα επιλογής. Δυστυχώς, πολλά αντικείμενα με 

παρόμοιο όνομα εμφανίζονται στη λίστα χωρίς επιπλέον 

πληροφορία, οπότε είναι δύσκολο να επιλέξει κάποιος το σημείο 

ενδιαφέροντος που επιθυμεί. Π.χ. η ονομασία ‗Αγιος 

Κωνσταντίνος‘ θα δημιουργήσει μία λίστα με 7 ίδια αντικείμενα. 

Αν υπήρχε δίπλα στην ονομασία ο Δήμος, τότε θα ήταν 

ευκολότερη η αναγνώριση. 

Ένα ενδιαφέρον στοιχείο είναι η δυνατότητα επιλεκτικής 

οπτικοποίησης των σημείων ενδιαφέροντος, και μάλιστα η 

παράθεση σε λίστα αυτώς που υπάρχουν κάθε στιγμή στο 

παράθυρο της οθόνης. 

Σα αποτέλεσματα της εφαρμογής, όσον αφορά μετακινήσεις με 

τα ΜΜΜ, αποτελούνται από 1 κύρια και 2 εναλλακτικές 

προτάσεις. Παρέχονται αναλυτικότατα στοιχεία, που αφορούν 

χρόνους διαδρομής, οδηγίες κίνησης, τα στοιχεία των 

χρησιμοποιούμενων ΜΜΜ, και όλα αυτά δίνονται και 

οπτικοποιημένα πάνω σε χάρτη, η λειτουργία του οποίου 

βασίζεται στo OpenLayers. 

Η διαδικασία Routing βασίζεται σε συγκεκριμένους χώρους 

διέλευσης των ΜΜΜ από τις στάσεις του δικτύου. ΢τα πλαίσια 

αυτά δεν προσφέρονται πληροφορίες για τις εναλλακτικές γραμμές ώστε να μετακινηθεί κάποιος σε 

ένα τμήμα της διαδρομής που ορίζεται από δύο συγκεκριμένες στάσεις. Οι εναλλακτικές διαδρομές 

που παρουσιάζονται μπορούν να αφορούν και διαφοροποίηση του τμήματος που γίνεται πεζή. 

Δηλαδή οι 2 προτάσεις να χρησιμοποιούν τις ίδιες γραμμές ΜΜΜ και τα ίδια δρομολόγια, όμως να 

διαφέρουν π.χ. ως προς την τελική στάση αποβίβασης, και συνεπώς την διαδρομή πεζή από αυτήν 

ως το σημείο τερματισμού. 

Σα αποτέλεσματα παράγονται σε σύντομο χρόνο, όμως φαίνεται να προτείνονται ταξίδια που 

περιλαμβάνουν πολλές μετεπιβιβάσεις, ακόμη κι όταν επιλεγεί ως μέθοδος βελτιστοποίησης αυτή 

των λιγότερων αλλαγών μέσου. 

΢τον χρήστη παρέχεται η δυνατότητα εκτύπωσης των αποτελεσμάτων, χωρίς όμως να γίνεται 

ιδιαίτερη τροποποίηση της μορφοποίησης των αποτελεσμάτων έτσι ώστε να ταιριάζουν καλύτερα 

στην έντυπη μορφή. 

Εικόνα 16: Παράδειγμα 

εμφάνισης ΢ημείων 

Ενδιαφέροντος με ίδια ονομασία, 

χωρίς δυνατότητα άμεσης 

αναγνώρισής τους. 

27


Η εφαρμογή βρίσκεται διαθέσιμη στην διεύθυνση: http://www.atticaroute.gr. 

2.2.7 YouDrive (Αθήνα). 

Πρόκειται για site που παρέχει προτάσεις ταξιδίου στην Αθήνα αμιγώς με χρήση των ΜΜΜ και πεζή. 

Δεν εμφανίζεται συγκεκριμένος φορέας ή εταιρεία υλοποίησης και λειτουργίας. Είναι δομημένο 

πάνω στο σύστημα μεταφορών της Αθήνας, κι έτσι παρέχεται η δυνατότητα π.χ. λεπτομερέστερων 

επιλογών για την χρήση ή όχι μέσων (Μετρό/Η΢ΑΠ/Προαστιακός κι όχι όλων μαζί ως Μετρό). 

Σο περιβάλλον χρήσης είναι απλό κι εύχρηστο, βασισμένο στον χάρτη των Google Maps, και 

γενικότερα στο Google Maps API. Παρέχεται επίσης η δυνατότητα εύρεσης σημείων ενδιαφέροντος 

και η επιλεκτική οπτικοποίησή τους, μέσα από μία μεγάλη λίστα σημείων, και μάλιστα 

κατηγοριοποιημένων. Δυστυχώς, το site μέχρι στιγμής παρέχεται μόνο στην ελληνική γλώσσα. 

΢τον χρήστη παρέχονται παραπάνω από μία προτάσεις ταξιδίου, χωρίς να είναι σταθερός ο αριθμός 

αυτών, προβαλλόμενες κατά σειρά χρόνου διαδρομής. Δεν είναι γνωστό πως γίνεται η διαδικασία 

του routing, όμως κάτι πολύ θετικό στην περίπτωση της Αθήνας είναι πως αυτή δεν βασίζεται σε 

αυστηρούς χρόνους διέλευσης των μέσων από τις στάσεις. Βασίζεται δηλαδή στις συχνότητες 

διέλευσης. ¨Ομως, ο χρήστης μπορεί να επιλέξει μόνο τον τύπο της ημέρας που θέλει να ταξιδέψει 

(Καθημερινή/΢αββάτο/Κυριακή) κι όχι την ώρα, ή έστω την περίοδο μέσα στην ημέρα (πχ. Πρωί, 

Μεσημέρι, Βράδυ). Αυτό σημαίνει ότι τα στοιχεία συχνοτήτων που χρησιμοποιούνται είναι ίδια για 

όλη την όποια ημέρα, οπότε δεν λαμβάνονται υπόψη οι διαφοροποιήσεις που συμβαίνουν στον 

προγραμματισμό των δρομολογίων μέσα σε αυτήν. 

28


Εκτός από την επιλογή των Μέσων που επιθυμείται να χρησιμοποιηθούν ή όχι, ο χρήστης μπορεί να 

επιλέξει να μην υπάρχει αλλαγή μέσου, ακόμη κι αν έτσι παράγονται λύσεις με μεγαλύτερο χρόνο 

διαδρομής. 

Εικόνα 17: Φαρακτηριστικό στιγμιότυπο από την εφαρμογή YouDrive, όπου εμφανίζεται μία πρόταση 

ταξιδίου. 

29


Σα αποτελέσματα του routing παρέχονται σε μορφή λίστας στα αριστερά της οθόνης, με κάθε 

πρόταση να βρίσκεται σε διαφορετικό tab. ΢ε κάθε λίστα αναφέρονται στοιχεία για τις ονομασίες 

των γραμμών ΜΜΜ που πρέπει να χρησιμοποιηθούν, τις ονομασίες των στάσεων επιβίβασης κι 

αποβίβασης σε/από αυτά, τις συχνότητες διέλευσης, όπως επίσης το μήκος και τον χρόνο που 

απαιτείται για τις μετακινήσεις πεζή. ΢το τέλος εμφανίζεται ο συνολικός χρόνος που απαιτείται για το 

ταξίδι, ο χρόνος αναμονής σε στάσεις (εκτιμώμενος ως το ήμισυ του αθροίσματος του χρόνου των 

περιόδων διέλευσης), και μία εκτίμηση του αποτυπώματος CO2 για το συγκεκριμένο ταξίδι. 

Σα στοιχεία της λίστας παρέχονται οπτικοποιημένα σε InfoBoxes και Marks του Google Maps API. 

Επιπλέον των στοιχείων της λίστας, στα Infoboxes εμφανίζονται όλες οι Γραμμές οι οποίες 

εξυπηρετούν τις στάσεις. Περεταίρω, μπορεί κανείς να δει σε μεγαλύτερο InfoBox όλα τα κοντινά 

σημεία ενδιαφέροντος, κατηγοριοποιημένα και με εκτίμηση του χρόνου που απαιτείται για την 

μετακίνηση προς αυτά, είτε πεζή, είτε με αυτοκίνητο. 

Η οπτικοποίηση των στοιχείων αφορά απλώς τα σημεία αφετηρίας και τερματισμού, όπως επίσης και 

τις στάσεις που χρησιμοποιούνται. Δεν οπτικοποιούνται δηλαδή οι διαδρομές των ΜΜΜ, ενώ δεν 

παρέχεται καθόλου πληροφόρηση, ούτε χαρτογραφικά, ούτε με κείμενο, για τις διαδρομές πεζή. 

Για κάθε τμήμα της διαδρομής από στάση σε στάση θα πρέπει να σημειωθεί ότι εμφανίζονται όλες οι 

Γραμμές που τις συνδέεουν. (π.χ «Επιβιβάζεστε στο λεωφορείο Α17 ή 806, ή 807». ΋μως ως 

φαίνεται, οι εναλλακτικές Γραμμές απλώς εμφανίζονται στον χρήστη, χωρίς να συμμετέχουν στον 

αλγόριθμο εύρεσης της πρότασης ταξιδίου. Έτσι, η κάθε λύση δεν προκύπτει λαμβάνοντας υπόψη 

τον χρόνο αναμονής που προκύπτει από το σύνολο των Γραμμών που συνδέεουν τις στάσεις ανά δύο 

μεταξύ τους (που έχουν τις στάσεις αυτές τμήμα του δρομολογίου τους δηλαδή), αλλά για κάθε μία 

Γραμμή ξεχωριστά. 

Δεν υπάρχει η δυνατότητα εμφάνισης των αποτελεσμάτων προσαρμοσμένων στις ιδιαιτερότητης της 

έντυπης μορφής, κι έτσι ο χρήστης θα πρέπει απλά να εκτυπώσει την ιστοσελίδα ως εμφανίζεται. 

Η εφαρμογή YouDrive βρίσκεται στην εξής διεύθυνση: www.youdrive.gr. 

30


2.3 Γενικές Παρατηρήσεις – Διαφοροποίηση Σης Παρούσας 

Τπηρεσίας. 

΋πως εύκολα μπορεί να παρατηρηθεί, οι περισσότερες από τις εφαρμογές πλοήγησης με χρήση 

ΜΜΜ έχουν ως βασικό στοιχείο τους τον χάρτη της περιοχής για την οποία λειτουργούν. Ο χάρτης 

αυτός, είτε έχει φτιαχτεί ειδικά για την περιοχή, είτε είναι κάποιος από τους ευρέως διαδεδομένους 

για όλον τον πλανήτη, με κυριότερο αυτόν της Google. 

΋λες οι εφαρμογές έχουν πάνω-κάτω την ίδια λογική βημάτων που απαιτούνται, καθώς αυτά είναι 

αρκετά συγκεκριμενοποιημένα από την φύση του αντικειμένου. Έτσι, αρχικά ο χρήστης επιλέγει την 

προέλευση και τον προορισμό, ορίζει κάποιες παραμέτρους για τα μέσα που επιθυμεί να 

χρησιμοποιήσει, την βελτιστοποίηση κτλ, και τέλος του παρουσιάζονται τα αποτελέσματα. 

Μία εφαρμογή, η Google Transit, απευθύνεται με την ίδια ακριβώς μορφή σε όλο τον πληθυσμό, για 

διάφορες περιοχές ολόκληρης της Γης. Αυτό της δίνει το πλεονέκτημα ότι γίνεται ευρέως γνωστή, 

τόσο σαν ύπαρξη, όσο και σαν χειρισμός. Για τον λόγο αυτό γίνεται ιδιαίτερα θελκτικό για έναν 

φορέα ΜΜΜ να ενδιαφερθεί από μόνος του να δώσει τα στοιχεία του για συμμετοχή στην 

εφαρμογή, ενισχύοντας ακόμη περισσότερο την ευρύτητα της κάλυψης. Σο μειονέκτημα του Google 

Transit όμως είναι ότι έτσι δεν μπορεί να προσαρμοστεί εύκολα, τουλάχιστον προς το παρόν, στις 

ιδιαίτερες συνθήκες που αφορούν κάθε περιοχή και τον τρόπο λειτουργίας των ΜΜΜ σε αυτή. Οι 

υπόλοιπες εφαρμογές παρουσιάζουν σχετική προσαρμογή για τις ιδιαιτερότητες των περιοχών, όχι 

όμως και στο κοινό στο οποίο απευθύνονται. ΋λες οι εφαρμογές απευθύνονται κατά όμοιο τρόπο 

στους πάντες, έχοντας ως χρήστη αναφοράς τον τυπικό κάτοικο της περιοχής. 

΢τις περισσότερες από τις εφαρμογές παρατηρείται το φαινόμενο να δίνονται πλήθος στοιχείων, τα 

οποία δεν έχουν πάντα μεγάλη χρησιμότητα στον χρήστη. ΢την ουσία οι σχεδιαστές φαίνεται να 

υποκύπτουν στον πειρασμό, έχοντας πάρα πολλά διαθέσιμα στοιχεία και την ευκολία να υπολογίζουν 

ακόμη περισσότερα, ώστε να υπερβάλουν στην ποσότητα της πληροφορίας που παρουσιάζουν στα 

αποτελέσματα. Αυτό μάλιστα γίνεται συνήθως χωρίς να υπάρχει η δυνατότητα επιλογής από τον 

χρήστη της αναλυτικότητας των στοιχείων, με τελικό αποτέλεσμα οι εφαρμογές να παρουσιάζονται 

ως να μην έχουν στο επίκεντρο τον άνθρωπο-επιβάτη, τι θέλει και πως μπορεί αυτός κατά το 

δυνατόν απλά κι εύκολα να κάνει και να μάθει, αλλά περισσότερο να δίνουν την αίσθηση κάποιες 

στιγμές ενός interface μεταφοράς δεδομένων, του οποίου η μορφή είναι δυνατόν να αναγνώσκεται. 

Η εφαρμογή που αναπτύχθηκε για την παρούσα Εργασία στηρίζεται στην λογική τού να παρέχεται 

στον χρήστη άμεσα η πληροφορία που είναι απολύτως απαραίτητη, μέσα από μία όσο το δυνατόν 

περισσότερο απλή, εύκολα κατανοητή, αλλά και σύντομη διαδικασία. Επίσης, υπάρχει συγκεκριμένο 

κοινό στο οποίο απευθύνεται, το οποίο είναι ο επισκέπτης της πόλης. Αυτό προσιορίζει διαφόρες 

ιδιαιτερότητες λειτουργίας, που έχουν να κάνουν τόσο με την ανύπαρκτη εώς πάρα πολύ μικρή 

31


εμπειρία χρήσης, με το ότι δεν υπάρχει κανείς λόγος ένας επισκέπτης να θέλει να μάθει κάτι το 

οποίο θα του χρειαστεί για λίγες μόνο ημέρες, όπως επίσης με το ότι υπάρχει πολύ μικρή γνώση του 

επισκέπτη για τον τρόπο λειτουργίας και το δίκτυο ΜΜΜ της πόλης. 

Ακόμη, το ενδιαφέρον δεν είναι για την οπωσδήποτε βέλτιστη διαδρομή, καθώς αυτή μπορεί να γίνει 

ίσως και μόνο μία φορά, αλλά για μία ικανοποιητική κι εύκολη διαδρομή. Κατά αυτόν τον τρόπο 

έχουν μεγάλη σημασία κάποια λίγα τμήματα του δικτύου και σημεία της περιοχής, ενώ τα 

περισσότερα άλλα από αυτά δεν έχουν σχεδόν καμία σημασία. 

΢τα πλαίσια αυτά, μία άμεση διαφοροποίηση αφορά την Γλώσσα του περιβάλλοντος χρήσης. Έτσι, η 

γλώσσα της Εφαρμογής είναι τα Αγγλικά, κι όχι τα Ελληνικά, με δυνατότητα για την προσθήκη 

μελλοντικά ακόμη περισσότερων γλωσσών. Η χρήση άλλης γλώσσας αφορά όχι μόνο το περιβάλλον 

χρήσης, αλλά και τον τρόπο με τον οποίο αναφέρονται κάποια στοιχεία, όπως π.χ. ‗AIRPORT‘ ως 

ονομασία στάσης, κι όχι ‗AERODROMIO‘. Δίνεται δηλαδή σημασία στην λειτουργική σημασία των 

στοιχείων. 

Ένα απλό, αλλά χρήσιμο σε αρκετές περιπτώσεις χαρακτηριστικό, είναι η δυνατότητα της 

Εφαρμογής που αναπτύχθηκε να δέχεται μέσω άλλων sites έτοιμες κάποιες από τις παραμέτρους 

που αφορούν την προέλευση, τον προορισμό, την ημερομηνία κι ώρα κτλ. Με αυτόν τον τρόπο, 

αφενός υποβοηθείται η ίδια η Εφαρμογή να γίνει γνωστή, αφετέρου προσφέρεται ένα εργαλείο 

στους διοργανωτές ενός συνεδρίου π.χ., ώστε διευκολύνουν τους συμμετέχοντες στην μετακίνησή 

τους. Γενικότερα πάντως, με τέτοιες εφαρμογές ευνοοείται η χρήση των ΜΜΜ, με πλήθος άμεσων κι 

έμμεσων θετικών επιδράσεων στις συνθήκες διαβίωσης. 

Αν και επιλογή ήταν η υιοθέτηση επισήμων και μη προτύπων, και η προσαρμογή στις ιδιαίτερες 

συνθήκες διατηρώντας όμως κατά το δυνατόν σχετικές τυποποιήσεις κι ευρύτερα 

χρησιμοποιούμενες μεθοδολογίες και γνώσεις, εν τούτοις η εν λόγω Εφαρμογή είναι ένα καλό 

εργαλείο ώστε να αναγνωριστούν, επισημανθούν, κι εν μέρει επιλυθούν, ή δρομολογηθεί να 

επιλυθούν, τα σχετικά προβλήματα. ΢αν παραδείγματα αναφέρονται το πρότυπο για τα στοιχεία του 

Δικτύου, και οι αλγόριθμοι που είναι υπεύθυνοι για το routing. 

Οι περισσότερες από τις εφαρμογές πλοήγησης με ΜΜΜ είναι ιδιαίτερα ακριβές. Σο κόστος τους 

ποικίλει, ανάλογα με τις παρεχόμενες λειτουργίες, τις αναγκαίες παράλληλες εργασίες, αλλά και με 

το μέγεθος του Δικτύου που αφορούν. Η εφαρμογή που αναπτύχθηκε χρησιμοποιεί αποκλειστικά 

λογισμικό ανοικτού κώδικα, όπως επίσης δεδομένα διαθέσιμα ελεύθερα. Με αυτόν τον τρόπο 

επιτυγχάνεται η δυνατότητα δημιουργίας και λειτουργίας αντίστοιχων εφαρμογών για διάφορες 

πόλεις, με πολύ μικρό κόστος, κάνοντας εφικτή την λειτουργία ακόμη και για μικρά δίκτυα, όπου δεν 

θα ήταν οικονομικά δυνατόν αυτό να γίνει με άλλες εφαρμογές. 

Η ανάπτυξη της εφαρμογής έγινε ώστε να υπάρχει η δυνατότητα αυτής της εύκολης προσαρμογής 

σε διαφορετικές ιδιαιτερότητες, όπως επίσης το να μπορεί να τροποποιείται με σκοπό την διαρκή 

32


βελτίωση. Ακόμη, η πλατφόρμα που χρησιμοποιήθηκε για το περιβάλλον χρήστη (Adobe Flex) 

εξελίσσεται διαρκώς, και μάλιστα για διάφορα λειτουργικά συστήματα, επιτρέποντας έτσι και την 

εύκολη επέκταση της εφαρμογής προς διάφορες συσκευές, όπως είναι π.χ. τα netbooks με μικρή 

οθόνη και τα κινητά τηλέφωνα, διατηρώντας όμως σε μεγάλο βαθμό έναν όμοιο βασικό τρόπο 

λειτουργίας. 

33


34


3Θεωρητικό Τπόβαθρο. – 

3.1 Γράφοι. 

Βασικές Πληροφορίες. 

Σα συστήματα μεταφορών αναπαρίστανται σχετικά εύκολα με την χρήση γράφων. Έτσι, προβλήματα 

όπως π.χ. η εύρεση της γρηγορότερης διαδρομής ανάγονται σε προβλήματα επίλυσης γράφων, 

δηλαδή σε μια γενικότερη αντιμετώπιση και με πλούσιο θεωρητικό υπόβαθρο. 

΢την Ελληνική αλλά και στην Αγγλική γλώσσα, πολλές από τις έννοιες που συνδέονται με τους 

Γράφους έχουν ποικίλα ονόματα, και μερικές φορές η ίδια ονοματολογία μπορεί να αφορά 

παρεμφερή αλλά διαφορετικά πράγματα. Έτσι, στη συνέχεια του κειμένου γίνεται προσπάθεια να 

τηρηθεί αυστηρά η μονοσημαντικότητα, κι επίσης παρατίθενται σε αρκετές περιπτώσεις οι 

αντίστοιχες αγγλικές λέξεις, ώστε κάποιος, αναζητώντας περισσότερες πληροφορίες, να μπορεί να 

συνδέσει ευκολότερα το παρόν κείμενο με την διεθνή βιβλιογραφία, 

35


Ένας γράφος είναι μια αφαιρετική αναπαράσταση ενός συνόλου αντικειμένων, όπου κάποια από 

αυτά τα αντικείμενα σχηματίζουν ζευγάρια μέσω ενός συνδέσμου (link). Σα αντικείμενα που 

συνδέονται ονομάζονται Κόμβοι (vertex στον ενικό, vertices στον πληθυντικό), ενώ οι σύνδεσμοι 

Ακμές (edges). ΢ε μορφή διαγράμματος, οι κόμβοι αναπαρίστανται με σημεία, και οι σύνδεσμοι με 

γραμμές ή καμπύλες. 

Οι Ακμές ενός Γράφου μπορεί να έχουν ή όχι φορά, οπότε να είναι ασύμμετρες ή συμμετρικές 

αντίστοιχα. Οι Ακμές μπορούν να αναπαριστούν σχέσεις μεταξύ των Κόμβων, όπως π.χ., πρόσβαση ή 

γνώση, και δύο άμεσα συνδεδεμένοι Κόμβοι ονομάζονται γειτονικοί (adjacent). ΋ταν όλες οι Ακμές 

είναι μίας κατεύθυνσης και υπάρχει μόνο μία Ακμή ανά ζέυγος Κόμβων, τότε ο Γράφος ονομάζεται 

απλός, ενώ σε περίπτωση που κάποιες είναι διπλής φοράς και κάποιες όχι, ο Γράφος ονομάζεται 

Μικτός. Ο αριθμός των Ακμών ορίζει το μέγεθος του Γράφου, ενώ ο αριθμός των Ακμών που 

συνδέεονται με έναν Κόμβο ορίζει τον Βαθμό του συγκεκριμένου Κόμβου. ΋ταν δύο Κόμβοι 

συνδέονται άμεσα μεταξύ τους με πάνω από μία Ακμή, τότε ο Γράφος ονομάζεται Πολλαπλός. 

Δύο Ακμές ενός Γράφου ονομάζονται γειτονικές (adjacent ή coincident) όταν ο ένας Κόμβος τους 

είναι κοινός, ενώ στην περίπτωση Ακμών με φορά, όταν η μία οδηγεί στον Κόμβο και η άλλη 

απομακρύνεται από αυτόν, τότε χαρακτηρίζονται ως Διαδοχικές (consecutives). 

Εικόνα 18: Διάγραμμα ενός Γράφου. Ο Γράφος μπορεί να περιγραφεί ως V = {1, 2, 3, 4, 5, 6}, E = 

{{1, 2}, {1, 5}, {2, 3}, {2, 5}, {3, 4}, {4, 5}, {4, 6}}, δηλαδή από τα σύνολα των Κόμβων και των Ακμών 

αντίστοιχα. Σο μέγεθος του Γράφου είναι 7, κι ο Βαθμός π.χ. του Κόμβου 5 είναι 3. Οι Ακμές {4,5}, 

{2,5}, {5,1} είναι γειτονικές. Επίσης, οι Κόμβοι 1, 2, 4 είναι γειτονικοί του 5. 

΋ταν σε έναν Γράφο έχουν οριστεί Βάρη για κάθε Ακμή, τότε ο Γράφος ονομάζεται Ζυγισμένος 

(weighted). Σα Βάρη αυτά μπορεί να αναπαριστούν κόστη, αποστάσεις, χρόνους, δυσκολίες, κ.α., 

ανάλογα με το πρόβλημα. Σο άθροισμα όλων των Βαρών είναι το Βάρος του Γράφου. Φάρη στην 

δυνατότητα οι Ακμές να αναπαριστούν ακόμη και ποσοτικά σχέσεις μεταξύ των Κόμβων, οι Γράφοι 

36


έχουν τεράστια χρησιμότητα στην επίλυση διαφόρων προβλημάτων, όπως είναι π.χ. στην εύρεση 

συντομότερης διαδρομής, θέμα που συναντάται στην παρούσα Εργασία. 

΢ε μία εφαρμογή πλοήγησης τα βάρη συνήθως αναπαριστούν τον απαιτούμενο χρόνο μετακίνησης, 

και το ζητούμενο είναι το Μονοπάτι (path), δηλαδή το πέρασμα από τους Κόμβους και τις Ακμές, 

από έναν Κόμβο-Αφετηρία σε έναν Κόμβο-Σερματισμό, το οποίο έχει το μικρότερο άθροισμα Βαρών 

για τις Ακμές που διασχίζονται. Σα Βάρη στο συγκεριμένο παράδειγμα θα μπορούσαν να αφορούν 

την έλλειψη ασφάλειας κατά μήκος μίας Ακμής, οπότε το ζητούμενο να είναι το Μονοπάτι με 

περισσότερο περιορισμένη την ανασφάλεια, όπως π.χ. όταν γίνεται χρήση ποδηλάτου. Σο Μονοπάτι 

που εκκινά και τερματίζει στον ίδιο Κόμβο ονομάζεται Κύκλος. 

Ας σημειωθεί ότι, στα μεταφορικά συστήματα οι κόμβοι συνήθως συνδέεονται μεταξύ τους με 

περισσότερες από μία Ακμές, είναι δηλαδή Πολλαπλοί (Multigraphs). Κάθε μία από τις Ακμές μεταξύ 

δύο Κόμβων μπορεί να αντιπροσωπεύει ένα μεταφορικό μέσο, έχοντας το αντίστοιχο Βάρος. ΢την 

πράξη, σε Intermodal συστήματα, δηλαδή σε ΢υνδυασμένες Μεταφορές, κάθε τέτοια Ακμή αφορά 

Κόμβους του ίδιου μέσου, και οι αντίστοιχοι Κόμβοι των μέσων συνδέεονται μεταξύ τους με Ακμές 

που το Βάρος τους αντοιστοιχεί σε «Ποινή» (penalty) για την αλλαγή (π.χ. μετεπιβίβαση). 

΋ταν σε έναν Γράφο με Ακμές χωρίς φορά υπάρχει Μονοπάτι που επιτρέπει την επίσκεψη σε κάθε 

Κόμβο μόνο μία φορά, τότε το Μονοπάτι αυτό ονομάζεται Hamiltonian. Αντίστοιχα ονομάζεται και ο 

Κύκλος με την ίδια ιδιότητα. 

΢την Ιστορία έχουν υπάρξει διάφορα προβλήματα σχετικά με Γράφους. Σα πιό γνωστά είναι τα εξής: 

3.1.1 Οι Επτά Γέφυρες του Königsberg. 

Πρόκειται για πρόβλημα που τέθηκε το 1735 από τον Ελβετό μαθηματικό και φυσικό Leonard Euler, 

θέτοντας τις αρχές της θεωρίας Γράφων, και προοιωνίζοντας την ιδέα της Σοπολογίας. Η εργασία 

του δημοσιεύθηκε με τον τίτλο «Solutio problematis ad geometriam situs pertinentis» («Η επίλυση 

ενός πρόβληματος σε σχέση με την γεωμετρία της θέσης») το 1741, στο «Commentarii academiae 

scientiarum Petropolitanae» [Αναφορά #38]. 

Σο Königsberg ήταν τότε πόλη της Πρωσίας (σημερινό Kaliningrad στη Ρωσία), και απλωνόταν στις 

δύο πλευρές του ποταμού Pregel. Σμήμα της πόλης βρισκόταν και πάνω σε δύο νησιά που ήταν 

συνδεδεμένα μεταξύ τους, και με τις όχθες, μέσω 7 γεφυρών. 

37


Εικόνα 19: Φάρτης του Königsberg την εποχή του Euler, με τονισμένες τις γέφυρες και τον ποταμό. 

Σο πρόβλημα που τέθηκε ήταν να βρεθεί μία διαδρομή μέσα στην πόλη ώστε κάποιος να διασχίσει 

όλες τις γέφυρες, διερχόμενος από κάθε γέφυρα μία μόνο φορά. Δεν επιτρεπόταν να γίνει 

μετακίνηση από μία επιφάνεια γης σε άλλη χωρίς την διάσχιση γέφυρας. Ο Euler δεν βρήκε λύση στο 

πρόβλημα, απέδειξε όμως ότι αυτό δεν έχει λύση. Ξεκινώντας, σημείωσε ότι η επιλογή διαδρομής 

πάνω σε κάθε επιφάνεια γης που συνδέουν οι γέφυρες, δεν παίζει κάποιο ρόλο. Σο μόνο σημαντικό 

στοιχείο ήταν λοιπόν η σειρά διάσχισης των γεφυρών. 

Με αυτόν τον τρόπο, ο Euler διαμόρφωσε το πρόβλημα με αφαιρετικούς όρους, θεμελιώνοντας την 

θεωρία Γράφων. Πλέον είχε να διαχειριστεί στο πρόβλημά του μόνο τις επιφάνειες γης ως σημεία, 

και τις γέφυρες που τις συνδέεουν. Με σημερινή ορολογία, οι επιφάνειες ήταν οι Κόμβοι, και οι 

γέφυρες οι Ακμές του Γράφου. Επίσης, με αυτήν την συσχέτιση μπορούσε να αναπαραστήσει 

διαγραμματικά το πρόβλημα χωρίς να τον ενδιαφέρει η ακριβής θέση των στοιχείων, παρά μόνο οι 

μεταξύ τους συνδέσεις/σχέσεις, ξεκινώντας έτσι την ανάπτυξη της τοπολογίας. 

Εικόνα 20: Η αφαιρετική διαδικασία στο πρόβλημα του Euler. 

38


΢τη συνέχεια ο Euler παρατήρησε ότι, όταν κάποιος πηγαίνει σε μία επιφάνεια γης μέσω μιας 

γέφυρας, την ίδια στιγμή μέσω αυτής της γέφυρας φεύγει από μία άλλη επιφάνεια γης. Αυτό φυσικά 

δεν ισχύει για τα αρχικά και τελικά σημεία. Με άλλα λόγια, κάνοντας μία βόλτα στον Γράφο, οι φορές 

που κάποιος πηγαίνει σε έναν μη τελικό Κόμβο ισούται με τις φορές που φέυγει από αυτόν. Αν κάθε 

γέφυρα διασχίζεται μία και μόνο φορά, επάγεται ότι για κάθε επιφάνεια γης (εκτός από την πρώτη 

και την τελευταία), ο αριθμός των γεφυρών που την συνδέουν είναι ζυγός (οι μισές θα διανυθούν 

προς την επιφάνεια , και οι άλλες μισές από την επιφάνεια). ΋μως, στην περίπτωση του Königsberg, 

και οι τέσσερεις επιφάνειες γης συνδέεονταν με μονό αριθμό γεφυρών, κι αφού μόνο δύο (το 

μέγιστο) επιφάνειες μπορούν να γίνουν η αρχική και η τελική, συμπεραίνεται ότι δεν υπάρχει λύση. 

Με σημερινή ορολογία, ο Euler έδειξε ότι η ύπαρξη μιας διαδρομής σε έναν Γράφο που να διέρχεται 

από κάθε Ακμή μόνο μία φορά, εξαρτάται από τους Βαθμούς των Κόμβων. Αναγκαία λοιπόν 

συνθήκη για την ύπαρξη μιας τέτοιας διαδρομής είναι ο Γράφος να είναι συνδεδεμένος και να έχει 

ακριβώς μηδέν ή δύο κόμβους περιττού Βαθμού. Η συνθήκη αυτή αργότερα, το 1871 από τον 

Γερμανό μαθηματικό Carl Hierholzer [Αναφορά #40: Hierholzer Carl (1871), Ueber eine Fläche der 

vierten Ordnung, Mathematische Annalen IV, 172-180] αποδείχθηκε ότι είναι και ικανή. Μία τέτοια 

διαδρομή καλείται σήμερα Eulerian. Εάν μάλιστα υπάρχουν 2 Κόμβοι περιττού Βαθμού στον Γράφο, 

τότε όλες οι Euerian διαδρομές εκκινούν από τον έναν και τερματίζουν στον άλλον. 

Αξιοσημείωτο είναι πως σήμερα υπάρχουν 3 μόνο από τις γέφυρες, η μία μάλιστα είναι 

ανακατασκευή της αρχικής. Δύο από τις γέφυρες καταστράφηκαν από τους βομβαρδισμούς του 2 ου 

Παγκοσμίου Πολέμου, και άλλες δύο κατεδαφίστηκαν αργότερα για την δημιουργία ενός 

αυτοκινητοδρόμου. Έτσι, δύο από τους Κόμβους είναι 2 ου Βαθμού (τα νησιά) και οι υπόλοιποι τρεις 

είναι 3 ου Βαθμού, γεγονός που σημαίνει την ύπαρξη Eulerian διαδρομής. Επειδή πάντως σημείο 

εκκίνησης και τερματισμού είναι τα 2 νησιά, η διαδρομή δεν μπορεί στην πράξη να πραγματοποιηθεί 

από κάποιον, εκτός βέβαια αν γεννηθεί σε ένα από αυτά! 

3.1.2 Σο Πρόβλημα της Διαδρομής Με Σο Μικρότερο Κόστος. 

Σο πρόβλημα συνίσταται στην εύρεση ενός Μονοπατιού μεταξύ δύο Κόμβων, έτσι ώστε το άθροισμα 

των Βαρών κατά μήκος των διανυόμενων Ακμών να είναι το ελάχιστο δυνατό. Σα βάρη μπορούν να 

αντιπροσωπεύουν οτιδήποτε, συνήθως όμως είναι ο χρόνος ή η απόσταση μεταξύ δύο Κόμβων. 

΢ε πιο μαθηματική γραφή, το πρόβλημα είναι να βρεθεί για έναν ζυγισμένο Γράφο, αποτελούμενο 

από το σύνολο των Κόμβων του V και των Ακμών του E, ένα Μονοπάτι P με αφετηρία τον Κόμβο v, 

και τερματισμό τον v‘, που να ελάχιστοποιεί την τιμή του αθροίσματος της συνάρτησης f : E → R , η 

39


οποία εκφράζει το Βάρος μετακίνησης κατά μία Ακμή. Δηλαδή θα πρέπει το να έχει την 

ελάχιστη δυνατή τιμή. 

΢τα μεταφορικά συστήματα οι Κόμβοι αντιπροσωπεύον τα διάφορα σημειακά στοιχεία (π.χ. 

διασταυρώσεις οδών, ή στάσεις), ενώ οι Ακμές αντιπροσωπεύουν μεμονωμένα οδικά τμήματα ή 

επιμέρους τμήματα διαδρομών. 

Σο Πρόβλημα βρίσκει εφαρμογές σε πάρα πολλούς τομείς, εκτός από την πλέον προφανή που είναι η 

καθοδήγηση μέσα σε ένα σύστημα οδών. Κι αυτό γιατί μπορούν εύκολα με τους Κόμβους, τις Ακμές, 

και τα Βάρη, να αναπαρασταθούν με αφαίρεση ένα τεράστιο πλήθος πραγμάτων. Για παράδειγμα, 

οι αλγόριθμοι επίλυσης μπορούν να χρησιμοποιηθούν για να βρεθεί η βέλτιστη σειρά επιλογών ώστε 

να επιτευχθεί κάποιος στόχος, με την έννοια π.χ. της μείωσης του συνολικού απαιτούμενου χρόνου. 

΢ε πιό συγκεκριμένο παράδειγμα, οι Κόμβοι θα μπορούσαν να αντιπροσωπεύουν τις φάσεις ενός 

puzzle όπως ο Κύβος του Rubik, και οι Ακμές τις μοναδιαίες κινήσεις. 

3.2 Αλγόριθμοι Επίλυσης. 

3.2.1 Γενικά Περί Αλγορίθμων. 

Ένας αλγόριθμος (η ονομασία προέρχεται από τον Πέρση μαθηματικό, αστρονόμο, και γεωγράφο al- 

Khwārizmī) είναι μία αποτελεσματική μέθοδος επίλυσης ενός προβλήματος, εκφρασμένη σαν μία 

πεπερασμένη σειρά βημάτων. ΢ε πιό ανεπτυγμένα ή αφηρημένα θέματα, οι οδηγίες μπορεί να μην 

αποτελούν πεπερασμένη σειρά, ούτε καν μία σειρά, όπως π.χ. στους μη ντετερμινιστικούς 

αλγόριθμους. 

Ξεκινώντας από ένα αρχικό σημείο, οι οδηγίες περιγράφουν έναν υπολογισμό που διέρχεται μέσα 

από πολύ καλά καθορισμένες σειρές επιτυχών σημείων, τερματίζοντας στο σημείο αυτό που είναι το 

ζητούμενο. Η μετάβαση από το ένα σημείο στο άλλο δεν είναι απαραίτητα ντετερμινιστική, και 

κάποιοι αλγόριθμοι εισαγάγουν τυχαιότητα. 

3.2.2 Ευρετικές (Heuristics). 

΢τη γενικότερη μορφή οι ευρετικές αφορούν τεχνικές που βασίζονται στην εμπειρία για την επίλυση 

προβλημάτων, την μάθηση, και την έρευνα, και κυρίως χρησιμοποιούνται για να επιταχυνθεί η 

40


διαδικασία. ΢τις ευρετικές ανήκουν έναν μεγάλο πλήθος τεχνικών, από την εκπαιδευμένη μαντεψιά, 

μέχρι την κοινή αίσθηση. 

΢την υπολογιστική επιστήμη, η ευρετική είναι η τεχνική που έχει σχεδιαστεί ώστε να επιλύει κάποιο 

πρόβλημα αδιαφορώντας εάν η λύση που θα προκύψει μπορεί να αποδειχθεί ότι είναι σωστή, αρκεί 

να είναι ικανοποιητική. ΢κοπός της χρησιμοποίησής της είναι η βελτίωση της ταχύητητας ή της 

εννοιολογικής απλότητας, με μείωση όμως της ακρίβειας. Πολλές φορές οι ευρετικές λύνουν απλά 

προβλήματα, που όμως στην συνέχεια οι λύσεις τους χρησιμοποιούνται ώστε να λυθούν δυσκολότερα 

προβλήματα. Φαρακτηριστικό παράδειγμα ευρετικών τεχνικών που χρησιμοποιούνται καθημερινά 

είναι οι τεχνικές που έχουν υλοποιηθεί στα λογισμικά κατά των ιών, ιδιαίτερα στο τμήμα που αφορά 

την πραγματικού χρόνου εξέταση. 

Μία ευρετική μέθοδος μπορεί να λειτουργεί χρησιμοποιώντας δένδρα αναζήτησης. Αντί όμως να 

δημιουργούνται όλοι οι δυνατοί κλάδοι λύσεων, μία ευρετική επιλέγει τους κλάδους που είναι 

πιθανότερο να παράγξουν το επιθυμητό αποτέλεσμα. 

Ένα κρίσιμο σημείο για την επιτυχία ή όχι των ευρετικών σε ένα πρόβλημα είναι το αν οι επιλεγμένες 

ευρετικές θα λειτουργούν καλά και στο μέλλον, δηλαδή σε ένα διαφορετικό σύνολο δεδομένων 

εισόδου. Αν οι ευρετικές έχουν δημιουργηθεί και επιλεγεί με βάση μόνο το τρέχον κατά την στιγμή 

ανάπτυξης του αλγόριθμου σύνολο δεδομένων, δηλαδή με βάση κάποια χαρακτηριστικά του 

συνόλου που πιθανότατα δεν θα υπάρχουν σε μελλοντικά σύνολα, τότε η χρησιμότητά τους θα έχει 

περιορισμένη χρονική διάρκεια, και ίσως όμοια και ολόκληρης της διαδικασίας που βασίζεται σε 

αυτές τις μεθοδολογίες. Έτσι, θα πρέπει να δίνεται ιδιαίτερη σημασία στην ανάλυση των δεδομένων 

εισόδου, και να εξετάζεται πολύ καλά το πως αυτά παράγονται. 

3.3 Αλγόριθμοι Για Σην Εύρεση Σης Βέλτιστης Διαδρομής Από 

Κόμβο ΢ε Κόμβο. 

3.3.1 Γενικά. 

Η βέλτιστη διαδρομή συνήθως αφορά την ελαχιστοποίηση κάποιου συνολικού κόστους κατά την 

διάσχιση των Ακμών ή/και το πέρασμα από τους Κόμβους. Σο κόστος αυτό μπορεί να αφορά την 

απόσταση, τον απαιτούμενο χρόνο, το άμεσο ή έμμεσο οικονομικό κόστος, την ανασφάλεια, κ.α.. 

΢την παρούσα περίπτωση μας ενδιαφέρει αποκλειστικά το πρόβλημα της βέλτιστης διαδρομής από 

ένα σημείο σε ένα μόνο άλλο σημείο, κι όχι η διαδρομή που να διέρχεται από ένα πλήθος σημείων, 

τυχαία ή με σειρά, πριν καταλήξει στο τελικό. 

41


΢τη συνέχεια αναφέρονται σε θεωρητικό επίπεδο οι αλγόριθμοι που σχετίζονται με την επίλυση του 

προβλήματος: 

3.3.2 Ο Αλγόριθμος Σου Dijkstra. 

Ο αλγόριθμος του Dijkstra, από το όνομα του Ολλανδού Edsger Dijkstra που τον δημοσίευσε το 

1959 [Αναφορά #39: Dijkstra Edsger Wybe (1959), A note on two problems in connexion with 

graphs, Numerische Mathematik 1: 269–271], επιλύει το πρόβλημα της εύρεσης της συντομότερης 

διαδρομής σε γράφους χωρίς αρνητικά κόστη στις ακμές, δηλαδή χωρίς οφέλη. Σο προϊόν της λύσης 

είναι το μονοπάτι στον γράφο, με την καθορισμένο κόμβο αφετηρίας και τον καθορισμένο κόμβο 

τερματισμού, το οποίο έχει το μικρότερο αθροιστικά κόστος. 

Για έναν δοσμένο κόμβο, ο αλγόριθμος βρίσκει στην πραγματικότητα το μονοπάτι με το μικρότερο 

κόστος για την διαδρομή από τον κόμβο αφετηρίας και προς οποιονδήποτε άλλον κόμβο. Μπορεί 

όμως να χρησιμοποιηθεί και για την εύρεση του κόστους του «φτηνότερου» μονοπατιού προς έναν 

μόνο άλλον κόμβο, αν σταματήσει η εκτέλεσή του μόλις έχει βρεθεί το φτηνότερο μονοπάτι προς 

αυτόν τον κόμβο προορισμό. 

3.3.2.1 Περιγραφή. 

Αν θεωρηθεί ως απόσταση του κόμβου Τ, η απόσταση του (κόστος) από τον κόμβο αφετηρίας, τότε, 

ο αλγόριθμος θα αποδώσει αρχικές τιμές για κάθε κόμβο, και θα προσπαθήσει να τις βελτιώσει, 

δηλαδή να τις μειώσει, μέ τα επόμενα βήματα: 

1. Απόδοση σε κάθε κόμβο μίας τιμής απόστασης. Η τιμή αυτή είνα «μηδέν» για τον κόμβο 

αφετηρίας, και «άπειρο» για όλους τους υπόλοιπους κόμβους. 

2. Μαρκάρισμα όλων των κόμβων ως μη επεσκεμμένους. Θέση αρχικού κόμβου ως τρέχοντα. 

3. Για τον τρέχοντα κόμβο, υπολόγισε για όλους τους γειτονικούς του που δεν είναι 

επεσκεμμένοι, την προσωρινή τους απόσταση από τον κόμβο αφετηρία. Η προσωρινή 

απόσταση υπολογίζεται ως το άθροισμα της απόστασης από τον τρέχοντα προς τον κόμβο, 

με την απόσταση του τρέχοντα. Εάν αυτή η προσωρινή απόσταση είναι μικρότερη από την 

προηγούμενη καταγεγραμμένη, τότε την αντικαθιστά. 

42


4. ΋ταν έχει ολοκληρωθεί το προηγούμενο βήμα για όλους τους γειτονικούς του τρέχοντα, 

τότε μαρκάρισε αυτόν ως επεσκεμμένους. Η απόστασή του πλέον δεν θα επανεξεταστεί, 

και είναι η τελική, συνεπώς και η μικρότερη. 

5. Αν όλοι οι κόμβοι είναι επεσκεμμένοι, τότε η εκτέλεση του αλγόριθμου ολοκληρώνεται. 

Διαφορετικά, τίθεται ως τρέχον ο κόμβος από τους μη επεσκεμμένους με την μικρότερη 

απόσταση, και η διαδικασία συνεχίζεται από το 3 ο βήμα. 

΢ε κάποιες περιπτώσεις είναι ζητούμενο να δωθούν παραπάνω από μία λύσεις, κι ας μην είναι 

βέλτιστες. Σότε, αφού γίνει κανονικά ο υπολογισμός των βέλτιστων, αφαιρείται μία ακμή βέλτιστης 

λύσης από τον γράφο, κι ο αλγόριθμος επανεκτελείται στο νέο υποσύνολο. 

3.3.2.2 Χευδοκώδικας. 

1 function Dijkstra(Graph, source): 

2 for each vertex v in Graph: // Αρτικοποίηζη. 

3 dist[v] := infinity ; 

// Άγνωζηη Απόζηαζη από ηην Αρτή μέτρι ηον Κόμβο v. 

4 previous[v] := undefined ; 

// Προηγούμενος Κόμβος ζηο Βέηιζηο Μονοπάηι από ηην Αρτή. 

5 end for ; 

6 dist[source] := 0 ; 

// Απόζηαζη για ηον Κόμβο Αθεηηρίας. 

7 Q := the set of all nodes in Graph ; 

// Όλοι οι Κόμβοι αρτικά ανήκοσν ζηο Σύνολο Q αθού δεν έτοσν 

επιζκεθθεί. 

8 while Q is not empty: 

// Ο Κύριος Βρότος. 

9 u := vertex in Q with smallest dist[] ; 

10 if dist[u] = infinity: 

11 break ; 

// Όλοι οι εναπομείνανηες Κόμβοι είναι μη προζπελάζιμοι από ηην 

Αθεηηρία. 

12 fi ; 

13 remove u from Q ; 

14 for each neighbor v of u: 

// Όηαν ο v δεν έτει ακόμη αθαιρεθεί από ηο Q. 

15 alt := dist[u] + dist_between(u, v) ; 

16 if alt < dist[v]: 

43


// Ελάηηωζε (u,v,a) 

17 dist[v] := alt ; 

18 previous[v] := u ; 

19 fi ; 

20 end for ; 

21 end while ; 

22 return dist[] ; 

23 end Dijkstra. 

Εάν ενδιαφέρει μόνο το βέλτιστο μονοπάτι προς έναν συγκεκριμένο κόμβο προορισμό, τότε η 

εκτέλεση μπορεί να τερματιστεί αν πριν την γραμμή 13 u = target. 

Σο βέλτιστο μονοπάτι μπορεί να ανακτηθεί ως εξής: 

1 S := empty sequence 

2 u := target 

3 while previous[u] is defined: 

4 insert u at the beginning of S 

5 u := previous[u] 

΋που S θα είναι στο τέλος η λίστα με τους κόμβους ανάμεσα στην αφετηρία και τον τερματισμό, ως 

ένα από τα βέλτιστα μονοπάτια, ή κενό, εάν δεν υπάρχει κανένα μονοπάτι. Ας σημειωθεί ότι η S θα 

περιέχει ένα από τα βέλτιστα μονπάτια, καθώς μπορεί να υπάρχουν παρά πάνω από ένα με το ίδιο 

ελάχιστο κόστος. Αν ζητούνται όλα τα βέλτιστα μονοπάτια, τότε θα πρέπει αντί να αποθηκέυεται 

μόνο μία τιμή για τον προηγούμενο κόμβο, να αποθηκεύονται όλες οι τιμές στη γραμμή 5. ΢ε αυτήν 

την περίπτωση, η δομή previous[] θα αποτελεί έναν γράφο υποσύνολο του δοσμένου. 

3.3.3 Ο Αλγόριθμος Α* (A-Star). 

Πρόκειται για μία επέκταση του Αλγόριθμου του Dijkstra, που περιγράφηκε πρώτη φορά το 1968 

από τους Peter Hart, Nils Nilsson, και Bertram Raphael [Αναφορά #41: Hart, P. E.; Nilsson, N. J.; 

Raphael, B. (1968), IEEE Transactions on Systems Science and Cybernetics SSC4 4 (2): 100– 

107. doi:10.1109/TSSC.1968.300136]. Φρησιμοποιεί ευρετικές κι έτσι επιτυγχάνει καλύτερους 

χρόνους. Σο όνομά του οφείλεται στην υιοθέτηση της λογικής γύρω από τον Kleene Star ή Kleene 

Operator, που αφορά λειτουργίες αλφαριθμητικών συνόλων. Ο πρώτος που έκανε μία ευρετική 

προσέγγιση για την αύξηση της ταχύτητας του αλγόριθμου του Dijksta ήταν ο Nils Nilsson το 1964, 

κι ο αλγόριθμός του ονομάστηκε Α1 [Δεν έχουν βρεθεί στοιχεία για το που έχει γίνει σχετική 

δημοσίευση]. Ο Bertram Raphael έκανε σημαντικές αλλαγές το 1967, αλλά δεν πέτυχε ιδιαίτερη 

βελτίωση στην πράξη. Ο αλγόριθμός του ονομάστηκε Α2 [΋μοια, δεν έχουν βρεθεί στοιχεία για το 

που έχει γίνει σχετική δημοσίευση]. Έπειτα από έναν χρόνο ο Peter Hart απέδειξε ότι ο Α2 ήταν 

βέλτιστος χρησιμοποιώντας μία σύμφωνη ευρετική, κι ότι μάλιστα ήταν ο καλύτερος δυνατός 

44


αλγόριθμος για τις συνθήκες [Αναφορά #41]. Με την ονομασία Α* που του έδωσε, ο αλγόριθμος 

περιλαμβάνει στην μαθηματική γλώσσα όλους τους αλγόριθμους που ανήκουν στην «σειρά» Α και 

έχουν μία αριθμητική έκφραση της έκδοσης. 

Ο Α* χρησιμοποιεί μία αναζήτηση τύπου «το καλύτερο πρώτα (best-first)» και βρίσκει το μονοπάτι 

ελάχιστου κόστους από έναν αρχικό κόμβο, σε έναν κόμβο στόχο (που μπορεί να είναι περισσότεροι 

από ένας). Η αναζήτηση τύπου «το καλύτερο πρώτα» διεισδύει στον γράφο ακολουθώντας την 

διαδρομή από έναν κόμβο που είναι η πιο πολλά υποσχόμενη για να δώσει την επιθυμητή λύση. 

Για την αναζήτησή του υιοθετεί μία συνάρτηση ευρετικού χαρακτήρα που είναι το άθροισμα του 

κόστους μέχρι τον τρέχοντα κόμβο, και ευρετικά από τον τρέχοντα μέχρι τον τερματισμό. Έτσι, αν 

ονομαστεί f(x) η συνάρτηση αυτή, θα είναι: f(x) = g(x) + h(x), όπου: 

Η συνάρτηση g(x) εκφράζει το κόστος από τον κόμβο εκκίνησης μέχρι τον τρέχοντα, 

Η συνάρτηση h(x) εκφράζει την ευρετική εκτίμηση της απόστασης μέχρι τον τερματισμό. 

Η τιμή της συνάρτησης της ευρετικής εκτίμησης δεν θα πρέπει να είναι μεγαλύτερη από την 

απόσταση προς τον στόχο, δεν θα πρέπει δηλαδή να κάνει υπερεκτίμησή της. Π.χ. σε έναν 

αλγόριθμο πλοήγησης με κόστος την απόσταση, θα μπορούσε ευρετική συνάρτηση να είναι η 

ευκλείδια άμεση απόσταση μεταξύ των κόμβων, η οποία είναι πάντα μικρότερη ή το πολύ ίση της 

πραγματικής που πρέπει να διανυθεί. 

΢την περίπτωση που ισχύει h(x) ≤ d'(x,y) + h(y) για κάθε ακμή (x,y ) του γράφου, όπου d είναι το 

μήκος της ακμής, τότε η ευρετική συνάρτηση ονομάζεται μονότονη και ο αλγόριθμος Α* μπορεί να 

υλοποιηθεί πιο αποτελεσματικά. Αυτό συμβαίνει επειδή δεν απαιτείται να γίνει επεξεργασία του 

οποιουδήποτε κόμβου παραπάνω από μία φορά. 

Θα πρέπει να σημειωθεί ότι ο Α* έχει γενικευτεί σε αλγόριθμο δύο κατευθύνσεων, δηλαδή η 

αναζήτηση γίνεται και από την αφετηρία προς το τέλος, αλλά και το αντίστροφα, με την διαδικασία 

να σταματάει όταν γίνεται συνάντηση των δύο αναζητήσεων. 

3.3.3.1 Περιγραφή. 

Η γενική αρχή είναι πως ο αλγόριθμος ακολουθεί ένα μονοπάτι με το μικρότερο γνωστό κόστος, 

κρατώντας λίστα με εναλλακτικά τμήματα κατά την διαδρομή του. Αν σε οποιοδήποτε σημείο, ένα 

τμήμα του μονοπατιού που διασχίζεται έχει υψηλότερο κόστος από ένα άλλο τμήμα που έχει 

καταγραφεί, ο αλγόριθμος σταματάει την πορεία του στο υψηλότερου κόστους μονοπάτι και 

ακολουθεί το χαμηλότερου κόστους. Η διαδιακασία αυτή είναι συνεχώς επαναλαμβανόμενη μέχρι να 

ολοκληρωθεί το μονοπάτι λύση. 

45


Αυτό που διαφοροποιεί τον Α* από άλλους greedy αλγόριθμους είναι ότι λαμβάνει υπόψη στην 

ευρετική συνάρτηση και το κόστος από την αρχή, κι όχι μόνο το τοπικό. Ξεκινώντας από τον κόμβο 

αφετηρία, ο αλγόριθμος διατηρεί μία λίστα προτεραιότητας για τους κόμβους προς διάσχιση, γνωστή 

ως «ανοικτό σύνολο». ΋σο πιο χαμηλή η τιμή της f(x) για έναν κόμβο x, τόσο μεγαλύτερη η 

προτεραιότητα για επίσκεψη στον κόμβο. ΢ε κάθε βήμα, ο κόμβος με την χαμηλότεργ τιμή της f(x) 

διαγράφεται από την σειρά, υπολογίζονται οι τιμές των f και h για τους γειτονικούς κόμβους, και 

αυτοί οι γειτονικοί κόμβοι προστίθενται στη σειρά. Η διαδιακασία συνεχίζεται μέχρι ένας κόμβος 

στόχος να έχει χαμηλότερη τιμή της f από οποιονδήποτε άλλον κόμβο στη σειρά, ή μέχρι να αδειάσει 

η σειρά.Οι κόμβοι στόχοι μπορεί να διασχισθούν πολλές φορές εάν παραμένουν άλλοι κόμβοι με 

χαμηλότερες τιμές της f , καθώς αυτοί μπορεί να οδηγήσουν σε συντομότερο μονοπάτι προς έναν 

στόχο. ΋ταν λοιπόν έχει ολοκληρωθεί η προηγούμενη διαδικασία, τότε η τιμή της f του στόχου είναι 

το μήκος του συντομότερου μονοπατιού, καθώς η τιμή της h είναι μηδέν. 

Εάν το μονοπάτι που βρέθηκε είναι τελικά αποδεκτό, τότε ο αλγόριθμος μπορεί να ενημερώσει κάθε 

γείτονα με την τιμή του αμέσως προηγούμενού του στο καλύτερο μονοπάτι. Η πληροφορία αυτή 

μπορεί να χρησιμοποιηθεί για την ανακατασκευή του μονοπατιού πηγαίνοντας προς τα πίσω. Εάν 

μάλιστα η ευρετική είναι μονότονη, για να γίνει η εύρεση πιο αποτελεσματική, είναι δυνατόν να 

χρησιμοποιηθεί το κλειστό σύνολο των κόμβων που έχουν ήδη διασχισθεί. 

Ας σημειωθεί ότι υπάρχουν διάφορες παραλλαγές του A*, όπως είναι D*, o FSA*, o GAA*, o LPA*, 

o Theta*,κ.α.. 

3.3.3.2 Χευδοκώδικας. 

1 function A*(start,goal) 

closedset := the empty set 

// Το ζύνολο ηων κόμβων πος έσοςν ήδη αξιολογηθεί. 

2 openset := set containing the initial node 

// Το ζύνολο ηων δοκιμαζηικών κόμβων ππορ αξιολόγηζη. 

3 came_from := the empty map 

// Το ζύνολο ηων κόμβων πος έσοςν διαζσιζθεί. 

4 g_score[start] := 0 

// Απόζηαζη από ηην απσή καηά μήκορ ηος βέληιζηος μονοπαηιού. 

5 h_score[start] := heuristic_estimate_of_distance(start, goal) 

6 f_score[start] := h_score[start] 

// Εκηιμώμενη ζςνολική απόζηαζη από ηην απσή ππορ έναν ζηόσο διαμέζω 

ηος y. 

7 while openset is not empty 

8 x := the node in openset having the lowest f_score[] value 

9 if x = goal 

10 return reconstruct_path(came_from, came_from[goal]) 

46


11 remove x from openset 

12 add x to closedset 

13 foreach y in neighbor_nodes(x) 

14 if y in closedset 

15 continue 

16 tentative_g_score := g_score[x] + dist_between(x,y) 

17 if y not in openset 

18 add y to openset 

19 tentative_is_better := true 

20 elseif tentative_g_score < g_score[y] 

21 tentative_is_better := true 

22 else 

23 tentative_is_better := false 

24 if tentative_is_better = true 

25 came_from[y] := x 

26 g_score[y] := tentative_g_score 

27 h_score[y] := heuristic_estimate_of_distance(y, goal) 

28 f_score[y] := g_score[y] + h_score[y] 

29 return failure 

30 function reconstruct_path(came_from, current_node) 

31 if came_from[current_node] is set 

32 p = reconstruct_path(came_from, came_from[current_node]) 

33 return (p + current_node) 

34 else 

35 return current_node 

Σο κλειστό σύνολο μπορεί να παραλειφθεί εάν διασφαλίζεται ότι υπάρχει μία λύση, ή εάν ο 

αλγόριθμος είναι προσαρμοσμένος έτσι ώστε νέοι κόμβοι να προστίθενται στο ανοικτό σύνολο μόνο 

αν έχουν την χαμηλότερη τιμή της f από σε οποιαδήποτε άλλη επανάληψη. 

3.3.3.3 Τλοποίηση. 

Ο Α* μπορεί εύκολα να τρέξει ως αλγόριθμος του Dijksta ή ως αλγόριθμος DFS (πρώτα σε βάθος, 

Depth-First) αναζήτησης, με μειωμένη όμως όπως είναι προφανές απόδοση σε σχέση με την καθαρή 

υλοποίηση των προηγούμενων, λόγω της διαχείρισης της τιμής της h(x) σε κάθε κόμβο. 

Για την πρώτη περίπτωση, αρκεί απλά να τεθεί h(x) = 0 για κάθε κόμβο x , να ακυρωθεί δηλαδή στην 

πράξη η ευρετική. Για την δεύτερη περίπτωση, αρκεί να οριστεί ένας μετρητής C με μία πολύ μεγάλη 

αρχική τιμή. Κάθε φορά που επεξργάζεται ένας κόμβος, τότε αποδίδεται η τιμή C ως h(x) σε όλους 

τους καινούριους γείτονες, ελαττωμένη κάθε φορά κατά μία μονάδα. Με αυτόν τον τρόπο, όσο πιο 

γρήγορα έχει βρεθεί ένας γείτονας, τόσο μεγαλύτερη η τιμή h(x). 

Τπάρχουν διάφορες τεχνικές υλοποίησης που μπορούν σημαντικά να αυξήσουν την απόδοση του Α* 

σε λειτουργία. Π.χ. το να διατηρείται για κάθε κόμβο μία αναφορά προς τον γονέα του, έτσι ώστε 

στο τέλος της αναζήτησης αυτές να μπορούν να χρησιμοποιηθούν για την ανάκτηση του βέλτιστου 

47


μονοπατιού. ΢την περίπτωση αυτή, είναι σημαντικό το να μην εμφανίζεται ο ίδιος κόμβος πάνω από 

μία φορά στην λίστα προτεραιότητας (με κάθε συμμετοχή να αντιστοιχεί σε ένα διαφορετικό 

μονοπάτι προς τον κόμβο, και με διαφορετικό κόστος). Η τυπική προσέγγιση στο θέμα είναι ο 

έλεγχος εάν ο κόμβος προς εισαγωγή στη λίστα υπάρχει ήδη σε αυτήν ή όχι. Εάν υπάρχει ήδη, τότε 

οι δείκτες της προτεραιότητας και του γονέα μεταβάλλονται ώστε να αντιστοιχούν στο μονοπάτι με 

το λιγότερο κόστος. 

3.3.4 Ο Αλγόριθμος/Σεχνική ‗Contraction Hierarchies‘ (‗΢υναιρετικές 

Ιεραρχίες‘). 

Πρόκειται για μία καινούργια σχετικά τεχνική, για την μείωση του μεγέθους του Γράφου, η οποία 

βασίζεται στην συναίρεση κόμβων, με απώτερο σκοπό βέβαια την επιτάχυνση της διαδικασίας. Οι 

κόμβοι πρώτα ταξινομούνται κατά σημαντικότητα κι έπειτα δημιουργείται μία ιεραρχία, 

συναιρώντας επαναληπτικά τον κόμβο με την μικρότερη σημαντικότητα. Η συναίρεση ενός κόμβου v 

σημαίνει την αντικατάσταση των συντομότερων μονοπατιών που διέρχονται από τον v με 

συντομεύσεις (shortcuts). ΢την πραγματικότητα, η συναίρεση κόμβων είναι ο τρόπος που 

ακολουθείται για την συναίρεση ακμών. 

΢το παρόν κείμενο γίνεται μια προσπάθεια συνοπτικής παρουσίασης, με εστίαση στην παρούσα 

Εφαρμογή, της εργασίας ‗Contraction Hierarchies: Faster and Simpler Hierarchical Routing in Road 

Networks‘ των Robert Geisberger, Peter Sanders, Dominik Schultes, και Daniel Delling του 

πανεπιστημίου του Karlsruhe [Αναφορά #17: Robert Geisberger, Peter Sanders, Domminik 

Schultes, Daniel Delling (2008), Contraction Hierarchies: Faster and Simpler Hierarchical Routing 

in Road Networks]. ΢ε κάθε πείπτωση ο αναγνώστης προτρέπεται να διαβάσει το πρωτότυπο 

κείμενο, το οποίο υπάρχει διαθέσιμο στην web διεύθυνση: 

http://algo2.iti.kit.edu/download/contract.pdf. 

3.3.4.1 Εισαγωγή ΢την Σεχνική. 

Ο αλγόριθμος για το ερώτημα της ιεράρχησης επιτυγχάνεται με αναζήτηση συντομότερων 

μονοπατιών κατά δύο κατευθύνσεις. Η αναζήτηση με φορά προς τα εμπρός χρησιμοποιεί μόνο 

ακμές που οδηγούν σε πιο σημαντικούς κόμβους, και η αναζήτηση με φορά προς τα πίσω 

χρησιμοποιεί μόνο ακμές που έρχονται από πιο σημαντικούς κόμβους. Ο Γράφος ενός οδικού 

48


δικτύου παραμένει αρκετά διεσπαρμένος κατά την διαδικασία συναίρεσης, χρησιμοποιώντας απλές 

ευρετικές για την ταξινόμηση των κόμβων. ΢ε σύγκριση με την καλύτερη προηγούμενη ιεραρχική 

τεχνική επιτάγχυνσης βασισμένη στον Dijkstra, η τεχνική Contraction Hierarchies επιτυγχάνει πέντε 

φορές καλύτερους χρόνους, κι ένα αρνητικό overhead χώρου. Σο τελευταίο συμβαίνει καθώς η δομή 

των δεδομένων για τον υπολογισμό της απόστασης απαιτεί λιγότερο χώρο από τον αρχικό Γράφο. Η 

τεχνική μπορεί να χρησιμοποιηθεί μαζί με άλλες τεχνικές και αλγόριθμους αναζήτησης καλύτερων 

διαδρομών. 

Ας θεωρηθεί ότι οι κόμβοι ενός ζυγισμένου και με φορά γράφου G = (V,E) είναι αριθμημένοι 1..n 

κατά αύξουσα σημαντικότητα. Είναι τότε δυνατόν να δημιουργηθεί μία ιεραρχία, αν συναιρούνται οι 

κόμβοι κατά αυτή την σειρά. Ένας κόμβος συναιρείται αφαιρόντας αυτόν από το δίκτυο κατά τέτοιο 

τρόπο ώστε να διατηρούνται τα συντομότερα μονοπάτια στον εναπομείναντα γράφο. Αυτή η 

ιδιότητα επιτυγχάνεται αντικαθιστώντας μονοπάτια της μορφής (u, v, w) από μία ακμή συντόμευσης 

(u,w). Η συντόμευση αυτή απαιτείται μόνο εάν το (u, v, w) είναι το μόνο συντομότερο μονοπάτι από 

u τον στον w. 

Η διαδικασία της συναίρεσης μπορεί να ειδοθεί σαν ένας τρόπος για να προστεθούν όλες οι 

συντομεύσεις που έχουν βρεθεί στο σύνολο των ακμών E. Η ταξινόμηση των κόμβων κατά 

σημαντικότητα παρόλο που δείχνει ένα δύσκολο πρόβλημα, εν τούτοις διάφορες ήδη υπάρχουσες 

ευρετικές κάνουν την σχετική διεργασία σχετικά εύκολη. Η βασική ιδέα είναι να διατηρούνται οι 

κόμβοι σε μία σειρά προτεραιότητας κατά κάποια εκτίμηση του πόσο θελκτική είναι η συναίρεση 

ενός κόμβου. Σο κύριο συστατικό αυτής της ευρετικής εκτίμησης είναι η διαφορά ακμής, δηλαδή ο 

αριθμός των συντομεύσεων που εισάγονται όταν συναιρείται ο κόμβος, μείον τον αριθμό των ακμών 

που σχετίζονται με αυτόν. Η σκέψη πίσω από αυτό είναι ότι ο συνειρημένος γράφος θα έχει όσο το 

δυνατόν λιγότερες ακμές. Ακόμη και μόνο με αυτόν τον απλό τρόπο απόδοσης και ταξινόμησης 

σημαντικότητας, υπολογίζονται αρκετά καλές ΢υναιρετικές Ιεραρχίες, όμως με πρόσθετες 

διαδικασίες το αποτέλεσμα είναι καλύτερο. Ιδιαίτερα, είναι σημαντικό να συναιρούνται οι κόμβοι 

‗ομοιόμορφα‘. 

Για το routing, η ΢υναιρετική Ιεραρχία (V,E) διασπάται σε έναν προς τα πάνω γράφο G↑:= (V,E↑) με 

E↑:= {(u, v) ϵ E : u < v} κι έναν προς τα κάτω γράφο G↓:= (V,E˅) με E↓ := {(u, v) ϵ E : u > v}. Για ένα 

ερώτημα συντομότερου μονοπατιού από το s στο t, πραγματοποιείται μία τροποποιημένη αναζήτηση 

Dijkstra δύο κατευθύνσεων, δηλαδή μία προς τα εμπρός αναζήτηση στο G↑ και μία προς τα πίσω 

αναζήτηση στο G↓. Εάν, και μόν εάν, υπάρχει ένα συντομότερο μονοπάτι s-t στον αρχικό γράφο, 

τότε οι δύο αναζητήσεις συναντώνται σε έναν κόμβο v, ο οποίος έχει την υψηλότερη θέση από όλους 

τους κόμβους στο συντομότερο αυτό μονοπάτι. 

49


3.3.4.2 ΢υναίρεση. 

΋πως ειπώθηκε προηγουμένως, όταν συναιρείται ένας κόμβος v, τότε πλέον διαχειρίζεται ένας 

γράφος G’ = (V’,E’) με V ‘ = v..n και ένα σύνολο ακμών E’ το οποίο διατηρεί τις αποστάσεις των 

συντομότερων μονοπατιών, όπως στον αρχικό γράφο. ΢τον νέο γράφο, υπάρχει το εξής πρόβλημα 

συντομότερου μονοπατιού many-to-many που πρέπει να επιλυθεί: Για κάθε πηγαίο κόμβο u ϵ v + 1..n 

με (u, v) ϵ E’ και κάθε κόμβο στόχο w ϵ v + 1..n με (v,w) ϵ E’, ζητείται να συγκριθεί η απόσταση του 

συντομότερου μονοπατιού d(u,w) με το μήκος της συντόμευσης c(u, v)+c(v,w) ώστε να αποφασιστεί 

εάν η συντόμευση χρειάζεται πραγματικά. Ένας απλός τρόπος υλοποίησης είναι να 

παραγματοποιηθεί μία προς τα εμπρός αναζήτηση συντομότερου μονοπατιού στον γράφο G’ από 

κάθε πηγή, αγνοώντας τον κόμβο v, μέχρι όλοι οι στόχοι να έχουν βρεθεί. Η αναζήτηση από τον v 

μπορεί να σταματήσει επίσης όταν θα έχει φτάσει σε απόσταση d(u, v) + max {c(v,w) : (v,w) ϵ E’}. 

΢την πραγματικότητα, η παρούσα τεχνική χρησιμοποιεί μία απλή, ασυμμετρική μορφή δύο 

κατευθύνσεων. Για κάθε κόμβο στόχο w πραγματοποιείται μία απλού βήματος προς τα πίσω 

αναζήτηση. Για κάθε ακμή (x,w) ϵ E’ αποθηκεύεται η (c(x,w),w) με τον κόμβο x. Κατά αυτόν τον 

τρόπο, η προς τα εμπρός αναζήτηση από τον μπορεί να περιοριστεί σε απόσταση c(u, v) + max (w:(v,w) 

ϵ E’) c(v,w) – min(x:(x,w) ϵ E’) c(x,w). 

Υτάνοντας σε έναν κόμβο x, παρατηρούνται οι τιμές που έχουν αποθηκευθεί για αυτόν. Για κάθε 

αποθηκευμένη τιμή (C,w), μπορεί να προκύψει το συμπέρασμα ότι υπάρχει ένα μονοπάτι από το u 

στο w μήκους d(u, x) + C. 

Καθώς η ακριβής αναζήτηση συντομότερου μονοπατιού μπορεί να απαιτεί αρκετό χρόνο, 

υλοποιούνται δύο τρόποι για να μειωθεί το εύρος των αναζητήσεων. Μπορεί να μειωθεί ο αριθμός 

των βημάτων (ακμές) που χρησιμοποιούνται σε κάθε μονοπάτι (u, . . . ,w), και μπορεί να περιοριστεί 

ο συνολικός χώρος μίας προς τα εμπρός αναζήτησης. Ας σημειωθεί ότι αυτό δεν έχει επίδραση στην 

ορθότητα των επόμενων ερωτημάτων στην τεχνική Contraction Hierarchies, καθόσο εξασφαλίζεται 

να εισάγεται πάντα μία συντόμευση (u,w) όταν δεν έχει βρεθεί ένα μονοπάτι από το u στο w, 

παρατηρώντας ότι η συντόμευση δεν είναι απαραίτητη. Επίσης, σημειώνεται ότι με περιορισμό των 

βημάτων σε δύο, η προσέγγιση δύο κατευθύνσεων παρακάμπτει μία πλήρη γρήγορη αναζήτηση 

Dijkstra. Επαρκεί για την εξέταση των ακμών που αφήνουν έναν πηγαίο κόμβο u. 

Με μικρά όρια βημάτων επιτυγχάνεται μία γρήγορη ‗συναίρεση‘, αλλά με μεγάλα όρια δημιουργείται 

ένας πιο αραιός γράφος, στον οποίο μειώνονται οι χρόνοι ερωτημάτων και είναι ευκολότερη η 

συναίρεση αργότερα. Σο ζητούμενο λοιπόν είναι να βρίσκεται η χρυσή τομή. ΢ύμφωνα με πειράματα, 

είναι καλύτερα να ξεκινά κανείς με μικρά όρια βημάτων, ακόμη κι ένα, και να τα αυξάνει αργότερα. 

Η αύξηση των ορίων μπορεί να γίνεται όταν ο μέσος βαθμός του γράφου G’ γίνεται μεγαλύτερος 

από κάποιο καθορισμένο μέγιστο. 

50


3.3.4.3 Σαξινόμηση Κόμβων. 

Η βασική προσέγγιση χρησιμοποιεί μία σειρά προτεραιότητας, της οποίας το ελάχιστο στοιχείο 

περιέχει τον κόμβο για τον οποίο φαίνεται να έιναι πιο θελκτική η συναίρεση. Η προτεραιότητα που 

χρησιμοποιείται είναι γραμμικός συνδυασμός διαφόρων παραγόντων. Η δυσκολία με αυτή την 

προσέγγιση είναι το ότι όταν ένας κόμβος v συναίρεται, αυτό θα μπορούσε να επηρεάσει τις 

προτεραιότητες άλλων κόμβων. Σο πρόβλημα αυτό αντιμετωπίζεται με αρκετές τεχνικές: 

Με χρησιμοποίηση οκνηρής ανανέωσης (lazy update). Π.χ. πριν την συναίρεση του 

κόμβου v, ανανεώνεται η προτεραιότητά του. Εάν υπερβαίνει πλέον την 

προτεραιότητα του δεύτερου μεγαλύτερου στοιχείου v’, επανεισάγεται ο v και 

συνεχίζεται η διαδικασία με τον v’. Αυτή η διαδικασία επαναλαμβάνεται μέχρι να 

βρεθεί ένα σταθερό ελάχιστο. Ας σημειωθεί ότι (τουλάχιστον ως προς την 

ταξινόμηση των κόμβων), η οκνηρή ανανέωση παρακάμπτει στιγμιαίες 

ενημερώσεις όταν η προτεραιότητα αυξάνει. 

Επαναυπολογίζεται η προτεραιότητα των γειτόνων του v. 

Περιοδικά επαναξιολογούνται όλες οι προτεραιότητες, ξαναδημιουργείται η σειρά 

προτεραιότητας. 

Σο πιο σημαντικό θέμα είναι η διαφορά ακμής. Για τον υπολογισμό της, η ταξινόμηση κόμβων 

χρησιμοποιεί τις ίδιες ευρετικές για τον περιορισμό των χώρων αναζήτησης που χρησιμοποιούνται 

αργότερα στην ίδια την συναίρεση. 

Φρησιμοποιώντας μόνο την διαφορά ακμής, είναι δυνατόν να προκύψει αργό routing. Για 

παράδειγμα, εάν ο αρχικός γράφος είναι ένα μονοπάτι, τότε η συναίρεση θα παρήγαγε μία γραμμική 

ιεραρχία όπου τα περισσότερα ερωτήματα θα ακολουθούσαν ξανά μονοπάτια γραμμικού μήκους. ΢ε 

αντίθεση, εάν επαναληπτικά συναιρούνται μέγιστα ανεξάρτητα σύνολα, τότε θα προέκυπτε μία 

ιεραρχία όπου κάθε ερώτημα θα ολοκληρωνόταν σε λογαριθμικό χρόνο. 

Γενικότερα, μια καλή ιδέα φαίνεται να είναι το να συναιρούνται οι κόμβοι οπουδήποτε στον γράφο, 

με έναν ομοιόμορφο τρόπο, παρά να διατηρείται η συναίρεση κόμβων σε μία μικρή περιοχή. Για την 

επιλογή των κόμβων ομοιόμορφα, έχουν δοκιμαστεί αρκετές ευρετικές, δύο από τις οποίες είναι οι 

εξής: 

Διεγραμμένοι Γείτονες: Μετράται ο αριθμός των γειτόνων που έχουν ήδη 

συναιρεθεί, συμπεριλαμβάνοντας τους κόμβους που έχουν προσεγγιστεί από 

αυντομεύσεις. Αυτή η ποσότητα μπορεί να διατηρείται ορθή, είτε με οκνηρή 

51


ανανέωση, είτε ανανεώνοντας τους γείτονες ενός συναιρεμένου κόμβου. Πρόκειται 

για πολύ απλές ευρετικές, οι οποίες μπορούν να υπολογιστούν αποδοτικά. 

Περιοχές Voronoi: Περιοχή Voronoi R(v) ενός κόμβου v σε έναν παράγωγο γράφο 

ορίζεται το σύνολο των κόμβων στον αρχικό γράφο που είναι πλησιέστερα στον v 

από ότι από κάθε άλλο κόμβο στον παράγωγο γράφο. Η τετραγωνική ρίζα του 

μεγέθους της περιοχής Voronoi είναι ένας παράγοντας στη συνάρτηση 

προτεραιότητας. ΢υναιρώντας συνειδητά μικρές περιοχές Voronoi, ελπίζεται ότι οι 

κόμβοι του παράγωγου γράφου θα είναι διεσπαρμένοι ομοιόμορφα στο δίκτυο. 

΋ταν συναιρείται ο v, τότε οι γειτονικές περιοχές Voronoi θα διαγράψουν την R(v). 

Οι απαραίτητοι υπολογισμοί μπορούν να γίνουν χρησιμοποιώντας O(|R(v)|) βήματα 

του αλγόριθμου του Dijkstra. Εάν πάντα συναιρούνται περιοχές Voronoi μεγέθους 

το πολύ ενός σταθερού πολλαπλάσιου του μέσου μεγέθους, εύκολα μπορεί να 

δειχθεί ότι ο συνολικός αριθμός των βημάτων στον Dijkstra για την διατήρηση του 

μεγέθους των περιοχών Voronoi είναι O(n log n). Καθώς οι περιοχές Voronoi 

μπορούν μόνο να μεγαλώσουν, η οκνηρή ανανέωση εξασφαλίζει ότι η σειρά 

προτεραιότητας δουλεύει ορθα όσον αφορά αυτόν τον παράγοντα της συνάρτησης 

προτεραιότητας. 

Τπάρχει ένας αριθμός επιπλέον προαιρετικών παράμετρων της συνάρτησης προτεραιότητας που 

μπορούν να βελτιώσουν περαιτέρω την ιεραρχία, με κόστος όμως την αύξηση του χρόνου 

ταξινόμησης των κόμβων. 

Ένα τμήμα της συναίρεσης που κοστίζει σε χρόνο είναι οι προς τα εμπρός αναζητήσεις 

συντομότερου μονοπατιού για την απόφαση σχετικά με την αναγκαιότητα των συντομεύσεων. Έτσι, 

για παράδειγμα, μπορεί να χρησιμοποιηθεί το άθροισμα των μεγεθών χώρου αυτών των 

αναζητήσεων ως ένας παράγοντας προτεραιότητας. Ας σημειωθεί ότι αυτή η ποσότητα μπορεί να 

αλλάξει πέρα από την άμεση γειτονιά του συναιρεμένου κόμβου. 

Μία εκτίμηση του πως οι συναιρεμένοι κόμβοι επηρεάζουν το μέγεθος των χρόνων που απαιτούνται 

για τις αναζητήσεις των ερωτημάτων, μπορεί να γίνει ως εξής: Τλοποιώντας την απλή εκτίμηση Q(v) 

που μπορεί να ειδοθεί ως το άνω όριο για τον αριθμό των αλμάτων ενός μονοπατιού (s, . . . , v) το 

οποίο έχει εξερευνηθεί κατά την διάρκεια ενός ερωτήματος, αρχικά είναι Q(v) = 0. ΋ταν ο v 

συναιρεθεί, τότε για κάθε γείτονά του u είναι Q(u):= max(Q(u),Q(v) + 1). 

Σέλος, μπορεί να είναι προτιμητέο να συναιρούνται κόμβοι που είναι στο σύνολο ασήμαντοι, με βάση 

μία μέτρηση κεντρικότητας μονοπατιού, όπως είναι η προσεγγιστική ενδιαμεσότητα (betweenness) 

ή το πλησίασμα (reach). 

52


3.3.4.4 Ερώτημα. 

Ένας αλγόριθμος που ήδη δουλεύει αρκετά καλά πραγματοποιεί αναζητήσεις Dijkstra από το s στο 

G↑ και από το t στο G↓. Έτσι: d(s, t) = min {d(s, v) + d(v, t) : v επισκζπτεται και στις δύο αναηθτισεις}. 

Τπάρχουν δύο βελτιώσεις στον πλήρη αλγόριθμο αναζήτησης. ΢τη μία, το ερώτημα εναλλάσει 

ανάμεσα στην προς τα εμπρός και την προςτα πίσω αναζήτηση. Οποτεδήποτε επισκέπτεται ένας 

κόμβος σε μία κατεύθυνση ο οποίος ήδη έχει επισκεφθεί στην άλλη κατεύθυνση, προκύπτει ένας 

καινούριος υποψήφιος ως συντομότερο μονοπάτι. Η αναζήτηση σε μία κατεύθυνση σταματά εάν το 

μικρότερο στοιχείο στη σειρά είναι τουλάχιστον τόσο μεγάλο όσο το καλύτερο υποψήφιο μονοπάτι 

που έχει ήδη βρεθεί. Αυτό δεν επηρεάζει την ορθότητα, καθώς πρόσθετοι επεσκεμμένοι κόμβοι σε 

αυτή την κατεύθυνση δεν μπορούν να συνεισφέρουν σε καλύτερες λύσεις. 

Ο χώρος αναζήτησης μπορεί να μειωθεί επίσης χρησιμοποιώντας την τεχνική stall-on-demand. Πριν 

επισκεφθεί ένας κόμβος v σε απόσταση d(v) στην προς τα εμπρός αναζήτηση, χρησιμοποιεί την 

πληροφορία που είναι διαθέσιμη στον G↓ για να επιθεωρήσει τις κατάντη ακμές (w, v) με w > v. Εάν 

d(w)+c(w, v) < d(v), τότε η αναζήτηση μπορεί να σταματήσει (stalled) στον v με απόσταση stalling 

d(w)+c(w, v), καθώς η υπολογισμένη απόσταση προς τον v είναι υποβέλτιστη, οπότε η συνέχιση της 

αναζήτησης από τον v θα ήταν χωρίς νόημα. Σέτοιοι κόμβοι επισκέπτονται αλλά οι ακμές που 

σχετίζονται με αυτούς δεν χαλαρώνονται, οδηγώντας σε ένα σημαντικά μικρότερο χώρο 

αναζήτησης. Παραπέρα, το stalling μπορεί να επεκταθεί σε άλλους κόμβους x στη γειτονιά του v, 

εάν το μονοπάτι που διέρχεται από τον w του γράφου G προς τον x είναι συντομότερο από το τρέχον 

μονοπάτι που έχει βρεθεί προς τον x στον γράφο G↑. Πραγματοποιείται μία τοπική Best-First 

αναζήτηση από τον v χρησιμοποιώντας τις διαθέσιμες ακμές στον G↑ ή στον G↓. Η αναζήτηση 

σταματά στους κόμβους που δεν είναι stalled. Για την εξασφάλιση της ορθότητας, γίνεται unstalled 

ένας κόμβος x εάν βρίσκεται ένα συντομότερο μονοπάτι στον G↑ προς τον x από ότι το τρέχον. Η 

τεχνική stall-on-demand εφαρμόζεται κατά τον ίδιο τρόπο και στην προς τα πίσω αναζήτηση. 

Οι γράφοι G↑ και G↓ μπορεί να αποθηκευθούν σε μία δομή δεδομένων, χρησιμοποιώντας σημαίες 

δύο κατευθύνσεων για κάθε ακμή, ώστε να δείχνεται αν αυτή ανήκει στον έναν ή στον άλλον. Άσχετα 

των σημαιών αυτών, κάθε ακμή (u, v) αποθηκεύεται μόνο μία φορά, στον μικρότερο κόμβο, που 

πληρεί τις απαιτήσεις τόσο της προς τα εμπρός, όσο και της προς τα πίσω αναζήτησης 

(συμπεριλαμβάνοντας την τεχνική stall-on-demand). Ειδικότερα, αυτό εφαρμόζεται επίσης σε ακμές 

χωρίς φορά {u, v}, με το ίδιο βάρος στις δύο κατευθύνσεις. ΢ε αντίθεση, μία αποτελεσματική 

υλοποίηση του αλγορίθμου του Dijksta (ακόμη και χωρίς φορές) χρειάζεται να αποθηκεύσει τέτοιες 

ακμές χωρίς φορά {u, v} τόσο στον u, όσο και στον v. Αυτή είναι και η αιτία που μπορεί να 

χρειάζεται λιγότερος χώρος από ότι με τον αλγόριθμο του Dijkstra για τον αρχικό γράφο, παρόλο 

που πρέπει να εισαχθούν και οι συντομεύσεις. 

53


΋πως σε όλες τις τεχνικές που χρησιμοποιούν συντομεύσεις, χρειάζεται ένας τρόπος για το 

‗ξεδίπλωμα‘ αυτών, έτσι ώστε να φανεί το συντομότερο μονοπάτι στον αρχικό γράφο. Αυτό είναι 

αρκετά απλό στην τεχνική των Contration Hierarchies, αφού κάθε συντόμευση (u,w) παρακάμπτει 

ακριβώς έναν κόμβο v. Η ανάκτηση του συντομότερου μονοπατιού γίνεται με μία απλή διεισδυτική 

ρουτίνα. Για την αποτελεσματική υλοποίηση, χρειάζεται ο κόμβος v να αποθηκεύεται κάπου μαζί με 

την συντόμευση. Ας σημειωθεί ότι αυτή η πληροφορία δεν αποκτάται εύκολα, μόνο από τον G↑ ή τον 

G↓. 

3.4 Σο Δίκτυο ΜΜΜ Σης Αθήνας. 

Η μητροπολιτική περιοχή της Αθήνας σήμερα έχει πληθυσμό περίπου 4 εκατομμυρίων, και μέση 

πυκνότητα της τάξης των 1400/km 2 . Η περιοχή αντιμετωπίζει έντονα κυκλοφοριακά προβλήματα, 

λόγω: 

Σου υπερπληθυσμού. Ο όποιος σχεδιασμός αφορά πληθυσμό περίπου 1 εκατομμυρίου, ενώ 

ακόμη κι αυτός δεν έχει τηρηθεί, με αποτέλεσμα την άναρχη ανάπτυξη. 

Σης υπερβολικής χρήσης του ΙΦ αυτοκινήτου. Η κακή διαχρονικά λειτουργία των ΜΜΜ της 

περιοχής, σε συνδυασμό με την θέαση του ΙΦ αυτοκινήτου ως συμβόλου κοινωνικής 

ανάδειξης, έχει δημιουργήσει μία πραγματικότητα όπου τα ΙΦ αυτοκίνητα χρησιμοποιούνται 

υπερβολικά, ακόμη και για μικρές αποστάσεις, ενώ αντίθετα τα ΜΜΜ σχετικά λίγο. 

Σης κακής αντιμετώπισης των ΜΜΜ. Λόγω του μεγάλου αριθμού ΙΦ αυτοκινήτων και της 

υπερβολικής χρήσης αυτών, σε συνδυασμό με την γενικότερη έλλειψη σεβασμού κανόνων, 

δημιοργούνται συνθήκες που επηρεάζουν ιδιαίτερα αρνητικά την λειτουργία κι ανάπτυξη 

των ΜΜΜ, όπως π.χ. η προβληματική παράνομη στάθμευση, η κίνηση εντός των 

λεωφορειολωρίδων, κ.α.. 

Σων πυκνών διαταράξεων της φυσιολογικής λειτουργίας της πόλης εξαιτίας των πολύ 

συχνών αποκλεισμών, ιδιαίτερα του Κέντρου, για την πραγματοποίηση πορειών, 

συλλαλητηρίων, επεισοδίων, κτλ.. 

Η λειτουργία των ΜΜΜ της περιοχής βελτιώθηκε σημαντικά προ περίπου 10-6 ετών, με την 

ανανέωση του στόλου των οχημάτων και την λειτουργία 2 επιπλέον γραμμών metro, την λειτουργία 

προαστιακού δικτύου, την επαναλειτουργία του tram, αλλά και την πρόσκαιρη αποσυμφόρηση σε 

κάποιους οδικούς άξονες από την δημιουργία νέων οδών (π.χ. Αττική Οδός) ή την βελτίωση της 

λειτουργίας υφιστάμενων, κάτι που έγινε λόγω της επικείμενης τότε διοργάνωσης των Ολυμπιακών 

Αγώνων του 2004. Έτσι σήμερα, το δίκτυο των ΜΜΜ αποτελείται από: 

Λίγο περισσότερες από 300 γραμμές θερμικών λεωφορείων. 

23 γραμμές ηλεκτροκίνητων λεωφορείων (Trolleys). 

54


3 γραμμές Metro. 

3 γραμμές Tram. 

Προαστιακό ΢ιδηρόδρομο. 

4 λεωφορειακές γραμμές εξυπηρέτησης του Αερολιμένα. Ο Αερολιμένας 

εξυπηρετείται κι από την μία γραμμή metro, όπως επίσης κι από τον Προαστιακό 

΢ιδηρόδρομο. 

Ας σημειωθεί ότι μέσα στην ίδια περιοχή υπάρχει παράλληλη λειτουργία των προαστιακών γραμμών 

του ΚΣΕΛ Αττικής, των λεωφορειακών γραμμών κάποιων δήμων, όπως επίσης και του μεγάλου 

αριθμού taxi. Επίσης, στην αρχή της εκπόνησης υπήρχε και η ειδική λεωφορειακή Γραμμή ‗400 – 

Athens Sightseeing‘, η οποία καταργήθηκε. Τπάρχουν όμως αντίστοιχες τουριστικού 

προσανατολισμού γραμμές που λειτουργούν από ιδιωτικές εταιρείες. 

Σο metro, από την στιγμή της αρχικής λειτουργίας των 2 επιπλέον γραμμών αλλά και των 

επεκτάσεών τους, αποτελεί την ραχοκοκκαλιά του συστήματος των ΜΜΜ, με συνεχή 

αναδιαμόρφωση των λεωφορειακών γραμμών ώστε να λειτουργούν τροφοδοτικά προς το metro. 

΋σον αφορά το tram, αν και υπάρχουν σκέψεις για την επέκτασή του και την δημιουργία νέων 

γραμμών, δεν έχει γίνει μέχρι σήμερα κάτι πρακτικό προς αυτή την κατεύθυνση. Έτσι, αυτή την 

στιγμή παρατηρείται σημαντική κίνηση στο Μεσόγειο τμήμα, δηλαδή μεταξύ Πλατείας ΢υντάγματος 

και παραλιακής ζώνης, ενώ αντίθετα, παρατηρείται μικρή κίνηση στα τμήματα που αφορούν την 

διαδρομή κατά μήκος της παραλίας. Η επέκταση του μέσου από το ΢ΕΥ προς το Κέντρο του Πειραιά 

θα έδινε σημαντική ώθηση στη λειτουργία του και θα βελτίωνε τις κυκλοφοριακές συνθήκες της 

πόλης, όμως μέχρι σήμερα δεν έχει υιοθετηθεί λύση προς πραγματοποίηση που να αντιμετωπίζει 

ικανοποιητικά την διέλευση των οχημάτων από τους στενούς και υπερφορτισμένους δρόμους της 

περιοχής. 

Ο Προαστικός ΢ιδηρόδρομος λειτουργεί ικανοποιητικά για το τμήμα από τον Αερολιμένα μέχρι το 

Κιάτο, εν τούτοις δεν συμβαίνει το ίδιο για το τμήμα από τον Πειραιά μέχρι τα Ν. Λιόσια, κυρίως 

λόγω προβλημάτων με την υπογειοποίηση της γραμμής, των συνεχών μετά την αρχική λειτουργεία 

συμπληρωματικών έργων, κτλ.. 

Κατά την εκπόνηση της παρούσας Εργασίας σημαντικά ήταν και τα προβλήματα που 

δημιουργούνταν στη λειτουργία του δικτύου των ΜΜΜ από τα έργα αναβάθμισης της Γραμμής 1 

του metro, οπότε και παρατηρούνταν συνεχείς διακοπές της λειτουργίας σε κάποια τμήματα. 

Ο κύριος φορέας οργάνωσης κι εποπτείας είναι ο Οργανισμός Αστικών ΢υγκοινωνιών της Αθήνας 

(ΟΑ΢Α), με θυγατρικές εταιρείες εκτέλεσης του συγκοινωνιακού έργου την ΕΘΕΛ για τα θερμικά 

λεωφορεία (~2000 οχήματα, 400 εκατομμύρια επιβάτες/έτος), την ΗΛΠΑΠ για τα ηλεκτροκίνητα 

λεωφορεία (~366 οχήματα, 77 εκατομμύρια επιβάτες/έτος), και την Η΢ΑΠ για την Γραμμή 1 του 

55


metro (‗ηλεκτρικός‘, 24 σταθμοί, 450 χιλιάδες επιβάτες/ημέρα). Η ΑΜΕΛ είναι η εταιρία λειτουργίας 

των Γραμμών 2 και 3 του metro ( 34 σταθμοί, 170 εκατομμύρια επιβάτες/έτος), με θυγατρική της 

την Σραμ (48 στάσεις, 65 χιλιάδες επιβάτες/ημέρα), για την λειτουργία του ομώνυμου μέσου. Η 

Προαστιακός είναι εταιρεία θυγατρική του Οργανισμού ΢ιδηροδρόμων Ελλάδος (Ο΢Ε), και είναι η 

εταιρεία λειτουργίας του προαστιακού δικτύου, το οποίο συνδέει τον Πειραιά, τον Αερολιμένα, το 

Κιάτο Κορινθίας, και την Φαλκίδα. Ας σημειωθεί ότι η οργανωτική μορφή είναι ιδιαίτερα ρευστή, 

καθώς κατά την περίοδο εκπόνησης της παρούσας υπήρχαν ήδη σκέψεις για την μεταβολή της. 

΋σον αφορά την τιμολογιακή πολιτική, το κύριο εισιτήριο είναι αυτό που ισχύει για όλα σχεδόν τα 

μέσα και τις γραμμές για διάρκεια 90‘ μέχρι την τελευταία επιβίβαση, χωρίς περιορισμό στις 

μετεπιβιβάσεις. Η υιοθέτηση αυτού του τύπου εισιτηρίου ήταν ένα πολύ σημαντικό βήμα για την 

ουσιαστικότερη λειτουργία του δικτύου ως ενιαίου και ολοκληρωμένου. Ειδικά εισιτήρια απαιτούνται 

για τις Γραμμές που εξυπηρετούν τον Αερολιμένα (€3.20 για τις λεωφορειακές, €6.00 για τις 

σιδηροδρομικές [ €4.00 από/προς τους 3 πλησιέστερους σταθμούς]), το τμήμα της λεωφορειακής 

γραμμής Ε22 που εξυπηρετεί την ΢αρωνίδα, μετά την Βάρκιζα (€1.20), ενώ υπάρχουν και μειωμένα 

εισιτήρια, π.χ. για φοιτητές, εισιτήρια 1, 3 ή 7 ημερών, όπως επίσης και μηνιαίες και ετήσιες κάρτες. 

Για έναν επισκέπτη της πόλης, είναι προφανές ότι μεγαλύτερο ενδιαφέρον έχουν τα εισιτήρια μέχρι 

και 7 ημερών, όπως επίσης και τα ομαδικά εισιτήρια 2 ή 3 ατόμων με έκπτωση, από/προς τον 

Αερολιμένα. 

Πρακτικά οι περισσότερες γραμμές λειτουργούν από τις 05:30 μέχρι τις 24:00 περίπου. Οι γραμμές 

του metro λειτουργούν κατ‘ εξαίρεση μέχρι τις 26:30 Παρασκευή και ΢άββατο, του Tram ολόκληρο 

το 24ωρο τις ίδιες ημέρες, με αραιά δρομολόγια τις μεταμεσονύχτιες ώρες, ενώ οι Γραμμές ‗040‘ 

και ‗11‘ λειτουργούν 24 ώρες όλη την εβδομάδα. Οι Γραμμές ‗500‘ (κατά μήκος της Γραμμής 1 του 

metro και ‗790‘ λειτουργούν τις ώρες 00:30-04:30, ενώ η Γραμμή ‗X14‘ τις ώρες 20:00-29:30 τις 

καθημερινές, και όλο το 24ωρο τα ΢αββατοκύριακα. Οι λεωφορειακές γραμμές που εξυπηρετούν 

τον Αερολιμένα λειτουργούν 24/7. 

Γενικά τα οχήματα έχουν την δυνατότητα εξυπηρέτης Ατόμων με Ειδικές Ανάγκες, όπως είναι οι 

ειδικοί χώροι για την τοποθέτηση αμαξιδίων, η λειτουργία επιγονάτισης κτλ, όμως στην πράξη η 

εξυπηρέτηση των Ατόμων αυτών είναι ελάχιστη εώς ανύπαρκτη. Σο ίδιο συμβαίνει κι όσον αφορά την 

εξυπηρέτηση των ποδηλατών, όπου είτε δεν επιτρέπεται καθόλου η μεταφορά ποδηλάτων, είτε έχει 

πάρα πολλούς περιορισμούς (Η΢ΑΠ). Ακόμη όμως κι αν τα πράγματα ήταν πολύ καλά ως προς την 

χρήση των ΜΜΜ, οι δύο αυτές κατηγορίες επιβατών και πάλι θα είχαν να αντιμετωπίσουν τις 

δυσκολίες που υπάρχουν σε ολόκληρη την πόλη. 

56


4Απαιτήσεις Και ΢χεδιασμός 

Τπηρεσίας. 

΋πως έχει αναφερθεί, πρόκειται για τον σχεδιασμό μίας Τπηρεσίας, κι όχι μίας Εφαρμογής. Ο όρος 

«Τπηρεσία» είναι σωστότερος, αφού πρόκειται για υπερσύνολο της Εφαρμογής, και μπορεί να 

περιλαμβάνει περισσότερες από μία εφαρμογές. Έτσι και στην συγκεκριμένη περίπτωση, μας 

ενδιαφέρει στην ουσία ο σχεδιασμός μίας Τπηρεσίας, η οποία διαμέσου διαφόρων εφαρμογών θα 

παρέχει αυτό που απαιτείται στους χρήστες, κι όχι μόνο, και η οποία θα επιτρέπει επιπλέον διάφορα 

χρήσιμα πράγματα που να μπορούν να επεκταθούν, όπως π.χ. την επικοινωνία με τον χρήστη, την 

δυνάτοτητα να εκφράσει μία άποψη, ένα παράπονο, ή την δυνατότητα να συνδεθεί εύκολα με 

παρόχους σχετικών χρήσιμων πληροφοριών. 

4.1 Σι Είναι Και ΢ε Ποιούς Απευθύνεται Η Τπηρεσία. 

Η Τπηρεσία σχεδιάστηκε αποσκοπώντας να διευκολύνει την μετακίνηση εντός της Αθήνας ενός 

αλλοδαπού επισκέπτη της πόλης, πεζή και κάνοντας χρήση των Μέσων Μαζικής Μεταφοράς. Σο 

κύριο μέρος της είναι η λειτουργία μίας εφαρμογής για τον σχεδιασμό ταξιδιών, αλλά σταδιακά 

μπορεί να περιλαμβάνει και διάφορα άλλα πράγματα, όπως είναι η πρώτη παρουσίαση 

57


ενδιαφερόντων σημείων, π.χ. μουσείων, ή η παρουσίαση γεγονότων που συμβαίνουν στην πόλη, με 

ενδιαφέρον συνήθως για τους επισκέπτες, όπως π.χ. ένα festival. 

Μελλοντική επέκταση θα μπορούσε να αφορά την προσαρμοσμένη παροχή πληροφοριών και σε ένα 

παράλληλο ή ανεξάρτητο τηλεφωνικό κέντρο, όπως είναι το 185 του ΟΑ΢Α, ώστε αυτό να τις 

προωθεί στους αναζητώντες. 

4.2 Βασικές Αρχές Σου ΢χεδιασμού. 

Λαμβάνοντας υπόψη ότι η Τπηρεσία απευθύνεται σε έναν αλλοδαπό επισκέπτη, είτε για τουρισμό, 

είτε για επαγγελματικούς λόγους, είναι προφανές ότι η χρησιμοποιούμενη γλώσσα δεν μπορεί να 

είναι (μόνο) η Ελληνική. Έτσι, το σύνολο της Τπηρεσίας έχει δημιουργηθεί για να παρέχεται αρχικά 

στην Αγγλική γλώσσα, με την πρόβλεψη ώστε να μπορούν να προστεθούν ολοένα και περισσότερες 

γλώσσες. 

Ένας επισκέπτης δεν γνωρίζει συνήθως τίποτα, ή έστω γνωρίζει ελάχιστα πράγματα, σχετικά με τις 

μετακινήσεις στην πόλη. Για τον λόγο αυτόν, θα πρέπει ο όλος σχεδιασμός να λαμβάνει υπόψη ότι 

όσο απλά κι αν είναι ορισμένα θέματα, εν τούτοις δεν είναι αυτονόητα για κάποιον που δεν γνωρίζει 

τα λοιπά θέματα που τα κάνουν αυτά να φαίνονται αυτονόητα. Έτσι, είναι σκόπιμο να δίνεται σε 

κάποιον που το επιθυμεί η δυνατότητα να διαβάσει τα βασικότερα στοιχεία που αφορούν τις 

μετακινήσεις στην Αθήμα, και να του δίνονται χρήσιμοι σύνδεσμοι για να αναζητήσει περισσότερα 

στοιχεία, όπως π.χ. το site του Οργανισμού Αστικών ΢υγκοινωνιακών της Αθήνας (ΟΑ΢Α). Η βασική 

αυτή ενημέρωση μπορεί να περιέχει π.χ. τα μέσα που λειτουργούν στο δίκτυο, την τιμολογιακή 

πολιτική, το που μπορεί να βρει κάποιος ένα εισιτήριο, το τι χρειάζεται να κάνει το εισιτήριο ώστε να 

μπορεί να ταξιδέψει, κτλ.. 

Ένας επισκέπτης συνήθως δεν ενδιαφέρεται για λεπτομέρειες στην πληροφορία, κι επίσης δεν 

αναζητά την τέλεια λύση. Είναι σημαντικότερο για αυτόν να βρίσκει εύκολα και άμεσα βασική 

πληροφόρηση για αυτό που θέλει, κι επίσης το να του προτείνεται κάτι απλό κι εύκολο, παρά να 

χρειάζεται να χρησιμοποιήσει κάτι πολύπλοκο, έστω κι αν του δίνει την μαθηματικά καλύτερη λύση. 

Για τον λόγο αυτόν, θα πρέπει να αποφευχθεί η παροχή στον χρήστη υπερβολικά μεγάλου αριθμού 

πληροφοριών και λειτουργιών, έστω κι αν έχει την δυνατότητα να επιλέξει το αν θα τις δει ή θα τις 

χρησιμοποιήσει. ΢την καλύτερη περίπτωση οι επισκέπτες δεν θα ενδιαφερθούν καν για αυτές, ενώ 

είναι πολύ πιθανόν να τους δυσκολέψει. 

Η τεχνολογία σήμερα παρέχει την δυνατότητα να δίνονται άμεσα και οργανωμένα μεγάλες 

ποσότητες πληροφοριών. ΋ταν κάποιος έχει μία σχετική γνώση γύρω από αυτές, και κάποιο 

μεγαλύτερο ενδιαφέρον, τότε το να του παρέχεις την δυνατότητα να τις δει και να τις ανακτήσει, σε 

κλιμακούμενο βαθμό λεπτομέρειας π.χ., είναι κάτι πολύ χρήσιμο για αυτόν. ΋μως, το ζητούμενο 

58


σήμερα είναι από την άλλη το πως θα μπορέσει κανείς να βρει την πηγή πληροφοριών για αυτό 

ακριβώς που θέλει, κατά τον τρόπο που τις θέλει, και κυρίως, πως θα φιλτράρει ποιές από όλες τις 

πληροφορίες τού είναι πραγματικά χρήσιμες. 

Κάτι αντίστοιχο συμβαίνει και με τα εργαλεία και τις δυνατότητες που παρέχονται σε κάποιον. ΋ταν 

πρόκειται για ένα θέμα που τον ενδιαφέρει και έχει τον απαιτούμενο χρόνο ενασχόλησης, τότε το να 

του προσφέρονται εργαλεία και δυνατότητες που θα είναι οργανωμένες έτσι ώστε σταδιακά να 

καταφεύγει σε αυτές και να τις χρησιμοποιήσει, είναι κάτι το επιθυμητό ή και αναγκαίο. ΢ε άλλες 

περιπτώσεις όμως, όπως π.χ. στην περίπτωσή μας, όπου κάποιος είναι απλά επισκέπτης σε μία πόλη, 

και ο οποίος δεν έχει συνήθως πολύ διαθέσιμο χρόνο και διάθεση για την εκμάθηση μιας πολύπλοκης 

ή εξεζητημένης λειτουργίας, τότε είναι προτιμότερο να γίνεται προσπάθεια κάλυψης όσο το δυνατόν 

περισσότερων τρόπον που κάποιος θα πρωτοσκεφτεί για να κάνει αυτό το απλό και βασικό που 

θέλει. 

Ψς παράδειγμα μπορεί να αναφερθεί ο τρόπος επιλογής τόπων προέλευσης και προορισμού. 

Κάποιος που πρωτοβλέπει μία αντίστοιχη εφαρμογή, μπορεί να θέλει το πρώτο που να κάνει να είναι 

ένα κλικ στον χάρτη, και να ορίζει το σημείο αυτό ως αφετηρία ή τερματισμό. Ένας άλλος, μπορεί να 

θέλει να επιλέγει από μία λίστα που θα του παρέχεται με βάση μία αλφαριθμητική αναζήτηση, ενάς 

τρίτος μπορεί να μην θέλει καν να κάνει αναζήτηση, αλλά να του παρέχεται εξαρχής μία πλήρη 

κατηγοριοποιημένη λίστα με ΢ημεία Ενδιαφέροντος. Μία σχετική εφαρμογή λοιπόν, είναι καλύτερο 

να καλύπτει όλους αυτούς τους τρόπους απλής και βασικής επιλογής, παρά να μην έχει κάποιον από 

αυτούς και να συμπεριλαμβάνει πρόσθετες λειτουργίες στους άλλους, όπως π.χ. την αναζήτηση με 

βάση την απόσταση που θα δίνεται γύρω από κάποιο επιλεγμένο σημείο, την δημιουργία λίστας 

αγαπημένων, κτλ.. 

Μία άλλη βασική αρχή του σχεδιασμού γενικότερα είναι να χρησιμοποιούνται εργαλεία και 

λειτουργίες τέτοια, ή κατά τέτοιο τρόπο, που να είναι όσο το δυνατόν οικεία στους χρήστες. Π.χ., η 

διαχείριση ενός χάρτη, δηλαδή η αλλαγή κλίμακας, η μετακίνηση, η περιστροφή κτλ, να γίνονται με 

τρόπους που ο χρήστης πιθανότατα γνωρίζει ήδη να χρησιμοποιεί, ακόμη κι αν αυτοί θεωρείται ότι 

δεν είναι οι βέλτιστοι. ΋μοια και για το περιεχόμενο του χάρτη πχ, που είναι σκόπιμο να 

παρουσιάζεται έτσι όπως έχουν μάθει οι περισσότεροι χρήστες να το βλέπουν, είτε σαν πληροφορίες 

που περιλαμβάνονται, είτε σαν τρόπο απόδοσης. Μικρές αλλαγές προσαρμογής είναι επιθυμητές, όχι 

όμως στον βαθμό που οι αλλαγές απομακρύνουν πολύ από αυτό που ήδη έχει στο μυαλό του ο 

χρήστης, ακόμη κι αν οδηγούν σε κάτι καλύτερο. Η μετάβαση των χρηστών σε κάτι καλύτερο πρέπει 

να γίνεται σταδιακά. 

59


4.3 Σρόποι Και Μέσα Παροχής της Τπηρεσίας. 

Η χρήση του World Wide Web ουσιαστικά είναι μονόδρομος σήμερα για την παροχή σχετικών 

εφαρμογών, για έναν μεγάλο αριθμό λόγων. Οι κυριότεροι από αυτούς τους λόγους είναι: 

Ο χρήστης δεν χρειάζεται να προμηθευθεί και να εγκαταστήσει τίποτα. Δεν χρειαζεται 

δηλαδή να κάνει εγκατάσταση μιας εφαρμογής στον υπολογιστή του, αλλά έχει πρόσβαση 

σε αυτήν μέσω λογισμικού ήδη εγκαταστημένου στον υπολογιστή του, που συνήθως γνωρίζει 

αρκετά, όπως είναι ο browser (Π.χ. Firefox). 

Οποιαδήποτε Web εφαρμογή πρακτικά είναι ανεξάρτητη του υπολογιστή στον οποίον 

εκτελείται. Έτσι, δεν απαιτούνται διαφορετικές εκδόσεις της εφαρμογής για τα διάφορα 

λειτουργικά συστήματα. Η εφαρμογή μπορεί εύκολα να υλοποιηθεί ώστε να λειτουργεί το 

ίδιο, είτε πρόκειται για σύστημα Windows, είτε για Linux π.χ.. 

Αφού δεν εγκαθίσταται κάτι στον υπολογιστή του χρήστη, είναι πολύ εύκολη και άμεση η 

συνεχής βελτίωση και ενημέρωση. 

Τπάρχει πρόσβαση σχεδόν από οποιοδήποτε σημείο του πλανήτη. ΢υνεπώς μπορεί κάποιος 

π.χ. να πάρει πληροφορίες και να προσχεδιάσει τις μετακινήσεις του στην Αθήνα, πριν καν 

επισκεφθεί την πόλη. 

΋μοια με το προηγούμενο, που αφορά τους χρήστες, η διαδικτυακή προσβασιμότητα 

διευκολύνει επίσης την διαχείριση της εφαρμογής από αυτούς που την παρέχουν, από 

οποιοδήποτε σημείο του πλανήτη κι αν βρίσκονται. 

Λόγω του ότι συνεχώς αναπτύσεται η χρήση του Internet από συσκευές όπως τα κινητά 

τηλέφωνα και οι μικροί φορητοί υπολογιστές, η δυνατότητα πρόσβασης αυξάνει σημαντικά. 

Η δυνατότητα αυτή μάλιστα, για Τπηρεσίες όπως η παρούσα, αλλάζει ταχύτατα το 

αντικείμενο και το περιεχόμενο, μεγενθύνοντας την χρησιμότητα. Σο ότι κάποιος μπορεί να 

έχει πρόσβαση σε μία υπηρεσία που αφορά τις μετακινήσεις του, όχι μόνο από το σπίτι ή 

από τον χώρο εργασίας, αλλά και από τον δρόμο όπου ήδη κινείται, είναι προφανώς πολύ 

λειτουργικό, και δημιουργεί την δυνατότητα και ανάγκη για παροχή περισσότερων 

πληροφοριών, όπως π.χ. την σε πραγματικό χρόνο ενημέρωση για τις κινήσεις των 

οχημάτων των Μέσων Μαζικών Μεταφορών. 

Παρέχεται η δυνατότητα συλλογής ανώνυμα στατιστικών στοιχείων για την χρήση, τα οποία 

μπορούν να βοηθήσουν στην βελτίωση της παρέχομενης υπηρεσίας. 

Είναι δυνατόν, μέσω π.χ. διαφημίσεων, να γίνεται μερική ή ολική χρηματοδότηση της 

λειτουργίας, χωρίς ιδιαίτερη όχληση των χρηστών, αρκεί φυσικά να τηρούνται κάποια 

λογικά όρια. 

Η λογική όλων των τεχνικών και εργαλείων σε σχέση με τις διαδικτυακές εφαρμογές 

διευκολύνει ιδιαίτερα την ανοιχτή αρχιτεκτονική, δηλαδή την δυνατότητα εύκολης 

επέκτασης. 

60


4.4 Σρόποι Και Εργαλεία Τλοποίησης. 

Αν και το θέμα αυτό δεν αφορά ιδιαίτερα τον χρήστη, είναι σημαντικό όμως σαν επιλογές για την 

ανάπτυξη της Τπηρεσίας, καθόσον καθορίζεται σημαντικά ο τρόπος υλοποίησης των διάφορων 

λειτουργιών, ακόμα και στον βαθμό τού κατά πόσο είναι αυτές εφικτές ή όχι. 

Βασική επιλογή ήταν η ανάπτυξη να γίνει κατά λόγο με χρήση λογισμικών ελεύθερης χρήσης 

(Freeware), ή ακόμη καλύτερα, με λογισμικό ανοιχτού κώδικα (Open Source). ΋μοια, τα δεδομένα 

επιλέχθηκε κι αυτά να είναι είτε ελεύθερα προς χρήση, είτε ακόμη καλύτερα, δεδομένα στα οποία 

θα μπορεί κανείς να επέμβει και να τα τροποποιήσει ή εμπλουτίσει. 

Η χρήση λογισμικού ανοικτού κώδικα, όχι μόνο διευκολύνει την ανάπτυξη καλύτερα 

προσαρμοσμένων λύσεων και την συνεχή επέκταση, αλλά στα πλαίσια του 

εκπαιδευτικού/ερευνητικού χαρακτήρα της παρούσας, έδωσε την δυνατότητα για ενασχόληση με 

ότι συνδέεται με την ανάπτυξη λογισμικού από ομάδες ανθρώπων που δουλεύουν παράλληλα σε 

κάποιο αντικείμενο ακόμη κι αν βρίσκονται σε πολύ απομακρυσμένα σημεία του πλανήτη, ακόμη κι 

αν δεν υπάρχει σαφής και συγκεκριμένος τρόπος διαχείρισης της εργασίας από συγκεκριμένα 

πρόσωπα, όπως συμβαίνει π.χ. σε επιχειρήσεις. 

Κάτι σημαντικό ήταν να ακολουθηθούν κατά το δυνατόν καθορισμένα πρότυπα όσον αφορά την 

διαχείριση και αποθήκευση των δεδομένων, ώστε αφενός να είναι εύκολη η χρήση έτοιμων 

εργαλείων, αφετέρου να μπορεί να γίνει συνεργασία της εφαρμογής με άλλες εφαρμογές στο μέλλον. 

4.5 Οικονομικά Θέματα. 

Σο τμήμα αυτό δεν αφορά άμμεσα τον ακαδημαϊκό χαρακτήρα της παρούσας υλοποίησης, όμως 

είναι ιδιαίτερα σημαντικό υπό άλλες συνθήκες στον σχεδιασμό. 

΢υνήθως, ο πάροχος μιας τέτοιας υπηρεσίας είναι ο ίδιος ο φορέας των αστικών συγκοινωνιών μίας 

πόλης, ο οποίος τις περισσότερες φορές δεν λειτουργεί αμιγώς κερδοσκοπικά, ή κι αν συμβαίνει 

αυτό, έχει έμμεσο όφελος με την λειτουργία μιας τέτοιας υπηρεσίας, από την προσέλκυση επιβατών. 

΢ε αυτήν την περίπτωση συνεπώς δεν παίζει ιδιαίτερο ρόλο η ύπαρξη άμεσων εσόδων, πρέπει απλώς 

να διατηρούνται χαμηλά τα έξοδα, τόσο για την ανάπτυξη, όσο και για την λειτουργία. 

΢ε περίπτωση που η Τπηρεσία δεν παρέχεται από τον φορέα εκτέλεσης ή εποπτείας του 

΢υγκοινωνιακού Έργου, ή άπο κάποιον άλλον σχετιζόμενο με αυτόν, τότε θα πρέπει απαραίτητα να 

υπάρχει κάποιο έσοδο. ΋πως έχει προαναφερθεί, η Τπηρεσία απευθύνεται στους επισκέπτες της 

61


πόλης. Αυτό σημαίνει ότι πρόκειται για περιστασιακούς χρήστες, οπότε και δεν μπορεί να υπάρξει 

συνδρομητική παροχή, ούτε μπορεί εύκολα να ενταχθεί η υπηρεσία σε κάποια άλλη που παρέχεται 

μέσω συνδρομής. Ακόμη, δεν έχει νόημα η καταβολή ενός τιμήματος εφάπαξ από τον χρήστη, αφού 

αυτό αναγκαστικά θα ήταν ιδιαίτερα μικρό, και συνεπώς η απαιτούμενη πρόσθετη διαδικασία που 

θα απαιτούνταν από τον χρήστη θα απέφερε λίγα, και περισσότερο θα απέτρεπε την χρήση. 

Έτσι, η μόνη δυνατότητα αυτοχρηματοδότησης της λειτουργίας της Τπηρεσίας είναι η ύπαρξη 

διαφημίσεων, ή η σύνδεσή της με κάποιο άλλο μέσο το οποίο να παράγει οικονομικό όφελος, όπως 

π.χ. αύξηση της προσβασιμότητας σε άλλο site, του οποίου η Τπηρεσία να αποτελεί τμήμα. 

΢ε κάθε περίπτωση, τα έξοδα υλοποίησης και λειτουργίας θα πρέπει να είναι όσο το δυνατόν πιο 

χαμηλά, κάτι που υποβοηθείται σημαντικά από την χρήση λογισμικού και δεδομένων που παρέχονται 

ελεύθερα ή με μικρό κόστος ακόμη και για εμπορική χρήση. 

4.6 Ονομασία Σης Τπηρεσίας. 

Μία υπηρεσία αυτού του είδους θα πρέπει να ονομάζεται με τρόπο που να είναι εύκολο σε κάποιον 

να τη θυμάται, δηλαδή κατά κανόνα με ένα σύντομο, απλό, και ίσως νοηματικά ιδιαίτερα σχετικό και 

περιεκτικό όνομα. Σο όνομα αυτό είναι καλό να είναι ανεξάρτητο από την γλώσσα, ή να βασίζεται 

πάνω στην αγγλική γλώσσα, που απευθύνεται ακουστικά και στο μεγαλύτερο κοινό. 

Ακόμη, θα πρέπει αυτό το όνομα να μην συγχέεται εύκολα με κάτι άλλο, κι επίσης, όσον αφορά 

διαδικτυακές εφαρμογές και υπηρεσίες, να μην είναι δεσμευμένο το domain με το όνομα αυτό. 

4.7 Περιγραφή Σης Τπηρεσίας ΋σον Αφορά Σον Φρήστη. 

΢τη συνέχεια γίνεται περιγραφή των βασικών λειτουργιών της Τπηρεσίας, έτσι όπως αποφασίστηκε 

να λειτουργεί και να παρέχεται: 

62



Η Τπηρεσία, εκτός από την εφαρμογή για την εύρεση διαδρομών με χρήση των ΜΜΜ, θα πρέπει να 

παρέχει επιπλέον την δυνατότητα επικοινωνίας με τους λειτουργούς, όπως μέσω ενός μηνύματος 

email. Έτσι, θα μπορούν να υποβάλλονται προτάσεις βελτίωσης π.χ.. 

Ακόμη, θα πρέπει να δίνονται κάποιο σχετικοί κι ενδιαφέροντες σύνδεσμοι, π.χ. προς τον ΟΑ΢Α ή τις 

εταιρείες εκτέλεσης μεταφορικού έργου. ΢την πράξη, εκτός της ΑΜΕΛ, της εταιρείας λειτουργίας του 

Metro, οι υπόλοιπες εταιρείες δεν παρέχουν ιδιαίτερα χρήσιμη πληροφόρηση για τον επισκέπτη. 

Επίσης, θα πρέπει να δίνεται στον χρήστη η δυνατότητα να βλέπει περισσότερες πληροφορίες για 

την ταυτοποίηση της Τπηρεσίας, δηλαδή ποιός την έχει δημιουργήσει, ποιός την λειτουργεί, όπως και 

ποιοί είναι οι όροι χρήσης. ΢το σημείο αυτό μπορούν να γινόνται και οι διάφορες αναφορές στο 

λογισμικό και στα δεδομένα που έχουν χρησιμοποιηθεί, με τα πιθανά σχετικά copyrights. 

Επιπλέον, είναι χρήσιμο να υπάρχει η δυνατότητα επέκτασης προβολής πληροφοριών, όπως π.χ. για 

δρώμενα στην πόλη. 

΢υνοπτικά, η διαδικασία που απαιτείται να κάνει ο χρήστης από την στιγμή της εισόδου του σε μία 

ανάλογη εφαρμογή, μέχρι την στιγμή της εξόδου του από αυτήν, έχοντας πάρει ότι ζητούσε, είναι σε 

μεγάλο βαθμό συγκεκριμενοποιημένη από την φύση του αντικειμένου. Αυτό που καταρχάς ζητείται 

είναι η παραμετροποίηση του ερωτήματος, η θέση του, η λήψη των αποτελεσμάτων, και ο 

παραπέρα χειρισμός τους, όπως π.χ. η εκτύπωση. 

΢ε μορφή διαγράμματος, η βασική αυτή λειτουργική ροή έχει ως εξής: 

Αρχικοποίθςθ 

Ραραμετροποίθςθ 

Ερωτιματοσ 

Θζςθ Ερωτιματοσ Λιψθ Απάντθςθσ 

Διάγραμμα 1: Λειτουργική Ροή της Εφαρμογής Φρήστη. 

Βοικεια / Πλθροφορίεσ / Επικοινωνία 

Διαχείριςθ 

Απάντθςθσ 

63


4.7.2 Ο Φάρτης. 

Σο κύριο στοιχείο που βλέπει ο χρήστης σε μία ανάλογη εφαρμογή είναι ο χάρτης, ο οποίος αφενός 

παρέχει το χαρτογραφικό υπόβαθρο, αφετέρου αποτελεί το εργαλείο με το οποίο επιτυγχάνεται η 

γραφική αναπαράσταση και η διαδραστικότητα. Θα πρέπει να είναι αρκετά πλήρης και 

ενημερωμένος, όπως επίσης, να παρέχει την ονομασία των οδών σε λατινική γραφή. 

Ο χάρτης πρέπει να έχει τουλάχιστον τις βασικές λειτουργίες, όπως είναι η δυνατότητα εύκολης 

μετακίνησης και αλλαγής της κλίμακας. Η δυνατότητα αλλαγής του τύπου χάρτη είναι επιθυμητή, 

αλλά όχι απαραίτητη. Σο ίδιο ισχύει και για την δυνατότητα τρισδιάστατης απεικόνισης. 

Κάτι σημαντικό, αν και όχι ορατό στον χρήστη, είναι η δυνατότητα αξιοποίησης των στοιχείων του 

χάρτη ως αντικείμενα, π.χ. το οδικό δίκτυο να υπάρχει σε διανυσματική μορφή, με διάφορα στοιχεία 

του ως περιεχόμενα δεδομένα, όπως τα ονόματα και οι τύποι των οδών. Είναι δυνατόν να 

χρησιμοποιηθούν διαφορετικοί χάρτες για το οπτικό/διαδραστικό ζητούμενο και για το σχετικό με τα 

δεδομένα και το routing αντίστοιχο. ΋μως, θα πρέπει αυτοί οι δύο χάρτες να ταυτίζονται σε 

ικανοποιητικό βαθμό, ιδίως χωρικά. 

Κάτι που είναι πέρα από αυτά που δίνονται στον χρήστη, είναι η δυνατότητα εύκολης και γρήγορης 

διαχείρισης προγραμματιστικά των αντικειμένων που μπορούν να τοποθετηθούν πάνω στον χάρτη, 

όπως επίσης των συμβάντων που καταγράφονται στον ίδιον και τα αντικείμενά του. 

4.7.3 Επιλογές Σαξιδίου. 

Σο πρώτο πράγμα που καλείται να δώσει ο χρήστης είναι οι παράμετροι που αφορούν το ταξίδι που 

θέλει να πραγματοποιήσει. Οι δύο κύριες παράμετροι είναι ο τόπος αφετηρίας και ο τόπος 

τερματισμού. Η επιλογή τους θα πρέπει να μπορεί να γίνεται είτε μέσω αναζήτησης, είτε γραφικά, με 

επιλογή των τόπων στον χάρτη, είτε με επιλογή από λίστα κατηγοριοποιημένων σημείων 


Η αναζήτηση των τόπων αφετηρίας ή τερματισμού είναι δυνατόν να γίνεται μέσω κάποιου σχετικού 

γεωευρετήριου, ανάλογα με το αλφαριθμητικό που έχει δώσει ο χρήστης. Σο γεωευρετήριο είναι 

δυνατόν να επιστρέψει πάνω από έναν τόπο, οπότε τότε είναι απαραίτητο να εμφανιστούν όλα τα 

αποτέσματα σε μία λίστα, ώστε ο χρήστης να επιλέξει αυτό που είναι όντως το ζητούμενο. 

Η επιλογή τόπου αφετηρίας ή τερματισμού είναι σκόπιμο να γίνεται και με γραφικό τρόπο, καθώς 

κάποιος μπορεί να μην ενδιαφέρεται ή να μην ξέρει μία ακριβή διεύθυνση, αλλά να έχει την εικόνα 

64


του τόπου από κάποιον άλλον χάρτη. Η επιλογή αυτή είναι δυνατόν να πραγματοποιείται με ένα 

context menu, δηλαδή με την προσθήκη 2 πρόσθετων γραμμών στις επιλογές που παρέχονται με 

πάτημα του δεξιού κουμπιού στο ποντίκι. 

Επειδή όμως μπορεί κάποιος να μην γνωρίζει τον ακριβή τρόπο γραφής ενός σημείου 

ενδιαφέροντος, κρίνεται σκόπινο να υπάρχει και η δυνατότητα επιλογής από κατηγοριοποιημένη 

λίστα, κάποιου από τα επιλεγμένα για τους χρήστες που απευθύνεται η εφαρμογή σημεία 

ενδιαφέροντος, όπως π.χ. είναι τα ξενοδοχεία, τα μουσεία, κτλ.. 

Μία πρακτικά χρήσιμη λειτουργία, είναι η δυνατότητα άμεσης εναλλαγής των τόπων προέλευσης και 

προορισμού. Αυτό μπορεί να είναι εφικτό με το πάτημα ενός κουμπιού τοποθετημένου κατάλληλα 

πάνω στην φόρμα εισαγωγής των στοιχείων. 

Άλλη επιλογή σχετικά με το ταξίδι αφορά τον χρόνο. Έτσι θα πρέπει ο χρήστης να εισάγει την 

ημερομηνία και την ώρα, όπως επίσης το αν η ώρα αφορά το πότε θέλει να ξεκινήσει το ταξίδι του, ή 

το πότε θέλει να φτάσει στον προορισμό του. 

Ένα άλλο σημείο των επιλογών αφορά τον τρόπο με τον οποίον θέλει να μετακινηθεί ο χρήστης. Ο 

προεπιλεγμένος τρόπος πρέπει να είναι ο πλέον συνηθισμένος, δηλαδή με οποιοδήποτε ΜΜΜ και 

πεζή. Άλλες επιλογές που μπορούν να προσφέρονται είναι μόνο πεζή, με λεωφορεία και πεζή, ή με 

metro και πεζή. Επιπλέον του τρόπου μετακίνησης, σκόπιμο είναι ο χρήστης να μπορεί να θέσει το 

προσωπικό του όριο για το μέγιστο μήκος της διαδρομής που θα πρέπει να κάνει πεζή. 

Σο τελευταίο στοιχείο όσον αφορά τις επιλογές ταξιδίου είναι η επιλογή του τρόπου βελτιστοποίησης. 

΢αν επιλογές πρέπει να υπάρχουν η ελαχιστοποίηση του χρόνου ταξιδίου, ή του αριθμού των 

μετεπιβιβάσεων, καθώς αυτές είναι ιδιαίτερα ενοχλητικές για κάποιους επιβάτες. 

4.7.3.1 Λειτουργία Προεπιλών. 

Κάτι ιδιαίτερα χρήσιμο σε μία τέτοια εφαρμογή είναι η ύπαρξη της δυνατότητας κάποιες από τις 

παράμετρους του ερωτήματος να έχουν προεπιλεγεί, από το site το οποίο κατευθύνει στην 

εφαρμογή. Π.χ. στο site που γίνεται αναφορά ενός συνεδρίου, μπορεί να υπάρχει στο τέλος ένα Link 

με την ονομασία «Δείτε πως μπορείτε να έρθετε στο χώρο του ΢υνεδρίου με ΜΜΜ», από όπου θα 

καλείται η εφαρμογή με προεπιλεγμένη την τοποθεσία του Προορισμού, όπως επίσης την επιθυμητή 

ημερομηνία κι ώρα άφιξης σε αυτήν. 

Κάτι τέτοιο είναι εξυπηρετικό για τον σύνεδρο, αφού μαθαίνει για την ύπαρξη της εφαρμογής, την 

οποία μάλιστα μπορεί να την χρησιμοποιήσει χωρίς να απαιτείται να βρει ο ίδιος τον προορισμό. 

65


Πολύ περισσότερο όμως, έτσι βοηθείται η ίδια η σχεδιαζόμενη εδώ Τπηρεσία, καθώς γίνεται πιο 

εύκολα και γρήγορα γνωστή, μέσα από την δημιουργία αναφορών για αυτήν σε άλλα sites. 

Αν και η λειτουργία προεπιλογών αφορά κυρίως τον προορισμό, εν τούτοις υπάρχουν κάποιες λίγες 

περιπτώσεις όπου μπορεί να είναι προεπιλεγμένη η αφετηρία, όπως π.χ. στο site ενός αερολιμένα: 

«Δείτε πως μπορείτε να φτάσετε από τον Αερολιμένα μας στον προορισμό σας με ΜΜΜ». 

4.7.4 Αποτελέσματα. 

Μετά από μία σύντομη αναμονή, στην οθόνη του χρήστη πρέπει να παρουσιάζονται τα σχετικά 

αποτελέσματα, ή ένα μήνυμα σφάλματος. Σα αποτελέσματα μπορούν να εμφανίζονται σε 

κατακόρυφη μορφή, όπου στο ψηλότερο σημείο θα εμφανίζονται συγκεντρωτικά οι επιλογές που 

έγιναν. Πιο κάτω θα εμφανίζονται οι προτάσεις ταξιδίου, με τα βήματα σε κατακόρυφη ανάπτυξη. 

Οι προτάσεις ταξιδίου θα μπορούν να είναι 3 το μέγιστο, και θα μπορεί να εμφανίζεται μία κάθε 

φορά στην οθόνη. Αυτό μπορεί να επιτευχθεί με την χρήση ενός accordion π.χ.. ΢την αρχή της κάθε 

πρότασης μπορούν να εμφανίζονται τα βασικά στοιχεία της, όπως η κατ‘ εκτίμηση ώρα εκκίνησης 

και ώρα τερματισμού, ο χρόνος διαδρομής, και ο αριθμός των μετεπιβιβάσεων. 

΢τα βήματα που αφορούν διαδρομή πεζή θα εμφανίζονται οδηγίες για την μετάβαση από το ένα 

σημείο στο άλλο και η απόσταση. ΢τα βήματα που αφορούν διαδρομές με ΜΜΜ θα αναφέρεται ο 

τύπος και ο αριθμός της γραμμής που πρέπει να χρησιμοποιηθεί, όπως επίσης ο απαιτούμενος 

χρόνος διαδρομής, η στάση επιβίβασης, η στάση αποβίβασης, η στάση πριν την αποβίβαση, για 

διευκόλυνση του Φρήστη στον έγκαιρη συνειδητοποίηση τού πότε πρέπει να αποβιβαστεί, καθώς και 

οι εναλλακτικές Γραμμές που θα μπορεί αυτός να χρησιμοποιήσει. 

΢το τέλος κάθε πρότασης θα δίνονται τα συγκεντρωτικά στοιχεία του χρόνου διαδρομής, του μήκους 

περπατήματος, όπως επίσης το κόστος κανονικού εισιτηρίου. Ο χάρτης θα πρέπει να οπτικοποιεί τα 

βήματα που παρουσιάζονται, χρησιμοποιώντας κατάλληλα σύμβολα και χρωματισμούς. 

Σέλος, θα πρέπει να δίνεται η δυνατότητα επανακαθορισμού των επιλογών ταξιδίου, όπως επίσης η 

δυνατότητα εκτύπωσης των αποτελεσμάτων. 

66


4.7.4.1 Εκτύπωση. 

Η λειτουργία της εκτύπωσης θα πρέπει παρουσίαζει όλα τα γενικά στοιχεία και τα αναλυτικά βήματα 

μιας επιλεγμένης πρότασης ταξιδιού σε μία νέα σελίδα, με μέγεθος που να είναι εφικτή η 

ικανοποιητική εκτύπωσή της σε σελίδα Α4. 

4.8 Περιγραφή Σης Τπηρεσίας ΋σον Αφορά Σην Ανάπτυξη. 

Προηγουμένως περιγράφηκαν οι απαιτήσεις και ο λειτουργικός σχεδιασμός της Τπηρεσίας, έτσι 

όπως αυτά αφορούν τις λειτουργίες του χρήστη. ΢την παρούσα παράγραφο εξετάζεται ο σχεδιασμός 

και η λειτουργία από την σκοπιά του developer και του operator. 

Πέρα από την λειτουργία της ίδιας της Τπηρεσίας, υπάρχει η ανάγκη του σχεδιασμού μεθόδων και 

εργαλείων για την διαχείριση αυτής και των δεδομένων της. Η διαχείριση της Τπηρεσίας αναφέρεται 

στις διαδικασίες για την διατήρηση σε λειτουργία, την αντιμετώπιση πιθανών προβλημάτων, τις 

επιλογές για την περαιτέρω ανάπτυξη και επέκταση. ΢ε μεγάλο βαθμό τα θέματα αυτά αφορούν 

πραγματική λειτουργία, σε περιβάλλοντα όπου υπάρχουν συγκεκριμένοι ρόλοι, και για αυτό δεν 

γίνεται εκτενής εξέταση, παρά μόνον όσον αφορά την λειτουργία των επιμέρους υλικών και 

λογισμικών. Έτσι, στην παρούσα περιοριζόμαστε π.χ. στο ότι όλα τα λογισμικά που θα 

χρησιμοποιηθούν (π.χ. Web server) είναι σκόπιμο να είναι ευρέως διαδεδομένα, και να μην 

χρειάζεται να γίνει ιδιαίτερη εκπαίδευση για αυτά σε κάποιον που είναι σχετικός με το αντικείμενο. 

΋σον αφορά τα δεδομένα, απαιτείται ένας τρόπος με τον οποίον να μετασχηματίζονται εύκολα από 

την μορφή που παραλαμβάνονται (π.χ. στοιχεία ΟΑ΢Α), σε μορφή που να χρησιμοποιούνται από τις 

εφαρμογές. Επίσης, απαιτούνται τρόποι για την εύκολο έλεγχο, την εποπτεία, αλλά και την 

ενημέρωσή τους. Επειδή η παρούσα δεν αφορά πραγματική λειτουργία, όπου θα πρέπει να 

επαναλαμβάνονται κάποια πράγματα, δεν πραγματοποιήθηκε ανάπτυξη σχετικών εργαλείων. Ο 

μετασχηματισμός δεδομένων έγινε χειροκίνητα π.χ., και αντίστοιχη χειροκίνητη εργασία απαιτείται 

για κάθε νέο set δεδομένων. Σο μόνο αναγκαίο εργαλείο αφορά την απαραίτητη μετατροπή των 

δεδομένων σε γράφο. 

΢τη σύνεχεια δίνονται διαγραμματικά τα διάφορα τμήματα της Τπηρεσίας και οι αλληλοσυσχετίσεις 

τους: 

67


Διάγραμμα 2: Σα διάφορα τμήματα που αποτελούν την υπηρεσία, και οι αλληλοσυσχετίσεις τους. 

68


5Δεδομένα. 

5.1 Δεδομένα Δικτύου ΜΜΜ. 

΢το σημείο αυτό του κειμένου αναλύεται το πολύ σημαντικό θέμα των δεδομένων του δικτύου ΜΜΜ. 

Και είναι πολύ σημαντικό, γιατί ακόμη κι αν χρησιμοποιείται η πιο εύχρηστη και πολυλειτουργική 

εφαρμογή για το interface, ακόμη κι αν έχει βρεθεί και υλοποιηθεί ο καλύτερος αλγόριθμος για την 

εξαγωγή αποτελεσμάτων, αυτά όλα θα είναι χωρίς αντίκρισμα αν τα δεδομένα με τα οποία 

λειτουργούν δεν είναι πλήρη, ακριβή, και κατάλληλα δομημένα. 

΢τα δεδομένα που αφορούν την εφαρμογή θα μπορούσαν να επισημανθούν κάποιες κύριες 

ιδιότητες που θα πρέπει να υπάρχουν όσο το δυνατόν σε μεγαλύτερο βαθμό: 

Η Πληρότητα. 

Σα δεδομένα θα πρέπει να είναι πλήρη, ή τουλάχιστον να έχει γίνει μελετημένη και 

αποτελεσματική επιλογή αυτών που μπορούν και να μην συμπεριλαμβάνονται. Δεν 

έχει νόημα π.χ. να υπάρχουν στοιχεία μόνο για μέρος των Γραμμών, καθώς τότε οι 

όποιες λύσεις μπορεί να απέχουν πάρα πολύ από τις πραγματικά καλές. Θα 

69


μπορούσαν όμως να μην συμπεριληφθούν στοιχεία Γραμμών με ιδιαίτερα μικρή 

συχνότητα, ή που η φύση της λειτουργίας τους δεν σχετίζεται με τις ανάγκες του 

κοινού στο οποίο απευθύνεται η Εφαρμογή. Σέτοιες 

Γραμμές π.χ. είναι αυτές που εξυπηρετούν ειδικές 

τοποθεσίες, όπως σχολεία, κοιμητήρια, στρατιωτικές 

εγκαταστάσεις. 

Η Εγκυρότητα. 

Σα δεδομένα θα πρέπει να είναι όσο το δυνατόν 

περισσότερο έγκυρα, δηλαδή να είναι ορθά και να μην 

περιέχουν λάθη. ΢ε περίπτωση που αυτό δεν συμβαίνει σε 

ικανοποιητικό βαθμό, τότε χάνει την αξία του το σύνολο 

των δεδομένων. Αν π.χ. τα δρομολόγια κάποιων Γραμμών 

δεν είναι σωστά, τότε δεν μπορεί να υπάρχει 

εμπιστοσύνη σε κανένα δεδομένο δρομολογίων. 

΢ε πολλές περιπτώσεις είναι καλύτερο να μην υπάρχουν 

κάποιες λειτουργίες, ή αυτές να υλοποιούνται με μία 

μέθοδο εκτίμησης, παρά να χρησιμοποιούνται στοιχεία 

μικρής αξιοπιστίας. Για παράδειγμα σε σχέση με την 

εφαρμογή, είναι προτιμότερο να χρησιμοποιηθούν ως 

χρόνοι διαδρομής από κάποια στάση σε κάποια άλλη 

αυτοί που προκύπτουν από παρεμβολή στον συνολικό 

χρόνο διαδρομής, λύση ευκολότερη μάλιστα, παρά να 

χρησιμοποιηθούν μετρημένοι χρόνοι που όμως έχουν 

πολλή μικρή αξιοπιστία. 

Η ΢υνάφεια. 

Ακόμη και αν τα στοιχεία δεν έχουν μεγάλη πληρότητα 

ή/και εγκυρότητα, ιδιαίτερα σημαντικό είναι πάντα να 

διαθέτουν συνάφεια, είτε εσωτερική (μεταξύ τους) είτε 

με άλλα στοιχεία που χρησιμοποιούνται. Αυτό σημαίνει 

ότι θα πρέπει τα έστω και χαμηλής ποιότητας δεδομένα 

για ένα θέμα, να είναι σύμφωνα με τα δεδομένα ενός 

άλλου θέματος. ΢τη συγκεκριμένη Εφαρμογή π.χ., τα 

στοιχεία των διαδρομών, δηλαδή οι αλληλουχίες των 

στάσεων, θα πρέπει να συμφωνούν με τα στοιχεία των 

στάσεων, ακόμη κι αν αυτές βρίσκονται σε λάθος θέσεις, έχουν λανθασμένα 

Εικόνα 21: Δείγμα του Πίνακα ‗Γραμμές‘ των πρωτογενών δεδομένων ΜΜΜ. 

70


ονόματα, ή οτιδήποτε άλλο. Μία συνήθης εμφάνιση τέτοιων προβλημάτων είναι τα 

ορφανά δεδομένα, ή τα δεδομένα που «δείχνουν» άλλα, ανύπαρκτα δεδομένα. ΢ε 

συνδυασμό με ελλειπή έλεγχο και χειρισμό λαθών από προγραμματιστικής πλευράς, 

η έλλειψη συνάφειας μπορεί να οδηγεί συχνά σε απρόβλεπτη λειτουργία κι 

αποτελέσματα. Σο ιδανικό είναι η ανάπτυξη εργαλείων που, είτε δεν επιτρέπουν 

καν την δημιουργία ασυναφειών, είτε εντοπίζουν και επισημαίνουν αυτές που 

έχουν δημιουργηθεί και υπάρχουν. 

Η Δυνατότητα Εύκολης Ενημέρωσης/Μεθοδολογία Ενημέρωσης. 

Σα δεδομένα λειτουργίας θα πρέπει να ανανεώνονται συνεχώς, ή έστω σε συχνά 

διαστήματα, έτσι ώστε να αντιπροσωπεύουν την πραγματική κατάσταση. Για τον 

λόγο αυτό θα πρέπει τα δεδομένα, τα μεταδεδομένα, αλλά και τα ενδιάμεσα 

δεδομένα από τα πηγαία προς τα χρησιμοποιούμενα, να είναι σε τέτοια μορφή που 

να μπορούν εύκολα να ενημερωθούν. Ιδιαίτερα χρήσιμη είναι φυσικά και η 

δυνατότητα τροποποίησης της ίδιας της δομής τους, η ευελιξία δηλαδή. 

Η δυνατότητα εύκολης ενημέρωσης αφορά και την ύπαρξη μέσων και μεθόδων 

έτσι ώστε να εντοπίζονται εύκολα και γρήγορα τα σημεία που θα πρέπει να 

ενημερωθούν και να υπάρχει μια κατά το δυνατόν αυτοματοποιημένη διαδικασία, 

αφού αυτή είναι επαναληπτική. 

΢την παρούσα Εφαρμογή, η εύκολη ενημέρωση και αυτοματοποίηση αφορά το 

κομμάτι της διατήρησης Βάσης Δεδομένων και της εξαγωγής τους σε GT Feed. 

Δυστυχώς, το προηγούμενο τμήμα, δηλαδή η ανάκτηση καταγεγραμμένων 

αλλαγών από τον ΟΑ΢Α, ή της εξέτασης των νέων κάθε φορά δεδομένων από 

αυτόν και η αυτοματοποιημένη εύρεση των αλλαγών, δεν είναι εφικτό να 

συστηματοποιηθεί. Αυτό, όπως φαίνεται σε άλλο σημείο του κειμένου, οφείλεται 

στον τρόπο καταγραφής και διαχείρισης των δεδομένων του Οργανισμού. 

71


5.1.1 Πρωτογενή Δεδομένα ΜΜΜ. 

΋λα σχεδόν τα πρωτογενή δεδομένα για τα ΜΜΜ αποκτήθηκαν 

απευθείας από τον ΟΑ΢Α, έπειτα από σχετική αίτηση. Σα στοιχεία 

αυτά επεξεργάστηκαν αργότερα με βάση την εμπειρική γνώση του 

δικτύου, όπως επίσης σε συνδυασμό με δεδομένα από έρευνα που 

είχε πραγματοποιήσει ο ΟΑ΢Α στο τέλος του 2006. Επίσης 

χρησιμοποιήθηκαν στοιχεία από τα sites του ΟΑ΢Α και των Εταιριών 

εκτέλεσης του συγκοινωνιακού έργου. 

Δυστυχώς όμως δεν ήταν δυνατόν να βρεθούν στοιχεία 

δρομολογίων για τις Γραμμές του Προαστιακού ΢ιδηροδρόμου, 

αφού λόγω κυρίως των εκτελούμενων έργων αυτά τροποποιούνταν 

διαρκώς. Επίσης δεν ήταν δυνατόν να βρεθούν αξιοποιήσιμα 

στοιχεία για τα δρομολόγια των λεωφορείων του ΚΣΕΛ Αττικής, κι 

έτσι οι Γραμμές αυτές δεν συμπεριλήθησαν καθόλου. Ούτως ή 

άλλως όμως, η χρησιμότητα των Γραμμών ΚΣΕΛ σε έναν επισκέπτη 

της πόλης είναι πολύ μικρή. 

Σα δεδομένα από τον ΟΑ΢Α παραδόθηκαν σε φύλλα MS Excel, τα 

οποία συνοπτικά είχαν ως εξής: 

‗ΓΡΑΜΜΕ΢‘ 

Πρόκειται για τη λίστα με τις Γραμμές 

(Lines/Routes) του δικτύου. Μία εικόνα δείγματος 

των δεδομένων είναι στο πλάι του κειμένου. 

Τπάρχει ο αριθμός κάθε Γραμμής, η ονομασία της, 

τα ημερήσια δρομολόγια, η μέση συχνότητα, ο 

χρόνος διαδρομής, το μήκος, ο αριθμός των 

κλάδων, και ο χρόνος αιχμής. 

΋πως φαίνεται, υπάρχουν τα στοιχεία για τα 

δρομολόγια μέσα στην ημέρα, χωρίς όμως να 

υπάρχουν οι ώρες για το κάθε ένα, ή έστω η 

κατανομή τους σε περιόδους της ημέρας. Τπάρχει 

βέβαια το στοιχείο της συχνότητας, καθώς και 

Εικόνα 22: Δείγμα του Πίνακα ‗ΚΛΑΔΟΙ‘ των πρωτογενών δεδομένων ΜΜΜ. 

72


αυτό της συχνότητας σε ώρα αιχμής, η οποία θεωρείται την πρωινή περίοδο 7:30- 

9:00 και την απογευματινή 16:30-18:00 συνήθως. ΋μως αυτά δεν είναι σε καμία 

περίπτωση αρκετά, καθώς δεν δίνονται οι διαφορετικές συχνότητας σε άλλες 

ημέρες πλην τυπικής καθημερινής, πχ. Δευτέρα, Σετάρτη. 

Σα στοιχεία των δρομολογίων πολλών γραμμών, όπως αναφέρεται και σε άλλο 

σημείο του κειμένου, αντλήθηκαν τελικά από το site του Οργανισμού, με μία 

διαδικασία σχεδόν χειροκίνητη, που επαναλήφθηκε για κάθε μία από τις Γραμμές. 

Ο χρόνος διαδρομής που δίνεται αφορά το σύνολο της Γραμμής, δηλαδή από την 

Αφετηρία στο Σέρμα και ξανά πίσω. Σο κάθε τέτοιο τμήμα της διαδρομής 

αναφέρεται ως Κλάδος, ή κατά την παρούσα Εργασία, ως Route. Τπάρχουν 

Γραμμές οι οποίες χαρακτηρίζονται ως κυκλικές, και για αυτόν τον λόγο έχουν μόνο 

έναν Κλάδο. ΋πως αναφέρεται στη συνέχεια στο κείμενο, αυτό δεν έχει να κάνει με 

την λειτουργία της Γραμμής έτσι όπως φαίνεται στον επιβάτη. 

‗ΚΛΑΔΟΙ‘ 

΋πως έχει αναφερθεί, Κλάδος (η Route/Direction κατά την ορολογία της 

Παρούσας) είναι το τμήμα μια Γραμμής από την Αφετηρία προς το Σέρμα ή το 

αντίστροφο. ΢την πρώτη περίπτωση ο Κλάδος ονομάζεται γενικά ‗Α‘, ενώ στην 

δεύτερη περίπτωση ‗Σ‘. ΢τον πίνακα των στοιχείων του ΟΑ΢Α, όπως φαίνεται και 

στην εικόνα του δείγματος στο πλάι: 

Τπάρχουν τα στοιχεία του αριθμού Γραμμής, του Κλαδου (Αριθμός Γραμμής + ‗Α‘ ή 

‗Σ‘ ή ‗Κ‘ ανάλογα), το μήκος του Κλάδου, τα ημερήσια δρομολόγια, αυτά του 

΢αββάτου και της Κυριακής, ο χρόνος διαδρομής, οι χρονικές στιγμές του πρώτου 

και του τελευταίου δρομολογίου, και τέλος οι συχνότητες αιχμής και μη αιχμής. 

Ένα πρόβλημα που υπάρχει στο σύνολο των δεδομένων, είναι ότι δεν υπάρχει 

ενιαίος τρόπος γραφής. Έτσι, π.χ. σε άλλες περιπτώσεις έχουν χρησιμοποιηθεί 

ελληνικοί χαρακτήρες, και σε άλλες περιπτώσεις λατινικο χαρακτήρες, για αυτούς 

που είναι κοινοί και στα δύο αλφάβητα. Οπτικά, όπως το βλέπει ένας άνθρωπος, 

δεν υπάρχει διαφορά, όμως στην διαχείριση υπολογιστικά των δεδομένων είναι 

τελείως διαφορετικές περιπτώσεις, καθώς πρόκειται για διαφορετικούς κωδικούς 

χαρακτήρων. 

73


΋σον αφορά τους Φρόνους Διαδρομής, συτοί χρησιμοποιήθηκαν σε συνδυασμό με 

στοιχεία από σχετική έρευνα του 2006, οπότε και τροποποιήθηκαν ώστε να γίνουν 

περισσότερο ρεαλιστικοί και να εξάγονται ορθότερα αποτελέσματα. 

Ένα ιδιαίτερα σημαντικό πρόβλημα, είναι το ποιές Γραμμές θεωρούνται από τον 

ΟΑ΢Α κυκλικές. Δυστυχώς, η θεώρηση αυτή δεν συμφωνεί με τον τρόπο λειτουργίας 

που βλέπουν οι επιβάτες. Για τον ΟΑ΢Α κυκλικές είναι οι Γραμμές οι οποίες είναι 

γεωμετρικά «κυκλικές» στο μεγαλύτερο τμήμα τους, ανεξάρτητα τού αν έχουν μόνο 

Αφετηρία, ή έχουν και Σέρμα. 

Ένα παράδειγμα φαίνεται στην παρακάτω εικόνα, η οποία αντιστοιχεί στην Γραμμή 

‗100‘. Η Γραμμή αυτή είναι κυκλική, τόσο σαν γεωμετρία, όσο και σαν λειτουργία 

(μία αφετηρία, κίνηση μόνο προς την μία φορά). Ακόμη όμως κι αν υπήρχε μία 

στάση ως Σερματισμός κάπου στην διαδρομή, για τον ΟΑ΢Α η Γραμμή αυτή θα 

ήταν και πάλι κυκλική. ΢ε αυτή την περίπτωση πάντως δεν θα υπήρχε πρόβλημα, 

καθώς θα υπήρχαν δύο Κλάδοι. 

Εικόνα 23: Η κυκλική κατά όλες τις απόψεις Γραμμή ‗100‘. 

Dot for correct aligning. 

΢ε ένα άλλο παράδειγμα όμως, τη Γραμμή ‗17‘ που λειτουργεί ως Κυκλική, ο ΟΑ΢Α 

την χαρακτηρίζει ως δύο κλάδων (‗17Α‘, ‗17Σ‘), καθώς η Γραμμή στο μεγαλύτερο 

74


μέρος της κινείται κατά τις ίδιες οδούς, απλά στην διαφορετική κατεύθυνση. Κατά 

τον ΟΑ΢Α υπάρχει λοιπόν κι ένας θεωρητικός τερματισμός. 

Εικόνα 24: Η κυκλική σε λειτουργία αλλά όχι σε γεωμετρία Γραμμή ‗910‘. 

seudo Dot for correct aligning. 

Σο σκεπτικό για αυτή την θεώρηση είναι ότι αφού οι επιβάτες, ανάλογα με την 

κατεύθυνση που θέλουν να μετακινηθούν θα χρησιμοποιήσουν τις αντίστοιχες 

στάσεις από τις δύο πλευρές του δρόμου, χωρίς να κάνουν τον περιττό κύκλο, τότε 

στην πράξη η Γραμμή δεν είναι κυκλική λειτουργικά. Αυτό είναι μεν σωστό αν το δει 

κανείς από την συγκοινωνιακή θεώρηση, δυσχεραίνει όμως σημαντικότατα τον 

όποιο χειρισμό των δεδομένων, και είναι πηγή για την δημιουργία ποικίλων λαθών. 

Ακόμη και ο ίδιος ο ΟΑ΢Α π.χ., στο θέμα της δρομολόγησης χρησιμοποιεί 

διαφορετική λογική από ότι στο θέμα αλληλουχίας στάσεων για την τήρηση των 

δεδομένων, με αποτέλεσμα να μην μπορεί να γίνει άμεση σύνδεση αυτών, καθώς ο 

Κλάδος επιστροφής δεν έχει δρομολόγια. 

΢την παρούσα Εφαρμογή, οι Γραμμές ελέγχθησαν μία προς μία, κι όποιες 

λειτουργούσαν με μόνο μία πραγματική αφετηρία, θεωρήθηκαν ως κυκλικές. Ο 

ένας και μοναδικός αυτός κλάδος συμπεριλαμβάνει αθροιστικά τα στοιχεία των 

επιμέρους κλάδων ΟΑ΢Α, ή τους μέσους όρους αυτών, ανάλογα με την περίπτωση. 

Ένα παράδειγμα ασυνάφειας των πρωτογενών δεδομένων είναι ότι οι χρόνοι 

διαδρομής των δύο κλάδων αθροιστικά είναι σε πάρα πολλές περιπτώσεις 

διαφορετικός από αυτόν που δίνεται για το σύνολο της διαδρομής στον πίνακα 

‗ΓΡΑΜΜΕ΢‘. Μάλιστα ο αθροιστικός χρόνος των κλάδων είναι συνήθως 

μεγαλύτερος, που σημαίνει ότι η διαφορά του συνολικού χρόνου δεν οφείλεται στην 

75


συμπερίληψη σε αυτές τις περιπτώσεις του χρόνου layover, δηλαδή του χρόνου 

ανάμεσα στην άφιξη στον Σερματισμό και στην αναχώρηση για την επιστροφή στην 

Αφετηρία. 

‗΢ΣΑ΢ΕΙ΢‘ 

΢τον Πίνακα αυτόν υπάρχουν οι ΢τάσεις του Δικτύου ΜΜΜ. Ένα δείγμα του πίνακα 

εμφανίζεται στο πλάι του κειμένου. 

΢τον πίνακα υπάρχουν ο κωδικός της κάθε ΢τάσης, η 

ονομασία της, η οδός στην οποία βρίσκεται, ένας κωδικός 

που αντιστοιχεί στον Δήμο στον οποίο βρίσκεται η ΢τάση, κι 

επίσης οι γεωγραφικές συντεταγμένες στο σύστημα ΕΓ΢Α87. 

Ο κωδικός της ΢τάσης είναι ένας 6ψήφιος αριθμός, τα δύο 

πρώτα ψηφία του οποίου είναι ο διψήφιος κωδικός του 

Δήμου. Ο κωδικός είναι προφανώς μοναδικός για κάθε 

΢τάση, όμως αυτό δεν συμβαίνει ιστορικά, καθώς ο ΟΑ΢Α 

δίνει κωδικούς από κατηργημένες ΢τάσεις εκ νέου σε 

καινούριες. 

Οι θέσεις των ΢τάσεων δεν είναι ακριβείς, κι έτσι μπορεί να 

εμφανίζονται είτε σωστά στο πλάι του δρόμου, αλλά ίσως με 

λάθος τοποθέτηση ως προς τα δύο άκρα, είτε μέσα στον 

δρόμο ή μέσα στα οικοδομικά τετράγωνα. ΢ε κάποιο βαθμό 

αυτό θα συνέβαινε και λόγω διαφορετικού υποβάθρου, όμως 

η ανακρίβεια υπάρχει εξαρχής. ΢την πράξη αυτό δεν είναι 

σημαντικό πρόβλημα, εκτός τού ότι αλλοιώνεται η 

οπτικοποίηση και αναφέρονται μικρά βήματα πεζή χωρίς 

σημασία. Τπάρχουν και κάποιες περιπτώσεις όπου οι στάσεις 

είναι στην πραγματικότητα μία έκταση, όπως είναι οι σταθμοί 

metro, οπότε η θέση της ΢τάσης είναι ―όντως‖ εντός του 

δρόμου ή της πλατείας. 

‗ΑΛΛΗΛΟΤΦΙΑ ΢ΣΑ΢ΕΨΝ‘ 

΢τον πίνακα αυτόν εμφανίζονται για κάθε Κλάδο οι ΢τάσεις που 

πραγματοποιούνται, ως μία αριθμημένη λίστα. Οι στάσεις αναφέρονται με τον 

μοναδικό Κωδικό Αριθμό τους, οπότε είναι εύκολο να γίνει σύνδεση με τον πίνακα 

Εικόνα 25: Δείγμα από τον πίνακα ‗΢ΣΑ΢ΕΙ΢‘ των πρωτογενών δεδομένων 

76


των ΢τάσεων. Επίσης, αναφέρεται το μήκος ανάμεσα στις στάσεις. Μία ασυνάφεια 

στα πρωτογενή στοιχεία είναι π.χ. ότι για αποστάσεις μεταξύ δύο στάσεων, το 

μήκος δεν είναι ίδιο σε όλους τους κλάδους που συνδέεουν τις δύο στάσεις, ακόμη 

και χωρίς να υπάρχει διαφοροποίηση της ενδιάμεσης διαδρομής. 

Εικόνα 26: Δείγμα από τον πίνακα ‗ΑΛΛΗΛΟΤΦΙΑ ΢ΣΑ΢ΕΨΝ‘ των πρωτογενών δεδομένων ΜΜΜ. 

Δεν υπάρχουν στοιχεία για τις περιπτώσεις που σε κάποια στάση γίνεται μόνο 

επιβίβαση ή μόνο αποβίβαση, όπως επίσης δεν υπάρχουν διαφορετικές 

Αλληλουχίες ΢τάσεων για διαφορετικές μορφές κάποιου Κλάδου, π.χ. σε 

περιπτώσεις τροποποιήσεων κάποιες ημέρες της εβδομάδας λόγω λαϊκών αγορών. 

‗ΔΗΜΟΙ‘ 

Ο τελευταίος πίνακας αφορά τις ονομασίες των Δήμων, σε σχέση με τους κωδικούς 

τους, όμως είναι στοιχείο χωρίς ενδιαφέρον για την Εφαρμογή μας. 

5.1.2 General Transit Feed Specification (GTFS) Και Δημιουργία Σου 

Feed. 

To GTFS, με την προηγούμενη ονομασία ‗Google Transit Feed Specification‘, είναι το de facto 

πρότυπο για την αποθήκευση των δεδομένων δικτύου ΜΜΜ και την διαχείρισή τους έπειτα από τις 

διάφορες εφαρμογές. Προσπαθώντας να καλύψει όσο το δυνατόν περιπτώσεις, δεν είναι αρκετά 

ευέλικτο για να συμπεριλάβει εύκολα τις διαφοροποιήσεις που υπάρχουν από δίκτυο σε δίκτυο, 

καθώς τα στοιχεία που αφορούν τη λειτουργία ενός δικτύου ΜΜΜ είναι φυσικά σε μορφή 

συσχετισμένη με τον τρόπο της λειτουργίας του. 

Ένα Feed με τις προδιαγραφές GT αποτελείται από μία σειρά απλών αρχείων κειμένου, το καθένα 

από τα οποία αντιστοιχεί σε έναν πίνακα, κι όπου τα δεδομένα των πεδίων διαχωρίζονται με κόμμα. 

Η πρώτη γραμμή κάθε αρχείου περιέχει τα πεδία που το αποτελούν. Ο τρόπος γραφής (κεφαλαία- 

77


πεζά) δεν παίζει ρόλο, ενώ οι τιμές που περιέχουν κόμμα θα πρέπει να περιέχονται εντός 

εισαγωγικών. ΢υνήθως οι εφαρμογές βλέπουν όχι έναν folder με τα αρχεία αυτά μέσα του, αλλά ένα 

zip αρχείο το οποίο τα περιέχει συμπιεσμένα. 

Σα αρχεία αυτά συνοπτικά είναι τα εξής: 

‗agency.txt‘ 

(Απαιτείται). Περιέχει στοιχεία για τους φορείς ΜΜΜ. 

‗stops.txt‘ 

(Απαιτείται). Περιέχει στοιχεία για τις στάσεις του δικτύου. 

‗routes.txt‘ 

(Απαιτείται). Περιέχει πληροφορίες για τις Γραμμές του Δικτύου. Μην γίνεται 

σύγχυση με το ότι ο όρος Route στην παρούσα Εργασία αντιστοιχεί στον Κλάδο. 

Πρόκειται στην ουσία για μιά ομάδα δρομολογίων (Trips). 

‗trips.txt‘ 

(Απαιτείται). Περιέχει τα Δρομολόγια και τους Κλάδους στους οποίους ανήκουν. 

Ένα Δρομολόγιο είναι μία σειρά στάσεων σε μία χρονική στιγμή. 

‗stop_times.txt‘ 

(Απαιτείται). Περιέχει τη λίστα με τους χρόνους στους οποίους ένα Δρομολόγιο 

φτάνει ή αναχωρεί από κάθε ΢τάση του. ΢το αρχείο αυτό περιέχεται και η λίστα 

στάσεων του Δρομολογίου. 

‗calendar.txt‘ 

(Απαιτείται). Καθορίζει τις ημέρες της εβδομάδας στις οποίες ισχύει κάθε τύπος 

δρομολογίων που επαναλαμβάνεται (ServiceID). 

‗calendar_dates.txt‘ 

(Προαιρετικά). Καθορίζει τις ημερομηνίες για τις οποίες υπάρχει εξαίρεση των 

Services του Calendar, και τι θα ισχύει διαφορετικό εκείνες τις ημερομηνίες. Π.χ. 

περιέχει τις ημερομηνίες που υπάρχουν αργίες, και καθορίζει ότι τότε θα ισχύει το 

πρόγραμμα της Κυριακής. 

‗fare_atttributes.txt‘ 

(Προαιρετικά). Περιέχει τα στοιχεία για τα εισιτήρια που ισχύουν. 

78


‗fare_rules.txt‘ 

(Προαιρετικά). Περιέχει τους κανόνες με τους οποίους προσδιορίζεται το εισιτήριο 

μιας διαδρομής. 

‗shapes.txt‘ 

(Προαιρετικά). Περιέχει τους κανόνες για την οπτικοποίηση των διαδρομών στον 

χάρτη. Αν για μια Διαδρομή δεν υπάρχουν τα σχετικά στοιχεία, τότε στην 

οπτικοποίηση οι στάσεις συνδέονται απλώς μεταξύ τους. 

‗frequencies.txt‘ 

(Προεραιτικά). Περιέχει την πληροφορία για την συχνότητα των Δρομολογίων μίας 

Γράμμης στην περίπτωση που αυτά δεν έχουν καθορισμένους χρόνους. 

‗transfers.txt‘ 

(Προεραιτικά). Περιέχει τους κανόνες για την πραγματοποίηση μετεπιβιβάσεων σε 

μεγάλους σταθμούς. 

΢τη συνέχεια δίνεται μία περιγραφή του πρωτύπου ανά αντικείμενο, μαζί με την αναλυτική 

περιγραφή της διαδικασίας για την δημιουργία του Feed της παρούσας εφαρμογής, με τις 

παραδοχές και τις αποφάσεις που ελήφθησαν. 

5.1.2.1 Αρχείο ‗agency.txt‘. 

(Απαιτείται). 

Περιέχει στοιχεία για τους φορείς ΜΜΜ. 

Σο αρχείο έχει τα εξής πεδία: 

Agency_id (Προαιρετικό). Περιέχει έναν κωδικό που αντιστοιχεί μοναδικά σε έναν 

Υορέα ΜΜΜ. 

79


Agency_name (Απαραίτητο). Η ονομασία του Υορέα ΜΜΜ. 

Agency_url (Απαραίτητο). Μία URL διεύθυνση για τον Υορέα ΜΜΜ. 

Agency_timezone (Απαραίτητο). Η Ζώνη Ώρας που αντιστοιχεί στον Υορέα ΜΜΜ. Δίνεται 

σύμφωνα με τον ορισμό από την tz ‗database‘. 

Agency_lang (Προαιρετικό). Περιέχει δύο χαρακτήρες κατά ISO 639-1 οι οποίοι 

αντιστοιχούν στην κύρια γλώσσα που χρησιμοποιεί ο Υορέας. 

Agency_phone (Προεραιτικό). Περιέχει ένα τηλέφωνο στο οποίο μπορεί κανείς να καλεί τον 

Υορέα. 

Σο πλήρες αρχείο που δημιουργήθηκε για την παρούσα Εφαρμογή είναι το εξής: 

agency_id agency_name agency_url agency_timezone agency_lang agency_phone 

AMEL AMEL S.A. http://www.amel.gr Europe/Athens el +302105194012 

ETHEL ETHEL S.A. http://www.ethel.gr Europe/Athens el +302104933002 

ILPAP ILPAP S.A. http://athens-trolley.gr Europe/Athens el +302102583300 

ISAP ISAP S.A. 

Athens Urban 

http://www.isap.gr Europe/Athens el +302103248311 

OASA 

Transport http://www.oasa.gr Europe/Athens el 185 

PROASTIAKOS PROASTIAKOS S.A. http://www.proastiakos.gr Europe/Athens el +302105272000 

TRAM TRAM S.A. http://www.tramsa.gr Europe/Athens el +302109978000 

Εικόνα 27: Σο πλήρες αρχείο ‗agency.txt‘ όπως δημιουργήθηκε, σε πινακοποιημένη μορφή. 

Δεν υπάρχει κάτι ιδιαίτερο για να σχολιαστεί όσον αφορά το συγκεκριμένο αρχείο, καθώς είναι πολύ 

απλά τα δεδομένα που περιέχονται σε αυτό. 

80


5.1.2.2 Αρχείο ‗stops.txt‘. 


Περιέχει τα στοιχεία για τις στάσεις του δικτύου. 

Σο αρχείο έχει τα εξής πεδία: 

Stops_id (Απαραίτητο). Σο πεδίο περιέχει έναν κωδικό μοναδικό για κάθε στάση. 

Stop_code (Προαιρετικό). Περιέχει έναν κωδικό ή σύντομο κείμενο ετσι όπως αναγνωρίζεται 

η στάση ή ο σταθμός από τους επιβάτες. 

Stop_name (Απαραίτητο). Περιέχει το όνομα της στάσης ή του σταθμού. 

Stop_desc (Προαιρετικό). Περιέχει μία περιγραφή για την στάση ή τον σταθμό. Θα 

μπορούσε να περιέχει και στοιχεία παρατηρήσεων. 

Stop_lat (Απαραίτητο). Σο γεωγραφικό πλάτος της στάσης/του σταθμού, στο σύστημα 

WGS84. 

Stop_lon (Απαραίτητο). Σο γεωγραφικό μήκος της στάσης/του σταθμού, στο σύστημα 

WGS84. 

Zone_id (Προαιρετικό). Η ζώνη εισιτηρίων στην οποία ανήκει η στάση ή ο σταθμός. 

Stop_url (Προαιρετικό). Μία διεύθυνση URL που αντιστοιχεί στην στάση ή στον σταθμό. 

Εκεί μπορεί να περιέχονται π.χ. διάφορες πληροφορίες. 

81


Location_type (Προαιρετικό). Ορίζει εάν το στοιχείο είναι στάση ή σταθμό. 

Η τιμή ‗0‘ ή το κενό αντιστοιχούν σε στάση. 

Η τιμή ‗1‘ αντιστοιχεί σε μία φυσική κατασκευή ή περιοχή που 

περιέχει μία ή περισσότερες στάσεις. 

Parent_station (Προαιρετικό). Για στάσεις που περιέχονται φυσικά μέσα σε σταθμούς, περιέχει 

τον κωδικό αυτού του σταθμού. Ο κωδικός πρέπει να υπάρχει κι αυτός στη λίστα, 

με location_type=‘1‘. 

Ένα δείγμα του αρχείου που δημιουργήθηκε για την παρούσα Εφαρμογή είναι το εξής: 

stop_id stop_code stop_name stop_desc stop_lat stop_lon zone_id stop_url location_type parent_station 

ST011000 STROFI 37.99860826 23.66498462 FZ0 0 

ST011001 KOLONES 37.99671944 23.66318232 FZ0 0 

ST011002 AG. VARVARA 37.99469474 23.66115296 FZ0 0 

ST011003 DIMARCHIO (TOWN HALL) 37.99283266 23.65927101 FZ0 0 

ST011004 KRITIS 37.99042616 23.65615036 FZ0 0 

Εικόνα 28: Δείγμα από το αρχείο ‗stops.txt‘ όπως δημιουργήθηκε, σε πινακοποιημένη μορφή. 

΢υνολικά το αρχείο περιέχει 7956 εγγραφές. 

Ο κωδικός στο πεδίο stop_id είναι ο εξαψήφιος κωδικός του ΟΑ΢Α για την στάση, με το πρόθεμα 

‗ST‘. 

O κωδικός στο πεδίο stop_code είναι κενός παντού, καθώς οι επιβάτες δεν γνωρίζουν τον κωδικό 

της στάσης, και δεν χρησιμοποιείται από αυτούς. Θα μπορούσε να είναι ο εξαψήφιος αριθμός ο 

οποίος υπάρχει και στα πληροφοριακά έντυπα στις στάσεις, όμως θα είχε μηδαμινή χρησιμότητα. 

Σο όνομα της στάσης έχει μετατραπεί από τα Ελληνικά στο Λατινικό Αλφάβητο. Η διαδικασία έχει 

γίνει αυτοματοποιημένα, ακολουθώντας μία τυποποιημένη αντιστοιχία χαρακτήρων. ΢ε κάποιες 

περιπτώσεις βέβαια αυτό δεν είναι αρκετό, καθώς η ονομασία της στάσης αναφέρεται ευθέως στην 

περιοχή που εξυπηρετεί. Ψς παράδειγμα μπορεί να αναφερθεί η ονομασία ‗ΑΕΡΟΔΡΟΜΙΟ‘. ΢την 

λατινική γραφή γίνεται ‗AERODROMIO‘, όμως είναι σκόπιμο να γίνει τελικά ‗AIRPORT‘, αποδίδοντας 

έτσι στην Αγγλική γλώσσα τη λειτουργία του χώρου που εξυπηρετεί η στάση. 

Οι γεωγραφικές συντεταγμένες της στάσης έχουν προκύψει στο σύστημα WGS84 έπειτα από 

μετατροπή των συντεταγμένων ΕΓ΢Α87 των πρωτογενών δεδομένων. Η μετατροπή εκτιμάται ότι έχει 

82


ανακρίβεια στο αποτέλεσμα της τάξης του ±1.20 m, η οποία είναι ασήμαντη αν λάβει κανείς 

μάλιστα υπόψη ότι οι αρχικές συντεταγμένες έχουν ανακρίβεια ακόμη κι αρκετών μέτρων. 

Σο location_type έχει παντού την τιμή 0, καθώς δεν υπάρχουν ΢ταθμοί στη λογική του ΟΑ΢Α, παρά 

μόνο ΢τάσεις. Θα μπορούσε να υπάρξει μία ομαδοποίηση στάσεων για την λειτουργία της ίδιας της 

Εφαρμογής, κύριως σε σταθμούς Μετρό, όπως π.χ. στον ΢ταθμό Δουκίσσης Πλακεντίας, από όπου 

διέρχονται γραμμές metro, Προαστιακού, και αρκετές λεωφορειακές γραμμές με διάφορες στάσεις. 

5.1.2.3 Αρχείο ‗routes.txt‘. 


Περιέχει πληροφορίες για τις Γραμμές του Δικτύου. Δεν πρέπει να γίνεται σύγχuση 

με το ότι ο όρος Route στην παρούσα Εργασία αντιστοιχεί στον Κλάδο. Πρόκειται 

στην ουσία για μιά ομάδα δρομολογίων (Trips). 

Σα πεδία του αρχείου είναι τα εξής: 

Route_id (Απαραίτητο). Ένας κωδικός μοναδικός για κάθε Γραμμή. 

Agency_id (Προαιρετικό). Ο Κωδικός του Υορέα που εξυπηρετεί την Γραμμή. 

Route_short_name (Απαραίτητο). Περιέχει τη σύντομη ονομασία της Γραμμής. Π.χ. ‗Α5‘. 

Route_long_name (Απαραίτητο). Περιέχει την πλήρη ονομασία της Γραμμής. 

Route_desc (Προαιρετικό). Περιέχει μία περιγραφή για την Γραμμή. Θα μπορούσε να έχει 

και στοιχεία παρατηρήσεων. 

83


Route_type (Απαραίτητο). Ένας κωδικός που περιγράφει τον τύπο του μέσου που εκτελεί 

το συγκοινωνιακό έργο. Οι δυνατές τιμές κωδικού είναι οι εξής: 

‗0‘: Tram, Streetcar, Light Rail. 

‗1‘: Τπόγειος ΢ιδηρόδρομος, Μετρό. 

‗2‘: ΢ιδηρόδρομος (΋χι αμιγώς αστικού χαρακτήρα). 

‗3‘: Λεωφορείο. 

‗4‘: Ferry. 

‗5‘: ΢χοινόδρομος. 

‗6‘: Γόνδολα. 

‗7‘: Οδοντωτός ΢ιδηρόδρομος. 

Route_url (Προαιρετικό). Η διεύθυνση URL για μία σελίδα π.χ. με περισσότερα στοιχεία 

για την Γραμμή. 

Route_color (Προαιρετικό). Σο χρώμα που αντιστοιχεί σε μία Γραμμή. Σο χρώμα δίνεται 

σε δεκαεξαδική μορφή RRGGBB. Αν δεν δοθεί τιμή, τότε θεωρείται η 

FFFFFF που αντιστοιχεί στο λευκό. 

Route_text_color (Προαιρετικό). Σο χρώμα του κειμένου για την Γραμμή σε δεκαεξαδική 

μορφή RRGGBB. Αν δεν δοθεί τιμή, τότε θεωρείται η 000000 που 

αντιστοιχεί στο μαύρο. 

΢τη συνέχεια δίνεται ένα δείγμα από τα στοιχεία του αρχείου routes.txt όπως δημιουργηθήκε για την 

παρούσα Εφαρμογή: 

route_id agency_id route_short_name route_long_name route_desc route_type route_url route_color route_text_color 

RT501 ETHEL 501 PEFKI-MAROYSSI A 3 0099FF 000000 

RT503 ETHEL 503 ZIRINIO-VARIMPOMPI 3 0099FF 000000 

RT504 ETHEL 504 THRAKOMAKEDONES-KIFISSIA 3 0099FF 000000 

RT507 ETHEL 507 ZIRINIO-RODOPOLI-STAMATA 3 0099FF 000000 

RT508 ETHEL 508 ZIRINIO-AGIOS STEFANOS 3 0099FF 000000 

Εικόνα 29: Δείγμα από το αρχείο ‗routes.txt‘ όπως δημιουργήθηκε, σε πινακοποιημένη μορφή. 

84


Σο πεδίο route_id περιέχει τον αριθμό Γραμμής με το πρόθεμα ‗RT‘. Λόγω χρησιμοποίησης του 

λατινικού αλφάβητου, έτσι ώστε να είναι συμβατή η εφαρμογή ακόμη και από συσκευές που δεν 

μπορούν να απεικονίσουν ελληνικό κείμενο, οι Γραμμές με τo στοιχείo ‗Γ‘, έχουν μετονομαστεί σε ‗C‘. 

Π.χ. η ‗Γ5‘ έχει γίνει ‗C5‘. Για να διατηρηθεί σταθερό το μέγεθος του κωδικού, και για να μην υπάρξει 

σύγχυση σε σχέση με τις Γραμμές, κάθε Γραμμή μετά το πρόθεμα ‗RT‘ αναγράφεται πάντα με 3 

χαρακτήρες. Έτσι: 

Οι Γραμμές με τρία στοιχεία στην σύντομη ονομασία τους, την διατηρούν ως έχει. 

Π.χ. ‗025‘ -> ‗TR025‘. 

Οι Γραμμές trolley που είναι διψήφιες, αποκτούν στη αρχή τον χαρακτήρα ‗T‘ ή το 

‗Σ0‘ ανάλογα. Π.χ. ‗25‘ -> ‗TRT25‘, ‗7‘ -> ‗TRT07‘. 

Οι Γραμμές με έναν χαρακτήρα κι ένα ψηφίο, επαναλαμβάνουν στην αρχή το 

ψηφίο αυτό. Π.χ. ‗Μ2‘ -> ‗TRΜΜ2‘. 

΢το πεδίο route_long_name έχουν μπει οι ονομασίες των Γραμμών, με λατινική γραφή, και σε 

κάποιες περιπτώσεις με μετάφραση στην Αγγλική Γλώσσα, όπως έγινε και με τις ονομασίες των 

στάσεων. Π.χ. το ‗΢Σ. ΤΠΕΡ. ΛΕΨΥ. ΚΗΥΙ΢ΟΤ-ΑΕΡ/ΝΑ΢ ΑΘΗΝΨΝ (EXPRESS)‘ δεν έγινε απλώς ‗ST. 

IPER. LEOF. KIFISSOU-AER/NAS ATHINON (EXPRESS)‘, αλλά ‗KIFISSOS COACH STATION-AIRPORT 

(EXPRESS)‘, κάτι προφανώς πιο πληροφοριακό για έναν επισκέπτη της πόλης. 

Κάτι τέτοιο θα έπρεπε να είχε γίνει κι από τον ΟΑ΢Α, ώστε οι ονομασίες των Γραμμών και των 

΢τάσεων που βλέπει ο επιβάτης να παρέχονται και στα Ελληνικά, και στα Αγγλικά. Δυστυχώς, σήμερα 

για τον αλλοδαπό επιβάτη, η ταυτοποίηση της Γραμμής μπορεί να γίνει μόνο τον τριψήφιο κωδικό. 

Σο πεδίο route_type έχει πάρει τις κατάλληλες τιμές, ανάλογα με τον τύπο του μέσου που εξυπηρετεί 

την Γραμμή, όπως επίσης και το route_color έχει αποκτήσει τιμή χρώματος κοντά σε αυτά που 

χρησιμοποιούνται από τον ΟΑ΢Α. Π.χ. Γραμμές Μπλε, Κόκκινο, ΢κούρο Πράσινο του Μετρό, Κίτρινο 

για τα Trolley κτλ.. 

΢τον πίνακα/αρχείο του routes.txt υπάρχουν 346 εγγραφές κατά το πιο πρόσφατο Feed. 

85


5.1.2.4 Αρχείο ‗trips.txt‘. 


Περιέχει τα Δρομολόγια και τους Κλάδους στους οποίους ανήκουν. Ένα Δρομολόγιο 

είναι μία σειρά στάσεων σε μία χρονική στιγμή. Σα πεδία που περιέχονται στο 

αρχείο είναι: 

Route_id (Απαραίτητο). Ο κωδικός της Γραμμής τής οποίας είναι το Δρομολόγιο. 

Service_id (Απαραίτητο). Περιέχει έναν κωδικό για το service στο οποίο ανήκει το 

Δρομολόγιο, δηλαδή την ομάδα Δρομολογίων σε σχέση με τις ημέρες και τις 

ημερομηνίες. ΢υνδυάζεται με τα περιεχόμενα των αρχείων calendar.txt, 

calendar_dates.txt. 

Trip_id (Απαραίτητο). Ένας κωδικός, μοναδικός για κάθε Δρομολόγιο. 

Trip_headsign (Προαιρετικό). Περιέχει το κείμενο που εμφανίζεται ως προορισμός στους 

επιβάτες. Φρησιμοποιείται για την διάκριση ανάμεσα σε διαφορετικές μορφές 

Δρομολογίων (Patterns) για την ίδια Γραμμή. 

Trip_short_name (Προαιρετικό). Περιέχει το κείμενο που εμφανίζεται στην πληροφόρηση των 

επιβατών για την αναγνώριση του Δρομολογίου. Η Σιμή πρέπει να είναι 

μοναδική για κάθε Δρομολόγιο. Δεν πρέπει να συγχέεται δηλαδή με το 

trip_headsign και να χρησιμοποιείται στην θέση του για να δείξει προορισμό 

π.χ.. 

Direction_id (Προαιρετικό). Περιέχει μία δυαδική τιμή, η οποία είναι ενδεικτική της 

κατεύθυνσης. Οι δύο δυνατές τιμές είναι: 

‗0‘ για την μία κατεύθυνση (π.χ. Αφετηρία -> Σέρμα). 

‗1‘ για την αντίθετη κατεύθυνση (π.χ. Σέρμα -> Αφετηρία). 

Block_id (Προαιρετικό). Σαυτοποιεί την ομάδα/αλληλουχία στην οποία ανήκει το 

86


Δρομολόγιο. Μία αλληλουχία συνεχόμενων Δρομολογίων αφορά Δρομολόγια 

στα οποία ένας επιβάτης μπορεί να συνεχίσει στο επόμενο, το οποίο 

πραγματοποιείται με το ίδιο όχημα. 

Shape_id (Προαιρετικό). Ο κωδικός της πολυγωνικής γραμμής για την οπτικοποίηση της 


΢τη συνέχεια δίνεται ένα δείγμα από τα στοιχεία του αρχείου trips.txt όπως δημιουργηθήκε για την 

παρούσα Εφαρμογή: 

route_id service_id trip_id trip_headsign trip_short_name direction_id block_id shape_id 

RT026 Swk TR0260SwkTtttttX 0 

RT026 Swk TR0261SwkTtttttX 1 

RT027 Ssa TR0270Ssa053000X 0 

RT027 Ssa TR0270Ssa055500X 0 

RT027 Ssa TR0270Ssa061500X 0 

Εικόνα 30: Δείγμα από το αρχείο ‗trips.txt‘ όπως δημιουργήθηκε, σε πινακοποιημένη μορφή. 

Σο πεδίο trip_id περιέχει τον κωδικό του Δρομολογίου. Αυτός αποτελείται από 16 αλφαριθμητικούς 

χαρακτήρες, κατά την μορφοποίηση ‗RRRRRRSSSTTTTTTX‘. ΢την μορφοποίηση αυτή: 

RRRRRR είναι ο κωδικός της Γραμμής, με επίθεμα το ψηφίο ‗0‘, ή ‗1‘, ανάλογα με 

την κατεύθυνση. ΢τη Γραμμή ‗Μ3‘ του Μετρό χρησιμοποιούνται και τα ψηφία ‗2‘, 

‗3‘ για να γίνεται επιπλέον διάκριση ανάμεσα στα Δρομολόγια προς/από τον 

΢ταθμό ‗Δουκίσσης Πλακεντίας» και στα Δρομολόγια προς/από τον Αερολιμένα. 

Γενικότερα, το τελευταίο ψηφίο είναι ενδεικτικό των διαφορετικών Κλάδων, και 

Διαδρομών (Patterns). 

SSS Είναι ένας τριψήφιος κωδικός, ο οποίος αντιστοιχεί στο Service. 

TTTTTT είναι ένα εξαψήφιο αλφαριθμητικό, που είτε περιέχει την ώρα έναρξης του 

Δρομολογίου στην μορφή ‗ΗΗΜΜ‘ και το επίθεμα ‗00‘, για αυτά τα Δρομολόγια 

που έχουν υιοθετηθεί οι ακριβείς ώρες, είτε περιέχει την τιμή ‗Tttttt‘, για τα 

Δρομολόγια εκείνα για τα οποία έχει υιοθετηθεί το σύστημα Πρώτο Δρομολόγιο + 

Περίοδος Επανάληψης. 

87


Η διάκριση αυτή έχει γίνει με βάση την εμπειρία από την λειτουργία του Δικτύου, κι 

ανάλογα με το αν σε κάθε Γραμμή ταιριάζει καλύτερα η μία λογική ή η άλλη. ΢την 

πρώτη περίπτωση υπάρχουν καταγεγραμμένα όλα τα Δρομολόγια της Γραμμής, 

έτσι όπως έχουν παρθεί από το site του ΟΑ΢Α. ΢την δεύτερη περίπτωση υπάρχει 

μόνο ένα Δρομολόγιο, από όπου η μηχανή του routing παίρνει τον χρόνο του 

πρώτου Δρομολογίου, τoν χρόνο διαδρομής, και τους χρόνους στάσεων, και το 

επαναλαμβάνει κάθε τόσα δευτερόλεπτα όσα ορίζονται στο αρχείο 

‗frequencies.txt‘. 

Ειδικά στις Γραμμές Μετρό ‗Μ2‘ και ‗Μ3‘, επειδή υπήρχαν διαθέσιμα στοιχεία, 

έχουν υιοθετηθεί διαφορετικές περίοδοι επανάληψης μέσα σε κάθε service. Έτσι, 

υπάρχουν κάποια «πρώτα» Δρομολόγια, το πρώτο της κάθε περιόδου, κι έπειτα τα 

υπόλοιπα Δρομολόγια είναι επαναληπτικά μέχρι την στιγμή που αλλάζει ο χρόνος 

περιόδου. Για να γίνεται διάκριση αυτών των «πρώτων» Δρομολογίων, έχει 

ακολουθηθεί για την μορφοποίηση το ‗FP‘ + ‗HHMM‘. Π.χ. το ‗FP1030‘ αντιστοιχεί 

στο Δρομολόγιο με έναρξη την 10:30 κι όλα τα υπόλοιπα, μέχρι αυτό που ορίζεται 

ως ‗FP1200‘ για την ώρα 12:00, θα έχουν περίοδο επανάληψης όπως αυτή 

ορίζεται στο αρχείο ‗frequencies.txt‘. 

Σο αλφαριθμητικό κλείνει με το επίθεμα ‗Φ‘ το οποίο είναι θέση χαρακτήρα 

δεσμευμένη για μελλοντική επέκταση της κωδικοποίησης. 

Ένα παράδειγμα αυτής της μορφοποίησης, όπως φαίνεται και στο συνημμένο 

δείγμα από το αρχείο ‗trips.txt‘, είναι το εξής: ‗TR0260SwkTtttttX‘. 

΢τo παράδειγμα αυτό, απεικονίζεται ένα Δρομολόγιο της route TR0260, δηλαδή 

της Γραμμής 026 στην Κατεύθυνση (ή παραλλαγή) ‗0‘, για το Service ‗Swk‘, το 

οποίο καθορίζει τη σειρά των στάσεων, και τους χρόνους διαδρομής και στάσεων, 

για όλα τα Δρομολόγια του Service, με την χρονική στιγμή έναρξης, την χρονική 

στιγμή λήξης, και την επαναληπτικότητα, όπως αυτές ορίζονται στο αρχείο 

‗frequences.txt‘. Για το συγκεκριμένο παράδειγμα, τα στοιχεία στο ‗frequencies.txt‘ 

(που περιγράφεται σε άλλο σημείο του κειμένου), δίνουν: 

trip_id start_time end_time headway_secs 

TR0260SwkTtttttX 05:15:00 23:00:00 1500 

, δηλαδή πρώτο 

δρομολόγιο ώρα 05:15, τελευταίο δρομολόγιο 23:00, κι ενδιάμεσα παρόμοια 

δρομολόγια ανά 1500 s = 25 min. 

88


Αντίστοιχα, το αλφαριθμητικό στοιχείο ‗TR0270Ssa061500X‘ απεικονίζει ένα 

Δρομολόγιο του route ‗TR0270‘, δηλαδή της Γραμμής ‗027‘ στην 

Κατεύθυνση/Κλάδο (ή Παραλλαγή Διαδρομής) ‗0‘, το οποίο ξεκινά ώρα 15:00, για 

το Service ‗Ssa‘, δηλαδή ΢άββατο. (Σο θέμα των Services αναλύεται σε άλλο 

σημείο του κειμένου.) 

΢το πεδίο trip_headsign υπάρχουν οι τιμές ‗EGALEO‘, ‗PLAKENTIAS‘, ‗AIRPORT‘, για τα Δρομολόγια 

της Γραμμής ΄Μ3‘ με τους αντίστοιχους προορισμούς. 

΢το πεδίο ‗direction_id‘ έχει εισαχθεί η τιμή ‗0‘ για τα Δρομολόγια από την Αφετηρία προς το Σέρμα 

(Α->Σ) και η τιμή ‗1‘ για τα Δρομολόγια από το Σέρμα προς την Αφετηρία (Σ->Α). 

΢υνολικά στο αρχείο ‗trips.txt‘, υπάρχουν 25688 εγγραφές κατά το πιό πρόσφατο Feed. 

5.1.2.5 Αρχείο ‗stop_times.txt‘. 


Περιέχει τη λίστα με τους χρόνους στους οποίους ένα Δρομολόγιο φτάνει ή 

αναχωρεί από κάθε ΢τάση του. ΢το αρχείο αυτό περιέχεται έτσι και η λίστα 

στάσεων του Δρομολογίου. 

Σα πεδία τα οποία περιέχονται στο αρχείο είναι τα εξής: 

Trip_id (Απαραίτητο). Κωδικός του Δρομολογίο το οποίο περιγράφεται. 

Arrival_time (Απαραίτητα). Καθορίζουν την ώρα άφιξης και την ώρα αναχώρησης του 

89


Departure time Δρομολογίου στην ΢τάση. Η αναγραφή γίνεται στη μορφή ‗HH:MM:SS‘. Για 

ώρες μετά την αλλαγή ημέρας, η αναγραφή γίνεται ως 24:00:00 π.χ. 

Εάν δεν υπάρχουν στοιχεία για διαφορετικές ώρες άφιξης/αναχώρησης, 

τότε μπορεί να εισαχθεί τιμή μόνο στο ένα από τα δύο πεδία. 

΢ε περίπτωση που κάποια στάση δεν αποτελεί χρονικό σημείο της 

διαδρομής (ή δεν υπάρχουν διαθέσιμα στοιχεία), τότε μπορούν και τα δύο 

πεδία να είναι κενα. Οι χρόνοι άφιξης/αναχώρησης τότε θα προκύψουν ως 

παρεμβολή στις τιμές των δύο πλησιέστερων πριν και μετά στάσεων. Οι 

στάσεις αφετηρίας/τερματισμού πρέπει οπωσδήποτε να έχουν μία από τις 

δύο τιμές. 

Stop_id (Απαραίτητο). Ο Κωδικός Αριθμός της ΢τάσης. Δεν μπορεί να είναι 

΢ταθμός. 

Stop_sequence (Απαραίτητο). Η σειρά της ΢τάσης μέσα στο Δρομολόγιο. Η σειρά πρέπει να 

είναι αυξανόμενη αριθμητικά, αλλά όχι απαραίτητα συνεχής. 

Stop_headsign (Προαιρετικό). Περιέχει το κείμενο που αναφέρεται προς τους επιβάτες 

σαν προορισμός στην ΢τάση. Εάν έχει συμπληρωθεί, τότε αντικαθιστά το 

κείμενο του αντίστοιχου πεδίου στο ‗trips.txt‘. Είναι χρήσιμο σε περίπτωση 

που το Δρομολόγιοα αλλάζει κείμενο προορισμού σε κάποιες στάσεις. 

90


Pickup_time (Προαιρετικό). Δείχνει τον τρόπο με τον οποίον γίνεται η επιβίβαση στη 

΢τάση. Οι δυνατές τιμές είναι οι ακόλουθες: 

‗0‘: ΢υνήθης λειτουργία στάσης. 

‗1‘: Δεν γίνεται επιβίβαση. 

‗2‘: Πρέπει να γίνει τηλεφωνική επικοινωνία ώστε να 

σταματήσει το όχημα. 

‗3‘: Η επιβίβαση πρέπει να έχει προσυνεννοηθεί με τον 

οδηγό. 

Η default τιμή είναι το ‗0‘. 

Drop_off_type (Προαιρετικό). Καθορίζει όμοια με το ‗pickup_time‘ τον τρόπο 

αποβίβασης. 

Shape_dist_traveled (Προαιρετικό). Περιέχει την πληροφορία για την απόσταση της στάσης από 

το πρώτο σημείο της γραμμής απεικόνισης στον χάρτη. Η τιμή μπορεί να 

είναι σε οποιαδήποτε μονάδα, π.χ. Km, ή feets, αρκεί να συμφωνεί με 

αυτήν στο αρχείο ‗shapes.txt‘. Κατά αυτόν τον τρόπο γίνεται δυνατή η 

απεικόνιση στον χάρτη μέρους μόνο της διαδρομής. 

Ένα δείγμα από το αρχείο ‗stop_times.txt‘, όπως δημιουργήθηκε για την παρούσα Εφαρμογή, είναι 

το εξής: 

91


trip_id arrival_time departure_time stop_id stop_sequence stop_headsign pickup_type drop_off_type shape_dist_traveled 

TR0210SwkTtttttX 05:15:00 05:15:00 ST061934 1 1 

TR0210SwkTtttttX ST061456 2 








TR0210SwkTtttttX 05:31:00 05:31:00 ST061466 10 1 

Εικόνα 31: Δείγμα από το αρχείο ‗stop_times.txt‘ όπως δημιουργήθηκε, σε πινακοποιημένη μορφή. 

΢το συγκεκριμένο δείγμα παρουσιάζεται ένα πλήρες Δρομολόγιο. Αυτό είναι το ‗TR0210SwkTtttttX‘, 

το οποίο σύμφωνα με την κωδικοποιημένη ονομασία του είναι της Γραμμής ‗021‘, στον Κλάδο ή 

Παραλλαγή ‗0‘, για το Service ‗Swk‘, και μάλιστα είναι το Δρομολόγιο το οποίο καθορίζει για τους 

χρόνους στάσεων και διαδρομής όλα τα δρομολόγια του Service, όπως επαναλαμβάνονται κατά την 

καθορισμένη περίοδο στο αρχείο ‗frequencies.txt‘, όπου υπάρχουν και οι ώρες του πρώτου και του 

τελευταίου όμοιου Δρομολογίου. 

Οι ώρες άφιξης και αναχώρησης στα πεδία ‗arrival_time‘ και ‗departure_time‘ αντίστοιχα έχουν 

εισαχθεί ίδιες, και μόνο στις στάσεις αφετηρίας και τερματισμού. Σα στοιχεία που έχουν περαστεί 

αφορούν το πρώτο Δρομολόγιο, αν κι αυτό δεν είναι απαραίτητο. Αφού τα Δρομολόγια σαν έναρξη 

κι επαναληπτικότητα προσδιορίζονται από το αρχείο ‗frquencies.txt‘, οι χρόνοι στο παράδειγμα 

έχουν σημασία μόνο ως χρόνοι διαφοράς μεταξύ τους, δηλαδή ως χρόνος διαδρομής. 

΢το πεδίο ‗stop_id‘ έχει εισαχθείο ο κωδικός 8 αλφαριθμητικών χαρακτήρων της κάθε στάσης, ενώ 

το ‗pickup_type‘ έχει την τιμή ‗1‘ στο τέλος, και το ‗dropoff_type‘ την ίδια τιμή στην αρχή, αφού 

προφανώς στα σημεία αυτά δεν γίνεται επιβίβαση και αποβίβαση αντίστοιχα. ΢ε όλες τις ενδιάμεσες 

στάσεις δεν έχει εισαχθεί τιμή, κι έτσι ισχύει η default ‗0‘, δηλαδή γίνεται συνήθης επιβίβαση κι 

αποβίβαση. ΢τα μόνα Δρομολόγια που δεν ισχύει αυτό είναι τα Δρομολόγια των λεωφορειακών 

Γραμμών Express του Αερολιμένα, όπου στον Κλάδο προς Αερολιμένα γίνεται μόνο επιβίβαση, και 

κατά τον αντίθετο Κλάδο, μόνο αποβίβαση. 

92


Σο αρχείο ‗stop_times.txt‘ είναι το μεγαλύτερο ενός συνήθους Feed, και στο τελευταίο Feed που έχει 

δημιουργηθεί για την Εφαρμογή περιείχε 1021541 εγγραφές. 

5.1.2.6 Αρχείο ‗calendar.txt‘. 


Καθορίζει τις ημέρες της εβδομάδας στις οποίες ισχύει κάθε τύπος δρομολογίων 

που επαναλαμβάνεται (ServiceID). 

Σα πεδία που περιέχονται στο αρχείο είναι τα εξής: 

Service_id (Απαραίτητο). Ένας κωδικός που χαρακτηρίζει μοναδικά το Service. 

Monday (Απαραίτητο). Περιέχει μία δυαδική τιμή, ανάλογα με το αν το Service 

Tuesday 

Wednesday 

Thursday 

Friday 

Saturday 

Sunday 

πραγματοποιείται την ημέρα αυτή. Οι δυνατές τιμές είναι: 

‗1‘: Σο Service είναι διαθέσιμο κάθε τέτοια ημέρα για την περίοδο 

που ορίζεται από τα πεδία ‗start_date‘, ‗end_date‘. 

‗0‘: To Service δεν είναι διαθέσιμο κάθε τέτοια ημέρα για την 

περίοδο που ορίζεται από τα πεδία ‗start_date‘, ‗end_date‘. 

Start_date (Απαραίτητο). Η ημερομηνία έναρξης του Service. 

End_date (Απαραίτητο). Η ημερομηνία λήξης του Service. 

Σο πλήρες αρχείο ‗calendar.txt‘ όπως έχει δημιουργηθεί στο τελευταίο Feed της παρούσας 

Εφαρμογής είναι το εξής: 

93


service_id monday tuesday wednesday thursday friday saturday sunday start_date end_date 

Sdf 1 1 1 1 0 0 0 20091101 20101231 

Sfr 0 0 0 0 1 0 0 20091101 20101231 

Ssa 0 0 0 0 0 1 0 20091101 20101231 

Ssu 0 0 0 0 0 0 1 20091101 20101231 

Swd 1 1 1 1 1 0 0 20091101 20101231 

Swk 1 1 1 1 1 1 1 20091101 20101231 

Εικόνα 32: Σο πλήρες αρχείο ‗calendar.txt‘ όπως δημιουργήθηκε, σε πινακοποιημένη μορφή. 

΋πως φαίνεται, έχουν δημιουργηθεί έξι διαφορετικά εβδομαδιαία προγράμματα, ανάλογα με τα 

διαφορετικά προγράμματα που παρατηρούνται στα στοιχεία του ΟΑ΢Α: 

‗Sdf‘: Αφορά τις καθημερινές πλην Παρασκευής. 

‗Sfr‘: Αφορά μόνο την Παρασκευή. 

‗Ssa‘: Αφορά μόνο το ΢άββατο. 

‗Ssu‘: Αφορά μόνο την Κυριακή. 

‗Swd‘: Αφορά όλες τις καθημερινές. 

‗Swk‘: Αφορά όλες τις ημέρες της εβδομάδας. 

5.1.2.7 Αρχείο ‗calendar_dates.txt‘. 

(Προαιρετικά). 

Καθορίζει τις ημερομηνίες για τις οποίες υπάρχει εξαίρεση των Services 

Σο αρχείο περιέχει τα εξής πεδία: 

(εβδομαδιαίων προγραμμάτων) του Calendar, και τι θα ισχύει διαφορετικό εκείνες 

τις ημερομηνίες. Π.χ. περιέχει τις ημερομηνίες που υπάρχουν αργίες, κκαι 

καθορίζει ότι τότε θα ισχύει το πρόγραμμα της Κυριακής. 

Service_id (Απαραίτητο). Ο κωδικός του Service το οποίο επηρεάζεται. 

94


Date (Απαραίτητο). Καθορίζει την ημερομηνία κατά την οποία δεν ισχύει (ή ισχύει) το 

εβδομαδιαίο Service. 

Exception_type (Απαραίτητο). Καθορίζει το εάν το αναφερόμενο Service ισχύει ή δεν ισχύει ως 

εξαίρεση την ημερομηνία που δίνεται στο ‗date‘. Οι δυνατές τιμές είναι οι εξής: 

‗1‘: Σο Service ισχύει κατ‘ εξαίρεση την ημερομηνία. 

‗2‘: Σο Service δεν ισχύει κατ‘ εξαίρεση την ημερομηνία. 

 

Σο αρχείο συμπεριλαμβάνει μία εγγραφή για την εξαίρεση του προγράμματος σε μία αργία ή 

ημιαργία, κι άλλη μία εγγραφή για το πρόγραμμα που το αντικαθιστά. Π.χ.: 

service_id date exception_type 

΢το παράδειγμα αυτό, για την ημερομηνία των Φριστουγέννων, εξαιρείται το πρόγραμμα της 

Παρασκευής ‗Sfr‘ από το πρόγραμμα της Κυριακής ‗Ssu‘. 

Ο αριθμός των εγγραφών για μία περίοδο ισχύος του προγράμματος δρομολογίων κυμαίνεται γύρω 

στο 30. 

Sfr 20091225 2 

Ssu 20091225 1 

5.1.2.8 Αρχείο ‗fare_attributes.txt‘. 


Περιέχει τα στοιχεία για τα εισιτήρια που ισχύουν. 


Fare_id (Απαραίτητο). Περιέχει έναν κωδικό που αντιστοιχεί μοναδικά στο είδος 

εισιτηρίου. 

Price (Απαραίτητο). Περιέχει την τιμή του εισιτηρίου. 

95


Currency_type (Απαραίτητο). Περιέχει έναν κωδικό για το νόμισμα στο οποίο εκφράζεται η 

τιμή του πεδίου ‗price‘. Ο κωδικός αυτός πρέπει να αναγράφεται όπως 

ορίζεται από το πρότυπο ISO4217. 

Payment_method (Απαραίτητο). Προσδιορίζει πότε πρέπει να πληρωθεί το εισιτήριο. Οι δυνατές 

τιμές είναι οι εξής: 

‗0‘: Σο εισιτήριο πληρώνεται εντός του οχήματος. 

‗1‘: Σο εισιτήριο πληρώνεται πριν την επιβίβαση. 

Transfers (Απαραίτητο). Προσδιορίζει τον αριθμό των μετεπιβιβάσεων που 

επιτρέπονται με αυτό το εισιτήριο. Οι δυνατές τιμές είναι οι εξής: 

‗0‘: Δεν επιρέπονται μετεπιβιβάσεις. 

‗1‘: Επιτρέπεται μία μετεπιβίβαση. 

‗2‘: Επιτρέπονται δύο μετεπιβιβάσεις. 

(κενό): Επιτρέπονται άπειρες μετεπιβιβάσεις. 

Transfer_duration (Προαιρετικό). Προσδιορίζει το χρονικό διάστημα σε δευτερόλεπτα πριν λήξει 

μία μετεπιβίβαση. ΢ε συνδυασμό με την τιμή ‗0‘ του ‗transfers‘ προσδιορίζει 

τον χρόνο ισχύος ενός εισιτηρίου χωρίς μετεπιβιβάσεις. 

To σύνολο του αρχείου/πίνακα ‗fare_attributes‘ όπως δημιουργήθηκε για την παρούσα Εφαρμογή 

είναι το εξής: 

Εικόνα 33: To σύνολο του αρχείου ‗fare_attributes.txt‘ όπως δημιουργήθηκε, σε πινακοποιημένη 

μορφή. 

fare_id price currency_type payment_method transfers transfer_duration 

FA0 1.00 EUR 1 

FA1 1.20 EUR 1 

FA2 3.20 EUR 1 

FA3 6.00 EUR 1 

FA4 5.00 EUR 0 

FA5 4.00 EUR 1 

96


Δυστυχώς ο τρόπος που το GTFS ορίζει την καταγραφή των κανόνων εισιτηρίων, δεν επιτρέπει τον 

σωστό χειρισμό των επιτρεπόμενων επ‘αόριστον μετεπιβιβάσεων εντός περιόδου 90‘, όπως ισχύει με 

το κανονικό εισιτήριο του ΟΑ΢Α σχεδόν για όλες τις Γραμμές. Ο χειρισμός αυτός μπορεί να 

υλοποιηθεί μόνο κατά την ανάπτυξη προγραμματιστικά της εφαρμογής. 

Επίσης, ένα γενικότερο πρόβλημα είναι ότι δεν μπορούν να καθορισθούν διαφορετικά εισιτήρια ως 

προς την αξία, τα οποία χρησιμοποιούνται από κάποιες ομάδες επιβατών. Π.χ. δεν μπορούν να 

συνυπάρχουν εισιτήρια κανονικά €1, και εισιτήρια μειωμένα για φοιτητές αξίας €0.50 στις ίδιες 

Γραμμές. 

(Παρατήρηση: Κατά την διάρκεια της εκπόνησης, ο ΟΑ΢Α άλλαξε την τιμολογιακή πολιτική, κι επ‘ 

ευκαιρίας ο υπολογισμός του αναγκαίου εισιτηρίου γίνεται πλέον στην client εφαρμογή, χωρίς να 

χρησιμοποιείται ο πίνακας του Feed.) 

5.1.2.9 Αρχείο ‗fare_rules.txt‘. 


Περιέχει τους κανόνες με τους οποίους προσδιορίζεται το εισιτήριο μιας 


Οι κανόνες μπορούν να βασίζονται σε μία από τις ακόλουθες μορφές: 

Σο εισιτήριο εξαρτάται από την αφετηρία και τον τερματισμό. 

Σο εισιτήριο εξαρτάται από το ποιά ζώνη εισιτηρίων διασχίζει η διαδρομή. 

Σο εισιτήριο εξαρτάται από ποιά Γραμμή χρησιμοποιείται. 


Fare_id (Απαραίτητο). Ένας κωδικός που αντιστοιχεί στον τύπο εισιτηρίου. 

Route_id (Προαιρετικό). Ο κωδικός Γραμμής εάν υπάρχει σύνδεση του εισιτηρίου με την 

Γραμμή. 

97


Origin_id (Προαιρετικό). ΢ύνδεση του εισιτηρίου με την ζώνη εισιτηρίων στην οποία ανήκει 

η περιοχή επιβίβασης. 

Destination_id (Προαιρετικό). ΢ύνδεση του εισιτηρίου με την ζώνη εισιτηρίων στην οποία ανήκει 

η περιοχή αποβίβασης. 

Contains_id (Προαιρετικό). ΢υνδέει το εισιτήριο με ένα ‗zone_id‘ όπως περιέχεται στο αρχείο 

‗stops.txt‘. Έτσι, το εισιτήριο συνδέεται επίσης με τις διαδρομές που διέρχονται 

από κάθε ζώνη του contains_id. 

Σο πλήρες αρχείο/πίνακας ‗fare_rules.txt‘ κατά το τελευταίο Feed που δημιουργήθηκε για την 

παρούσα Εφαρμογή, είναι το εξής: 

Εικόνα 34: Σο πλήρες αρχείο ‗fare_rules.txt‘ όπως δημιουργήθηκε, σε πινακοποιημένη μορφή. 

΋πως φαίνεται υπάρχουν 17 διαφορετικοί κανόνες. Ο ΟΑ΢Α δεν χρησιμοποιεί ζώνες στην 

τιμολογιακή του πολιτική. ΢την Εφαρμογή όμως έχουν χρησιμοποιηθεί πλασματικές ζώνες, έτσι ώστε 

με έμμεσο τρόπο να καταγραφεί το πως ισχύουν τα εισιτήρια. Οι πλασματικές ζώνες δεν αφορούν 

καθαρά γεωγραφικές περιοχές. Έτσι: 

fare_id route_id origin_id destination_id contains_id 

FA0 FZ0 FZ0 

FA1 FZ0 FZ1 

FA1 FZ1 FZ1 

FA3 FZ0 FZ3 

FA3 FZ3 FZ0 

FA4 FZ4 FZ0 

FA5 FZ3 FZ5 

FA5 FZ5 FZ3 

FA4 RT400 

FA2 RTX92 

FA2 RTX93 

FA2 RTX94 

FA2 RTX95 

FA2 RTX96 

FA2 RTX97 

FA2 FZ0 FZ2 

FA2 FZ2 FZ0 

98


‗FZ0‘ είναι η ζώνη που περιέχει όλες τις Γραμμές με το κανονικό εισιτήριο. 

‗FZ1‘ είναι η ζώνη που περιέχει τις στάσεις στην περιοχή της ΢αρωνίδας. 

‗FZ2‘ είναι η ζώνη που αντιστοιχεί στις λεωφορειακές Γραμμές που εξυπηρετούν 

τον Αερολιμένα. 

‗FZ3‘ είναι η ζώνη που αντιστοιχεί στις Γραμμές Μετρό και Προαστιακού όταν 

εξυπηρετούν τον Αερολιμένα. 

‗FZ4‘ είναι η ζώνη που αντιστοιχεί στην λεωφορειακή Γραμμή sightseeing ‗400‘. 

‗FZ5‘ είναι η ζώνη που αντιστοιχεί στο εισιτήριο των €4.00 όταν αφετηρία ή 

τελικός προορισμός με Μετρό ή Προαστιακό είναι ο Αερολιμένας, αλλά ο 

προορισμός ή η αφετηρία αντίστοιχα είνα κάποιους από τους σταθμούς μετά τον 

‗Δουκίσσης Πλακεντίας‘. 

Οι κανόνες δεν έχουν εισαχθεί μόνο με τον τρόπο κατά Γραμμή, καθώς επιτρέπονται μετεπιβιβάσεις 

με το ίδιο εισιτήριο των ειδικών περιπτώσεων, ή απαιτούνται διαφορετικά εισιτήρια για την ίδια 

Γραμμή. Π.χ. για την Γραμμή ‗Ε22‘ που συνδέει την Αθήνα με την ΢αρωνίδα, για ένα τμήμα της 

Γραμμής ισχύει το κανονικό εισιτήριο ‗FA0‘ €1.00, ενώ για το τμήμα από Βάρκιζα μέχρι ΢αρωνίδα, 

απαιτείται εισιτήριο ‗FA1‘ €1.20. 

(Παρατήρηση: Κατά την διάρκεια της εκπόνησης, ο ΟΑ΢Α άλλαξε την τιμολογιακή πολιτική, κι επ‘ 

ευκαιρίας ο υπολογισμός του αναγκαίου εισιτηρίου γίνεται πλέον στην client εφαρμογή, χωρίς να 

χρησιμοποιείται ο πίνακας του Feed.) 

5.1.2.10 Αρχείο ‗shapes.txt‘. 


Περιέχει τους κανόνες για την οπτικοποίηση των διαδρομών στον χάρτη. Αν για μια 

Διαδρομή δεν υπάρχουν τα σχετικά στοιχεία, τότε στην οπτικοποίηση οι στάσεις 

συνδέονται απλώς μεταξύ τους. 

Κάθε εγγραφή αναφέρεται σε ένα σημείο κόμβο μίας πολυγωνικής γραμμής. Σα πεδία του αρχείου 

είναι τα εξής: 

99


Shape_id (Απαραίτητο). Ένας κωδικός μοναδικός για κάθε πολυγωνική γραμμή. 

Shape_pt_lat (Απαραίτητο). Σο γεωγραφικό πλάτος του σημείου κόμβου της πολυγωνικής 

γραμμής στο σύστημα WGS84. 

Shape_pt_lon (Απαραίτητο). Σο γεωγραφικό μήκος του σημείου κόμβου της πολυγωνικής 

γραμμής στο σύστημα WGS84. 

Shape_pt_sequence (Απαραίτητο). Η σειρά του σημείου κόμβου στην πολυγωνική γραμμή. 

Shape_dist_traveled (Προαιρετικό). ΋ταν χρησιμοποιείται, προσδιορίζει το σημείο κόμβο σαν μία 

απόσταση που έχει διανυθεί από την αρχή της πολυγωνικής γραμμής. 

Κατά κάποιο τρόπο είναι δηλαδή η ‗χιλιομετρική θέση‘. Μπορεί να 

χρησιμοποιηθεί για την απεικόνιση τμήματος της διαδρομής. Η μονάδα 

μήκους μπορεί να είναι οτιδήποτε, αρκεί να συμφωνεί με την μονάδα στο 

αρχείο ‗stop_times.txt‘. 

΢την παρούσα Εφαρμογή δεν έχει δημιουργηθεί το συγκεκριμένο προαιρετικό αρχείο. Ο λόγος είναι 

ότι δεν υπήρχαν διαθέσιμα στοιχεία για την ακριβή κίνηση των οχημάτων πάνω στο οδικό δίκτυο. Για 

κάποιες Γραμμές η διαδρομή τους είναι γνωστή εμπειρικά, όμως αν το αρχείο χρησιμοποιούταν μόνο 

για λίγες Γραμμές, τότε το μικτό οπτικό αποτέλεσμα θα δημιουργούσε περιέργη εικόνα. Σο θέμα είναι 

ούτως ή άλλως περισσότερο μία πιο καλή οπτικοποίηση, καθώς ο επιβάτης δεν ενδιαφέρεται 

ιδιαίτερα για την διαδρομή των οχημάτων, παρά για τις στάσεις που πρέπει να 

επιβιβαστεί/αποβιβαστεί και τον χρόνο διαδρομής μεταξύ αυτών. 

Μία ιδέα δημιουργίας των σχετικών στοιχείων, χωρίς να εξασφαλίζεται ότι αυτά θα αντιστοιχούν 

απόλυτα στην πραγματικότητα, είναι η χρησιμοποίηση της πλοήγησης των Google Maps ανάμεσα 

στα σημεία που ορίζονται από τις στάσεις. Έτσι, θα προκύψουν οι διαδρομές με βάση π.χ. τον 

μικρότερο χρόνο για κίνηση με αυτοκίνητο, χωρίς όμως να είναι πάντα απαραίτητο ότι οι 

λεωφορειακές Γραμμές κινούνται όντως πάνω σε αυτές τις διαδρομές. ΋πως όμως ειπώθηκε, ο 

επιβάτης δεν ενδιαφέρεται ιδιαίτερα για την διαδρομή μεταξύ των στάσεων και κάτι τέτοιο θα 

εξυπηρετούσε απλώς την καλύτερη αισθητικά παρουσίαση, οπότε δεν θα υπήρχε ιδιαίτερο 

πρόβλημα με την ανακρίβεια. ΋μως προς το παρόν δεν έχει υλοποιηθεί η ιδέα αυτή, ώστε να 

αποφευχθεί στο στάδιο της ανάπτυξης η δημιουργία μεγάλων αρχείων. 

100


5.1.2.11 Αρχείο ‗frequencies.txt‘. 


Περιέχει την πληροφορία για την συχνότητα των Δρομολογίων μίας Γράμμης, στην 

περίπτωση που αυτά δεν έχουν καθορισμένους χρόνους. 


Trip_id (Απαραίτητο). Ο κωδικός Δρομολογίου στο οποίο αναφέρεται η συχνότητα. 

Start_time (Απαραίτητο). Προσδιορίζει την ώρα ‗HH:MM:SS‘ κατά την οποία συμβαίνει 

το πρώτο δρομολόγιο με αυτή την συχνότητα. 

End_time (Απαραίτητο). Προσδιορίζει την ώρα ‗HH:MM:SS‘ κατά την οποία λήγει αυτή 

η συχνότητα δρομολογίων. 

Headway_secs (Απαραίτητο). Προσδιορίζει τον χρόνο σε δευτερόλεπτα μεταξύ δύο 

συνεχόμενων δρομολογίων, είναι δηλαδή η χρονική απόσταση ή περίοδος 

πραγματοποίησης για το χρονικό διάστημα που ορίζεται από το ‗start_time‘ 

και το ‗end_time‘. 

Ένα δείγμα του αρχείου/πίνακα ‗frequencies.txt.‘ όπως δημιουργήθηκε για την παρούσα Εφαρμογή 

είναι το εξής: 

trip_id start_time end_time headway_secs 

TRMM31SwdFP1730X 17:30:00 22:00:00 300 

TRMM31SwdFP2200X 22:00:00 23:59:00 600 

TRPP10SwkTtttttX 00:01:00 00:02:00 99999 

TRPP11SwkTtttttX 00:01:00 00:02:00 99999 

TRT020SwkTtttttX 05:00:00 24:15:00 900 

TRT021SwkTtttttX 05:00:00 24:15:00 900 

Εικόνα 35: Δείγμα από το αρχείο ‗frequencies.txt‘ όπως δημιουργήθηκε, σε πινακοποιημένη μορφή. 

101


΢το συγκεκριμένο εσκεμμένα επιλεγμένο δείγμα μπορούν να παρατηρηθούν τα εξής: 

Οι δύο πρώτες εγγραφες αφορούν την Γραμμή Μετρό ‗Μ3‘, τον Κλάδο/Παραλλαγή 

‗1‘, για το εβδομαδιαίο Πρόγραμμα (Service) ‗Swd‘. ΢τη μία εγγραφή γίνεται 

προσδιορισμός της συχνότητας των δρομολογίων για το διάστημα 17:30-22:00 ως 

ανά 300 s = 5 min. ΢τη δεύτερη εγγραφή γίνεται προσδιορισμός της συχνότητας 

για το επόμενο διάστημα 22:00-23:59, ως ανά 600 s = 10 min. Αυτή η 

διακύμανση συχνότητας μέσα στην ημέρα έχει υιοθετηθεί μόνο για τις Γραμμές 

Μετρό. 

΢τις υπόλοιπες Γραμμές τα δρομολόγια δεν ακολουθούσαν πάντα μία συγκεκριμένη 

συχνότητα ανά χρονικές περιόδους, καθώς π.χ. μπορεί να υπήρχε χρονική 

απόσταση του Β από το Α 20 min, του Γ από το Β 12 min, και στη συνέχεια του Δ 

από το Γ πάλι 20 min. Για τον λόγο αυτό προτιμήθηκε η υιοθέτηση μίας μέσης 

σταθερής συχνότητας για το σύνολο της ημέρας. 

΢τις περιπτώσεις που υπήρχε σημαντική παρόλα αυτά διακύμανση της μέσης κατά 

διαστήματα συχνότητας μέσα στην ημέρα, δημιουργηθήκαν αναλυτικά τα 

Δρομολόγια σύμφωνα με το πρόγραμμα ΟΑ΢Α, και τα Δρομολόγια αυτά 

περιέχονται στο αρχείο ‗stop_times.txt‘. 

Η Σρίτη και η Σέταρτη εγγραφή αφορούν Γραμή του Προαστιακού. Εξαιτίας του ότι 

δεν υπήρχαν καθόλου διαθέσιμα στοιχεία για τα δρομολόγια του Προαστιακού, 

υπάρχει η πλασματική περίοδος 00:01-00:02 με συχνότητα ανά 99999 s, οπότε 

πρακτικά τα δρομολόγια του Προαστιακού δεν λαμβάνονται υπόψη κατά το 

routing. 

Η Πέμπτη και η έκτη εγγραφή αναφέρονται σε δύο Κλάδους/Παραλλαγές της 

Γραμμής trolley 2, για το Service ‗Swk‘. Αναφέρονται στο σύνολο της ημέρας, με 

έναρξη δρομολογίων 05:00 και λήξη 24:15, δηλαδή 15‘ μετά τα μεσάνυχτα προς 

την επόμενη ημέρα. Η συχνότητα είναι ανά 900 s = 15 min, και πάντα οι Κλάδοι 

επιστροφής έχουν, όπως και στην συγκεκριμένη περίπτωση, την συχνότητα των 

Κλάδων από την Αφετηρία προς το Σέρμα. 

Σο αρχείο/πίνακας ‗frequencies.txt‘, όπως δημιουργήθηκε για την παρούσα Εφαρμογή, περιέχει 431 

εγγραφές, οι οποίες αφορούν 236 Γραμμές. Για τις υπόλοιπες Γραμμές υπάρχουν αναλυτικά 

δρομολόγια (στο ‗stop_times.txt‘) όπως καθορίζονται από το πρόγραμμα του ΟΑ΢Α. Ειδικά για την 

Γραμμή Μετρό ‗M3‘ έχει ακολουθηθεί όπως αναφέρεται σε άλλο σημείο ένα μικτό σύστημα. 

102


5.1.2.12 Αρχείο ‗transfers.txt‘. 

(Προεραιτικά). 

Περιέχει τους κανόνες για την πραγματοποίηση μετεπιβιβάσεων σε μεγάλους 

σταθμούς. ΢υνήθως οι σχεδιαστές ταξιδιών υπολογίζουν σημεία μετεπιβιβάσεων με 

βάση την σχετική γειτνίαση των στάσεων. ΢ε περιπτώσεις όπου υπάρχει έντονη 

ασάφεια για ένα ζεύγος στάσεων, ή όπου χρειάζεται να κωδικοποιηθούν 

συγκεκριμένες επιλογές, τότε μπορεί να χρησιμοποιηθεί το αρχείο αυτό ώστε να 

καθοριστούν επιπλέον κανόνες για τις μετεπιβιβάσεις. 


From_stop_id (Απαραίτητο). Περιέχει έναν κωδικό στάσης, της στάσης από την οποία 

ξεκινά η σύνδεση. ΢ε περίπτωση που ο Κωδικός αντιστοιχεί σε σταθμό 

(ομάδα στάσεων), τότε ο κανόνας εφαρμόζεται για όλες τις στάσεις που 

περιέχει αυτός. 

To_stop_id (Απαραίτητο). Περιέχει έναν κωδικό στάσης, της στάσης στην οποία ξεκινά η 

σύνδεση. ΢ε περίπτωση που ο Κωδικός αντιστοιχεί σε σταθμό (ομάδα 

στάσεων), τότε ο κανόνας εφαρμόζεται για όλες τις στάσεις που περιέχει 

αυτός. 

Transfer_type (Απαραίτητο). Καθορίζει τον τύπο της σύνδεσης για το ζεύγος στάσεων. Οι 

δυνατές τιμές για το πεδίο είναι: 

‗0‘ ή (κενό): Είναι ένα προτεινόμενο σημείο μετεπιβίβασης 

μεταξύ δύο Γραμμών. 

‗1‘: Είναι ένα περιορισμένο σημείο μετεπιβίβασης μεταξύ 

δύο Γραμμών. Σο όχημα που αναχωρεί αναμένεται ότι θα 

περιμένει την άφιξη του οχήματος που καταφθάνει, με 

επαρξή διαθέσιμο χρόνο για την μετεπιβίβαση. 

‗2‘: Η μετεπιβίβαση απαιτεί έναν ελάχιστο χρόνο μεταξύ 

άφιξης κι αναχώρησης για να είναι σίγουρη η σύνδεση. Η 

103


τιμή του απαιτούμενου χρόνου προσδιορίζεται στο πεδίο 

‗min_transfer_time‘. 

‗3‘: Δεν είναι δυνατή η μετεπιβίβαση μεταξύ των Γραμμών 

σε αυτή την τοποθεσία. 

Min_transfer_time (Προαιρετικά). ΋ταν απαιτείται ένας ελάχιστος χρόνος μεταξύ άφιξης και 

αναχώρησης από την σύνδεση (‗transfer_type‘=2), τότε το πεδίο αυτό 

προσδιορίζει τον χρόνο σε δευτερόλεπτα που πρέπει να είναι διαθέσιμος σε 

ένα ταξίδι ώστε να επιτρέπεται η μετεπιβίβαση μεταξύ των Γραμμών σε 

αυτές τις στάσεις. Ο χρόνος αυτός πρέπει να είναι αρκετός ώστε να καλύψει 

τον χρόνο για την μετακίνηση από την μία στάση στην άλλη, αλλά και τον 

χρόνο ασφαλείας για την απόκλιση από τον προγραμματισμό. 

Κατά την παρούσα Εφαρμογή το αρχείο/πίνακας ‗transfers.txt‘ δεν συμπληρώθηκε με στοιχεία, 

καθώς τέτοιων ειδών μετεπιβιβάσεις δεν συμβαίνουν στο δίκτυο του ΟΑ΢Α, εκτός ειδικών και μη 

μόνιμων περιπτώσεων. Η λογική θα μπορούσε πάντως να χρησιμοποιηθεί για την εμπειρική βελτίωση 

των αποτελεσμάτων, μέσω ώθησης κάποιων μετεπιβιβάσεων και περιορισμού κάποιων άλλων. 

5.1.2.13 Διάγραμμα Οντοτήτων-΢υσχετίσεων (E-R) Σου GT Feed. 

To GTFS ορίζει στην πραγματικότητα μία δομή οντοτήτων και μεταξύ τους συσχετίσεων, έστω κι αν 

αυτή υλοποιείται με χρήση απλών ASCII αρχείων. Κάθε τέτοιο αρχείο ισοδυναμεί με έναν 

διαφορετικό πίνακα μίας σχεσιακής Βάσης Δεδομένων. Σο σχετικό διάγραμμα που περιγράφει 

συνοπτικά αυτή την δομή είναι το εξής: 

104

- 


ID 

Phone 

URL 

1 

Color 

Block 

Name UR 

L 

AGENCIES 

Time 

Zone 

Language 

Ν 

ID 

Description 

ID 

Εξυπθρετείται 

Από 

Type 

Shape 

Text Color 

ROUTES 

1 

Route 

Direction 

Start 

Time 

Agency 

Long 

Name 

Ν 

Είναι 

Σθσ 

FREQUENCIES 

Short 

Name 

Ν 

Service 

TRIPS 

Ζχει 

End 

Time 

Short 

Name 

1 

ID 

Headway 

Headsign 

1 

Zone 

Latitude 

M 

URL Type 

ID Code 

Longitude 

Ιςχφει 

Για 

M 

Pickup 

Type 

N 

Ζχει Σο 

Sunday 

Saturday 

STOPS 

Για 

Σθν 

Drop Off 

Type 

Trip 

Stop 

Headsign 

N 

Parent 

Station 

Name 

Description 

Start 

Date 

N 

Ζχει Σο 

Service 

Friday 

Ν 

Shape 

Distance 

Traveled 

Arrival 

Time 

STOP TIMES 

Stop 

Sequence 

End 

Date 

1 

Thursday 

Monday 

CALENDAR 

2 

Από/΢ε 

Departure 

Time 

Stop 

Tuesday 

Wednesday 

From 

Stop 

Ανικει 

΢τθν Ηώνθ 

Θ ΢τάςθ 

Αντιςτοιχεί 

΢ε Μικοσ 

Σου 

Distance 

Traveled 

ID 

To 

Stop 

TRANSFERS 

Minimum 

Transfer 

Time 

Point 

Latitude 

SHAPES 

Point 

Sequence 

(Δεν) 

Ιςχφει 

Transfer 

Type 

ID 

Point 

Longitude 

N M 

Διάγραμμα 3: Σο Διάγραμμα Οντοτήτων-΢υσχετίσων (E-R) που αντιστοιχεί στο GTFS (Με γαλάζιο χρώμα ή παχείς χαρακτήρες τα απαραίτητα στοιχεία). 

N 

N 

1 

1 

1 

Route 

FARE RULES 

Contains 

Zone 

1 

Origin 

Destination 

ID 

Transfer 

Duration 

Χρειάηεται 

Σο 

N 

Price 

FARE ATTRIBUTES 

Transfers 

Service Date Exception 

Type 

CALENDAR DATES 

Currency 

Type 

Payment 

Method 

105


106


5.2 Δεδομένα Οδικού Δικτύου. 


Σα δεδομένα που αφορούν το οδικό δίκτυο απαιτούνται για την εύρεση διαδρομών στα τμήματα 

πεζή. ΢ε επέκταση της Εφαρμογής ώστε να μπορούν να υπάρχουν τμήματα με ποδήλατο, ή με 

λειτουργίες Park & Ride, τότε θα χρησιμοποιούνταν και για τις σχετικές ευρέσεις διαδρομών με 

ποδήλατο ή ΙΦ αυτοκίνητο. Η επέκταση αυτή δεν κρίνεται όμως προς το παρόν ιδιαίτερης πρακτικής 

αξίας για την περίπτωση της Αθήνας, όπου αφενός τα ποδήλατα είναι λίγα και σχεδόν δεν 

επιτρέπονται στα ΜΜΜ, αφετέρου οι περιπτώσεις όπου υπάρχουν δυνατότητες Park & Ride είναι 

ελάχιστες. ΋μως, πέρα όλων αυτών, αλλά και σε συνδυασμό μαζί τους, ακόμη μικρότερη πρακτική 

χρησιμότητα υπάρχει λόγω του ότι η Εφαρμογή απευθύνεται σε επισκέπτες της πόλης. 

Για τα δεδομένα του οδικού δικτύου έγινε αναζήτηση διαφόρων λύσεων, και τελικά αποφασίστηκε να 

χρησιμοποιηθούν τα στοιχεία αποό το Project ‗Open Street Map‘, ή ‗OSM‘ σε συντομία. O χάρτης 

του OSM χρησιμοποιείται κι από την Εφαρμογή Φρήστη του Open Trip Planner, ως χαρτογραφικό 

υπόβαθρρο. Η Εφαρμογή αυτή χρησιμοποιήθηκε αρχικά ως βάση και για την Εφαρμογή Φρήστη της 

παρούσας, οπότε το OSM έβρισκε χρησιμότητα σε δύο λειτουργίες, χωρίς μάλιστα να υπάρχουν έτσι 

διαφοροποιήσεις μεταξύ αυτών. Δηλαδή, αυτό που προέκυπτε από το routing engine, ήταν απόλυτα 

κι αυτό που εμφανιζόταν στον χάρτη. 

5.2.2 Open Street Map (OSM). 

Πρόκειται για Project που αποσκοπεί στην δημιουργία ενός 

ελεύθερου/δωρεάν και επεξεργάσιμου χάρτη ολόκληρου του 

κόσμου, μέσα από την συνεργασία εθελοντών. Ο χάρτης 

βελτιώνεται και επεκτείνεται συνεχώς, με δεδομένα που 

προκύπτουν από καταγραφές GPS, την γνώση ενός τόπου από 

τους εθελοντές, τις διαθέσιμες αεροφωτογραφίες, κ.α.. 

΢ε αρκετές περιπτώσεις δεδομένα έχουν χορηγηθεί μάλιστα από 

ιδιωτικές εταιρείες ή δημόσιους φορείς, ενώ και η Yahoo! π.χ. έχει 

επιτρέψει την χρήση των αεροφωτογραφιών της για το Project. Σο Project ξεκίνησε το 2004, και 

μέχρι τα τέλη του 2009 υπήρχαν περισσότεροι από 20000 συνεργάτες. Μόνο όμως το 10% περίπου 

από αυτούς συνεισφέρει με δεδομένα σε μηνιαία βάση. 

107


Σα δεδομένα παρέχονται προς χρήση είτε σε διανυσματική (π.χ. ESRI Shape Files), είτε σε raster 

μορφή. Τπάρχει μάλιστα η δυνατότητα να γίνονται rendering τα διανυσματικά δεδομένα σε μορφή 

raster, από διάφορους renderers (π.χ. Mapnik ή Osmarender), και σε διάφορα θέματα, όπως π.χ. 

γενικός χάρτης, χάρτης ποδηλασίας, με απεικόνιση του αναγλύφου, κτλ.. Σα δεδομένα που 

παρέχονται ως raster tiles από διάφορους servers ανά τον κόσμο είναι πολύ εύκολο να 

χρησιμοποιηθούν σε εφαρμογέςπου απεικονίζουν WMS, με αξιοποίηση π.χ. των Openlayers. Η 

δυνατότητα rendering από τον χρήστη των διανυσματικών δεδομένων κάνει εφικτό το να 

δημιουργούνται WMS για ιδία χρήση, με πλήρως επιλεγμένη την χαρτογραφική απόδοση. 

Εικόνα 36: Απεικόνιση του κέντρου της Αθήνας με OpenStreetMap δεδομένα και Openlayers. 

Σο site με το wiki του OpenStreetMap βρίσκεται στη διεύθυνση: 

wiki.openstreetmap.org/wiki/Main_Page. 

108


5.2.3 Παρατηρήσεις. 

΋σον αφορά την περιοχή της Αθήνας, αν και υπάρχει ολόκληρο το οδικό δίκτυο σαν γεωμετρία στο 

Open Street Map, με μεγάλη μάλιστα ακρίβεια, εν τούτοις η συμπερίληψη της ονομασίας των οδών 

στα δεδομένα υπάρχει σε ιδιαίτερα μικρό ποσοστό, και μάλιστα όχι με κάποιον συγκεκριμένο τρόπο, 

δηλαδή υπάρχουν οδοί με καταγραφή της ονομασίας με ελληνικούς ή με λατινικούς χαρακτήρες. 

Για τον παραπάνω λόγο, αφενός δεν μπορούν να αναφερθούν σωστά στοιχεία όπως τα ονόματα των 

οδών ως καθοδήγηση, αφετέρου δεν μπορεί να πραγματοποιηθεί ικανοποιητικό geocoding. ΢ε 

περίπτωση χρήσης υπηρεσίας geocoding που να μην αναφέρεται στο OSM, τότε σε αρκετές 

περιπτώσεις δημιουργείται αναντιστοιχία μεταξύ διεύθυνσης κι εμφάνισής της στον χάρτη, δυσκολία 

στην διαχείριση, κι επιπλέον, πιθανόν παραβίαση όρων χρήσης. Αυτό συμβαίνει π.χ. με την σχετική 

υπηρεσία της Google, η οποία τελικά χρησιμοποιήθηκε Η Google ζητάει τα αποτελέσματα του 

geocoding να απεικονίζονται πάνω στον χάρτη της Google Maps. Αυτός είναι ένας από τους λόγους 

που ώθησαν στην μετέπειτα ανάπτυξη μία εντελώς νέας Εφαρμογής Φρήστη, όπου οι υπηρεσίες της 

Google χρησιμοποιούνται τόσο για την χαρτογραφική απόδοση, όσο και για το geocoding. 

Επιπλέον αυτού του προβλήματος, υπάρχουν χαρακτηριστικά σημεία στα οποία η κάλυψη των οδών 

δεν είναι επαρκής, όπως π.χ. στην περιοχή του Αερολιμένα. Και ναι μεν τα σημεία αυτά είναι 

ιδιαίτερα μικρά στην συνολική έκταση ώστε να μειώσουν την συνολική πληρότητα κι ακρίβεια, όμως, 

όπως περιγράφεται παρακάτω, δημιουργούν αρκετά προβλήματα στην παρούσα Εφαρμογή, αφού 

πρόκειται για σημεία/περιοχές σημαντικού ενδιαφέροντος για αυτήν. 

Κατά την διάρκεια εκπόνησης της Εργασίας δοκιμάστηκαν διάφορες λύσεις για τον εμπλουτισμό και 

την διόρθωση των στοιχείων OSM για την περιοχή της Αθήνας, κυρίως με χρήση του πακέτου ArcGIS. 

Οι περισσότερες από αυτές τις λύσεις φάνηκε να έχουν σχετική επιτυχία, όμως ακόμη κι έτσι 

δημιουργούταν υπερβολικά μεγάλος όγκος εργασίας για τον manual έλεγχο και την αντιμετώπιση 

των όποιων προβλημάτων, πολύ πέρα από το αντικείμενο της παρούσας Εργασίας. Ακόμη, όλες οι 

λύσεις παραβίαζαν, ή πιθανόν παραβίαζαν, πνευματικά δικαιώματα, οπότε δεν υπήρχε άμεση 

πρακτική χρησιμότητα. Ο τελευταίος είναι προφανώς και ο λόγος για τον οποίον δεν 

χρησιμοποιήθηκαν πλήρως τέτοια sets δεδομένων. 

Η λύση που τελικά εφαρμόστηκε, και περιγράφεται παρακάτω, είναι να χρησιμοποιούνται τα 

στοιχεία του OSM για την δημιουργία γράφου και το routing με όλα τα μέσα από την σχετική 

μηχανή, όμως για το χαρτογραφικό υπόβαθρο και το geocoding να χρησιμοποιούνται οι αντίστοιχες 

υπηρεσίες της Google. ΢την νέα Εφαρμογή Φρήστη που αναπτύχθηκε, στα τμήματα πεζή γίνεται 

μετεπεξεργασία των διαδρομών με χρήση της υπηρεσίας Google Directions, ώστε να υπάρχει 

καλύτερη αντιστοιχία με τον χάρτη. Έτσι όμως δημιουργείται αναπόφευκτα κάποια αναντιστοιχία 

όσον αφορά το routing, π.χ. για το μήκος διαδρομής. 

109


5.3 Δημιουργία Γράφου. 

Ο Γράφος που αντιστοιχεί στα παραπάνω δεδομένα, και ο οποίος χρησιμοποιείται από το routing 

engine, δημιουργήθηκε με χρήση του graph-builder του Open Trip Planner, ένα open source 

εργαλείο που περιγράφεται στο Error! Reference source not found.. Ο Γράφος περιέχει στοιχεία του 

δικτύου των ΜΜΜ και των δρομολογίων τους, αλλά και στοιχεία για το οδικό δίκτυο, τα οποία 

χρησιμοποιούνται για το αρχικό routing πεζή. Σα στοιχεία αυτά προέρχονται από το Open Street 

Map και γίνονται download από τον ίδιον τον graph-builder. 

Ο Γράφος που έχει δημιουργηθεί για την Αθήνα έχει μέγεθος περίπου 120 Mb. Ο χρόνος 

δημιουργίας του σε έναν υπολογιστή με υπολογιστή Quad Core 2.4 GΗz είναι της τάξης των αρκετών 

λεπτών της ώρας (~20). Ο χρόνος αυτός είναι αισθητά μικρότερος όταν υπάρχουν cached δεδομένα 

του Open Street Map, οπότε δεν γίνεται το σχετικό κατέβασμα. 

Εικόνα 37: (Επανάληψη) Ο Γράφος της Εφαρμογής στο Κέντρο της Αθήνας όπως απεικονίζεται στο 

module GUI του OTP. Οι κίτρινες γραμμές αντιστοιχούν σε δρομολόγια των ΜΜΜ, ενώ οι γαλάζιες 

στο οδικό δίκτυο. 

110


6Τλοποίηση ΢υστήματος. 

΢το Κεφάλαιο αυτό γίνεται περιγραφή της υλοποίησης, αλλά και των σημαντικότερων εργαλείων που 

χρησιμοποιήθηκαν. 

Πριν ξεκινήσει όμως το κυρίως μέρος του Κεφαλαίου, θα πρέπει να αναφερθεί ότι το όνομα που 

δόθηκε στην Τπηρεσία/Εφαρμογή της παρούσα Εργασίας είναι ‗Tsoop!‘. Δεν σημαίνει κάτι ιδιαίτερα, 

είναι όμως αρκετά απλό. Η φημολογία θέλει να προέρχεται από την φράση ―..και Σσουπ, Έφτασες!‖. 

Επίσης να αναφερθεί ότι, λόγω της συνεχούς ανάπτυξης της Εφαρμογής, είναι δυνατόν να 

παρατηρούνται διαφοροποιήσεις κάποια στιγμή ανάμεσα σε αυτό που τρέχει στην πραγματικότητα 

και σε ότι αναφέρεται στο παρόν Κεφάλαιο, χωρίς όμως οι διαφοροποιήσεις αυτές να είναι επί της 

ουσίας πολύ σημαντικές. Π.χ. αντί για PostgreSQL μπορεί να χρησιμοποιείται MySQL, απλά και μόνο 

επειδή αυτή υποστηρίζεται από κάποιον συγκεκριμένο Server. 

6.1 Εργαλεία Που Φρησιμοποιήθηκαν. 

΢τη συνέχεια δίνεται μία σύντομη περιγραφή των βασικότερων εργαλείων που χρησιμοποιήθηκαν, με 

σκοπό στη συνέχεια η περιγραφή της υλοποίησης να είναι περισσότερο κατανοητή. ΢ε κάθε 

111


περίπτωση που ο αναγνώστης επιθυμεί περισσότερες πληροφορίες για κάποια από τα εργαλεία, 

προτρέπεται στην σχετική τεκμηρίωση. 

Η εφαρμογή έγινε προσπάθεια να πραγματοποιηθεί με την όσο το δυνατόν περισσότερη χρήση 

λογισμικού και δεδομένων που να διατίθενται ελεύθερα, κι ακόμη καλύτερα, με συνεισφορά του 

οποιουδήποτε το επιθυμεί (ανοικτός κώδικας, ανοικτά δεδομένα). Αυτό ήταν περισσότερο 

επιδιωκόμενο στο κομμάτι των στοιχείων που συμμετέχουν άμεσα στην λειτουργία (π.χ. web server), 

και δευτερευόντως στο κομμάτι που αφορά τα εργαλεία ανάπτυξης. 

Ένας κύριος λόγος αυτής της επιδίωξης ήταν να μπορεί να λειτουργήσει η εφαρμογή στην 

πραγματικότητα, ώστε το προϊόν της παρούσας Μεταπτυχιακής Διπλωματικής Εργασίας να είναι 

κάτι χρήσιμο, χωρίς να απαιτείται κάποιο σημαντικό κόστος, είτε για την αγορά λογισμικού, είτε για 

την αγορά δεδομένων. Ένας άλλος κύριος λόγος ήταν το να αποκτηθεί γνώση σχετικά με την 

ανάπτυξη ανοικτού λογισμικού και δεδομένων, δηλαδή τις διαδικασίες που πραγματοποιούνται για 

την λήψη αποφάσεων, τον συντονισμό της εργασίας, την ενημέρωση των μελών μίας κοινότητας 

κ.α.. 

6.1.1 Java. 

Πρόκειται για ένα σύνολο προϊόντων λογισμικού και προδιαγραφών από την 

Sun Microsystems, η οποία είναι πλεόν θυγατρική εταιρεία της Oracle. 

Επιτρέπει την ανάπτυξη εφαρμογών οι οποίες μπορούν να λειτουργήσουν 

ανεξάρτητα πλατφόρμας, σε ένα πολύ μεγάλο εύρος συσκευών, όπως 

personal computers, servers, κινητά τηλέφωνα, και μικροσυσκευές. Αυτό 

είναι δυνατόν λόγω του ότι η εκτέλεση του κώδικα δεν πραγματοποιείται 

άμεσα από τον υπολογιστή, αλλά μέσω του Java Virtual Machine (JVM). 

O compiler της Java, ο οποίος περιέχεται στο Java Development Kit (JDK), παράγει έναν ενδιάμεσο 

κώδικα, τον Java bytecode, ο οποίος είναι ανεξάρτητος της πλατφόρμας εκτέλεσης, και ο οποίος 

μετασχηματίζεται σε εκτελέσιμη μορφή με τον JIT (Just-in-time) compiler του Java Runtime 

Environment (JRE). Ο τελευταίος μετασχηματισμός γίνεται on the fly, δηλαδή την στιγμή της 

εκτέλεσης. 

Ο κύριος λόγος μάλιστα ανάπτυξης της Java στην αρχή ήταν αυτή ακριβώς η δυνατότητα. Σο να 

μαθαίνει κάποιος μόνο μία γλώσσα, και να γράφει έναν κώδικα που να μπορεί να εκτελείται από ένα 

112


μεγάλο εύρος συσκευών, ιδίως από αυτές χωρίς μεγάλη επξεργαστική ισχύ και απαιτήσεις, όπως π.χ. 

είναι οι οικιακές συσκευές, ήταν ένα πολύ ζητούμενο της βιομηχανίας, αφού περιόριζε σημαντικά το 

κόστος. 

΢ήμερα η Java, λόγω της σύνδεσής της με τον web server από τα μέσα της δεκαετίας του 1990, 

χρησιμοποείται στην πλειοψηφία των εφαρμογών που βρίσκονται στην πλευρά του server. Λόγω της 

ευελειξίας που παρέχει το web, οι επιχειρήσεις και οι οργανισμοί έχουν μετατοπίσει τις εσωτερικές 

τους εφαρμογές σε περιβάλλον client-server, με αποτέλεσμα να έχει οφεληθεί σημαντικότατα η 

Java, χρησιμοποιούμενη πλεον ως η γλώσσα ανάπτυξης εταιρικών εφαρμογών. 

Βέβαια, η οφέλεια προέρχεται και από την ανάπτυξη του internet ως μέσο για πλήθος νέων 

εφαρμογών προς πελάτες, όπως είναι π.χ. τα online καταστήματα, οι αγορές εισιτηρίων, κ.α., για τις 

οποίες εφαρμογές, και πάλι στην πλευρά του server χρησιμοποιείται κατά κανόνα η Java. 

Λόγω αυτού του τρόπου λειτουργείας, η Java δεν διαθέτει αρκετά στοιχεία low-level, όπως είναι οι 

pointers, κι έχει ένα πολύ απλό μοντέλο μνήμης, στο οποίο κάθε αντικείμενο τοποθετείται στο heap 

και όλες οι μεταβλητές τύπου object είναι αναφορές. Η διαχείριση μνήμης γίνεται από το JVM με 

χρήση ενός ολοκληρωμένου ενσωματωμένου μηχανισμού. 

Η Java παρέχεται σε διάφορες εκδοχές, όπως 

Java Card, μία τεχνολογία που επιτρέπει μικρές Java εφαρμογές (applets) να τρέχουν με 

ασφάλεια σε έξυπνες κάρτες (smart cards) και αντίστοιχες συσκευές. 

Java ME (Micro Edition), η οποία έχει κάποια διαφορετικά set βιβλιοθηκών, έτσι ώστε να 

εξασφαλίζουν ότι δεν θα πρόκυψει χρήση υπερβολικά μεγάλων ποσοτήτων μνήμης. 

Java SE (Standard Edition), η οποία αποτελεί το πακέτο γενικής χρήσης, όπως π.χ. σε 

desktop υπολογιστές. 

Java EE (Enterprise Edition), η οποία αποτελεί ένα υπερσύνολο της SE, με επιπλέον 

διάφορα χρήσιμα APIs για την ανάπτυξη client-server εφαρμογών. 

Περισσότερα στοιχεία για την Java μπορεί κανείς να βρει στη διεύθυνση: www.java.com. 

113


6.1.2 Eclipse. 

To Eclipse είναι ένα περιβάλλον ανάπτυξης λογισμικού για 

διάφορες γλώσσες προγραμματισμού, συνδυάζονντας ένα 

ολοκληρωμένο περιβάλλον ανάπτυξης (Integrated 

Development Environment – IDE) κι ένα σύστημα 

πρόσθετων plug-ins. Ενδεικτικά, το Eclipse μπορεί να 

χρησiμοποιηθεί για την αν ανάπτυξη εφαρμογών σε γλώσσες 

όπως η Java, η C, η C++, η PHP, η Perl, η Python, κ.α.. Πρόκειται για λογισμικό ανοικτού κώδικα. 

Προέρχεται από την γενιά IDE της IBM με την ονομασία VisualAge, και η πιό συχνή χρήση αφορά 

την ανάπτυξη εφαρμογών Java με την χρήση των Java Development Tools (JDT). Οι δυνατότητες 

είναι επεκτάσιμες τοποθετώντας κατάλληλα πρόσθετα για ένα μεγάλο εύρος θεμάτων. Με την 

εξαίρεση μάλιστα ενός μικρού run-time kernel, οτιδήποτε στο Eclipse είναι στην πραγματικότητα 

ένα plug-in. 

Πρόκειται για λογισμικό ανοικτού κώδικα, και το επίσημο site είναι στην διεύθυνση: www.eclipse.org. 

6.1.3 Apache Subversion. 

΢υνήθως αναφέρεται ως SVN, και είναι ένα σύστημα 

διαχείρισης εκδόσεων λογισμικού. Με την βοήθειά του 

είναι δυνατόν να διατηρούνται διάφορες εκδόσεις 

αρχείων, που μπορούν να αφορούν π.χ. πηγαίο κώδικα, ιστοσελίδες κ.α.. Πρόκειται δηλαδή για 

λογισμικό που ανήκει στην κατηγορία Software Configuration Management (SCM). 

Σα repositories που χρησιμοποιεί μπορούν να είναι είτε βασισμένα στο σύστημα αρχείων, είτε στπ 

σχήμα http://host/path access. Σοποθετείται στο Eclipse ως plug-in, και είναι λογισμικό 

ανοικτού κώδικα, υπό την γενική άδεια Apache. Σο επίσημο site βρίσκεται στην διεύθυνση: 

subversion.apache.org. 

114


6.1.4 Apache Maven. 

Πρόκειται για προγραμματιστικό εργαλείο για την διαχείριση 

projects λογισμικού και την αυτοματοποίηση διαφόρων 

εργασιών κατά την φάση της ανάπτυξης (build automation), 

δηλαδή π.χ. το compilibg, το packaging του δυαδικού κώδικα, την εκτέλεση δοκιμών, την 

εγκατάσταση, ή ακόμα και την δημιουργία τεκμηρίωσης. 

΋πως προδίδει και το όνομά του, ανήκει στο γενικότερο project Apache, και μπορεί θεωρητικά να 

χρησιμοποιηθεί για οποιαδήποτε γλώσσα προγραμματισμού. Φρησιμοποιεί ένα Project Object Model 

(POM) ώστε να περιγράψει το λογισμικό που αναπτύσσεται, τις εξαρτήσεις του (dependencies) σε 

εξωτερικά modules και άλλα συστατικά, όπως επίσης και την σειρά των βημάτων του building. 

Σο Maven κατεβάζει δυναμικά τις βιβλιοθήκες Java και τα plug-ins του ιδίου που απαιτούνται, από 

ένα ή περισσότερα repositories. Αν και θεωρητικά το σύστημα αρχιτεκτονικής των plug-ins 

επιτρέπει την χρήση του για οποιαδήποτε γλώσσα προγραμματισμού, εν τούτοις στην πράξη 

χρησιμοποιείται σχεδόν αποκλειστικά για την Java. Σο ίδιο το Maven γίνεται πολύ εύκολα plug-in στο 

περιβάλλον του Eclipse. 

Περισσότερα στοιχεία μπορεί να βρει κανείς στο site του project, το οποίο είναι στην διεύθυνση: 

http://maven.apache.org. 

6.1.5 Apache Tomcat. 

Σο Apache Tomcat (ή Jakarta Tomcat) είνα ένας servlet container 

ανοικτού κώδικα, ο οποίος έχει αναπτυχθεί από το Apache Software 

Foubdation. Εφαρμόζει τόσο την Java Servlet όσο καο την 

JavaServer Pages (JSP) προδιαγραφή της Sun Microsystems, και 

παρέχει ένα αμιγώς Java περιβάλλον HTTP web server περιβάλλον για 

την εκτέλεση κώδικα Java. Η παραμετροποίηση του server είναι 

δυνατή είτε μέσω εργαλείων επιλογών, είτε με την επεξεργασία XML αρχείων. 

O servlet container του Tomcat ονομάζεται ‗Catalina‘, ενώ το ‗Coyote‘ είναι ο HTTP connector, ο 

οποίος υποστηρίζει τo HTTP 1.1 πρωτόκολλο για τον web server ή τον application container. Σο 

Coyote παρακολουθεί ένα συγκεκριμένο TCP Port για εισερχόμενες συνδέσεις, και προωθεί το 

αίτημα στο Tomcat Engine για την επεξεργασία και την αποστολή πίσω μίας απάντησης στον 

115


αιτούντα. Σο Jasper 2 είναι το JSP Engine του Tomcat (από την έκδοση 5.x κι έπειτα), που αποτελεί 

μία υλοποίηση της προδιαγραφής JavaServer Pages 2.0 της Sun Microsystems. Σο Jasper αναλύει 

τα JSP αρχεία ώστε να τα κάνει compiling σε κώδικα Java σαν servlets, τα οποία μπορεί να τα 

χειριστεί το Catalina. Κατά την εκτέλεση, το Jasper εντοπίζει αλλαγές στα JSP αρχεία και τα κάνει 

ξανά compiling. 

Περισσότερες πληροφορίες μπορεί κανείς να βρεί στην web διεύθυνση: http://tomcat.apache.org. 

6.1.6 Apache HTTP Server. 

Σο Apache HTTP Server (ή σκέτο Apache) είναι ένα λογισμικό web server το οποίο αναπτύσεται και 

συντηρείται από μία ανοικτή κοινότητα developers, την Apache Software Foundation. Σο λογισμικό 

είναι διαθέσιμο για μία μεγάλη ποικιλία λειτουργικών συστημάτων, αν και κυρίως εγκαθίσταται σε 

συστήματα τύπου Unix. ΢ύμφωνα με τις πιο πρόσφατες εκτιμήσεις, το Apache ήταν ο server για το 

60% των web sites, και περίπου των 2/3 από τα 1000000 sites με την μεγαλύτερη επισκεψιμότητα. 

Διαθέτει μεγάλο πλήθος χαρακτηριστικών και λειτουργιών, πολλά από τα οποία έχουν υλοποιηθεί ως 

compiled modules τα οποία επεκτείνουν την κύρια λειτουργικότητα. Σα modules αυτά μπορούν να 

αφορούν από υποστήριξη γλωσσών προγραμματισμού στην πλευρά του server, μέχρι συστήματα 

ασφαλείας. Η δυνατότητα virtual hosting επιτρέπει σε μία εγκατάσταση του server να εξυπηρετεί 

πολλά διαφορετικά domains και sites. 

Η απόδοση του Apache HTTP Server είναι ιδιαίτερα υψηλή, καθώς βασίζεται σε μία αρχιτεκτονική 

όπου παρέχονται Modules Πολυεπεξεργασίας (MPMs), τα οποία επιτρέπουν στον server να τρέχει σε 

διάφορες καταστάσεις, έτσι ώστε να ταιριάζει καλύτερα στην εκάστοτε υποδομή και να την αξιοποιεί 

περισσότερο. 

Περισσότερες πληροφορίες μπορεί κανείς να βρει στην διεύθυνση: http://httpd.apache.org. 

6.1.7 AlivePDF. 

Πρόκειται για μία Open Source βιβλιοθήκη για την εκτύπωση από την Actionscript 3 απευθείας σε 

PDF αρχεία. Επιτρέπει λεπτομερή χειρισμό του κειμένου, όμως δυστυχώς δεν διαχειρίζεται ορθά την 

εκτύπωση των γραφικών αντικειμένων, καθώς βείσκεται ακόμη σε πολύ πρωίμη μορφή. 

116


Δεν υπάρχουν πολλές πληροφορίες διαθέσιμες προς το παρόν, μπορεί όμως κανείς να βρει κάποια 

επιπλέον στοιχεία στην διεύθυνση: http://alivepdf.bytearray.org. 

6.1.8 Open Street Map (OSM). 

Πρόκειται για Project που αφορά την δημιουργία ενός διανυσματικού χάρτη για ολόκληρο τον 

κόσμο, με την εθελοντική συμβολή των χρηστών. Περισσότερες πληροφορίες για το OSM δίνονται 

στο 5.2.2, μιας που χρησιμοποιήθηκε ως πηγή για τα δεδομένα του οδικού δικτύου και την 

δημιουργία του γράφου. 

6.1.9 PostgreSQL. 

To PostgreSQL είναι ένα αντικειμενοσχεσιακό σύστημα 

διαχείρισης βάσης δεδομένων (object-relational database 

management system [ORDBMS]). Διατίθεται κάτω από μία MIT- 

style άδεια και είναι λογισμικό ανοικτού κώδικα. 

Σο PostgreSQL προέρχεται από το project Ingres του 

πανεπιστημίου Berkeley, εξελίσσοντας την ιδέα πάνω σε έναν νέο 

κώδικα. Η πρώτη εμφάνιση έγινε το 1985. Έπειτα από μία 

διακοπή που πραγματοποίηθηκε το 1993, μετά την έκδοση 4, η εξέλιξη του PostgreSQL 

πραγματοποιήθηκε ως open source. H ονομασία PostgreSQL (η αρχική ήταν Postgres) δόθηκε το 

1996, έτσι ώστε να εμφανίζεται η υποστήριξη της SQL. 

To PostgreSQL υποστηρίζει Procedural γλώσσες (pgSQL, Tcl, Perl, Python) , διάφορα είδη 

ευρετηρίων (B+-tree, hash, GiST, GiN, και οριζόμενα από τον χρήστη), όπως επίσης και Εxpression 

και Partial ευρετήρια. ΢τα Expression ευρετήρια χρησιμοποιείται η τιμή μιάς συνάρτησης αντί της 

τιμής κάποιας στήλης, ενώ στα Partial ευρετήρια χρησιμοποιείται μία συνάρτηση WHERE έτσι ώστε 

το ευρετήριο να αφορά τμήμα μόνο του Πίνακα. 

Ένα άλλο χαρακτηριστικό του PostgreSQL είναι η υποστήριξη triggers για τα διάφορα συμβάντα που 

αφορούν πίνακες (όχι όμως για αυτά που αφορούν views), όπως επίσης το σύστημα Multi-Version 

117


Concurrency Control (MVCC) το οποίο δίνει σε κάθε χρήστη ένα στιγμιότυπο της βάσης δεδομένων, 

επιτρέποντας να γίνονται έτσι αλλαγές που δεν είναι ορατές στους άλλους χρήστες, παρά μόνο 

έπειτα από ένα transaction. Με τον τρόπο αυτό περιορίζεται η αναγκαιότητα των read locks. 

To PostgreSQL υποστηρίζει μία μεγάλη ποικιλία από τύπους δεδομένων, επιτρέποντας στους χρήστες 

την δημιουργία πρόσθετων, δικών τους τύπων δεδομένων. Ένα τέτοιο παράδειγμα ανάπτυξης 

πρόσθετων τύπων δεδομένων είναι το Project PostGIS, όπου υποστηρίζονται διάφοροι τύποι 

δεδομένων σχετικοί με χωρικά στοιχεία, όπως επίσης και ανάλογες συναρτήσεις. 

Σο administration γίνεται μέσα από διάφορα front-ends ανοικτού κώδικα, με το ποιό γνωστό από 

όλα να είναι το pgAdmin, το οποίο είναι διαθέσιμο σε πάρα πολλές γλώσσες για τα δημοφιλέστερα 

λειτουργικά συστήματα. 

Περισσότερες πληροφορίες για το PostgreSQL μπορεί κανείς να βρει στην εξής διέυθυνση: 

http://www.postgresql.org. 

6.1.10 Google Maps – Google Maps API. 

Σο Google Maps είναι μία υπηρεσία της Google γνωστή σχεδόν σε όλους σήμερα, η οποία παρέχει 

χάρτες και δορυφορικούς ή αερο- ορθοφωτοχάρτες για το σύνολο του πλανήτη. Επιπλέον των 

χαρτών όμως, η υπηρεσία συμπεριλαμβάνει την τεχνολογία για την χαρτογραφική υποστήριξη 

διαφόρων εφαρμογών, μέσα από το Google Maps API. 

118


Εικόνα 38: Σο κέντρο της Αθήνας, όπως φαίνεται στον οδικό χάρτη του Google Maps. 

Η υπηρεσία παρέχεται δωρεάν για μη εμπορική χρήση από κάποιο συγκεκριμένο domain, για το 

οποίο αφού δηλωθεί, παραχωρείται ένα αλφαριθμητικό κλειδί-ταυτότητα. Επίσης, μέχρι αυτή την 

στιγμή δεν υπάρχουν διαφημίσεις, αλλά υπάρχει η επιφύλαξη για την εισαγωγή τους. 

Λόγω της μεγάλης πληρότητας και ακρίβειας τον δεδομένων που περιέχουν, οι χάρτες της Google 

έχουν γίνει αυτή τη στιμή οι ευρύτερα διαδεδομένοι διαδικτυακοί χάρτες. ΢ε αυτό έχουν βοηθήσει 

και παράγοντες βέβαια όπως η αξιοπιστία της υπηρεσίας, η παροχή των πληροφοριών σε πάρα 

πολλές γλώσσες, αλλά και η προσθήκη συνεχώς νέων θεμάτων, όπως είναι π.χ. χάρτες 

κυκλοφοριακών συνθηκών. 

Ιδιαίτερα έχει βοηθήσει η ύπαρξη του Google Maps API, το οποίο έχει επιτρέψει την δημιουργία 

πολυάριθμων εφαρμογών ανά τον κόσμο, με χρήση των Google Maps ως υπόβαθρο. Με τα εργαλεία 

που παρέχονται μπορεί κανείς να δημιουργήσει σχετικά εύκολα μία εφαρμογή, της οποίας ο χάρτης 

και οι λειτουργίες του να είναι ήδη οικία στο μεγαλύτερο ποσοστό των χρηστών. Σο Google Maps API 

παρέχεται σε έκδοση για JavaScript, αλλά και για Adobe Flash, όπου μάλιστα μπορεί να γίνει μίξη με 

τα στοιχεία του Adobe Flash. 

119


6.1.10.1 Κύρια ΢τοιχεία του API. 

Σο κύριο αντικείμενο του Google Maps API είναι το map, πάνω στο οποίο τοποθετούνται όλα τα 

υπόλοιπα αντικείμενα-παιδιά. Μια βελτιωμένη εκδοχή του map είναι το map3D, το οποίο παρέχει 

επιπλέον την δυνατότητα για χάρτες με τρισδιάστατη οπτική. Σο αντικείμενο map έχει ιδιότητες που 

καθορίζουν το μέγεθος, το κεντράρισμα, την κλίμακα, την γλώσσα απεικόνισης, όπως επίσης τα είδη 

χάρτη και ποιά από αυτά είναι θα είναι επιλέξιμα από τον χρήστη (π.χ. χάρτης, δορυφορικός 

ορθοφωτοχάρτης, κ.α.). 

Σο map δέχεται επάνω του διάφορα χειριστήρια, όπως για τον προσανατολισμό, την κλίμακα, ή την 

απεικόνιση ενός ευρύτερου χάρτη μικρής κλίμακας. Σο αντικείμενο map μπορεί να αντιδρά σε 

διάφορα συμβάντα (π.χ. click του χρήστη σε κάποιο σημείο), κι ανάλογα να ενεργοποιούνται οι 

σχετικές ρουτίνες της εφαρμογής. 

Αντικείμενα-παιδιά του map μπορούν να είναι διάφορα επιθέματα, όπως Markers για σημεία, 

Polylines για γραμμικά στοιχεία, και Polygons για επιφανειακά στοιχεία, ή ακόμη και εικόνες (ground 

overlays). Καθέ ένα από αυτά έχει ένα πλήθος από ιδιότητες (σχήμα, μέγεθος, χρώμα, κτλ), και 

μπορεί να υπάρχει χειρισμός των συμβάντων, όπως π.χ. το click του χρήστη επάνω τους. 

Ένα ιδαίτερα χρήσιμο στοιχείο, το οποίο μπορεί να ανήκει σε κάποιο από τα υπόλοιπα (Map, 

Markers, Polylines, Polygons) είναι το InfoWindow. Πρόκειται για ένα συννεφάκι στην πιο 

συνηθισμένη του μορφή, το οποίο μπορεί να περιέχει μέσα του περιέχομενο από απλό κέιμενο και 

HTML, μέχρι άλλα αντικείμενα, ακόμη και Flash. 

Περισσότερες και αναλυτικές πληροφορίες μπορεί κανείς να βρει στην διεύθυνση: 

http://code.google.com/intl/en/apis/maps/documentation/flash. 

6.1.11 Google Geocoding API. 

To Google Geocoding είναι μία Web Τπηρεσία που παρέχεται από την Google και η οποία μπορεί να 

μετατρέπει διευθύνσεις σε γεωγραφικές συντεταγμένες, αλλά και το αντίστροφο. Σο API δίνει την 

δυνατότητα πρόσβασης σε έναν geocoder μέσω ενός HTTP request. 

120


Η χρήση της Τπηρεσίας είναι δωρεάν κι ελεύθερη από διαφημίσεις μέχρι αυτή την στιγμή, αρκεί τα 

queries να μην ξεπεράσουν τα 2500/ημέρα για κάποιον χρήστη, ή να μην γίνονται σε πολύ γρήγορο 

ρυθμό. Απαραίτητη προϋπόθεση της άδειας χρήσης της υπηρεσίας είναι τα αποτελέσματα να 

σχετίζονται με την εμφάνισή τους σε έναν Google Map. 

Περισσότερες πληροφοριές μπορεί κανείς να βρει στην διεύθυνση: 

http://code.google.com/apis/maps/documentation/geocoding/#Geocoding 

6.1.12 Google Directions API. 

To Google Directions API είναι και αυτό μία υπηρεσία της Google η οποία βρίσκει διαδρομές μεταξύ 

τοποθεσιών, με ερωτήματα στην μορφή HTTP. Οι τοποθεσίες είναι δυνατόν να δίνονται είτε 

περιγραφικά, σαν κείμενο, οπότε γίνεται και geocoding, είτε σε μορφή γεωγραφικών συντεταγμένων. 

Η υπηρεσία προσφέρεται δωρεάν, με ανώτατο όμως όριο τα 2500 ερωτήματα ανά ημέρα, με 

μέγιστο τα 8 ενδιάμεσα σημεία ανά ερώτημα. ΢ε περιπτώση μεγαλύτερης κίνησης, τότε μπορεί 

κάποιος να αγοράσει το Google Maps Premier, οπότε τα ερωτήματα μπορεί να είναι μέχρι 100000 

την ημέρα, με μέγιστο τα 23 ενδιάμεσα σημεία ανά ερώτημα. ΋πως και στην περίπτωση του 

Geocoding API, η χρήση επιτρέπεται μόνο όταν γίνεται απεικόνιση των αποτελεσμάτων σε χάρτη της 

Google. 

Περισσότερες πληροφοριές μπορεί κανείς να βρει στην διεύθυνση: 

http://code.google.com/apis/maps/documentation/directions 

6.1.13 Adobe Flex 4, Adobe Flash Builder 4. 

Σο Flex της εταιρίας Adobe είναι ένα πλαίσιο open source, με το οποίο οι 

προγραμματιστές μπορούν να δημιουργήσουν web εφαρμογές που να 

επιτρέπουν στους χρήστες την διαχείριση δεδομένων με ιδιαίτερα 

αποτελεσματικό τρόπο. Ένα σημαντικό πλεονέκτημα είναι ότι οι εφαρμογές μπορούν να τρέχουν 

χωρίς πολλές τροποποιήσεις σε έναν μεγάλο αριθμό διαφορετικών συσκευών και λειτουργικών 

συστημάτων. Σο τρέξιμο των εφαρμογών μπορεί να γίνεται είτε μέσα σε κάποιον από τους γνωστούς 

121


web browser μέσω του Flash Player, είτε αυτόνομα, μέσα από το Adobe AIR το οποίο παρέχεται 

δωρεάν. 

Σο Flex παρέχει μία γλώσσα προγραμματισμού κι ένα μοντέλο που βασίζεται σε διαδεδομένα 

πρότυπα. Η γλώσσα ονομάζεται MXML, και όπως μαρτυρά το όνομά της βασίζεται στην XML για να 

περιγράψει δηλωτικά τα συστατικά του user interface και των συμπεριφορών (π.χ. listboxes και 

mouseover αντίστοιχα). Επιπλέον, η γλώσσα ActionScript 3.0 είναι μία αντικειμενοστραφής γλώσσα 

για την δημιουργία της «λογικής» στην εφαρμογή. Σο Flex είναι δυνατόν να επεκτείνεται, κι έτσι αυτή 

την στιγμή υπάρχουν πάνω από 100 στοιχεία για το user interface. 

Ένα πολύ σημαντικό στοιχείο του Flex είναι η δυνατότητα να ορίζονται προκαθορισμένα states. 

Κάθε state αντιστοιχεί σε κάποιες ιδιότητες των αντικειμένων του user interface. Έτσι, είναι πολύ 

εύκολο να δημιουργήσει κανείς μία εφαρμογή όπου κάποια διακριτά στάδια της λειτουργίας (π.χ. 

είσοδος δεδομένων, παρουσίαση αποτελεσμάτων) θα είναι σχεδόν πλήρως ανεξάρτητα από την 

άποψη των widgets, και η εναλλαγή των καταστάσεων αυτών θα γίνεται γρήγορα και με μία μόνο 

γραμμή κώδικα, χωρίς να χρειάζεται να ορίζονται συνεχώς οι ιδιότητες των αντικειμένων (π.χ. 

εμφάνιση, θέση, μέγεθος, ενεργό ή όχι, κτλ). 

Εικόνα 39: ΢τιγμιότυπο από το Adobe Flash Builder κατά τθν ανάπτυξθ τθσ εφαρμογισ. 

Σο Adobe Flash Builder βασίζεται στην λειτουργία του Eclipse, και είναι όπως κι εκείνο ένα εργαλείο 

ανάπτυξης εφαρμογών, αλλά για το Flex. Προσφέρει μεταξύ άλλων δυνατότητες debugging, οπτικής 

122


σχεδίασης του layout του user interface, κα.. Ιδιαίτερα σημαντικό στοιχείο είναι ότι όλες οι 

εφαρμογές της Adobe συνεργάζονται σε μεγάλο βαθμό μεταξύ τους, οπότε στην ουσία μπορούν 

διάφορες εφαρμογές να συνδυαστούν και να αποτελούν όλες μαζί ένα ολοκληρωμένο πακέτο 

εργαλείων. 

Ενδεικτικά αναφέρονται η εφαρμογή LiveCycle Data Services, ένας server συνεργαζόμενος εύκολα 

με τα υπόλοιπα λογισμικά της εταιρείας, έτσι ώστε να παρέχει δεδομένα σε client εφαρμογές, το 

Dreamweaver, εφαρμογή για τον σχεδιασμό ιστοσελίδων, τo Adobe Flash, για την δημιουργία Flash 

Animations και εφαρμογών, και το Flash Catalyst, με την οποία διάφορα αρχεία εικόνων 

μετατρέπονται σε αντικείμενα web με αλληλεπίδραση. 

Θα πρέπει να σημειωθεί όμως ότι στο Flash Builder η υποστήριξη των HTTP συνδέσεων είναι μεν 

αρκετά πλούσια σε δυνατότητες, όπως το ότι μπορούν να ανιχνεύονται σε μεγάλο βαθμό οι δομές 

των JSON και των XML αποκρίσεων και να δημιουργούνται κατάλληλες οντότητες, όμως δεν είναι 

πλήρως ολοκληρωμένες. Έτσι, σε περιπτώσεις που εμφανίζονται λάθη ή προβλήματα π.χ., δεν 

εμφανίζεται κανένα μήνυμα λάθους, ούτε καν απλώς ως επισήμανση χωρίς αναφορά για το είδος 

του προβλήματος. Αυτό ήταν κάτι που δυσκόλεψε ιδιαίτερα την ανάπτυξη της Εφαρμογής της 

Εργασίας. 

Περισσότερες πληροφορίες για όλα τα προϊόντα μπορεί κανείς να βρει στο site της εταιρείας, στην 

διεύθυνση: www.adobe.com. 

6.1.14 OpenTripPlanner (OTP). 

Ο Open Trip Planner (OTP) είναι ένα Project ανοικτού κώδικα σχετικά με την Δημόσια ΢υγκοινωνία, 

το οποίο έχει την συνεισφορά μικρότερων Projects και φορέων, όπως είναι ο OpenPlans, το 

OneBusAway, το FivePoints, το GraphServer, και το byCycle. 

Η αδειοδότηση του OTP γίνεται κατά GNU LGPL, κάτι που σημαίνει ότι οποιοσήποτε μπορεί να τον 

αντιγράψει, να τον τροποποιήσει και να τον διανείμει, αρκεί να περάσει τα δικαιώματα αυτά και 

στους χρήστες του. Η απαίτηση αυτή δεν ισχύει για κώδικα που απλώς χρησιμοποιεί τον OTP. 

123


Ο OTP σαν συνολικό project δεν αφορά μόνο την μηχανή routing, αλλά ένα πλήθος λειτουργιών, οι 

οποίες περιγράφονται στη συνέχεια. ΢την πραγματικότητα είναι μια ολοκληρωμένη λύση για Journey 

Planner, αν και στην παρούσα υλοποίηση δεν χρησιμοποιήθηκαν τα τμήματά του που αφορούν το 

user interface. 

Σο site www.opentripplanner.org αφορά την ανάπτυξη του project. 

6.1.15 Βασικοί ΢υμμέτοχοι. 

Ο OpenPlans είναι μη κερδοσκοπικός οργανισμός τεχνολογίας, ο οποίος 

εστιάζει στην ανοικτή διακυβέρνηση, και ο οποίος αναπτύσει λογισμικό 

ανοικτού κώδικα για την μετατροπή δεδομένων σε προσβάσιμη και χρήσιμη πληροφορία. Ιδρύθηκε 

το 1999, εδρεύει στην New York, και αποτελείται από 50 προγραμματιστές, σχεδιαστές, ειδικούς 

πολιτικής, εκπαιδευτές, και δημοσιογράφους. Σο site του οργανισμού βρίσκεται στην εξής 

διεύθυνση: www.openplans.org. 

Σο OneBusAway πρόκειται για project το οποίο ξεκίνησε από φοιτητές του 

Πανεπιστημίου της Washington, και παρέχει υποστήριξη στην βελτίωση της 

χρηστικότητας των Μέσων Μαζικής Μεταφοράς. Αυτή την στιγμή παρέχει με διάφορους τρόπους 

(web, τηλέφωνο, SMS) πληροφόρηση για τα δρομολόγια και την πραγματικού χρόνου κίνηση των 

οχημάτων αρκετών Υορέων ΜΜΜ στην περιοχή Puget Sound. Περισσότερες πληροφορίες μπορεί 

κανείς να βρει στη διεύθυνση: www.onebusaway.org. 

Σο FivePoints είναι Project το οποίο αφορά την ανάπτυξη λογισμικού ανοικτού 

κώδικα με εστίαση σε εργαλεία για μετακίνηση πεζή, με ποδήλατο, και με 

ΜΜΜ. Ξεκίνησε το 2004, και σήμερα προσφέρει υπηρεσίες στην πόλη της Atlanta, με επέκταση σε 

άλλες πόλεις να πρόβλεπεται εντός σύντομου χρόνου. Σο site του Project βρίσκεται στην διεύθυνση: 

www.fpdev.org. 

Σο GraphServer είναι και αυτό project το οποίο αφορά ανάπτυξη λογισμικού 

ανοικτού κώδικα για multi modal trip planning. Δυστυχώς δεν υπάρχουν 

πάρα πολλά στοιχεία σχετικά με το Project, του οποίου το site βρίσκεται στην εξής διεύθυνση: 

bmander.github.com/graphserver. ΢τα πρώτα βήματα, η υλοποίηση της παρούσας εφαρμογής 

βασίστηκε στο GraphServer. 

124


Σο byCycle παρέχει μία διαδικτυακή εφαρμογή για τον σχεδιασμό διαδρομών 

που θα πραγματοποιηθούν με ποδήλατο, κι αφορά αυτή τη στιγμή τις 

μητροπολιτικές περιοχές του Portland, του Milwaukee, και του Pittsburgh. Ο κώδικας της 

εφαρμογής είναι ανοικτός, βασίζεται σε DHTML και AJAX, αλλά δυστυχώς δεν υπάρχουν κι εδώ 

περισσότερα στοιχεία διαθέσιμα. Σο site της εφαρμογής είναι στην διεύθυνση: bicycle.org. 

6.1.16 Κύρια Φαρακτηριστικά Σου OTP. 

Ο OTP αναπτύσσεται σε ένα ολοκληρωμένο σχεδιαστή ταξιδίων με ΜΜΜ, ποδήλατο, και πεζή. Δεν 

αφορά μόνο το τμήμα της μηχανής εύρεσης, αλλά και τα τμήματα του web περιβάλλοντος χρήστη 

και του περιβάλλοντος διαχειριστή. Ο OTP είναι δυνατόν να προτείνει ταξίδια που μπορεί να 

επιλεγούν να γίνουν πεζή, με ΜΜΜ (Λεωφορεία, Σρένα), με ποδήλατο, ή με συνδυασμούς αυτών. 

Εικόνα 40: Φαρακτηριστικό στιγμιότυπο από τις επιλογές του χρήστη στο γραφικό περιβάλλον που 

συμπεριλαμβάνει ο OTP. 

Σο περιβάλλον του χρήστη παρέχει πληροφορίες για την καθοδήγηση, τόσο με βάση το κείμενο, όσο 

και με βάση την οπτικοποίηση σε χάρτη. Εάν ο Υορέας των ΜΜΜ διαθέτει στοιχεία σχετικά με την 

125


προσβασιμότητα σταθμών και οχημάτων από Άτομα Με Ειδικές Ανάγκες, τότε ο OTP μπορεί να 

δώσει προτάσεις ταξιδίων που να εξαρτώνται από αυτήν. Επίσης, το περιβάλλον χρήστη που 

παρέχεται είναι δυνατόν να διαμορφωθεί αρκετά και εύκολα κατά κάποιον επιθυμητό τρόπο, έτσι 

ώστε να ταιριάξει π.χ. με την εικόνα που έχει οικία ο χρήστης για τα σύμβολα, τους τρόπους 

απεικόνισης, κ.α., όπως αυτά χρησιμοποιούνται από τον Υορέα σε χάρτες, στάσεις, οχήματα, κτλ. 

Εικόνα 41: Φαρακτηριστικό στιγμιότυπο με στοιχεία καθοδήγησης από το web interface που 

συμπεριλαμβάνει ο OTP. 

Η βελτιστοποίηση των ταξιδιών μπορεί να γίνει είτε για τον μικρότερο χρόνο, είτε για τις λιγότερες 

μετεπιβιβάσεις, ενώ στην περίπτωση χρήσης ποδηλάτου μπορεί να γίνει επιλογή βελτιστοποίησης για 

την μεγιστοποίηση της ασφάλειας, όπως αυτή αντιπροσωπεύεται από τα στοιχεία του οδικού 

δικτύου. ΢την περίπωση αυτή μάλιστα μάλιστα, της χρήσης ποδηλάτου, είναι δυνατόν να παρέχεται 

η μηκοτομή υψομέτρων της διαδρομής, αρκεί να παρέχονται τα απαραίτητα τοπογραφικά στοιχεία 

Αν και σαν γλώσσα χρησιμοποιείται η Αγγλική, εν τούτοις ο OTP έχει αναπτυχθεί με τρόπο ώστε να 

επιδέχεται εύκολα διαμόρφωση για λειτουργία και σε άλλες γλώσσες. Μέχρι σήμερα είναι γνωστό 

πως υπάρχουν εκδόσεις στα Ισπανικά, τα Πολωνικά, και τα Ινδικά. Η αλλαγή διαμόρφωσης δεν 

126


αφορά μόνο τη γλώσσα, αλλά και την χρήση μονάδων μέτρησης (m, ή ft), τον τρόπο απεικόνισης 

(των ημερομηνιών π.χ.), κτλ.. 

Ο OTP είναι γραμμένος κατά κόρον σε Java EE, μία δοκιμασμένη πλατφόρμα, η οποία είναι 

ανεξάρτητη του υλικού και του λειτουργικού συστήματος, κι επίσης παρέχει, ως modular που είναι, 

την δυνατότητα για εύκολη κατανόηση και επέκταση από πολλούς προγραμματιστές. Η καρδιά του 

λογισμικού είναι ο αλγόριθμος βασισμένος στον Α* σχετικά με την εύρεση των ταξιδιών, ο οποίος 

χρησιμοποιεί contraction hierarchies όσον αφορά τον οδικό δίκτυο, και κάνει χρήση των ακριβών 

χρόνων των δρομολογίων για το δίκτυο ΜΜΜ. Σο τελευταίο είναι όπως αναλύεται αλλού ένα κατά 

κάποιο τρόπο μειονέκτημα της παρούσας εγαρμογής, λόγω του τρόπου λειτουργίας των ΜΜΜ στην 

περιοχή της Αθήνας. 

Σο περιβάλλον χρήστη βασίζεται στην λειτουργία με web browser ο οποίος τρέχει JavaScript. Τπό 

εξέλιξη βρίσκεται έκδοση του περιβάλλοντος προσαρμοσμένη στις ιδιαιτερότητες των φορητών 

συσκευών, όπως είναι τα κινητά τηλέφωνα. Ένα ιδιαίτερα σημαντικό στοιχείο του OTP είναι η ύπαρξη 

RESTful API, η οποία δίνει την δυνατότητα για ευκολη δημιουργία ποικίλων εφαρμογών, όπως π.χ. 

περιβάλλοντων χρήστη, ή περιβάλλοντων για λειτουργία σε κεντρά εξυπηρέτησης, όπως π.χ. σε 

τηλεφωνικά κέντρα φορέων ΜΜΜ. 

΋σον αφορά τα δεδομένα του οδικού δικτύου για την δημιουργία των γράφων που δημιουργεί ο OTP, 

αυτά μπορούν να προέρχονται είτε από το OpenStreetMap Project, είτε από ESRI Shape Files. 

Τπάρχει επίσης η δυνατότητα χρησιμοποίησης στοιχείων υψομέτρου, από αρχεία NED, τα οποία 

αφορούν όμως μόνο τις USA. Σα δεδομένα για το δίκτυο των ΜΜΜ πρέπει να ακολουθούν το 

πρώτυπο GTFS (General Transit Feed Specification), το οποίο είναι το de facto πρότυπο που έχει 

καθιερωθεί από την Google. 

΢τον παρακάτω πίνακα εμφανίζονται οι εκτιμήσεις για τον απαιτούμενο υπολογιστικό εξοπλισμό 

ανάλογα με τον φόρτο και το μέγεθος της περιοχής εξυπηρέτησης. 

1000 τετραγωνικά μίλια) 

4GB RAM, 1 Core 16GB RAM, 1 Core 

4GB RAM, 2+ Cores 16GB RAM, 4+ Cores 

Πίνακας 1: Εκτιμήσεις απαιτήσεων του OTP σε υπολογιστικό εξοπλισμό. 

127


6.1.17 Σα Σμήματα Που Αποτελούν τον Open Trip Planner. 

Ο OTP αποτελείται στην πλήρη εκδοχή του, όπως αναπτύσσεται, από διάφορα τμήματα. Υυσικά, 

είναι δυνατόν στις διάφορες υλοποιήσεις με βάση τον OTP να χρησιμοποιηθεί μέρος μόνο των 

τμημάτων του πακέτου, και μάλιστα τροποποιημένων, αφού κάτι τέτοιο είναι επιτρεπτό από την 

χορηγούμενη άδεια. Σα τμήματα αυτά είναι τα εξής: 

6.1.17.1 WEBAPP: 

Πρόκειται για το τμήμα του OpenTripPlanner το οποίο παρέχει το Web Interface στους χρήστες. Σο 

σημείο αυτό, δηλαδή τα απεικονιζόμενα στοιχεία και ο τρόπος λειτουργίας, είναι εξίσου σηματικό με 

το να παρέχονται επιτυχημένες προτάσεις διαδρομών. Ένα δύσχρηστο interface αποτρέπει τους 

χρήστες, και η κακή σχεδίασή του είναι ικανή να καταστρέψει την όποια υπόλοιπη καλή υλοποίηση 

της εφαρμογής. 

΢την παρούσα Περίπτωση δεν χρησιμοποιήθηκε τελικά το user interface του OpenTripPlanner, 

παρόλο που αρχικά είχαν γίνει διάφορες εργασίες και μία υλοποίηση με βάση αυτό, αλλά 

δημιουργήθηκε ένα νέο με χρήση του Adobe Flex, το οποίο δίνει δυνατότητα εύκολης αξιοποίησης 

των API της Google, κι επιπλέον ένα πολύ πιο καλό οπτικά αποτέλεσμα. Έτσι, στο τμήμα αυτό γίνεται 

μια σύντομη μόνο αναφορά. 

΢την παρακάτω εικόνα φαίνεται το interface από την εφαρμογή στην Granada, ως παράδειγμα μιας 

τυπικής εφαρμογής. 

128


Εικόνα 42: To User Interface της εφαρμογής του OpenTripPlanner στην Granada. Η οθόνη επιλογής 

των παραμέτρων διαδρομής. 

Σο κύριο στοιχείο είναι ο χάρτης OpenStreetMap, ο οποίος απεικονίζεται με χρήση των OpenLayers, 

με τα συνήθη χειριστήρια (μετακίνηση και αλλαγή κλίμακας). ΢τα αριστερά υπάρχει ένα accordion, 

στο οποίο το ένα panel περιέχει τις επιλογές (ή τις απαντήσεις), και το άλλο panel προορίζεται να 

περιέχει κάποια στοιχεία copyright και όρων χρήσης. 

Εικόνα 43: Οι επιλογές στο τυπικό UI του OTP, από την εφαρμογή στην Grenada. 

129


Παρατηρείται ότι το panel εισαγωγής στοιχείων έχει δύο πεδία για την επιλογή προέλευσης και 

προορισμού (η επιλογή των οποίων μπορεί να γίνει και με click στον χάρτη), ένα κουμπί για την 

δυνατότητα εναλλαγή τους, την επιλογή για Άφιξη ή Αναχώρηση την χρονική στιγμή που ορίζεται 

(σαν DropDownList), την επιλογή ημερομηνίας από ένα calendar, και την επιλογή ώρας από ένα 

textbox με stepper για πάνω-κάτω. 

Οι υπόλοιπες επιλογές αφορούν τον τρόπο μετακίνησης, την επιθυμητή βελτιστοποίηση, το μέγιστο 

μήκος διαδρομής πεζή, και το αν απαιτείται η πρόσβαση από αναπηρικό αμαξίδιο. ΋λες αυτές οι 

επιλογές γίνονται από αντίστοιχα DropDownLists. 

Αφού ο χρήστης εισάγει τα στοιχεία και κάνει τις επιλογές που θέλει, μετά από σύντομη αναμονή 

εμφανίζεται η οθόνη αποτελεσμάτων. 

Εικόνα 45: Η οθόνη αποτελεσμάτων στο τυπικό UI 

του OTP, από την εφαρμογή στην Grenada. 

΢την οθόνη αποτελεσμάτων, ο χάρτης μετατίθεται, 

κεντράρεται, και αλλάζει η κλιμακά του, ώστε να 

απεικονίσει το σύνολο της διαδρομής. Η απεικόνιση 

γίνεται με μικρά σύμβολο που αναπαριστούν το μέσο 

κάθε τμήματος της διαδρομής, και με μία γραμμή 

για την διαδρομή μέσα στην πόλη. Μέσα στο panel 

των επιλογών στα αριστερά, έχει προστεθεί ένα 

Εικόνα 44: Σο tab με την λίστα 

αποτελεσμάτων για την πρόταση ταξιδίου. 

130


επιπλέον tab, κάτω από το οποίο παρέχονται τα τμήματα του προτεινόμενου ταξιδίου, και 

περιεχόμενο σε κάθε ένα από αυτά ανάλογα με το μέσο. ΢το τέλος της λίστας παρέχονται 

συγκεντρωτικά στοιχεία για την πρόταση, δηλαδή ο χρόνος διαδρομής και η απόσταση που πρέπει 

να διανυθεί, ενώ στο πάνω μέρος αναφέρεται ο αριθμός των μετεπιβιβάσεων που απαιτούνται. 

΢το τέλος υπάρχουν κάποιες επιλογές για τα επόμενα βήματα, οι οποίες είναι η εναλλαγή αφετηρίας- 

τερματισμού, η επεξεργασία των επιλογών, η εκτύπωση, και η εμφάνιση ενός συνδέσμου για το 

αποτέλεσμα. Η λειτουργία της εκτύπωσης δεν είναι ακόμη υλοποιημένη, κι ετσί απλά ανοίγει ένα νέο 

παράθυρο στον browser, επαναλαμβάνοντας τα αποτελέσματα. Ο σύνδεσμος είναι το HTTP URL 

Request στην εφαρμογή για τις συγκεκριμένες επιλογές, αλλά παρέχονται HTTP URL requests για τις 

ίδιες επιλογές και για άλλα site που παρέχουν καθοδήγηση πεζή, όπως αυτό της Google. 

΋λο το UI βασίζεται σε JavaScript, OpenLayers, και τα EXT widgets, όπως επίσης σε css για την 

μορφοποίηση. ΢τη συνέχεια δίνονται ενδεικτικά τα αρχεία που αποτελούν το module, το οποίο κι 

αυτό παρέχεται από τον Apache Tomcat server. 

6.1.17.2 GRAPH-BUILDER: 

Πρόκειται για το module το οποίο δημιουργεί το αρχείο γράφου, παίρνοντας σαν δεδομένo εισόδου 

για το σύστημα συγκοινωνιώn ένα αρχείο GT Feed. Σα στοιχεία του οδικού δικτύου μπορούν να 

εισαχθούν είτε ως στοιχεία OSM, είτε ως Shape Files. To module έχει την δυνατότητα να κατεβάζει 

μόνο του τα στοιχεία OSM που αντιστοιχούν στην περιοχή που ορίζεται από το δίκτυο συγκοινωνιών, 

αρκεί να του δοθεί η διεύθυνση κάποιου σχετικού server. Επιπλέον, είναι δυνατόν να συμπεριληφούν 

στα δεδομένα εισόδου υψομετρικά στοιχεία των USA σε μορφή NED, τα οποία αφορούν την 

καθοδήγηση για διαδρομές με ποδήλατο. 

131

6.1.17.3 GUI: 


Πρόκειται για module το οποίο επιτρέπει την θέαση/οπτικοποίηση ενός Γράφου, με την εμφάνιση 

διαφόρων data και metadata ανάλογα με τις επιλεγμένες κάθε φορά ακμές, τους κόμβους (στάσεις), 

ή τις διαδρομές. 

Εικόνα 46: Ο Γράφος της Εφαρμογής στο Κέντρο της Αθήνας όπως απεικονίζεται στο module GUI 

του OTP. Οι κίτρινες γραμμές αντιστοιχούν σε δρομολόγια των ΜΜΜ, ενώ οι γαλάζιες στο οδικό 

δίκτυο. 

6.1.17.4 ROUTING: 

Πρόκειται για το module που είναι η καρδιά του συστήματος, καθώς είναι η μηχανή για την εύρεση 

των ταξιδιών προς πρόταση. Φρησιμοποιώντας contraction hierarchies και τον αλγόριθμο Α*, 

αναζητά στον Γράφο τα ταξίδια με βάση τους περιορισμούς και τις άλλες παραμέτρους που του 

δίνονται. Οι παράμετροι αφορούν την ημερομηνία και ώρα, τα επιθυμητά μέσα μετακίνησης, την 

μέγιστη επιθυμητή απόσταση περπατήματος, τον τρόπο βελτιστοποίησης (πιο γρήγορη διαδρομή, με 

τις λιγότερες μετεπιβιβάσεις, ασφαλέστερη διαδρομή), όπως επίσης το αν η ώρα αφορά την 

αναχώρηση ή την άφιξη. 

132


Επιπλέον παραμετροποιήσεις, που δεν γίνονται από τον χρήστη, αφορούν π.χ. την ταχύτητα 

περπατήματος, το κάτα πόσο πιο επιθυμητή είναι η αναμονή ενός ΜΜΜ από το περπάτημα, ή ποιές 

είναι οι ποινές-βάρη για τις μετεπιβιβάσεις. Οι παράμετροι αυτές ρυθμίστηκαν για την παρούσα 

εφαρμογή με βάση την εμπειρική αξιολόγηση των αποτελεσμάτων σε διάφορες δοκιμές. 

6.1.17.5 UTILS: 

Πρόκειται για ένα πολύ μικρό module προς το παρόν, το οποίο δημιουργεί τα αλφαριθμητικά strings 

κατά base64 για την οπτικοποίηση των διαδρομών. Είναι δηλαδή ένας polyline encoder. 

6.1.17.6 API-WEBAPP: 

Ρρόκειται για το API το οποίο παρζχει τθν ςφνδεςθ του OTP με τθν όποια εφαρμογι 

δθμιουργίασ ερωτθμάτων και διαχείριςθσ των αποτελεςμάτων. Ρρόκειται για module το 

οποίο γίνεται ορατό μζςω του Apache Tomcat Server. Δεν γίνεται εκτενζςτερθ περιγραφι 

ςτο ςθμείο αυτό του κειμζνου, κακϊσ υπάρχει λεπτομερισ περιγραφι ςτθν 6.4.5. 

6.1.17.7 API-EXTENDED: 

Πρόκειται για ένα πρόσθετο API, το οποίο λειτουργεί ως proxy ανάμεσα στην web εφαρμογή και τον 

Geoserver. Η λειτουργία του είναι να παρουσιάζονται πάνω στον χάρτη πρόσθετα στοιχεία για το 

δίκτυο ΜΜΜ, όπως οι στάσεις, οι γραμμές, και τα επόμενα δρομολόγια από κάθε στάση. ΢την 

παρούσα Εφαρμογή δεν χρησιμοποιήθηκε καθόλου, αφού ως υπόβαθρο χρησιμοποιήθηκε το Google 

Maps, το οποίο δεν λειτουργεί με openlayers. Ακόμη όμως κι αν δεν είχε συμβεί αυτό, θα ήταν πολύ 

δύσκολο να χρησιμοποιηθεί αυτή η πρόσθετη λειτουργία του OpenTripPlanner, αφού: 

Σο δίκτυο ΜΜΜ της Αθήνας είναι αρκετά μεγάλο, συνεπώς θα ήταν ιδιαίτερα μεγάλος 

φόρτος η μεταφορά των δεδομένων μέσω Internet και η απεικόνισή τους από τα 

openlayers. Κάτι τέτοιο θα ήταν πρακτικά εφικτό μόνο αν περιορίζονταν τα στοιχεία, 

όπως π.χ. να απεικονίζονταν μόνο οι γραμμές metro. 

133


Σο API απαιτεί να έχουν οριστεί οι διαδρομές ως shapes μέσα στο GT Feed (αναλύεται 

σε άλλο σημείο). ΋μως αυτό δεν θα μπορούσε να γίνει, για το σύνολο των γραμμών 

τουλάχιστον, καθώς δεν υπάρχουν διαθέσιμα σχετικά στοιχεία. Σα στοιχεία του ΟΑ΢Α 

περιέχουν την αλληλουχία των στάσεων μιας γραμμής με τις συντεταγμένες τους, κι 

έτσι μπορεί να γίνει χονδρική απεικόνιση με γραμμές που να συνδέουν τις στάσεις 

μεταξύ τους. ΋μως, δεν είναι εφικτή η απεικόνιση των γραμμών με λεπτομέρεια πάνω 

στο οδικό δίκτυο, αφού δεν είναι καταγεγραμμένη σε αξιοποίησιμη μορφή η σχετική 

πληροφορία. 

Σο API Extended παρέχεται κι αυτό μέσω του Apache Tomcat. Επειδή δεν χρησιμοποιήθηκε στην 

παρούσα εφαρμογή, δεν γίνεται κάποια περαιτέρω περιγραφή. 

6.2 Δομή ΢υστήματος. 

Σο σύστημα που αφορά την Εφαρμογή που υλοποιήθηκε είναι βασισμένο στη λογική Client-Server. 

Κατά αυτήν, υπάρχει ένα κομμάτι που εκτελείται στον υπολογιστή (ή άλλη συσκευή του χρήστη) και 

το οποίο επικοινωνεί με τον ή τους servers για την υποστήριξή του. Έτσι, το client κομμάτι μπορεί να 

δέχεται δεδομένα ως απάντηση σε σχετικές αιτήσεις που κάνει, ή να στέλνει στοιχεία στον server για 

την επεξεργασία τους από αυτόν και την επιστροφή της απάντησης. Σο μεγάλο μειονέκτημα της 

αρχιτεκτονικής είναι, αφενός η διαρκής διακίνηση δεδομένων, αφετέρου και κυρίως όμως, πως σε 

περίπτωση βλάβης κάποιου server, οι clients μένουν σχεδόν χωρίς καμία δυνατότητα λειτουργίας 

τους. 

Client 

Διάγραμμα 4: Απεικόνιση της Αρχιτεκτονικής Client-Server, με έναν ή περισσότερους Servers, οι 

οποίοι ενδέχεται να επικοινωνούν άμεσα μεταξύ τους. 

Server 

Server 2 

134


6.3 Λειτουργίες Φρήστη. 

΢το σημείο αυτό του κειμένου γίνεται μία παρουσίαση των λειτουργιών που παρέχονται στον χρήστη 

από το σχετικό client κομμάτι. Με αυτόν τον τρόπο ο αναγνώστης θα μπορεί να έχει εικόνα για το σε 

τι αναφέρεται στην τεχνική περιγραφή που ακολουθεί. 

6.3.1 Γενικά Για την Εφαρμογή Φρήστη. 

Σόσο οι αλγόριθμοι για το routing, όσο και τα δεδομένα που χρησιμοποιούνται σε μία τέτοια 

Εφαρμογή, είναι πολύ σημαντικά ώστε να παράγονται έγκυρα και χρήσιμα αποτελέσματα. ΋μως 

εξίσου σημαντικό είναι και το περιβάλλον χρήστη, το τμήμα δηλαδή της εφαρμογής που δίνει στον 

χρήστη την δυνατότητα να αναζητήσει αυτό που θέλει, και να πάρει το αποτέλεσμα της αναζήτησης 

με έναν τρόπο ώστε να μπορεί να το αξιοποίησει άμεσα και αποτελεσματικά. 

΢ήμερα όλα τα αντίστοιχα περιβάλλοντα τείνουν να είναι διαθέσιμα μέσω World Wide Web, καθώς 

με αυτόν τον τρόπο υπάρχουν μία σειρά από πλεονεκτήματα, όπως αυτά αναφέρονται στην 

Παράγραφο 4.3. 

Για την ανάπτυξη της εφαρμογής που περιγράφεται στην παρούσα, αρχικά χρησιμοποιήθηκε η 

σχετική εφαρμογή που έχει αναπτυχθεί στα πλαίσια του Open Trip Planner, με διάφορες βέβαια 

τροποποιήσεις, τόσο στην λειτουργία, όσο και στην εμφάνιση. Σο σημαντικότερο πρόβλημα που 

υπήρχε ήταν η χρησιμοποίηση του OSM ως χάρτη απεικόνισης, ο οποίος όμως παρουσιάζει προς το 

παρόν αρκετές ελλείψεις όσον αφορά την περιοχή της Αθήνας. Αν και υπήρχε η δυνατότητα για 

χρήση του Google Maps μαζί με το OpenLayers, μέσω ενός μικρού λογισμικού που λειτουργούσε ως 

ενδιάμεσος WMS server, η λύση αυτή, η οποία δοκιμάστηκε επιτυχώς, είχε εν τούτοις δύο σημαντικά 

μειονεκτήματα: 

Καταρχάς, υπήρχε η ανάγκη λειτουργίας ενός ακόμη server, ο οποίος θα 

δημιουργούσε σημαντικότατο υπολογιστικό φόρτο, και πολύ περισσότερο, φόρτο 

διακίνησης δεδομένων μέσω του δικτύου. Ο λόγος είναι βέβαια ότι όλη η διακίνηση 

δεδομένων για τις απεινονίσεις χάρτη θα είχαν ως ενδιάμεσο τον server αυτόν, και 

δεν θα υπήρχε απευθείας κατέβασμα από τους servers της Google. 

135


Κατά δεύτερον, η χρήση του Google Maps μέσω ενδιάμεσου server, επί της ουσίας 

συνιστούσε παραβίαση των όρων σύμφωνα με τους οποίους η Google παρέχει την 

υπηρεσία δωρεάν, οπότε δεν θα υπήρχε η δυνατότητα η εφαρμογή να έχει 

πραγματική λειτουργία. 

Ούτως ή άλλως ήταν αναγκαία η χρήση των υπηρεσιών της Google για την λειτουργία του 

geocoding, καθώς δεν υπήρχε άμεση δυνατότητα χρήσης κάποιος άλλης υπηρεσίας με αντίστοιχα 

καλά αποτελέσματα. Αλλά, και η καθοδήγηση με αναφορά στα ονόματα οδών έπρεπε να γίνει με 

χρήση του Google Directions, καθώς από τον χάρτη OSM έλλειπαν τα περισσότερα από τα ονόματα 

των οδών του Λεκανοπεδίου Αττικής. 

Οι λύσεις λοιπόν που υπήρχαν για να ξεπεραστούν τα παραπάνω προβλήματα, ήταν οι εξής: 

Είτε να δημιουργηθεί ένα τελείως νέο χαρτογραφικό υπόβαθρο, με χρήση 

κατάλληλων διανυσματικών στοιχείων για όλες τις εργασίες routing. 

Είτε να ενημερωθούν τα στοιχεία του OSM για την περιοχή ενδιαφέροντος, μέ 

πιθανή χρησιμοποίηση στοιχείων από άλλες πηγές, 

Είτε να δημιουργηθεί μία τελείως καινούρια εφαρμογή, η οποία να χρησιμοποιεί ως 

χάρτη αυτόν του Google Maps. 

Η πρώτη από τις τρεις λύσεις απαιτούσε πάρα πολύ μεγάλη ποσότητα εργασίας, καθώς απαιτούσε 

την συλλογή, επεξεργασία, και διαχείριση των στοιχείων για ολόκληρη την περιοχή, με πιθανότες τις 

σημαντικές απαιτούμενες τροποποιήσεις και στην ίδια την εφαρμογή. Σο πλεονέκτημα θα ήταν η 

χρησιμοποίηση ενός χάρτη που θα μπορούσε να διαμορφωθεί ελεύθερα, και με πιθανή χρησιμότητα 

και σε άλλες εφαρμογές. 

Η δεύτερη λύση απαιτούσε και αυτή πολύ μεγάλη ποσότητα εργασίας, καθώς θα έπρεπε να 

ελεγχθούν κι ενημερωθούν τα στοιχεία του OSM στο σύνολο της περιοχής. Η ενημέρωση αυτή 

πρακτικά μπορούσε να γίνει μόνο με επίθεση των στοιχείων από άλλες πηγές, μέσα από διάφορα 

στάδια επεξεργασίας, μετασχηματισμών, κτλ.. ΋μως ήταν σχεδόν αδύνατον να βρέθουν τέτοια 

στοιχεία που να ήταν αξιόπιστα και να μπορούν να χρησιμοποιθούν ελεύθερα, πολύ περισσότερο το 

να υπάρχει εξασφαλισμένη ενημέρωσή τους, κάτι το οποίο ισχύει φυσικά ως βασικό μειονέκτημα και 

για την πρώτη λύση. 

Η τρίτη από τις λύσεις ήταν εμφανώς η καλύτερη, καθώς έδινε την δυνατότητα ανάπτυξης μιας 

καινούριας εφαρμογής, χωρίς να απαιτείται η χρονοβόρα, εργοβόρα, αλλά ίσως και χρηματοβόρα, 

ενασχόληση με τα στοιχεία του χάρτη. Η καινούρια εφαρμογή θα μπορούσε να χτιστεί ελεύθερα, 

136


ανεξάρτητα από το ότι ήδη είχε δημιουργηθεί για τον OpenTripPlanner, δίνοντας εξαρχής την 

δυνατότητα προσαρμογής στην ιδιαίτερη λειτουργία για την συγκεκριμένη Τπηρεσία, είτε άμεσα, 

όσον αφορά δηλαδή το λειτουργικό κομμάτι που σχετίζεται με τον χρήστη, είτε έμμεσα, όσον αφορά 

δηλαδή το κομμάτι που σχετίζεται με την διαχείριση των αποτελεσμάτων του routing σε δεύτερο 

στάδιο, χωρίς επιπλέον τροποποιήσεις του ίδιου του Open Trip Planner. 

6.3.2 Λειτουργική Ροή της Εφαρμογής Φρήστη. 

Η διαδικασία που απαιτείται να κάνει ο χρήστης από την στιγμή της εισόδου του σε μία ανάλογη 

εφαρμογή, μέχρι την στιγμή της εξόδου του από αυτήν έχοντας πάρει αυτό που ζητούσε, είναι σε 

μεγάλο βαθμό συγκεκριμενοποιημένη από την φύση του αντικειμένου. Αυτό που καταρχάς ζητείται 

είναι η παραμετροποίηση του ερωτήματος, η θέση του, η λήψη των αποτελεσμάτων, και ο 

παραπέρα χειρισμός τους, όπως π.χ. η εκτύπωση. 

΢ε μορφή διαγράμματος, η βασική αυτή λειτουργική ροή έχει ως εξής: 

Αρχικοποίθςθ 



Διάγραμμα 5: Λειτουργική Ροή της Εφαρμογής Φρήστη. 

Κατά την αρχικοποίηση γίνεται η δημιουργία του περιβάλλοντος της Εφαρμογής και δίνονται οι 

προκαθορισμένες τιμές στις διάφορες παραμέτρους. 

Βοικεια / Πλθροφορίεσ / Επικοινωνία 

Θζςθ Ερωτιματοσ Λιψθ Απάντθςθσ 

Διαχείριςθ 

Απάντθςθσ 

Κατά την Παραμετροποίηση Ερωτήματος ο Φρήστης καλείται να παραμετροποιήσει το ερώτημά του, 

να θέσει δηλαδή την προέλευση και τον προορισμό, τα επιθυμητά μέσα για να κάνει την διαδρομή, 

137


τον τρόπο βελτιστοποίησης των αποτελεσμάτων, την μέγιστη επιθυμητή απόσταση διαδρομής πεζή, 

κι επίσης την στιγμή που επιθυμεί να ξεκινήσει το ταξίδι, ή να αφιχθεί στον προορισμό του. 

Κατά την Θέση Ερωτήματος η Εφαρμογή διαμορφώνει ανάλογα τα ερωτήματα κι επικοινωνεί με 

τους διάφορους Servers, έτσι ώστε να λάβει την απάντηση σχετικά με το επιθυμητό ταξίδι. Πρόκειται 

για ένα στάδιο στο οποίο δεν υπάρχει παρέμβαση του Φρήστη. 

΋μοια δεν υπάρχει παρέμβαση του Φρήστη και στο επόμενο στάδιο, κατά το οποίο γίνεται η λήψη 

της απάντησης από τους Servers. ΢την πραγματικότητα τα δύο αυτά στάδια, της θέσης του 

ερωτήματος και της λήψης της απάντησης, είναι άμεσα συνδεδεμένα μεταξύ τους. Κι αυτό γιατί 

κατά την λήψη της απάντησης π.χ. από το Route Engine υπάρχει συνεχής νέα υποβολή 

υποερωτημάτων, τα οποία αφορούν τις εναλλακτικές Γραμμές για έναν κλάδο μίας πρότασης 

ταξιδίου, ή την διαδρομή πεζή που χρειάζεται να πραγματοποιηθεί από και προς τις στάσεις ΜΜΜ. 

΢τη διαδικασία της λήψης συμπεριλαμβάνεται και η ενημέρωση των στοιχείων της Εφαρμογής με τα 

δεδομένα που παρέχονται από τους Servers, αλλά κι από αυτά που η ίδια η Εφαρμογή παρέχει 

έπειτα από μετεπεξεργασία, όπως είναι π.χ. η τιμή του απαιτούμενου εισιτηρίου. 

Κατά το στάδιο της διαχείρισης απάντησης ο Φρήστης μπορεί να επιλέγει να βλέπει κάθε φορά την 

μία από τις εώς και τρεις παρεχόμενες προτάσεις ταξιδίου, όπως επίσης μπορεί να επιλέξει να κάνει 

ένα νέο ερώτημα, να διαμορφώσει διαφορετικά αυτό που ήδη έχει υποβάλλει, ή τέλος να εκτυπώσει 

κάθε μία από τις παρεχόμενες προτάσεις. 

Παράλληλα στα προηγούμενα στάδια, υπάρχουν και τα στάδια που αφορούν την παροχή βοήθειας 

για την χρήση, την παροχή πληροφοριών σχετικά με την υπηρεσία, πληροφοριών σχετικά με τα 

ΜΜΜ στην Αθήνα, την διαδρομή από/προς τον Αερολιμένα, κι επίσης την δυνατότητα επικοινωνίας 

του Φρήστη με τους λειτουργούς της Τπηρεσίας, π.χ. για την υποβολή προτάσεων βελτίωσης. 

6.3.3 Λειτουργική Ανάλυση της Εφαρμογής Φρήστη. 

6.3.3.1 Εκτέλεση Εφαρμογής Φρήστη και Προκαθορισμός Επιλογών. 

Η Εφαρμογή Φρήστη είναι μία Flash εφαρμογή, η οποία μπορεί να εκτελείται μέσα σε έναν browser, 

ή ανεξάρτητα, ως desktop εφαρμογή εντός του Adobe Air. ΢την περίπτωση του browser η εφαρμογή 

είναι «τοποθετημένη» εντός ενός HTML αρχείου. Σο αρχείο αυτό κάνει έλεγχο για την ύπαρξη της 

κατάλληλης έκδοσης του Flash Player, και πρυτρέπει για την εγκατάστασή της αν αυτό απαιτείται. 

138


Επίσης, σε συνδυασμό με την σχετική υπηρεσία StatsCounter που παρέχεται δωρεάν, στέλνει σε 

αυτήν διάφορα στατιστικά στοιχεία (ημερομημία, ώρα, περιοχή, IP Address από το οποίο προήλθε η 

επίσκεψη,το λειτουργικό, τον Web Browser, την ανάλυση οθόνης κτλ του Φρήστη. ΢ε καμία 

περίπτωση δεν αποστέλλονται προσωπικά στοιχεία, ενώ η χρήση της εν λόγω υπηρεσίας είναι 

ενδεικτική, καθώς διατίθενται δωρεάν πλήθος άλλων. 

Η μητρική HTML σελίδα προωθεί προς την Flash εφαρμογή και τις πιθανές σχετικές 

προκαθορισμένες τιμές στην παραμετροποίηση ερωτήματος, αν το link προς την Εφαρμογή 

προέρχεται από κάποιο site που προωθεί σε αυτήν για την εξυπηρέτηση μίας εγκατάστασης ή ενός 

γεγονότος, όπως π.χ. την πρόσβαση με ΜΜΜ σε ένα συνέδριο. 

6.3.3.2 Αρχικοποίηση. 

Με την έναρξη της Εφαρμογής παργματοποιείται η αρχικοποίηση, κατά την οποία γίνεται η 

δημιουργία του περιβάλλοντος Φρήστη, και δίνονται οι αρχικές τιμές. Κατά το στάδιο αυτό 

εμφανίζεται μία εισαγωγική Splash εικόνα στον Φρήστη, με περιεχόμενο και τις πιθανόν υπάρχουσες 

σημαντικές πληροφορίες, όπως είναι π.χ. για παρατηρούμενες ή προβλεπόμενες δυσλειτουργίες. 

139


Εικόνα 47: Η αρχική εικόνα που εμφανίζεται στον Φρήστη κατά την έναρξη της Εφαρμογής. Εκτός 

του τίτλου, περιέχονται μηνύματα σχετικά με σημαντικά θέματα άμεσου ενδιαφέροντος, όπως π.χ. 

μία προγραμματισμένη απεργία. 

Πατώντας στο «CONTINUE» εμφανίζεται στον Φρήστη η κύρια οθόνη της Εφαρμογής, στην λειτουργία 

παραμετροποίησης του ερωτήματος. 

140


6.3.3.3 Γενική Διάταξη. 

Εικόνα 48: Η οθόνη για την παραμετροποίηση του Ερωτήματος, όπως αυτή πρωτοεμφανίζεται στον 

Φρήστη. 

Η παραπάνω εικόνα εμφανίζει το γενικό layout της εφαρμογής σε μία μεγάλη οθόνη, σε state 

Options, χωρίς να έχει υπάρξει προκαθορισμός επιλογών. ΢τα γενικά στοιχεία διακρίνονται τα εξής: 

Κύριο στοιχείο της οθόνης είναι ο Φάρτης Google, ο οποίος αρχικά βρίσκεται σε εμφάνιση Map. Η 

εμφάνιση αυτή μπορεί να αλλάξει, πατώντας ένα άλλο πλήκτρο πάνω δεξιά, το οποίο αντιστοιχεί σε 

μία άλλη εμφάνιση: «Satellite» για δορυφορική εικόνα, «Hybrid» για συνδυασμό δορυφορικής εικόνας 

και χάρτη, και τέλος «Terrain», με απόδοση της μορφής του αναγλύφου. Οι περισσότες από τις 

μορφές αυτές εμφάνισης είναι ήδη ευρέως γνωστές από άλλες εφαρμογές, και για αυτόν τον λόγο 

δεν γίνεται εκτενέστερη αναφορά. ΋μοια δεν γίνεται και για το slider κλίμακας, ή για τον γενικότερο 

χειρισμό του χάρτη. Ο εμφανιζόμενος χάρτης έχει τα αναγραφόμενα στοιχεία τόσο στην Ελληνική, 

όσο και στην Αγγλική γλώσσα, ενώ υπάρχει μάλιστα η δυνατότητα 3D απεικόνισης μέσα από το Flex, 

απεικόνιση εντυπωσιακή μεν, που μάλλον όμως θα μπέρδευε κάποιους από τους χρήστες. 

141


Η Google επιτρέπει ελεύθερα την χρήση του χάρτη, χωρίς περιορισμούς στις εμφανίσεις που γίνονται 

ημερησίως. Σο μόνο που απαιτείται είναι η εφαρμογή που τον χρησιμοποιεί να διατίθεται δωρεάν 

στο ευρύ κοινό, και η απόκτηση ενός αλφαριθμητικού κλειδιού για το domain ή subdomain 

φιλοξενίας. 

6.3.3.4 Φάρτης Δικτύου Metro. 

΢την κάτω δεξιά γωνία του χάρτη υπάρχει ένα κουμπί που λειτουργεί ως διακόπτης δύο θέσεων 

(toggle button). Με την ενεργοποίηση του γίνεται οπτικοποίηση από την Εφαρμογή πάνω στον χάρτη 

του βασικού δικτύου ΜΜΜ της Αθήνας, το οποίο αποτελείται από τις Γραμμές Μετρό και τους 

σχετικούς ΢ταθμούς. Πηγαίνοντας τον κέρσορα πάνω σε έναν σταθμό, εμφανίζεται ένα tooltip με την 

ονομασία του. 

Εικόνα 49: Οπτικοποίηση του δικτύου Metro όταν είναι ενεργοποιημένο το σχετικό Toggle Button 

κάτω δεξιά στον Φάρτη. 

Σα σύμβολα των σταθμών είναι ενεργά αντικείμενα στον Φάρτη, καθώς με απλό click πάνω τους 

ανοίγει ένα InfoWindow το οποίο επιτρέπει την επιλογή κάθε σταθμού ως προέλευση ή προορισμό. 

Αυτό είναι χρήσιμο για κάποιον που ενδιαφέρεται απλώς να βρεθεί σε έναν συγκεκριμένο σταθμό 

metro, γνωρίζοντας τα υπόλοιπα τμήματα της διαδρομής που θέλει να κάνει, καθώς οι σταθμοί 

αποτελούν ούτως ή άλλως σημαντικά σημεία αναφοράς τής ευρύτερης περιοχής τους. 

142


Οπτικοποίηση του συνολικού δικτύου ΜΜΜ είναι πρακτικώς αδύνατη για τους εξής λόγους: 

Θα υπήρχε υπερβολικά μεγάλος αριθμός αντικειμένων (΢τάσεις και Γραμμές) πάνω 

στον χάρτη, γεγονός που θα τον έκανε αργό στις ανανεώσεις, και θα απαιτούσε 

μεγάλη επεξεργαστική ισχύ. 

Ο υπερβολικά μεγάλος αυτός αριθμός αντικειμένων θα δημιουργούσε ανάλογα 

μεγάλη κίνηση στο δίκτυο του internet και στους server της εφαρμογής για την 

διακίνηση των σχετικών data, με αποτέλεσμα το αυξημένο κόστος και την πιο αργή 

λειτουργία. 

Αν και για τους προηγούμενους λόγους μπορεί να επιτευχθεί περιορισμός των 

προβλημάτων, όπως π.χ. με το κατέβασμα δεδομένων και την απεικόνιση τους 

ιεραρχικά και με βάση την κλίμακα και την περιοχή απεικόνισης, εν τούτοις δεν 

υπάρχει μεγάλη ωφέλεια από την απεικόνιση προς τον χρήστη ενός μεγάλου και 

πολύπλοκου δικτύου ΜΜΜ. Ιδιαίτερα μάλιστα όταν αυτός είναι επισκέπτης της 

πόλης, οπότε κατά κανόνα δεν έχει και δεν θέλει να μάθει την λεπτομερή δομή και 

μορφή του δικτύου. Λόγω μικρού όγκου, τα σχετικά στοιχεία της απεικόνισης του 

δικτύου metro περιέχονται εντός του αρχείου της Εφαρμογής Φρήστη. 

6.3.3.5 Πληροφορίες ΢χετικά Με Σα ΜΜΜ ΢την Αθήνα, Σην Εξυπηρέτηση Σου 

Αερολιμένα, Και Σην Φρήση Σης Εφαρμογής. 

΢τα αριστερά της οθόνης βρίσκεται σε κατακόρυφη μορφή μία λεπτή στήλη. Αυτή περιέχει το 

λογότυπο της Εφαρμογής, τα λογότυπα αυτών που την παρέχουν, και μία σειρά από κουμπιά 

λειτουργιών. ΢τον ελεύθερο κάθε φορά χώρο θα μπορούσαν να προστεθούν κουμπιά επιπλέον 

λειτουργιών, ή πληροφορίες άμεσης θέασης, όπως: ‗Athens‘ Urban Transit Info Line 185‘. 

΢ε μία εμπορική λειτουργία, θα μπορούσαν να τοποθετούνται και στοιχεία όπως είναι π.χ. 

διαφημίσεις. 

Σα κουμπιά λειτουργιών είναι τα εξής αυτή την στιγμή: 

143


Εικόνα 50: Σα κουμπιά λειτουργιών στην αριστερή κατακόρυφη στήλη της Εφαρμογής. 

Σα κουμπιά «To/From Airport», «Transit in Athens», και «Help», δεν έχουν κάποιο ιδιαίτερο τεχνικό 

ενδιαφέρον, και γι‘ αυτό δεν αναλύονται περισσότερο. Με το πάτημά ενός από αυτά, ανοίγει ένα 

επιπλέον tab στον web browser, στο οποίο εμφανίζονται αντίστοιχα πληροφοριές στην Αγγλική 

γλώσσα για την μετακίνηση από/προς τον Αερολιμένα, την λειτουργία των ΜΜΜ στην Αθήνα (τιμές 

εισιτηρίων, χρήσιμα τηλέφωνα κτλ), και την χρήση της Εφαρμογής με εικόνες και παραδείγματα. Σο 

άνοιγμα πρόσθετων tabs αφενός επιτρέπει την χρήση απλής HTML, που όμως είναι η καταλληλότερη 

για την περίσταση, αφετέρου επιτρέπει την σχεδόν παράλληλη θέαση με την Εφαρμογή και την 

εύκολη εκτύπωση. 

144


6.3.3.6 Εμφάνιση Πληροφοριών Για Σην Εφαρμογή. 

Σο πλήκτρο «About» αλλάζει το state της Εφαρμογής στο ομώνυμο, όπου εμφανίζεται ένα modal 

παράθυρο με βασικές πληροφορίες σχετικά με αυτήν, και με κουμπιά-links προς διάφορα σχετικά 

sites. 

Εικόνα 51: Σο modal παράθυρο About της Εφαρμογής, με βασικές πληροφορίες σχετικά με αυτήν, 

κι επίσης με links προς διάφορα σχετικά sites. 

6.3.3.7 Επικοινωνία Με Σους Λειτουργούς Σης Τπηρεσίας. 

΋μοια, με πάτημα στο κουμπί «Contact» ενεργοποιείται το ομώνυνο state, από όπου υπάρχει η 

δυνατότητα να αποσταλεί email σε μία διεύθυνση ταχυδρομείου των λειτουργών της Τπηρεσίας. 

Σο email μπορεί να αποσταλεί μέσω του Mail Client του Φρήστη, όπου προσυμπληρώνεται η 

διεύθυνση παραλήπτη. Με αυτόν τον τρόπο ο Φρήστης στέλνει email με έναν τρόπο που του είναι 

145


οικείος, αφού χρησιμοποιεί το δικό του λογισμικό για ηλεκτρονικό ταχυδρομείο. Τπάρχουν βέβαια 

περιπτώσεις που αυτό μπορεί να μην λειτουργεί, ιδιαίτερα αν ο Φρήστης δεν χρησιμοποιεί εκείνη την 

στιγμή τον δικό του Τπολογιστή. Για τις περιπτώσεις αυτές, αναγράφεται και η διεύθυνση 

ηλεκτρονικού ταχυδρομείου στην οποία μπορεί να γίνει αποστολή του όποιου μηνύματος. 

Εικόνα 52: To modal παράθυρο Contact της Εφαρμογής, από το οποίο μπορεί να ενεργοποιηθεί ο 

Mail Client του Φρήστη, με προσυμπληρωμένη την διεύθυνση παραλήπτη. 

6.3.3.8 Παραμετροποίηση Ερωτήματος. 

΋πως έχει αναφερθεί, αμέσως μετά την εισαγωγική splash οθόνη, ο Φρήστης βλέπει το γενικό layout 

της Εφαρμογής, σε κατάσταση κατά την οποία μπορεί να γίνει η παραμετροποίηση του ερωτήματος 

που θέλει αυτός να υποβάλει. ΢την κατάσταση αυτή, το κύριο στοιχείο είναι ο Φάρτης, ενώ πάνω 

αριστερά εμφανίζεται ένα παράθυρο στο οποίο εμφανίζονται οι διάφορες παράμετροι. 

146


Εικόνα 53: Σο κύριο παράθυρο από όπου γίνεται η παραμετροποίηση από τον Φρήστη του 

ερωτήματος. 

Η επιλογή Προέλευσης και Προορισμού μπορεί να γίνεται με έναν από τους εξής τρόπους: 

Με geocoding μίας διεύθυνσης ή ενός ζεύγους συντεταγμένων. Σα στοιχεία 

εισάγονται στα αντίστοιχα text boxes κι έπειτα εμφανίζεται ένα επιπλέον παράθυρο 

στο οποίο υπάρχει η λίστα με τις εώς και δέκα καλύτερες απαντήσεις σύμφωνα με 

την Τπηρεσία Geocoding της Google. 

Πατώντας ο Φρήστης πάνω σε μία απάντηση, ο Φάρτης μετακινείται ώστε να 

κεντραριστεί στο σημείο που αντιστοιχεί η απάντηση, ενώ ένας Marker επισημαίνει 

καλύτερα το σημείο αυτό. Βλέποντας ότι η συγκεκριμένη απάντηση ταιριάζει σε 

αυτό που ψάχνει, ο Φρήστης μπορεί να την αποδεχθεί ως προέλευση ή προορισμό. 

Ο τρόπος αυτός επιλογής προέλευσης/προορισμού αναμένεται να είναι κι ο πλέον 

χρησιμοποιούμενος, αφού συνήθως έχει κάποιος την διεύθυνση για το μέρος από 

το οποίο φεύγει ή θέλει να φτάσει, όπως π.χ. την διεύθυνση ενός ξενοδοχείου. 

147


Εικόνα 54: Η λειτουργία Geocoding για την προέλευση. 

Με διπλό click πάνω στον Φάρτη. ΢το σημείο του click ανοίγει ένα InfoWindow, από 

το οποίο μπορεί κανείς να επιλέξει αν επιθυμεί το σημείο αυτό για προέλευση ή 

προορισμό. 

Εικόνα 55: Με διπλό click σε κάποιο σημείο του Φάρτη εμφανίζεται ένας Marker με ένα Info Window 

για την δηλωσή του σημείου ως προέλευση ή προορισμό. 

148


Με επιλογή από λίστα σημείων ενδιαφέροντος. Πατώντας πάνω στο κουμπί ‗POIs‘ 

που εμφανίζεται δίπλα στην διεύθυνση για την προέλευση ή τον προορισμό, ανοίγει 

ένα επιπλέον παράθυρο, από το οποίο μπορεί να γίνει επιλογή ενός σημείου για τον 

αντίστοιχο ρόλο. 

Η λίστα εμφανίζει τα διάφορα σημεία ενδιαφέροντος κατηγοριοποιημένα σε μορφή 

δένδρου. Πατώντας πάνω σε ένα από τα αντικείμενα της λίστας, ο Φάρτης 

κεντράρεται στο σημείο που αντιστοιχεί χωρικά στο αντικείμενο αυτό, κι ένας 

Marker επισημαίνει καλύτερα το σημείο αυτό. Βλέποντας ότι η συγκεκριμένη θέση 

ταιριάζει σε αυτό που ψάχνει, ο Φρήστης μπορεί να την αποδεχθεί. 

Εικόνα 56: Επιλογή ενός ΢ημείου Ενδιαφέροντος ως Προέλευση ή Προορισμό, από 

κατηγοριοποιημένη λίστα. 

Με επιλογή κάποιου ενεργού σημείου πάνω στον Φάρτη. Προς το παρόν τέτοια 

ενεργά σημεία είναι οι σταθμοί του Μετρό, όταν απεικονίζεται το σχετικό δίκτυο. 

Μέσα από ένα InfoWindow μπορεί ο Φρήστης να θέσει το σημείο ως προέλευση ή 

προορισμό. Μελλοντικά θα μπορούσαν να υπάρξουν ακόμη και τρισδιάστες 

αναπαραστάσεις χαρακτηριστικών κτηρίων, όπως π.χ. ο Παρθενώνας. 

149


Εικόνα 57: Επιλογή ενός Ενεργού ΢ημείο (΢ταθμός Μετρό) ως προέλευση ή προορισμό. 

Με σύρσιμο (dragging) πάνω στον Φάρτη ενός από τους Markers που επισημαίνουν την 

προέλευση ή τον προορισμό.΋ταν έχουν επιλεγεί, είτε η προέλευση, είτε ο προορισμός, τότε 

τα σημεία αυτά επισημαίνονται με έναν πράσινο κι έναν κόκκινο Marker αντίστοιχα. 

΢ύροντας έναν από τους Markers σε κάποια τοποθεσία, τότε αυτή επιλέγεται ως προέλευση 

ή προορισμός, κι ανάλογα ενημερώνεται το σχετικό πεδίο με τις ΢υντεταγμένες της 

τοποθεσίας. Πατώντας πάνω στο συμπληρωμένο πεδίο κειμένου ο Φρήστης, έχει την 

δυνατότητα να εμφανίζεται πλέον η διεύθυνση που αντιστοιχεί στις συγκεκριμένες 

συντεταγμένες. 

Εικόνα 58: Σα επιλεγμένα κάθε φορά σημεία προέλευσης και προορισμού επισημαίνονται με 

πράσινο και κόκκινο Marker αντίστοιχα, οι οποίοι είναι draggable. 

150


Εικόνα 59: Με σύρσιμο (dragging) του Marker της προέλευσης ή του προορισμού, επιλέγεται μία 

τοποθεσία από τον Φάρτη. Σα αντίστοιχα πεδία ενημερώνονται με τις συντεταγμένες της τοποθεσίας. 

Εικόνα 60: Αντικατάσταση της εμφάνισης των συντεταγμένων μιας τοποθεσίας, έπειτα από σύρσιμο 

του Marker σε αυτήν, από την διεύθυνση που τους αντιστοιχεί. 

Η ύπαρξη ενός σχετικού πλήκτρου («SWAP») επιτρέπει οποτεδήποτε την εναλλαγή της προέλευσης 

και του προορισμού. 

151


΢την παραμετροποίηση του ερωτήματος ο Φρήστης μπορεί να επιλέξει επίσης τα μέσα με τα οποία 

επιθυμεί να πραγματοποιήσει το ταξίδι του. ΢τις επιλογές για τα επιθυμητά μέσα πραγματοποίησης 

του ταξιδιού εμφανίζονται τα εξής: 

Εικόνα 61: Σο List Box με τις επιλογές των επιθυμητών Μέσων για την πραγματοποίηση του ταξιδίου. 

‗Using Any Mean‘: Δηλαδή το ταξίδι μπορεί να γίνει με οποιοδήποτε ΜΜΜ. Αυτή 

είναι και η default επιλογή. 

‗Using Trains‘: Σο ταξίδι μπορεί να γίνει μόνο με τρένα, όχι και με λεωφορεία 

δηλαδή. 

‗Using Buses‘: Σο ταξίδι μπορεί αντίστοιχα να γίνει μόνο με λεωφορεία, εξαιρώντας 

δηλαδή τα τρένα. 

‗Walking Only‘: Οπότε έτσι το ταξίδι μπορεί να γίνει μόνο πεζή. ΢ε όλες τις άλλες 

επιλογές συμπεριλαμβάνεται η διαδρομή πεζή, κάτι που είναι απαραίτητο για να 

υπάρξη απάντηση με την διαδρομή π.χ. μέχρι την πρώτη στάση, από την τελευταία 

στάση, ή ενδιάμεσα δύο στάσεων. 

Ο Φρήστης μπορεί επίσης να επιλέξει αν επιθυμεί την βελτιστοποίηση των απαντήσεων βάσει της 

συντομότερης άφιξης στον προορισμό, ή βάσει των λιγότερων μετεπιβιβάσεων, δηλαδή ‗As Soon As 

Possible‘ ή ‗With Fewest Transfers‘ αντίστοιχα. Default επιλογή είναι η πρώτη. 

Εικόνα 62: Οι επιλογές βελτιστοποίησης που παρέχονται στον Φρήστη. 

152


Μία άλλη δυνατότητα επιλογής που παρέχεται στον Φρήστη είναι της μέγιστης απόστασης που 

επιθυμεί να διανύσει πεζή. Οι δυνατές επιλογές είναι για 600 m, 1200 m, 2000 m, και ‗Doesn ‗t 

Matter‘, δηλαδή να αγνοείται αυτή η παράμετρος. Σα 600 m είναι η απόσταση στην οποία 

θεωρείται ότι πρέπει να βρίσκεται μία στάση metro, όμως ως default επιλογή τέθηκε η 1200m, ώστε 

να αποφεύγονται οι πολύ μικρές μετακινήσεις με ΜΜΜ για μία ή δύο στάσεις. Σο Routing Engine δεν 

χρησιμοποιεί δεσμευτικά την παραμετροποίηση αυτή, καθώς μπορεί να χαλαρώνει ανάλογα τον 

περιορισμό απόστασης, ώστε να προκύπτουν λύσεις. 

Εικόνα 63: Οι επιλογές για την μέγιστη απόσταση σε μέτρα που επιθυμεί ο Φρήστης να διανύσει πεζή. 

Σα τελευταία στοιχεία παραμετροποίησης του ερωτήματος αφορούν χρονικές παραμέτρους. Έτσι, ο 

Φρήστης επιλέγει μέσω δύο radio buttons αν ο χρόνος αφορά την εκκίνηση από την προέλευση ή την 

άφιξη στον προορισμό, την χρονική στιγμή, και την ημερομηνία. Η επιλογή της χρονικής στιγμής 

γίνεται μέσω ενός slider με στρογγυλοποιημένες τιμές ανά 5 λεπτά, ενώ της ημερομηνίας, μέσω ενός 

ημερολογίου. Σέλος, ένα κουμπί με την ένδειξη ‗NOW‘ επιτρέπει τον ορισμό της ώρας και της 

ημερομηνίας στις τρέχουσες τιμές. 

Εικόνα 64: Οι επιλογές για την ημερομηνία και την ώρα αναχώρησης ή άφιξης. 

153


6.3.3.9 Θέση Ερωτήματος & Λήψη Απαντήσης. 

Μετά την επιθυμητή παραμετροποίηση, ο Φρήστης πατώντας στο κουμπί «Plan My Journey!», 

ξεκινάει την διαδικασία για την εύρεση και παρουσίαση των προτάσεων ταξιδίου. Κατά την 

διαδικασία αυτή είναι ενεργοποιημένο η κατάσταση αναμονής, κατά το οποίο εμφανίζεται στον 

Φρήστη ένα πληροφοριακό παράθυρο με μία Progress Bar που είναι ενδεικτική της εξέλιξης. 

Εικόνα 65: ΢τιγμιότυπο από την οθόνη αναμονής καθόσο διαρκεί η αναζήτηση και επεξεργασία των 

προτάσεων ταξιδίου. 

΢το σημείο αυτό γίνονται και οι κύριες λειτουργίες της Εφαρμογής. 

6.3.3.10 Παρουσίαση Προτάσεων, 

΢την κατάσταση της οπτικοποίησης των Προτάσεων Σαξιδίου, εμφανίζεται μία κατακόρυφη στήλη 

στα αριστερά της οθόνης με τα λεκτικά αποτελέσματα, ενώ πάνω στον χάρτη γίνεται η αντίστοιχη 

οπτικοποίηση. Αρχικά εμφανίζεται η πρώτη Πρόταση, όμως ο Φρήστης μπορεί να επιλέξει σε ένα 

accordion όποια από τις εώς και τρεις Προτάσεις θέλει για να είναι η ενεργή. 

154


Εικόνα 66: Η Client Εφαρμογή σε κατάσταση παρουσίασης και διαχείρισης των Προτάσεων 

Σαξιδίου. 

155


Η κατακόρυφη στήλη με τα λεκτικά αποτελέσματα έχει 

την εξής τυπική μορφή σε ένα τυχαίο παράδειγμα: 

΢το πάνω τμήμα εμφανίζονται τα γενικά στοιχεία, τα 

οποία αφορούν όλες τις Προτάσεις Σαξιδίου, και τα 

οποία προέρχονται από την Παραμετροποίηση του 

Ερωτήματος. Σα στοιχεία αυτά είναι η προέλευση, ο 

προορισμός, τα επιθυμητά ΜΜΜ προς χρησιμοποίηση, 

κι επίσης η χρονική στιγμή για την αναχώρηση ή την 

άφιξη. Η διάκριση ανάμεσα σε αυτές γίνεται από τον 

τίτλο που εμφανίζεται για την χρονική στιγμή. ΢το 

παράδειγμα της διπλανής στήλης ο τίτλος είναι ‗Depart 

Soon After:‘, που σημαίνει ότι η χρονική στιγμή αφορά 

την επιθυμητή αναχώρηση από τον προορισμό. Αν ο 

τίτλος ήταν ‗Arrive No Later Than:‘, τότε η χρονική 

στιγμή θα αφορούσε την επιλεγμένη αργότερη άφιξη 

στον προορισμό. 

Κάτω από τα γενικά στοιχεία του ταξιδίου εμφανίζεται 

ένα accordion με τις μέχρι και 3 Προτάσεις Σαξιδίου 

που έχουν δοθεί ως απάντηση από το routing engine. 

Ο τίτλος κάθε Pane εμφανίζει την χρονική διάρκεια του 

προτεινόμενου ταξιδίου στρογγυλοποιημένη στα πάνω 

5‘ και των αριθμό των μετεπιβιβάσεων. 

Μέσα στο Pane υπάρχουν αρχικά τα στοιχεία για την 

ώρα αναχώρησης από την προέλευση και την ώρα 

άφιξης στον προορισμό, όπως επίσης την απόσταση 

που πρέπει να διανυθεί πεζή με ανάλυση 100m, και 

την αξία του απαιτούμενου κανονικού εισιτηρίου. 

Σο μέγεθος της απόστασης πεζή που εμφανίζεται 

προέρχεται από την απάντηση του routing engine, 

δηλαδή βασίζεται στα στοιχεία του OpenStreetMap. 

Επειδή όμως η οπτικοποίηση γίνεται με βάση την 

υπηρεσία Directions της Google, είναι πιθανόν να 

υπάρχει ασυμφωνία μεταξύ της τιμής που 

αναγράφεται και των απεικονιζόμενων διαδρομών 

στον Φάρτη. Ακόμη κι όπου αυτό πρόκειται να συμβεί 

Εικόνα 67: Συπική Μορφή της 

Κατακόρυφης ΢τήλης με τα λεκτικά 

αποτελέσματα, μέσα από ένα τυχαίο 

παράδειγμα. 

156


όμως, δεν αναμένεται η διαφορά να είναι μεγάλη, πλην ελάχιστων ιδιαίτερων περιπτώσεων, όπου 

π.χ. οι δύο χάρτες διαφέρουν σημαντικά. 

΢ε κατακόρυφη λίστα εμφανίζονται στη συνέχεια οι οδηγίες και τα στοιχεία για κάθε κλάδο της 

εμφανιζόμενης Πρότασης Σαξιδίου. Η αναγραφή έχει γίνει προσπάθεια να είναι όσο το δυνατόν 

κοντύτερα στον τρόπο που επικοινωνεί κι αντιλαμβάνεται ένας άνθρωπος, δηλαδή χωρίς να 

παρατίθενται τυποποιημένα νούμερα, όμοια σε κάθε περίπτωση. Ο κάθε κλάδος διακρίνεται από την 

αρίθμησή του και τον τρόπο και το μέσο με το οποίο θα πρέπει να πραγματοποιηθεί, ενώ και ο 

χρωματισμός της επικεφαλίδας αυτής γίνεται ανάλογα. Έτσι, γίνεται ευκολότερη αναγνώριση των 

τρόπων ταξιδίου, αλλά κι ευκολότερη αναγνώριση της οπτικοποίησης του κλάδου στον διπλανό 

χάρτη. 

Εικόνα 68: Παράδειγμα περιγραφής αρχικού κλάδου διαδρομής πεζή. 

΢το παραπάνω παράδειγμα εμφανίζονται τα στοιχεία για έναν αρχικό κλάδο διαδρομής πεζή. Σα 

στοιχεία που παρατίθενται είναι τα ελάχιστα που μπορούν να ενδιαφέρουν κάποιον, έτσι ώστε αυτός 

να μην πνίγεται από κατακλυσμό παράθεσης στοιχείων, κάτι που δείχνει να είναι το πιο σύνηθες 

λάθος αντίστοιχων εφαρμογών. 

Εικόνα 69: Παράδειγμα περιγραφής κλάδου με Μέσα Μαζικής Μεταφοράς. 

΢το δεύτερο παράδειγμα που εμφανίζεται παραπάνω, περιέχονται τα στοιχεία για έναν κλάδο της 

Πρότασης Σαξιδίου που πρέπει να πραγματοποιηθεί με χρήση ΜΜΜ. ΢την πρώτη σειρά εμφανίζεται 

157


το μέσο και η Γραμμή η οποία έχει δοθεί από το routing engine, ενώ οι υπόλοιπες Γραμμές (ή/και 

παραλλαγές αυτών) είναι οι υπόλοιπες που συνδέουν το ζεύγος των στάσεων προέλευσης και 

προορισμού του κλάδου. 

Σα στοιχεία στις υπόλοιπες Γραμμές αφορούν την στάση αποβίβασης, την στάση πριν από αυτήν, κι 

επίσης τον χρόνο που απαιτείται για την πραγματοποίηση της διαδρομής του κλάδου. Η εμφάνιση 

της ονομασίας της στάσης πριν από αυτή της αποβίβασης, δίνει την δυνατότητα στον Φρήστη να 

αναγνωρίσει ευκολότερα το ότι πλησιάζει στην τελευταία, και να έχει αρκετό χρόνο προετοιμασίας 

για την αποβίβασή του. 

Σόσο η προηγούμενη από την αποβίβαση στάση, όσο και ο χρόνος διαδρομής, αφορούν άμεσα μόνο 

την πρώτη εμφανιζόμενη Γραμμή, αυτή δηλαδή που δίνεται από το routing engine (στο 

συγκεκριμένο παράδειγμα η λεωφορειακή Γραμμή ‗036‘). Σα στοιχεία αυτά για τις εναλλακτικές 

Γραμμές μπορεί να είναι διαφοροποιημένα, όμως κάτι τέτοιο μπορεί να συμβεί σε απειροελάχιστες 

περιπτώσεις, λόγω της δομής και της μορφής του δικτύου ΜΜΜ, και του τρόπου λειτουργίας τους. Η 

παράθεση των διαφοροποιημένων στοιχείων θα πρόσθετε λοιπόν, προς χάριν πολύ σπανίων 

περιπτώσεων, αυξημένη πολυπλοκότητα κι όγκο στοιχείων προς τον Φρήστη. 

Δίπλα στην κατακόρυφη στήλη με τα λεκτικά στοιχεία υπάρχει ο χάρτης, πάνω στον οποίο 

παρουσιάζεται κάθε φορά η επιλεγμένη Πρόταση Σαξιδίου. 

158


Εικόνα 70: Η οπτικοποίηση της Πρότασης Σαξιδίου στον Φάρτη. 

΋πως μπορεί να παρατηρηθεί, οι διάφοροι κλάδοι της Πρότασης έχουν χρωματισθεί ανάλογα με τον 

τρόπο, το μέσο, και την Γραμμή με την οποία πρέπει να πραγματοποιηθούν, και στην αρχή τού κάθε 

159


κλάδου υπάρχει αντίστοιχα χρωματισμένος Marker με ετικέττα τον αύξοντα αριθμό του κλάδου. 

Έτσι, γίνεται άμεσα η σύνδεση από τον Φρήστη της οπτικοποίησης με την λεκτική παράθεση. Θέση 

του κέρσορα πάνω σε κάποιον Marker εμφανίζει ένα tooltip με το όνομα π.χ. της στάσης, ενώ το 

toggle button που υπάρχει κάτω δεξιά δίνει κι εδώ την δυνατότητα θέασης του δικτύου και των 

σταθμών του Metro. 

6.3.3.11 Διαχείριση Προτάσεων. 

΢το κάτω μέρος της η κατακόρυφη στήλη περιέχει τρία κουμπιά τα οποία ενεργοποιούν τις 

λειτουργίες διαχείρισης των προτάσεων: 

‗New‘, για την δημιουργία ενός νέου ερωτήματος, 

‗Edit‘, για την επιστροφή στην κατάσταση παραμετροποίησης ερωτήματος (state 

‗Options‘) και την νέα διαμόρφωσή τής τελευταίας, 

‗Print‘, για την εκτύπωση της εμφανιζόμενης Πρότασης Σαξιδίου. 

Η εκτύπωση πραγματοποιείται προς ένα αρχείο PDF, σε σελίδα μεγέθους Α4.. Η λειτουργία όμως 

αυτή είναι προβληματική, καθώς η open source βιβλιοθήκη AlivePDF που χρησιμοποιείται, βρίσκεται 

ακόμη σε πολύ πρωίμο στάδιο ανάπτυξης. ΢ε κάθε περίπτωση όμως, είναι εφικτή η εκτύπωση 

απευθείας από τον browser, ή ακόμη κι από το Flash Player Plugin, χωρίς όμως να υπάρχει έτσι η 

κατάλληλη προσαρμογή για το μέγεθος σελίδας, την οικονομία της εκτύπωσης (με περιορισμό των 

χρωμάτων), και την καλύτερη αντίθεση. 

Θα πρέπει να σημειωθεί, αν κι έχει αναφερθεί και σε άλλο σημείο του κειμένου, πως έχει γίνει 

προσπάθεια έτσι ώστε να μην υπάρχει μετά την μορφοποίηση των Προτάσεων Σαξιδίου εξάρτηση 

της client εφαρμογής από τους Servers. Αυτό, αφενός για να μειωθεί η κίνηση του δικτύου και ο 

υπολογιστικός φόρτος, αφετέρου για να μπορεί ο Φρήστης να βλέπει τα αποτελέσματα ακόμη κι όταν 

δεν έχει έπειτα διαθέσιμη πρόσβαση στο Internet, ή αυτή έχει ιδιαίτερα υψηλό κόστος. 

160


6.4 Σεχνική Περιγραφή. 

΋πως έχει αναφερθεί, το σύστημα ακολουθεί την αρχιτεκτονική Client-Server, ενώ οι άμεσες 

λειτουργίες που προσφέρονται είναι οι ακόλουθες: 

Εμφάνιςθ Δικτφου ΜΜΜ 

Χαρτογραφικό Τπόβακρο 

Προζλευςθσ-Προοριςμοφ 

Με Marker 

Dragging 

Με Λειτουργίεσ 

Επιλογι 

Χάρτθ 

Από Ενεργά 

Αντικείμενα 

Επιλογι Σρόπου 

Βελτιςτοποίθςθσ 

Επιλογι Επικυμθτών 

Μζςων 

Επιλογι Μζγιςτθσ 

Απόςταςθσ Πεηι 

Επιλογι Για Αναχώρθςθ ι 

Άφιξθ 

Επιλογι Χρονικισ ΢τιγμισ 

Διάγραμμα 6: Λειτουργίες κατά την παραμετροποίηση. 

Από ΢θμεία 

Ενδιαφζροντοσ 

Από Geocoding 

Παραμετροποίθςθ 


Προκακοριςμόσ 

Άλλεσ Λειτουργίεσ (Πλθροφορίεσ, Βοικεια, Επικοινωνία, κτλ) 

161


Διάγραμμα 7: Εύρεση προτάσεων ταξιδίου, μετεπεξεργασία, εμπλουτισμός, κι άλλες ενέργειες. 


Διαμόρφωςθ 

Προτάςεων 

Χαρτογραφικό Τπόβακρο 

Εκτφπωςθ 

Επεξεργαςία Από Σο Routing Engine 

Μετεπεξεργαςία 

Προςκικθ Εναλλακτικών Γραμμών 

Εφρεςθ Αναγκαίου Ειςιτθρίου 

Εμφάνιςθ 

Προτάςεων 

Σροποποίθςθ 

Παραμετροποίθςθσ 

Επανζναρξθ 

Άλλεσ Λειτουργίεσ (Πλθροφορίεσ, Βοικεια, Επικοινωνία, κτλ) 

Διάγραμμα 8: Παρούσιαση Προτάσεων, διαχείρισή τους, και επιλογή συνέχειας. 

162


Με βάση τις λειτουργίες αυτές, και τα εργαλεία που ήδη έχει αναφερθεί πως επιλέχτηκαν για την 

χρησιμοποίησή τους, το ευρύτερο μοντέλο που αναπτύχθηκε είναι το εξής: 




Ρροτάςεων 

ΧΡΘ΢ΣΘ΢ 

GOOGLE 

SERVICES 

Χαρτογραφικό 

Υπόβακρο 

Επιλογι 

Ρροζλευςθσ-Ρροοριςμοφ 


Πλα Εκτόσ 

Από Σθμεία Ενδιαφζροντοσ 

ΕΦΑΡΜΟΓΘ ΧΡΘ΢ΣΘ 


Ρροτάςεων 


Ρροκακοριςμόσ 

Άλλεσ Λειτουργίεσ 

Χαρτογραφικό Υπόβακρο 

Ραραμετροποίθςθ Ερωτιματοσ 

Ραροχι Εφαρμογισ Χριςτθ / Ρροκακοριςμόσ 

Άλλεσ Λειτουργίεσ 


Ρροςκικθ Εναλλακτικϊν Γραμμϊν 

Εφρεςθ Αναγκαίου Ειςιτθρίου 

Εμφάνιςθ Ρροτάςεων Εκτφπωςθ 

TSOOP! SERVER 

Διαμόρφωςθ Ρροςκικθ Εναλλακτικϊν Γραμμϊν 

Ρροτάςεων Routing Engine 

Διάγραμμα 9: Απεικόνιση τού ποιές λειτουργίες εκτελούνται σε κάθε τμήμα του ΢υστήματος. 

163



Η Web-Based εφαρμογή Φρήστη που έχει αναπτυχθεί στα πλαίσια του Open Trip Planner, και η 

οποία αποτελούσε την βάση για την αρχική εφαρμογή χρήστη και στην Παρούσα, χρησιμοποιεί τον 

Tomcat ως server, λειτουργώντας με βάση την javascript. 

Για την τελική όμως Εφαρμογή του Tsoop!, η οποία και περιγράφεται εδώ, επιλέχτηκε ως περιβάλλον 

ανάπτυξης το Adobe Flex framework, στην έκδοση 4, αν και δεν υπήρχε καμία εμπειρία από 

προηγούμενη χρήση του. ΋πως περιγράφεται και στην Παράγραφο 5.1.13, το Flex πρόκειται για ένα 

open source SDK πλάισιο το οποίο προσφέρει πάρα πολλές δυνατότητες για την δημιουργία RIAs 

(Rich Internet Apllications), έχοντας μάλιστα στοιχεία και διευκολύνοντας την συνδεσιμότητα με 

άλλες εφαρμογές και πρότυπα της εταιρίας Adobe, όπως είναι τo Flash. Λόγω λοιπόν του ευρύτερου 

περιβάλλοντος στο οποίο ανήκει, το Flex παρέχει την δ8υνατότητα δημιουργίας εφαρμογών με 

εντυπωσιακή και λειτουργική εμφάνιση, με εύκολη συμπερίληψη μάλιστα multimedia στοιχείων. 

Η γλώσσα που χρησιμοποιείται στο Flex για την ανάπτυξη της «λογικής» είναι η ActionScript v3.0, η 

οποία θυμίζει αρκετά την Java ως προς την σύνταξη, και είναι έντονα αντικειμενοστραφής. Ένα 

σημαντικό στοιχείο του Flex στην έκδοση που χρησιμοποιήθηκε είναι το Spark namespace, το οποίο 

προσφέρει οπτικά και μη αντικείμενα, με εξελιγμένες ιδιότητες και μεθόδους. 

Mεγάλο πλεονέκτημα του Flex είναι επίσης η δυνατότητα λειτουργίας σε μεγάλο αριθμό 

διαφορετικών λειτουργικών συστημάτων, σε ποικίλες κατηγορίες συσκευών (desktop υπολογιστές, 

κινητά τηλέφωνα), μέσα σε browsers ή ανεξάρτητα (σε Adobe AIR), χωρίς να απαιτείται σχεδόν 

καμία μεταβολή του κώδικα. 

6.4.2 Λειτουργίες ΢τον HTTP Server. 

H client Εφαρμογή Φρήστη παρέχεται σε αυτόν μέσω ενός HTTP Server. Ο Server παρέχει λοιπόν 

προς τον browser του χρήστη ένα αρχικό html αρχείο, το οποίο ελέγχει για την ύπαρξη του 

κατάλληλου Flash player και σε περίπτωση που αυτός λείπει αλλά είναι διαθέσιμος για την συσκευή, 

το λειτουργικό σύστημα, ή και τον browser του χρήστη, τότε προτείνεται στον τελευταίο να 

προχωρήσει στο κατέβασμα και την εγκατάσταση. 

Ο ΗΣΣP Server, ο οποίος έχει επιλεχθεί να είναι συγκεκριμένα ο Apache HTTP Server, προμηθεύει 

την client Εφαρμογή και με όλα τα αρχεία εικόνων (JPG, PNG, κ.α.), όπως επίσης και με τα όμοια 

αρχεία που χρησιμοποιούνται για την παροχή πληροφοριών και βοήθειας. Ο Server είναι 

164


προσβάσιμος μέσω συγκεκριμένου port που καθορίζεται. ΢υνήθως ο αριθμός του port για web 

servers είναι το 80, όμως στην συγκεκριμένη εφαρμογή χρησιμοποιήθηκε το 8087, έτσι ώστε να μην 

επηρεάζεται η λειτουργία άλλων προεγκατεστημένων web servers. 

Μία άλλη λειτουργία που πραγματοποιείται στον HTTP Server είναι η εκτέλεση διαφόρων αρχείων 

PHP. Σα αρχεία αυτά, όπως αναφέρεται και σε άλλο σημείο του κειμένου, χρησιμοποιούνται ως 

ενδιάμεσα για τις συνδέσεις της Flex εφαρμογής με τις διάφορες HTTP υπηρεσίες. Με αυτόν τον 

τρόπο παρακάμπτεται η αναγκαιότητα για την ύπαρξη ενός αρχείου αδειοδότησης της πρόσβασης, 

ανάλογα με το IP του client. Η δημιουργία ενός τέτοιου αρχείου δεν θα ήταν φυσικά πρόβλημα για 

τις HTTP υπηρεσίες που παρέχονται από τον Tsoop! Server, θα ήταν όμως αδύνατον για τις HTTP 

υπηρεσίες που παρέχονται από την Google. Αν και η Google παρέχει και αντίστοιχες SOAP 

υπηρεσίες, αυτές δεν προτιμήθηκαν, για λόγους που αναφέρονται στις αχετικές παραγράφους. 

Ένα πρόσθετο πλεονέκτημα της χρήσης PHP είναι η μετατροπή των δεδομένων που διακινούνται, 

από XML σε JSON μορφή. Με αυτόν τον τρόπο επιτυγχάνεται μείωση του διακινούμενου όγκου, 

καθώς τα περιγραφικά δεδομένα είναι λιγότερα. Από την άλλη όμως, προκύπτει διακίνηση των 

δεδομένων που αφορούν τις HTTP υπηρεσίες της Google μέσω του Tsoop! Server, γεγονός που 

αυξάνει έτσι την κίνηση από και προς τον server. 

Η PHP έχει έναν ακόμη ρόλο, αυτόν του ενδιάμεσου ανάμεσα στην client εφαρμογή και τον 

PostgreSQL Server. Ο Server αυτός χρησιμοποιείται για την εύρεση των εναλλακτικών Γραμμών 

(ή/και παραλλαγών) οι οποίες συνδέουν το ζεύγος στάσεων που αντιστοιχεί σε ένα τμήμα μίας 

Πρότασης Σαξιδίου. Αυτό γιατί το routing engine δίνει μόνο μία Γραμμή για την σύνδεση των δύο 

στάσεων, αυτή που αντιστοιχεί σε συγκεκριμένο δρομόλογιο. 

Για να έχει ο Apache HTTP Server την δυνατότητα παροχής της PHP, χρειάζεται να γίνει 

εγκατάσταση πρόσθετων αρχείων που δίνονται δωρεάν από το site ανάπτυξης της γλώσσας, όπως 

επίσης, να γίνουν οι κατάλληλες ρυθμίσεις. 

6.4.3 Λειτουργίες ΢τον Tomcat Server. 

Ο Tomcat Server ανήκει κι αυτός στην οικογένεια Apache. ΢την Εφαρμογή που υλοποιήθηκε ο 

Tomcat χρησιμοποιείται ως servlet container για το routing engine. ΢το Project του 

OpenTripPlanner o Tomcat χρησιμοποιείται και για την web-based Εφαρμογή Φρήστη. Η πρόσβαση 

στον Tomcat γίνεται μέσω ενός καθορισμένου port, το οποίο στην περίπτωση της παρούσας έχει 

οριστεί να είναι το 58080. 

165


Αν και θα μπορούσε να χρησιμοποιηθεί ο Tomcat και για την κάλυψη των υπηρεσιών που παρέχονται 

από τον HTTP server, εν τούτοις προτιμήθηκε να υπάρχουν σε λειτουργία και οι δύο. Αυτό γιατί ο 

τελευταίος παρέχει την δυνατότητα μεγαλύτερης παραμετροποίησης, είναι αρκετά πιο γρήγορος 

όσον αφορά στατικές σελίδες, αρκετά πιο ―ρωμαλέος», κι επίσης μπορεί να καλύψει γενικότερες 

ανάγκες. Έτσι, θέλοντας εξαρχής να υπάρχει ένα σύστημα το οποίο να είναι προσαρμόσιμο πάνω σε 

hardware που χρησιμοποιείται π.χ. και για άλλες χρήσεις, υιοθετήθηκε η συνλειτουργία και των δύο 

servers. 

6.4.4 Λειτουργίες Που Πραγματοποιούνται Με Φρήση Σων Τπηρεσιών Που 

Παρέχονται Από Σην Google. 

΢την Εφαρμογή που παρουσιάζεται, χρησιμοποιούνται η HTTP υπηρεσία της Google για το 

geocoding και το routing που αφορά τις διαδρομές πεζή. Οι υπηρεσίες αυτές ονομάζονται 

Geocoding και Directions αντίστοιχα. ΋πως έχει ήδη αναφερθεί, η πρόσβαση στην πρώτη υπηρεσία 

από την client εφαρμογή δεν γίνεται απευθείας, αλλά μέσω του Apache HTTP Server και των 

σχετικών PHP scripts. Πλέον αυτών, χρησιμοποιείται και η υπηρεσία χάρτη της εταιρείας, Google 

Map, ώς υπόβαθρο. Η πρόσβαση στην Directions και την Map γίνονται μέσω επεκτάσεων του Flex 

που παρέχονται δωρεάν από την ίδια την Google. 

Η υπηρεσία Geocoding χρησιμοποιείται για την εύρεση διευθύνσεων σύμφωνα με κάποια 

αλφαριμθητική εισαγωγή που κάνει ο Φρήστης. Οι διευθύνσεις αυτές χρησιμοποιούνται ως σημεία 

προελεύσεων και προορισμών. Παρέχεται δωρεάν, με όριο όμως τις 2500 κλήσεις ανά ημέρα. 

Η υπηρεσία Directions χρησιμοποιείται για το routing διαδρομών, τμήματα του προτεινόμενου 

ταξιδίου, που πρέπει να γίνουν πεζή. Σο routing αυτό γίνεται σε πρώτο στάδιο από το routing 

engine. ΋μως, τα διάφορα προβλήματα πληρότητας κι εγκυρότητας που παρουσιάζουν τα δεδομένα 

του οδικού δικτύου που χρησιμοποιούνται σε αυτό, δηλαδή του Open Street Map, ώθησαν ώστε από 

την Εφαρμογή Φρήστη να αντικαθίσταται το σχετικό routing πεζή με αυτό της υπηρεσίας Directions. 

Κατά αυτόν τον τρόπο είναι δυνατόν να παρέχεται και αναλυτική καθοδήγηση, χρησιμοποιοώντας 

τις ονομασίες των οδών. 

΋μως, έτσι δεν αποφευγέται η επιλογή Προτάσεων που εν μέρει βασίζονται σε όχι σωστά στοιχεία, 

ενώ είναι πρακτικά αναπόφευκτες οι διαφοροποιημένες απαντήσεις σε κάποιες περιπτώσεις. 

166


6.4.5 Routing Engine. 

To routing engine που χρησιμοποιείται βασίζεται στο open source πακέτο λογισμικού 

OpenTripPlanner, το οποίο όμως βρίσκεται σε πολύ πρωϊμο στάδιο ανάπτυξης. Φαρακτηριστικά, η 

τρέχουσα έκδοση είναι η 0.3. Αυτό ήταν ένα σημαντικό πρόβλημα κατά την δημιουργία του 

συστήματος που περιγράφεται, αφού παρουσιάζονταν διάφορες δυσλειτουργίες, και οι νέες εκδόσεις 

των διαφόρων κλάσεων δημιουργούσαν συνεχώς προβλήματα συμβατότητας. 

Μόλις οριστικοποιήθηκε ο συνδυασμός των εκδόσεων κλάσεων που ήταν λειτουργικός, τότε έγιναν 

πάνω σε αυτή την συνολική έκδοση διάφορες τροποποιήσεις, ώστε να καλυφθούν οι ανάγκες 

χρήσεις της εφαρμογής που υλοποιήθηκε. Οι τροποποιήσεις αυτές δεν αφορούσαν τον τρόπο με τον 

οποίον γίνεται η αναζήτηση λύσεων στον Γράφο, αλλά: 

την παραμετροποίηση των διαφόρων στοιχείων που καθορίζουν την αναζήτηση, 

όπως π.χ. του κόστος μετεπιβίβασης, τη; Σαχύτητα; περπατήματος, του πόσο 

προτιμότερο είναι το περπάτημα από την αναμονή οχήματος ΜΜΜ, κ.α.. Οι 

παραμετροποιήσεις αυτές δεν έχουν παραμείνει σταθερές, αλλά μεταβάλονται 

συνεχώς, ώστε να βελτιώνονται διαρκώς οι λύσεις που προτείνονται, ανάλογα με 

την εκτίμηση των λύσεων που εμφανίζονται στις διάφορες δοκιμές, σε συνδυασμό 

με την εμπειρία. 

την κατάλληλη μορφοποίηση των αποτελεσμάτων, έτσι ώστε να είναι συμβατά με 

το Flex Framework που χρησιμοποιείται στην Εφαρμογή Φρήστη, όπως επίσης και 

να είναι κατά το δυνατόν περιορισμένα σε μέγεθος. Για τον σκοπό αυτό 

τροποποιήθηκαν κατάλληλα τα classes που αφορούν την απάντηση (response) κι 

απαλείφτηκαν π.χ. οι λεπτομέρειες που αφορούν τα βήματα στις διαδρομές πεζή 

(οδηγίες καθοδήγησης). 

6.4.5.1 Μορφή HTTP Ερωτήματος. 

΋πως έχει αναφερθεί, το routing engine τρέχει στον Tomcat Server, ως ένα java module. ΢την 

πραγματικότητα τα modules είναι δύο: το ένα αφορά το ίδιο το routing, ενώ το άλλο αφορά την 

παροχή του web-api interface. 

Σο ερώτημα που τίθεται προς τον server από την Client Εφαρμογή είναι της εξής μορφής: 

167


http://{servernamedomain}:{port}/opentripplanner-apiwebapp/ws/plan 

?fromPlace={lat, lng} 

&toPlace={lat,lng} 

&arriveBy={Depart ή Arrive} 

&optimise={QUICK ή TRANSFERS ή SAFE} 

&maxWalkDistance={απόζηαζη ζε μέηπα} 

&mode={Σςνδςαζμόρ ηων λέξεων TRANSIT, BUSISH,TRAINISH,WALK,BICYCLE, 

σωπιζμένων με κόμμα} 

&numIteneraries={1 ή 2 ή 3} 

&date={ημεπομηνία} 

&time={ώπα} 

&showIntermediateStops={true ή false} 

Servernamedomain: 

Port: 

fromPlace: 

toPlace: 

Είναι η διεύθυνση του server στον οποίο τρέχει το API. Π.χ. www.tsoop.gr. 

Ο αριθμός της θύρας (port) στην οποία «ακούει» ο server τα ερωτήματα προς το API. Π.χ. 

58080. 

Σο σημείο αφετηρίας, με τις γεωγραφικές συντεταγμένες στην μορφή ‗πλάτος, μήκος‘ 

διαχωρισμένες με κόμμα. Π.χ. 37.12345,23.98765. 

Σο σημείο τερματισμού, εκφρασμένο όμοια με το σημείο αφετηρίας. 

168

arriveBy: 

optimise: 


Δέχεται μία από τις τιμές ‗Depart‘ και ‗Arrive‘. Με την ‗Depart‘ ορίζεται ότι η ημερομηνία 

και η ώρα αφορούν την επιθυμητή στιγμή αναχώρησης (όχι νωρίτερα από αυτήν), ενώ με 

την ‗Arrive‘ ορίζεται ότι η ημερομηνία και η ώρα του ερωτήματος αφορούν την επιθυμητή 

στιγμή άφιξης στον προορισμό (δηλαδή όχι αργότερα από αυτήν). 

Η επιθυμητή βελτιστοποίηση των προτεινόμενων διαδρομών. Με την ‗QUICK‘ επιλέγεται η 

βελτιστοποίηση που επιτυγχάνει την γρηγορότερη άφιξη, με την ‗TRANSFERS‘ αυτή που 

επιτυγχάνει τις λιγότερες αλλαγές μέσων, ενώ με την ‗SAFE‘ αυτή που επιτυγχάνει την 

ασφαλέστερη ποδηλατική διαδρομή, η οποία όμως δεν χρησιμοποιείται στην παρούσα. 

Για να χρησιμοποιηθεί σωστά η επιλογή ‗SAFE‘ απαιτείται καθορισμός της επίδρασης στην 

ασφάλεια που παρέχει κάθε οδός του δικτύου, ο οποίος καθορισμός μπορεί να γίνει είτε 

γενικά, ανάλογα με τον τύπο της οδού, είτε πιο ειδικευμένα, ανά οδό. Η διαδικασία 

απόδοσης στοιχείων ασφάλειας στις οδούς γίνεται κατά την δημιουργία του Γράφου. 

maxWalkDistance: 

mode: 

numItineraries: 

Η επιθυμητή μέγιστη απόσταση περπατήματος κατά το ταξίδι, εκφρασμένη σε μέτρα. Η 

απόσταση αυτή δεν είναι δεσμευτική από την μηχανή του routing, καθώς μπορεί να την 

αυξάνει για την δημιουργία προτάσεων ταξιδίου. 

Ο συνδυασμός των λέξεων, διαχωρισμένων με κόμμα, ορίζει τον επιθυμητό τρόπο ταξιδίου, 

αποκλείοντας άλλους. Με την λέξη ‗TRANSIT‘ επιλέγονται όλα τα ΜΜΜ, με την ‗BUSISH‘ 

μόνο τα λεωφορεία, με την ‗TRAINISH‘ μόνο τα τρένα. Με την ‗WALK‘ επιλέγεται και η 

διαδρομή πεζή, ενώ με την ‗BICYCLE‘ και η διαδρομή με ποδήλατο. Ο ορισμός της 

παραμέτρου ως ‗TRANSIT, WALK‘ π.χ., ορίζει η αναζήτηση να γίνει για ταξίδια που 

συνδυάζουν όλα τα ΜΜΜ και την διαδρομή πεζή. 

Πρόκειται για έναν ακέραιο αριθμό, με τον οποίο καθορίζεται ο αριθμός της Πρότασης 

Διαδρομής (Journey Proposal) που επιθυμείται στην απάντηση. Η τιμή μπορεί να έχει την 

τιμή 1, 2, 3, καθώς τρείς είναι οι μέγιστες επιστρεφόμενες Προτάσεις Σαξιδίου. Εύκολα 

μπορούν να παρέχονται περισσότερες Προτάσεις, όμως αυτό δεν έχει ιδιαίτερο πρακτικό 

169

date: 

time: 


νόημα. ΢την παρούσα φάση παρέχεται μόνο μία Πρόταση όταν έχει δοθεί το ‗Arrive‘ στην 

παράμετρο arriveBy. 

Η ημερομηνία στην οποία επιθυμείται η αναχώρηση ή η αφιξη. Πρόκειται για ένα string της 

μορφής ‗MM/DD/YYYY‘. 

Η ώρα στην οποία επιθυμείται η αναχώρηση ή η αφιξη. Πρόκειται για ένα string της μορφής 

‗hh:mm‘ ή ‗hh:mm p‘. 

showIntermediateStops: 

wheelchair: 

Boolean παράμετρος, η οποία δέχεται μία από τις τιμές ‗true‘, ‗false‘. ΢την περίπτωση της 

τιμής ‗true‘ στα αποτελέσματα δίνονται επιπλέον στοιχεία για τις ενδιάμεσες στάσεις κάθε 

τμήματος διαδρομής με ΜΜΜ. 

Boolean παράμετρος, η οποία δέχεται μία από τις τιμές ‗true‘, ‗false‘. ΢την περίπτωση της 

τιμής ‗true‘ η δημιουργία προτάσεων ταξιδίου λαμβανει υπόψη την προσβασιμότητα από 

αναπηρικά αμαξίδια. ΢την περίπτωση της Αθήνας δεν υπάρχουν τέτοια στοιχεία, αν και 

δυστυχώς αν αυτά δεν απεικόνιζαν μία εικονική πραγματικότητα, τότε ο Journey Planner 

δεν θα ήταν σε θέση να προτείνει διαδρομές. ΢υνεπώς, δεν χρησιμοποιείται στην παρούσα 

Εφαρμογή. 

Ένα πλήρες παράδειγμα της διατύπωσης ερωτήματος προς το API είναι το εξής: 

http://www.tsoopdomain.gr:58080/opentripplanner-api- 

webapp/ws/plan?fromPlace=38.013967724051,23.769744081396&toPlace=38.00869296 

9808,23.810427827732&arriveBy=Depart&optimise=QUICK&maxWalkDistance=840&mode 

=TRANSIT,WALK&numIteneraries=3&date=10/16/2010&time=14:30&showIntermediateSt 

ops=true&wheelchair=false 

Κάποιες από τις παραμέτρους μπορούν να μην υπάρχουν στο ερώτημα, οπότε και αντικαθίστανται 

από τις default τιμές τους κατά το routing. Π.χ. οι παράμετροι showIntermediateStops και 

wheelchair έχουν ως default την τιμή false. 

170


6.4.5.2 Μορφή Απάντησης. 

Σα αποτελέσματα που παρέχονται από το API είναι σε μορφή XML, αν και μέσω της PHP που 

χρησιμοποιείται ως ενδιάμεση, η τελική μορφή που λαμβάνει η client Εφαρμογή είναι JSON. Για το 

προηγούμενο παράδειγμα ερωτήματος, η απάντηση όπως δίνεται από την υλοποίηση της παρούσας 

Εφαρμογής, είναι σε αποσπασματική μορφή: 

 

 

 

2010-10-16T14:30:00+03:00 

 

Odos Dionisiou Solomou 

123 

23.76979128465102 

38.014089719552786 

 

{"type": "Point", "coordinates": [23.76979128465102,38.014089719552786]} 

 

 

 

way 32133535 from 1 

123 

23.810928071820058 

38.00869741175583 

 


 

 

Μέχρι το σημείο αυτό δίνονται τα στοιχεία που αφορούν το σύνολο της απάντησης (Response), 

όπου τα γεινκά στοιχεία αποτελούν το Plan. 

171


Έτσι βλέπουμε ότι η απάντηση περιλαμβάνει την ημερομηνία και την ώρα (UTC+ZONE Offset το 

οποίο αγνοείται στην παρούσα, και η ώρα θεωρείται τοπική Αθήνας. 

Επίσης αναφέρονται τα στοιχεία της αφετηρίας (Pfrom) και του τερματισμού (Pto). Και για τα δύο 

αυτά σημεία δίνονται πληροφορίες για την ονομασία, τον κωδικό στάσης (‗123‘ στην περίπτωση που 

το ταξίδι δεν ξεκινά ή σταματά σε μία στάση), καθώς και τις γεωγραφικές συντεταγμένες. Η 

ονομασία περιέχει τις τιμές από το αντίστροφο geocoding στα στοιχεία του Γράφου, με βάση ότι 

πληροφορία έχει εισαχθεί για το οδικό δίκτυο. Επιπλέον δίνονται τα στοιχεία της γεωμετρίας σε 

μορφή GeoJSON. 

 

 

3545000 

2010-10-16T14:35:06+03:00 

2010-10-16T15:34:11+03:00 

882000 

2346000 

0 

1171.326784312879 

0.0 

0.0 

1 

 

 

 

regular 

 

100 

 

 

 

 

 

΢το τμήμα αυτό δίνεται η επικεφαλίδα για το τμήμα που περιέχει τις Προτάσεις Σαξιδίου 

(JourneyProposals), και ξεκινάει η περιγραφή της πρώτης από αυτές. Δίνονται στοιχεία για την 

172


διάρκεια ταξιδίου συνολικά (σε ms), την χρονική στιγμή εκκίνησης, την χρονική στιγμή τερματισμού, 

τον χρόνο διαδρομής πεζή (σε ms), τον χρόνο διαδρομής εντός ΜΜΜ, τον χρόνο αναμονής, το 

μήκος περπατήματος (σε μέτρα), όπως επίσης στοιχεία για την μεταβολή υψομέτρου και τον αριθμό 

των μετεπιβιβάσεων. Σα στοιχεία υψομέτρου, ιδιαίτερα χρήσιμα στην περίπτωση διαδρομής με 

ποδήλατο, είναι μηδενικά πάντα στην περίπτωση της Παρούσας Εφαρμογής. 

Σο τελευταίο στοιχείο αφορά το απαιτούμενο κόστος εισιτηρίου, ανά τύπο εισιτηρίου. Θα πρέπει να 

σημειωθεί εδώ ότι στο συγκεκριμένο θέμα υπάρχουν προβλήματα, τόσο στο GTFS, όσο και στην 

υλοποίηση του OpenTripPlanner. ΢το μεν GTFS δεν παρέχεται η δυνατότητα ορισμού διαφορετικών 

τύπων εισιτηρίου, στον δε OpenTripPlanner δεν γίνεται απολύτως σωστά ο υπολογισμός του κόστους, 

καθώς το συγκεκριμένο τμήμα βρίσκεται σε πολύ πρώιμο στάδιο. Είναι ένα χαρακτηριστικό σημείο 

πάντως του μειονεκτήματος των trip planners που σχεδιάζονται για πολλές πόλεις, και σε αυτούς 

που αφορούν υλοποιήσεις για μία πόλη. ΢τους planners της πρώτης περίπτωσης δεν παρέχεται η 

απαραίτητη ευελιξία για την μοντελοποίηση των τιμολογιακών πολιτικών όπως διαφοροποιούνται 

από πόλη σε πόλη. 

 

 

2010-10-16T14:35:06+03:00 

2010-10-16T14:42:17+03:00 

571.6015332866416 

WALK 


 


23.76979128465102 

38.014089719552786 

 

{"type": "Point", "coordinates": 

[23.76979128465102,38.014089719552786]} 

 

 

 

AG. DIMITRIOU 

ST778533 

23.77175 

38.009472 

173


 


 

 

 

9 

_s_gFepapCb@{ArA`@rABzASfIiCdEqAvBm@Ss@ 

 

431000 

 

. 

. 

. 

Ακολουθούν τα υπόλοιπα legs. 

΢το τμήμα αυτό δίνεται η επικεφαλίδα για το ότι ακολουθεί η περιγραφή των τμημάτων ταξιδίου, των 

legs, και στη συνέχεια ξεκινάει η περιγραφή του πρώτου leg. ΢την αρχή δίνονται τα γενικά του 

στοιχεία, δηλαδή η χρονική στιγμή εκκίνησης, η χρονική στιγμή άφιξης, το μήκος σε μέτρα, το μέσο 

(‗WALK‘ για περπάτημα, ‗BUS‘ για λεωφορείο, ‗SUBWAY‘ για metro, ‗RAIL‘ για τρένο, ή άλλα που 

δεν αφορούν την παρούσα εφαρμογή, π.χ. ‗FUNICULAR‘ για σχοινόδρομο), αλλά και την Γραμμή 

(route) που πρέπει να χρησιμοποιηθεί. ΢την περίπτωση που το μέσο είναι ‗WALK‘, τότε το στοιχείο 

route περιέχει την οδό εκκίνησης. 

΢τη συνέχεια δίνονται για τα σημεία εκκίνησης (Pfrom) και τερματισμού (Pto) τα στοιχεία της 

ονομασίας, των συντεταγμένων, και της γεωμετρίας σε μορφή GeoJSON, όμοια με την περίπτωση 

του συνολικού ταξιδίου. 

΢το τμήμα δίνονται στοιχεία για την γεωμετρία του leg, δηλαδή ο αριθμός των 

σημείων και η encoded polyline, καθώς και η διάρκεια σε ms για την πραγματοποίηση του leg. 

΢την περίπτωση που το μέσο είναι λεωφορείο π.χ, τότε η περιγραφή του leg θα είναι σαν του 

επόμενου: 

 

2010-10-16T14:42:18+03:00 

2010-10-16T14:55:18+03:00 

2986.781358205151 

BUS 

174


653 

ETHEL 

 

AG. DIMITRIOU 

ST778533 

23.77175 

38.009472 

 


 

 

 

YGEIONOMIKO 

ST062237 

23.760923 

37.986801 

 


 

 

 

 

A'PLATEIA 

ST778523 

23.773988 

38.007745 

 


 

 

. 

. 

. 

Ακολοςθούν ηα ςπόλοιπα intermediate stops. 

175


Οι διαφορές σε σχέση με το leg που αφορά διαδρομή πεζή είναι οι εξής: 

΢τα γενικά στοιχεία του leg υπάρχει επιπλέον η πληροφορία για τον φορέα 

(agencyID) που εκτελεί το συγκοινωνιακό έργο της συγκεκριμένης Γραμμής. 

Τπάρχει επιπλέον (κατ‘ επιλογήν) μία λίστα με τις ενδιάμεσες στάσεις. Για κάθε στάση 

υπάρχουν τα στοιχεία της ονομασίας, του κωδικού της, των γεωγραφικών 

συντεταγμένων της, αλλά και της θέσης της σε GeoJSON μορφοποίηση. 

΢το τέλος κάθε Πρότασης Διαδρομής υτπάρχουν τα εξής στοιχεία: 

false 

 

Σο είναι στοιχείο που δεν χρησιμοποιείται στην παρούσα υλοποίηση. 

΢το τέλος της XML απάντησης συναντώνται τα εξής: 

 

 

 

 

optimize 

QUICK 

 

 

showIntermediateStops 

true 

 

 

time 

14:30 

176

 


wheelchair 

false 

 

 

maxWalkDistance 

840.0 

 

 

fromPlace 

38.013967724051,23.769744081396 

 

 

toPlace 

38.008692969808,23.810427827732 

 

 

date 

10/16/2010 

 

 

mode 

 

TraverseMode (WALK, TRAM, SUBWAY, RAIL, BUS, FERRY, CABLE_CAR, GONDOLA, 

FUNICULAR, TRANSIT, TRAINISH, BUSISH) 

 

 

 

numItineraries 

3 

 

 

 

177


Αφού κλείνουν τα τμήματα των Προτεινόμενων Διαδρομών και του plan, στην συνέχεια, μέσα στο 

τμήμα requestParameters παρέχονται σε μία ArrayList τα στοιχεία του ερωτήματος στο οποίο 

δόθηκε η απάντηση. Επίσης παρέχεται σαν τελευταίο στοιχείο το πλήθος των Προτεινόμενων 

Διαδρομών που περιέχονται (numItineraries). 

Θα πρέπει να σημειωθεί εδώ ότι η μορφή της XML απάντησης έχει τροποποιηθεί ειδικά για την 

παρούσα υλοποίηση, κι έτσι πλέον δεν είναι συμβατή με άλλες υλοποιήσεις του OpenTripPlanner. 

Η πρώτη τροποποίηση είναι η μη συμπερίληψη των περιγραφικών βημάτων για τα 

legs που γίνονται πεζή. Ο λόγος είναι ότι για το συγκεκριμένο αντικείμενο 

προτιμήθηκε η λειτουργία του Google Directions API, καθώς τα στοιχεία είναι πιο 

πλήρη από αυτά που επιστρέφονται από τα OSM δεδομένα. Ακόμη, τα στοιχεία της 

Google μπορούν να επιστρέφονται σε διάφορες γλώσσες, ενώ αυτά των OSM, όπου 

υπάρχουν στην Αθήνα, είναι τυχαία είτε στα Ελληνικά, είτε στα Αγγλικά/Λατινικό 

αλφάβητο. Σα στοιχεία από το Google Directions συνδυάζονται με τα στοιχεία που 

παρέχει ο opentripplanner από την εφαρμογή χρήστη. 

Η δεύτερη τροποποίηση αφορά τις ονομασίες πεδίων, οι οποίες έχουν αλλάξει ώστε 

να είναι συμβατά με τους κανόνες που ορίζονται για τα properties από το Adobe 

Flex και τo ActionScript 3.0. Σο ένα τέτοιο σημείο είναι οι ονομασίες from, to, οι 

οποίες έχουν γίνει Pfrom, Pto. Σο άλλο σημείο είναι η αλλαγή των itenenaries 

και itenenary σε JourneyProposals και JourneyProposal αντίστοιχα. 

Οι αλλαγές αυτές αναγκαστικά έχουν γίνει και στις ονομασίες των classes, αφού η 

XML απάντηση είναι στην πραγματικότητα παράθεση των αντίστοιχων ArrayLists. 

Η τρίτη τροποποίηση αφορά την ύπαρξη των πεδίων σε όλες τις απαντήσεις, ώστε 

να μην εξαρτάται η παρουσία τους από τα γονικά πεδία. Αυτό σημαίνει ότι π.χ. 

στοιχεία που αφορούν ενδιάμεσες στάσεις εμφανίζονται ακόμη κι όταν το τμήμα 

του ταξιδίου αφορά μετακίνηση πεζή. Οι πληροφορίες που περιέχονται σε αυτές τις 

περιπτώσεις είναι είτε 0 για τα αριθμητικά πεδία, είτε μηδενικού μήκους string για 

τα πεδία κειμένου, είτε κάποια πληροφορία που επισημαίνει την ειδική περίπτωση 

και δεν χρησιμοποιείται κανονικά. Ο λόγος που υπάρχουν παντού όλα τα πεδία 

είναι ώστε να υπάρχει συμβατότητα με τους μηχανισμούς Get HTTP του Flex, 

καθώς διαφορετικά τα αποτελέσματα στο response δεν γίνονται αποδεκτά. 

178


Επειδή οι αλλαγές αυτές θα χρειαστεί να γίνουν και σε άλλες υλοποιήσεις, προτείνεται στο forum 

ανάπτυξης του OpenTripPlanner να υιοθετηθούν όμοιες αλλαγές για το κύριο release, κι όχι να 

υπάρχουν κατά διαφορετικό τρόπο σε κάποια branches, όπως είναι αυτό της παρούσας Εφαρμογής. 

΢ε περίπτωση κάποιου προβλήματος στα στοιχεία του HTTP URL ερωτήματος, τότε επιστρέφεται μία 

διαφορετική απάντηση, επίσης σε XML. Ψς παράδειγμα παρατίθεται η εξής, η οποία αφορά 

ερώτημα με το γεωγραφικό μήκος του προορισμού να είναι εκτός περιοχής: 

 

 

400 

to 

 

Trip is not possible. You might be trying to plan a trip outside the map 

data boundary. 

 

false 

 

 

 

optimize 

QUICK 

 

. 

. 

. 

Η συνέχεια όμοια όπως και στην απάντηση σε περίπτωση που όλα είναι σωστά κι έχουν βρεθεί 

διαδρομές. 

΢το συγκεκριμένο παράδειγμα επιστρέφεται το πεδίο error, στο οποίο περιέχονται ένα id (400), 

το στοιχείο που λείπει (missing), κι ένα σχετικό μήνυμα περιγραφής. 

Άλλα πιθανά σφαλματα είναι τα εξής: 

179


# PLANNER ERROR MESSAGES 

1 PLAN_OK Success. 

2 SYSTEM_ERROR We're sorry. The trip planner is 

temporarily unavailable. Please try again 

later. 

3 OUTSIDE_BOUNDS Trip is not possible. You might be trying 

to plan a trip outside the map data 

boundary. 

4 REQUEST_TIMEOUT The trip planner is taking way too long to 

process your request. Please try again 

later. 

5 BOGUS_PARAMETER The request has errors that the server is 

not willing or able to process. 

6 PATH_NOT_FOUND Trip is not possible. Please check that 

you plan is within the bound of the map. 

7 NO_TRANSIT_TIMES 

No transit times available. The date may 

be past or too far in the future or there 

may not be transit service for your trip 

at the time you chose. 

8 GEOCODE_FROM_NOT_FOUND Origin is unknown. Can you be a bit more 

descriptive? 

9 GEOCODE_TO_NOT_FOUND Destination is unknown. Can you be a bit 

more descriptive? 

10 GEOCODE_FROM_TO_NOT_FOUND Both origin and destination are unknown. 

Can you be a bit more descriptive? 

11 TOO_CLOSE Origin is within a trivial distance of the 

destination. 

12 GEOCODE_FROM_AMBIGUOUS The trip planner is unsure of the location 

you want to start from. Please select from 

the following options, or be more 

specific. 

13 GEOCODE_TO_AMBIGUOUS The trip planner is unsure of the 

destination you want to go to. Please 

select from the following options, or be 

more specific. 

14 GEOCODE_FROM_TO_AMBIGUOUS The trip planner is unsure of the 

destination you want to go to. Please 

select from the following options, or be 

more specific. 

Από τα σφάλματα αυτά, τα 8, 9, 10, 12, 13, 14 δεν αφορούν την παρούσα Εφαρμογή, αφού ως 

Geocoder χρησιμοποιείται η υπηρεσία της Google από την εφαρμογή χρήστη. Γενικότερα πάντως, η 

διαχείριση των σφαλμάτων είναι θέμα της εφαρμογής χρήστη. 

180


6.4.6 Εύρεση Εναλλακτικών Γραμμών. 

Σο routing engine δίνει μία μόνο Γραμμή (σε συγκεκριμένη χρονική στιγμή) η οποία συνδέει τις δύο 

στάσεις ενός τμήματος μίας Πρότασης Σαξιδίου. ΋μως στην πράξη, όπως λειτουργεί το σύστημα 

ΜΜΜ της Αθήνας, όπου δεν υπάρχουν ιδιαίτερα συγκεκριμένοι χρόνοι για τις διελεύσεις των 

οχημάτων από τις στάσεις, είναι σκόπιμο ο Φρήστης να γνωρίζει και τις υπόλοιπες Γραμμές που 

συνδέεουν το ζεύγος στάσεων του κλάδου, έτσι ώστε σε περίπτωση που κάποιο όχημα των Γραμμών 

αυτών διέλθει από την στάση που αναμένουν, να επιβιβαστεί σε αυτό, και να μην περιμένει μόνο για 

όχημα της Γραμμής που δίνει σαν απάντηση ο OTP (και που θεωρητικά θα διέλθει πρώτο). Άλλωστε, 

οι χρόνοι διαδρομής μεταξύ δύο στάσεων για όλες τις Γραμμές του ΟΑ΢Α είναι πρακτικά ίδιοι, με 

σπάνιες διαφοροποιήσεις όταν υπάρχουν γραμμές Express που δεν κάνουν όλες τις ενδιάμεσες 

στάσεις. 

Η εύρεση των εναλλακτικών Γραμμών γίνεται στον Tsoop! Server, με χρήση ενός πίνακα βάσης 

δεδομένων σε PostgreSQL. Ο πίνακας αυτός περιέχει για κάθε Γραμμή και κατεύθυνση την 

αλληλουχία των στάσεων της διαδρομής. Ένα απόσπασμα του εν λόγω πίνακα έχει ως εξής: 

΋πως φαίνεται, περιέχονται πεδία που αφορούν: 

την σύντομη ονομασία της κάθε Γραμμής, 

τα headsigns που μπορεί να περιέχονται για κάποια Γραμμή, που πρακτικά 

αντιστοιχούν σε παραλλαγές της Γραμμής. Για παράδειγμα, η Γραμμή ‗M3‘ του 

metro έχει δύο παραλλαγές στην μία κατεύθυση: προς Δουκ. Πλακεντίας 

(‗PLAKENTIAS‘) και προς τον Αερολιμένα (‗AIRPORT‘). 

Σην κατεύθυνση της Γραμμής (‗0‘: Αφετηρία προς Σέρμα, ‗1‘: Σο αντίστροφο), 

Σην σειρά της κάθε στάσης στην Αλληλουχία, 

181


Σον κωδικό της στάσης, 

Σο είδος της επιβίβασης/αποβίβασης (επτρεπόμενη ή όχι). 

Ο πίνακας αυτός (‗otproutestops‘) έχει 22036 εγγραφές σύμφωνα με το τελευταίο Feed. Κλειδί του 

πίνακα είναι ο συνδυασμός των πεδίων (route_short_name, direction_id, trip_headsign, 

stop_sequence), ενώ ως index έχουν χρησιμοποιηθεί συνδυασμένα τα πεδία: route_short_name, 

stop_id, direction_id, trip_headsign, stop_sequence, pickup_type, drop_off_type, agency_id. Αυτό 

έχει πρακτικό νόημα, καθώς δεν υπάρχουν συχνές ενημερώσεις των στοιχείων του πίνακα. 

Η πρόσβαση στον εν λόγω πίνακα από τον client γίνεται μέσω PHP αρχείου που εκτελείται από τον 

Tsoop! HTTP Server. ΢το αρχείο δίνονται URL-encoded η Γραμμή από τον OTP, το headsign, ο 

κωδικός της στάσης προέλευσης, κι ο κωδικός της στάσης προορισμού. Σο PHP αρχείο 

πραγματοποιεί ένα SQL ερώτημα στην PostgreSQL, κι επιστρέφει σε μορφή XML την λίστα με τις 

εναλλακτικές Γραμμές και τις παραλλαγές τους που συνδέουν το ζεύγος των στάσεων. 

Διάγραμμα 10: Οι εναλλακτικές συνδέσεις μεταξύ δύο στάσεων βρίσκονται μέσω PHP αρχείου που 

κάνει SQL ερώτημα σε πίνακα της PostgreSQL. 

Το SQL Query όπωσ εκφράηεται μζςα ςτθν PHP ζίναι: 

"SELECT t1.route_short_name, t1.trip_headsign 

FROM otproutestops as t1, otproutestops as t2 

WHERE (t1.route_short_name'$route' OR (t1.route_short_name='$route' AND 

t1.trip_headsign'$headsign')) AND t1.stop_id='$fromStop' AND 

t2.stop_id='$toStop' AND (t2.stop_sequence>t1.stop_sequence AND 

t1.route_short_name=t2.route_short_name AND 

t1.trip_headsign=t2.trip_headsign AND t1.direction_id=t2.direction_id) AND 

t1.pickup_type=0 AND t2.drop_off_type=0 

;" 

Client Εφαρμογι 

PHP 

ςτον Tsoop! HTTP Server 

'otproutestops' πίνακασ 

ςε PostgreSQL 

182


΋που με $ είναι οι αντίστοιχες μεταβλητές στις οποίες έχουν δοθεί τιμές από την URL κλήση. Π.χ. μία 

απάντηση είναι η εξής: 

 

 

 

 

 

 

 

 

 

 

 

837 

 

839 

 

η οποία περιέχει δύο Γραμμές, την ‗837‘ και την ‗839‘. Η ψευδοεγγραφή στην αρχή χρησιμοποιείται 

για λόγους συμβατότητας με το Flex σε περίπτωση που δεν υπάρχει ούτε μία εναλλακτική Γραμμή. 

6.4.7 Φρήση Σης Τπηρεσίας Google Directions. 

Σο ερώτημα για την Google Directions είνα ένα HTTP URL στην ακόλουθη μορφή: 

http://maps.googleapis.com/maps/api/directions/output?parameters 

όπου: 

output 

Είναι η αιτούμενη μορφοποίηση των αποτελεσμάτων, σε xml ή json μορφή. 

Και οι παράμετροι: 

183


origin (απαιτείται) 

Η αφετηρία ως διεύθυνση σε αλφαριθμητική μορφή, ή ως ζεύγος γεωγραφικών 

συντεταγμένων. 

destination (απαιτείται) 

Ο προορισμός ως διεύθυνση σε αλφαριθμητική μορφή, ή ως ζεύγος γεωγραφικών 

συντεταγμένων. 

mode (προαιρετικά) 

Προσδιορίζει τον επιθυμητό τρόπο ταξειδίου. Μπορεί να είναι driving, walking, ή bicycling 

(μόνο για τις USA προς το παρόν). ΢την παρούσα χρησιμοποιείται μόνο το ‗driving‘. 

waypoints (προαιρετικά) 

Καθορίζει μία λίστα από ενδιάμεσα σημεία διαδρομής (waypoints). Σα σημεία μπορούν να 

δίνονται όμοια με την αφετηρία ή τον προορισμό, ως διευθύνσεις ή ως ζεύγη γεωγραφικών 

συντεταγμένων. ΢την παρούσα δεν υπάρχει ενδιαφέρον για ενδιάμεσα σημεία. 

alternatives (προαιρετικά) 

Εάν τεθεί true, τότε τα αποτελέσματα περιέχουν παραπάνω από μία προτάσεις διαδρομών, 

αυξάνοντας όμως τον χρόνο απόκρισης από τον server. ΢την παρούσα είναι πάντα false. 

avoid (προαιρετικά) 

Καθορίζει ότι η προτεινόμενη διαδρομή θα πρέπει να αποφεύγει τα στοιχεία που δίνονται. 

Προς το παρόν υπολογίζονται τα στοιχεία διόδια (tolls) και αυτοκινητόδρομοι (highways). 

Δεν χρησιμοποείται στην παρούσα αφού αφορά μόνο διαδρομές πεζή. 

units (προαιρετικά) 

Καθορίζει τις μονάδες μέτρησης στα αποτελέσματα. Δυνατές επιλογές είναι σε ‗metric‘ για 

το μετρικό, ή ‗imperial‘ για το αγγλοσαξονικό σύστημα (σε feets). Η παραμετροποίηση 

επηρεάζει μόνο τις οδηγίες καθοδήγησης σε μορφή κειμένου που περιέχονται στην 

απάντηση, καθώς όλα τα υπόλοιπα στοιχεία είναι πάντα σε μέτρα. 

184


Επιπλέον, το ερώτημα δέχεται όπως και το Geocoding API τις παραμέτρους που τροποποιούν την 

προτεραιότητα των αποτελεσμάτων στο geocoding για ορθογώνιο πολύγωνο ή χώρα, όπως και για 

την γλώσσα και τον αισθητήρα θέσης. Δεν χρησιμοποείται όμως η δυνατότητα αυτή στην παρούσα 

Εφαρμογή, καθώς δίνονται πάντα ζεύγη συντεταγμένων. 

Σα αποτελέσματα περιέχουν δύο στοιχεία: το ‗status‘ και το ‗routes‘. ΢το ‗status‘ 

περιγράφεται η απόκριση του server στο ερώτημα, πρόκειται δηλαδή για το πεδίο που περιέχει την 

τιμή ‗OK‘ αν έχει βρεθεί απάντηση΄, ή μία άλλη τιμή που αναφέρεται σε λάθος ή πρόβλημα. 

Αν το ‗status‘ είναι ‗OK’, τότε στο στοιχείο ‗route‘ περιέχονται τα αποτελέσματα για την διαδρομή (ή 

τις διαδρομές εάν έχει επιλεγεί το να παρουσιάζονται εναλλακτικές). Ένα παράδειγμα 

αποτελέσματος σε json είναι το εξής: 

(με ερώτημα: 

http://maps.googleapis.com/maps/api/directions/json?origin=37.95,23.7 

5&destination=38,24&mode=walking&language=en&sensor=false 

): 

"status": "OK", 

"routes": [ { 

"summary": "Mesogeion/Μεζογείων and Leoforos Marathonos/Λεωθόπορ 

Μαπαθώνορ", 

"legs": [ { 

"steps": [ { 

"travel_mode": "WALKING", 

"start_location": { 

}, 

"lat": 37.9500600, 

"lng": 23.7501500 

"end_location": { 

}, 

"lat": 37.9499500, 

"lng": 23.7502200 

"polyline": { 

}, 

"points": "{bsfFmu}oCTM", 

"levels": "BB" 

"duration": { 

"value": 16, 

185


}, 

"text": "1 min" 

"html_instructions": "Head \u003cb\u003esoutheast\u003c/b\u003e on 

\u003cb\u003eE. Karagiorgou/Ε. Καπαγιώπγος\u003c/b\u003e toward 

\u003cb\u003eKerasountos/Κεπαζούνηορ\u003c/b\u003e", 

"distance": { 

} 

}, { 

"value": 14, 

"text": "14 m" 

Όμοια για ηα ςπόλοιπα βήμαηα: 

. 

. 

. 

. 

} ], 

"travel_mode": "WALKING", 

"start_location": { 

"lat": 37.9499500, 

"lng": 23.7502200 

"start_address": "E. Karagiorgou 3-5, Ymittos 17236, Greece", 

"end_address": "Boumpoulinas, Artemida 19016, Greece", 

"via_waypoint": [ ] 

"copyrights": "Map data ©2010 Tele Atlas", 

"overview_polyline": { 

"points": 

"{bsfFmu}oCTMyAMJaBkK{@{Cc@YFm@|@_D[}@Ea@FmAjB{FaDsPyHuBkAsAd@sHsGa@n@{IwDoF 

xEyCkGe@qA{BkEc@|@g@a@e@QqR{DyH_COlAqByCwC{BsFcDyJcFmD}A}N}HiAcA_@aB_BfAm@gB 

oN|IiAaDcAw@kEuByAeCkFaFuEuF_@?k@Pa@[eEgJaCkDkEqFcFcPwA{DcBgDqJcOaCmFyDuGaGe 

JwHeKgDwFsDmI_B}F_AiEeB_GaF}IaJgMoAkCkFoS}@yIaAqEcE_OqEkMwCmH{AsE}@sE}Foa@gF 

wXYeEw@_e@DwPHuCzDk[d@aDj@aCAc@lGkQViAdCoc@`BwPt@_Ez@{Kp@cGfB_LlCyL~@iFhA{Px 

Eea@VsAzAcPl@oI~@yFzBsKzAiJJeC@{\\t@mFBqAGoBe@wD_De_@IcEPoCLaAH@Ly@hCuUzCib@ 

n@uNNe_@JiFHu@\\aAb@s@hAw@lGqCZ[r@sApB}JbGw_@r@yGj@_IKuIi@oRYiGc@qEgGkXwHcSq 

BeIwB_L{EqTqJce@e@sCS{E]sCkDmKw@kHi@yC}DkLUeB@qAh@{JCwA_@yCeAuDuF_MaBoEw@}E@ 

]~AoFfAqGVc@b@UvDu@LO`EyPfAmBbAkC~BoCdGaKb@_FbAiEfAyCn@yCdAsCzBoKbNah@tC}M`@ 

gCVmDFcFQ_@LuBEa@gFeD", 

"levels": 

"B??@?@?????@??????@@??@?????@???????@??@????????A?????@?????@???@??@??????@ 

??A???@?????@????@??????????@???@???@?????@??@??????@???A???@??@?????????@?? 

??@???A??@???@@???@??????@???@??@B" 

}, 

186


"warnings": [ "Walking directions are in beta. Use caution – This 

route may be missing sidewalks or pedestrian paths." ], 

} 

} ] 

"waypoint_order": [ ] 

΋πως φαίνεται και στο παραπάνω τυχαίο παράδειγμα, παρέχονται τόσο συνοπτικά, όσο και 

αναλυτικά αποτελέσματα. ΢ε κάθε βήμα παρέχονται τόσο οι γεωγραφικές συντεταγμένες αρχής- 

τέλους, ο απαιτούμενος χρόνος και το μήκος διαδρομής, αλλά κι επιπλέον html διαμορφωμένες 

οδηγίες κειμένου για την πραγματοποίηση του βήματος. 

Επίσης, παρέχονται τα στοιχεία των encoded poylylines για τα βήματα ή το σύνολο της διαδρομής. 

Οι encoded polylines περιγράφονται από αλφαριθμητικά data, ένα string χαρακτήρων, τα οποία 

δίνουν την πληροφορία θέσης και την πληροφορία για το επίπεδο κλίμακας μέχρι το οποίο θα γίνεται 

η απεικόνιση κάθε σημείου-κόμβου. Η διαδικασία κωδικοποίησης μετατρέπει μία δυαδική τιμή σε μία 

σειρά κωδικών χαρακτήρων ASCII χρησιμοποιώντας το σχήμα base64. Για την εξοικονόμηση χώρου, 

σε κάθε σημείο (εκτός του πρώτου) δίνεται η πληροφορία της μετακίνησης από το προηγούμενο, και 

όχι η απόλυτη θέση. 

Η ύπαρξη διαφορετικών τιμών για την απεικόνιση ανάλογα με την κλίμακα, επιτρέπει την γενίκευση 

της καμπύλης, είτε αυτό αφορά τη μορφή της, δηλαδή περιορισμό των εμφανιζόμενων θλάσεων, είτε 

το συνολό της, δηλαδή την εμφάνισή της ή όχι. 

187


6.4.8 ΢υνοπτικό Διάγραμμα Σης Δομής Σου ΢υστήματος Και Σων 

΢υνδέσεων. 

΢το Διάγραμμα που ακολουθεί παρουσιάζεται συνοπτικά και σχηματικά η δομή του συστήματος της 

Εφαρμογής και οι συσχετίσεις μεταξύ των διαφόρων τμημάτων, όπως προκύπτει με βάσει τα όσα 

έχουν αναφερθεί. 

MAPS DIRECTIONS GEOCODING 

PostgreSQL Server 

Εφρεςθ Εναλλακτικών Γραμμών 

PHP 

APACHE 

HTTP SERVER 

TOMCAT SERVER 

Routing Engine 

Διάγραμμα 11: ΢χηματική παράσταση των διαφόρων τμημάτων του συστήματος της 

Εφαρμογής και οι συνδέσεις μεταξύ τους. 

188


6.4.9 Προγραμματιστική Δομή Σης Εφαρμογής Φρήστη & ΢υνδέσεις. 

6.4.9.1 Σα States ΢το Flex. 

Κάτι ιδιαίτερα χρήσιμο στο FLEX είναι η ύπαρξη States. Κάθε State είναι μία συγκεκριμένη 

κατάσταση της εφαρμογής, όπου όλα τα αντικείμενα έχουν συγκεκριμένες ιδιότητες, όπως π.χ. 

εμφάνιση, χρώμα, μέγεθος, είναι ενεργά ή μη, κτλ.. ΢ε κάθε State δεν υπάρχουν διαφορετικά 

instances των αντικειμένων, αλλά τα ίδια αντικείμενα με διαφορετικές ιδιότητες. Αυτό επιτρέπει με 

τον ίδιο κώδικα να γίνεται διαχείριση διαφορετικών οπτικών απεικονίσεων, οι οποίες να ταιριάζουν 

σε διάφορες συσκευές λειτουργίας, όπως π.χ. desktop υπολογιστές με μεγάλες οθόνες, ή κινητά 

τηλέφωνα με πολύ μικρές οθόνες και αναλύσεις. Η εναλλαγή από το ένα State στο άλλο γίνεται με 

μία απλή εντολή στον κώδικα, οπότε είναι ιδιαίτερα εύκολη η διαχείριση διαφορετικών καταστάσεων 

λειτουργίας της εφαρμογής. 

Για την παρούσα εφαρμογή ορίστηκαν τα εξής States που αντιστοιχούν στην λειτουργική ροή που 

αναφέρθηκε, και στα επιμέρους: 

«Welcome»: Αφορά το στάδιο της Αρχικοποίησης, κατά το οποίο εμφανίζεται μία 

splash εικόνα, μαζί με κάποια μηνύματα σημαντικού κι άμεσου ενδιαφέροντος για 

τον Φρήστη, όπως π.χ. παρατηρούμενες ή αναμενόμενες δυσλειτουργίες των 

ΜΜΜ. 

«Options»: Αφορά το στάδιο της παραμετροποίησης ερωτήματος. ΢ε αυτό ανήκουν 

και τα δύο επόμενα states: 

o «Geocoding»: Είναι η λειτουργία της παραμετροποίησης που επιτρέπει την 

επιλογή από λίστα των αποτελεσμάτων του Geocoding μίας διεύθυνσης ή 

ενός ζεύγους συντεταγμένων για τον ορισμό της προέλευσης ή του 

προορισμού. 

o «SelectPOI»: ΋μοια με το Geocoding, επιτρέπει την επιλογή της 

προέλευσης ή του προορισμού από μία κατηγοριοποιημένη λίστα σημείων 


189


«Please Wait»: Σο State αυτό αντιστοιχεί στις λειτουργίες θέσης ερωτήματος και 

λήψης απάντησης από την την Εφαρμογή προς και από τους Servers. Κατά τα 

στάδια αυτά ο Φρήστης δεν μπορεί να παρέμβει, κι έτσι το state αφενός 

απενεργοποιεί τις διάφορες άλλες λειτουργίες, αφετέρου ενημερώνει τον Φρήστη 

για την απαιτούμενη αναμονή και την εξέλιξη της διαδικασίας. 

«Suggestions»: To State αυτό αντιστοιχεί στην διαχείριση των απαντήσεων. Έτσι, 

παρέχονται οι προτάσεις ταξιδίου για ενναλάξ θέαση, και δίνονται οι επιλογές για 

τροποποίηση του ερωτήματος, δημιουργίας ενός τελείως καινούριου, ή τέλος, 

εκτύπωσης κάθε μίας εκ των προτάσεων ταξιδίου. 

«Print»: Πρόκειται για το State κατά το οποίο γίνεται η εκτύπωση σε αρχείο PDF της 

κάθε πρότασης ταξιδίου. 

«About»: ΢το State αυτό γίνεται εμφάνιση ενός pop-up παραθύρου, το οποίο 

περιέχει κάποιες βασικές πληροφορίες σχετικά με την Εφαρμογή. Η έξοδος από το 

state αυτό οδηγεί κάθε φορά στο state από το οποίο έγινε η κλήση. 

«Contact»: ΢το State αυτό εμφανίζεται όπως και στο ‗About‘ ένα pop-up παράθυρο, 

μέσω του οποίου μπορεί ο Φρήστης να επικοινωνήσει με τους λειτουργούς της 

Τπηρεσίας. Η έξοδος από το state γίνεται όμοια προς το state που έκανε την 

κλήση. 

΢την παρούσα Εφαρμογή έχουν αναπτυχθεί αντίστοιχα States τόσο για μεγάλες οθόνες κι 

αναλύσεις, όσο και για μικρότερες, όπως π.χ. για netbooks. Η χρήση του κάθε προγραμματιστικού 

state που αντιστοιχεί στα παραπάνω λογικά states επιλέγεται από τον ίδιο τον κώδικα, ανάλογα με 

το αναγνωρισμένο μέγεθος του περιβάλλοντος που παρέχει ο browser. Η διαφοροποίηση έγκειται 

κυρίως στον απαιτούμενο χώρο των παραθύρων της Εφαρμογής στην οθόνη, όπου στα states 

μικρής οθόνης έχει γίνει προσπάθεια εξοικονόμησης χώρου, με όσο το δυνατόν μικρότερη απώλεια 

λειτουργικότητας και αισθητικής. Σα states αυτά θεωρητικά είναι συμβατά και με κινητά τηλέφωνα 

με οθόνη μεγάλης σχετικά ανάλυσης. 

Μέχρι την στιγμή της ολοκλήρωσης της Εφαρμογής υπήρχε σύγχυση σχετικά με την δυνατότητα να 

εκτελείται αυτή, όπως και όλες οι υπόλοιπες εφαρμογές Flex, σε κινητό τηλέφωνο. ΢υσκευές που 

διαφημίζονται ως Flash Capable έχουν περιορισμένη συμβατότητα, κι ελάχιστες είναι αυτές που 

πραγματικά κάνουν αυτό που ισχυρίζονται. ΋μως η τάση στην αγορά είναι για άμεση κυκλοφορία 

πλήρως Flash Capable συσκευών, είτε μέσω Browser είτε Air, και η ίδια η Adobe προτίθεται σύντομα 

να κυκλοφορήσει το νέο Flex με πρόσθετα νέα στοιχεία που θα αφορούν κινητά τηλέφωνα, μεταξύ 

άλλων π.χ. την αξιοποίηση του ενσωματωμένου GPS. 

190


Λόγω λοιπόν των αναμενόμενων σύντομα εξελίξεων, δεν έγινε παραπέρα προσπάθεια προσαρμογής 

σε κινητά τηλέφωνα, δόθηκε όμως προσοχή ώστε να είναι εύκολη η μελλοντική επέκταση της 

Εφαρμογής. Επαναλαμβάνεται εξάλλου ότι πιθανόν η Εφαρμογή να εκτελείται χωρίς προβλήματα 

και σε κάποια από τα ήδη κυκλοφορούντα κινητά, χωρίς αυτό όμως να έχει εξεταστεί. 

6.4.9.2 Αντικείμενα (Objects) που χρησιμοποιούνται. 

Με την έννοια αντικείμενα αναφέρονται οι διάφορες δομές οι οποίες μπορούν να συγκρατούν 

δεδομένα ή/και να δημιουργούν ιδιότητητες και μεθόδους., όπως είναι τα Classes, τα Arrays, τα 

ArrayLists, ArrayCollections, κ.α.. ΋λα αυτά τα αντικείμενα μπορούν να είναι προσβάσιμα είτε μόνο 

από την function που τα δημιούργησε ως instance, είτε από το σύνολο του κώδικα, όντας δηλωμένα 

ως public. 

Δύο κύρια αντικείμενα που υπάρχουν στην Εφαρμογή Φρήστη είναι αυτά που αφορούν τα σημεία 

Προέλευσης και Προορισμού. Σα αντικείμενα αυτά είναι instances ενός class το οποίο έχει ως 

ιδιότητες την ονομασία και τις συντεταγμένες, πλάτος και μήκος. Για κάθε ένα από τα αντικείμενα 

αυτά υπάρχει κι ένας Marker (πράσινου και κόκκινου χρώματος αντίστοιχα) ο οποίος επισημαίνει την 

τοποθεσία στον Φαρτη. Ένα άλλο αντικείμενο που χρησιμοποιείται στο σύνολο της Εφαρμογής είναι η 

χρονική στιγμή, η οποία μπορεί να αφορά είτε την αναχώρηση από την αφετηρία, είτε την άφιξη 

στον προορισμό. Πρόκειται για μία μεταβλητή τύπου Date. 

Αντικείμενα αποτελούν και οι απαντήσεις που λαμβάνονται για τα διάφορα HTTP ερωτήματα. Σο ίδιο 

το Flex, κατά την διαδικασία ορισμού των data συνδέσεων δημιουργεί κλάσεις και υποκλάσεις που 

αντιστοιχούν στους τύπους δεδομένων των διαφόρων πεδίων. Οι συνδέσεις που έχουν οριστεί είναι 3: 

Η πρώτη αφορά την σύνδεση με το routing engine, η δεύτερη την σύνδεση με την υπηρεσία 

Geocoding της Google, και η τρίτη, την σύνδεση με την PostgreSQL για την εύρεση των 

εναλλακτικών Γραμμών. 

Ακόμη ένα αντικείμενο, το οποίο περιέχει τις απαντήσεις που αφορούν την πλοήγηση, είναι η 

συλλογή των Προτάσεων Σαξιδίου. Κάθε Πρόταση Σαξιδίου (JourneyProposal ονομάζεται εδώ, αφού 

θα μπορούσε και να απορριφθεί σε μετεπεξεργασία) είναι κι αυτή ένα αντικείμενο, το οποίο ανήκει 

στην συλλογή κι έχει ως αντικείμενα-μέλη τους κλάδους που αποτελούν κάθε τμήμα της Πρότασης. 

Σα τελευταία δομικά αντικείμενα περιέχουν τις πληροφοριές για την οπτικοποίηση του τμήματος, 

όπως επίσης το κείμενο των εναλλακτικών Γραμμών που μπορούν να χρησιμοποιηθούν. Οι λεκτικές 

οδηγίες περιέχονται μόνο στον container που τις οπτικοποιεί, δηλαδή σε Vbox με RichText για κάθε 

λεκτική οδηγία/πληροφορία. 

191


Τπάρχουν κι άλλα αντικείμενα που χρησιμοποιούνται, χωρίς όμως σημαντική εννοιολογική σημασία, 

και για αυτό δεν γίνεται ιδιαίτερη αναφορά σε αυτά. Πρόκειται για αντικείμενα που εξυπηρετούν 

καθαρά προγραμματιστικούς σκοπούς. 

6.4.9.3 Αρχικοποίηση Σης Εφαρμογής Φρήστη. 

Η Εφαρμογή Φρήστη κατεβαίνει σε αυτόν από τον HTTP Server. Αυτό που πρώτα βλέπει ο browser 

είναι ένα HTML αρχείο, το οποίο κάνει έλεγχο της ύπαρξης του κατάλληλου Flash Player. Αν δεν 

υπάρχει η κατάλληλη έκδοση, τότε γίνεται προτροπή στον Φρήστη για το κατέβασμα και την 

εγκατάσταση. ΢την αντίθετη περίπτωση, εκκινάται η Flash εφαρμογή. Σο html αυτό αρχείο δίνει την 

δυνατότητα συγκέντρωσης κάποιων στατιστικών στοιχείων, όπως π.χ. για τημ προέλευση του χρήστη, 

τον browser και το λειτουργικό που χρησιμοποιεί, κτλ, αξιοποιώντας κάποια από τις υπάρχουσες 

υπηρεσίες που προσφέρονται ακόμη και δωρεάν (π.χ. Google Analytics ή StatCounter). 

Σο κατέβασμα του κυρίως κομματιού της Εφαρμογής διαρκεί μερικά δευτερόλεπτα, ανάλογα με την 

ταχύτητα σύνδεσης. Έχει γίνει προσπάθεια ώστε ακριβώς να μειωθεί ο χρόνος, τόσο για το 

κατέβασμα (το κυρίο αρχείο να μην περιέχει τα πάντα), όσο και για την πρώτη δημιουργία τού 

περιβάλλοντος χρήστη. Κατά αυτόν τον τρόπο η αναμονή φαίνεται αρκετά μικρότερη στον χρήστη, 

καθώς αυτός παρακολουθεί μία εξέλιξη στην οθόνη του. Σο κατέβασμα του κύριου αρχείου 

ενδεικνύεται από μία progress bar, η οποία θα μπορούσε να αντικατασταθεί από κάποιον preloader, 

ο οποίος να περιέχει γραφικά στοιχεία σχετικά με το αντικείμενο. Επειδή όμως ο χρόνος που 

απαιτείται είναι σχετικά μικρός σε συνήθεις ταχύτητες σύνδεσης, κρίθηκε πως κάτι τέτοιο δεν έχει 

ιδιαίτερο νόημα. 

Μέσα στην URL διεύθυνση με την οποία καλείται το Tsoop! είναι δυνατόν να περιέχονται 

παράμετροι οι οποίες χρησιμοποιούνται για τον προκαθορισμό των επιλογών. Περισσότερα για αυτές 

αναφέρονται στην σχετική παράγραφο. 

Μόλις ολοκληρώνεται το κατέβασμα, το Flex δημιουργεί τα αντικείμενα που διαμορφώνουν το 

αρχικό περιβάλλον της Εφαρμογής. Με την ολοκλήρωση και του Φάρτη, τότε αυτός κεντράρεται 

στην κατάλληλη περιοχή, αποκτώντας τα εργαλεία για το zoom και την επιλογή τύπου. 

Σο πρώτο state στο οποίο τίθεται η Εφαρμογή είναι το ‗Welcome‘, κατά το οποίο και παρουσιάζεται 

η αρχική splash εικόνα μαζί με τις ανακοινώσεις. Οι ανακοινώσεις προς το παρόν γίνονται compiled 

στο ίδιο το Flash αρχείο. ΢ε περίπτωση διαχωρισμού τού ποιός κάνει το compiling και ποιός 

διαχειρίζεται το σύστημα, τότε οι ανακοινώσεις θα μπορούσαν να περιέχονται σε ένα απλό 

ανεξάρτητο αρχείο κειμένου ή XML. 

192


6.4.9.4 Προκαθορισμός Επιλογών. 

Η μητρική HTML σελίδα προωθεί προς την Flash εφαρμογή και τις πιθανές σχετικές 

προκαθορισμένες τιμές στην παραμετροποίηση ερωτήματος, αν το link προς την Εφαρμογή 

προέρχεται από κάποιο site που προωθεί σε αυτήν για την εξυπηρέτηση μίας εγκατάστασης ή ενός 

γεγονότος, όπως π.χ. την πρόσβαση με ΜΜΜ σε ένα συνέδριο. 

Οι παράμετροι αυτές παρέχονται ως μεταβλητές μέσα στην URL διεύθυνση και είναι της εξής 

μορφής: 

http://site_address/tsoop/index.html# 

OriginDisplayText=origin_display_text;OriginLat=origin_lat;OriginLng=origin_ 

lng 

;DestinationDisplayText=destination_displaytext;DestinationLat=destination_l 

at;DestinationLng=destination_lng 

;Using=using_means;MaxWalkDist=maximum_walking_distance;Optimise=optimize;Ar 

riveOrDepart=arrive_or_depart;Date=date;Time=time 

Οι παράμετροι είναι λοιπόν: 

OriginDisplayText Σο κείμενο που θα εμφανίζεται ως τόπος προέλευσης. 

OriginLat Σο γεωγραφικό πλάτος του τόπου προέλευσης, σε WGS84 και στην 

μορφή: DD.ddddd. 

OriginLng Σο γεωγραφικό μήκος του τόπου προέλευσης, σε WGS84 και στην 


DestinationDisplayText Σο κείμενο που θα εμφανίζεται ως τόπος προορισμού. 

DestinationLat Σο γεωγραφικό πλάτος του τόπου προορισμού, σε WGS84 και στην 


DestinationLng Σο γεωγραφικό μήκος του τόπου προοορισμού, σε WGS84 και στην 


193


Using Σα μέσα που επιθυμείται να χρησιμοποιηθούν. Οι δυνατές τιμές είναι: 

ALL 

TRAINS 

BUSES 

WALKING 

MaxWalkDist Η μέγιστη επιθυμητή απόσταση για διαδρομή πεζή, σε μέτρα. 

Optimise Ο τρόπος βελτιστοποίησης. Οι δυνατές τιμές είναι: 

SOON 

TRANSFERS 

ArriveOrDepart Αν η χρονική στιγμή αφορά την αναχώρηση ή την άφιξη. Οι δυνατές τιμές 

είναι: 

DEPART 

ARRIVE 

Date Η ημερομηνία για την άφιξη ή την αναχώρηση, στην μορφή: 

DD.MM.YYYY. 

Time Η ώρα για την άφιξη ή την αναχώρηση, στην μορφή: ΗΗ:ΜΜ. 

Παράμετροι που δεν δίνονται τίθενται στις default τιμές τους. Οι παράμετροι OriginDisplayText και 

DestinationDisplayText θα πρέπει να είναι URL-encoded σε περίπτωση π.χ. που περιέχουν κενά 

διαστήματα. 

194


6.4.9.5 Γενική Διάταξη ΢την Οθόνη Κατά Σις Επιλογές. 

Αμέσως μετά την εισαγωγική spash εικόνα, η Εφαρμογή τίθεται στην κατάσταση Options. ΢την 

κατάσταση αυτή είναι δυνατή η επιλογή των διαφόρων στοιχείων, όπως είναι η προέλευση, ο 

προορισμός, η χρονική στιγμή, η βελτιστοποίηση, κτλ. Η οθόνη που εμφανίζεται στον Φρήστη έχει την 

εξής μορφή: 

Εικόνα 71: Η γενική διάταξη που πρωτοβλέπει ο Φρήστης. 

΋πως φαίνεται, κυρίαρχο στοιχείο είναι ο Φάρτης, αφού πάνω σε αυτόν επιτελούνται οι περισσότερες 

από τις λειτουργίες, όντας το κύριο μέσο επικοινωνίας με τον Φρήστη. Η οθόνη αποτελείται από ένα 

HBox, το οποίο περιέχει 2 στοιχεία: Σο αριστερό panel της κατακόρυφης στήλης, κι ένα 

BorderContainer. ΢την κατακόρυφη στήλη περιέχεται μία εικόνα με τα λογότυπα κτλ, κι ένα VGroup 

με τα κουμπιά για τις γενικές λειτουργίες. ΢τον BorderContainer περιέχονται ο Φάρτης, το panel με 

τις επιλογές, κι ένα toggle button για την εμφάνιση ή όχι του δικτύου metro. 

195


Διάγραμμα 12: Σα διάφορα αντικείμενα που αποτελούν την βασική οθόνη της Εφαρμογής, σε 

σχηματική παράσταση. 

6.4.9.6 Λειτουργίες ‗To/From About‘, ‗Transit in Athens‘, ‗About‘, ‗Help‘, και 

‗Contact‘. 

Οι λειτουργίες αυτές δεν έχουν κάποιο ιδιαίτερο προγραμματιστικό ενδιαφέρον. Για την About και 

την Contact ενεργοποιούνται τα ομώνυμα states, κατά τα οποία εμφανίζονται οι αντίστοιχες 

εικόνες. Για την επικοινωνία έχει υιοθετηθεί η μέθοδος του email, με άνοιγμα της εφαρμογής που 

χρησιμοποεί ο χρήστης για την διαχείριση και σύνταξη των μηνυμάτων του, ώστε να έχει ένα οικείο 

περιβάλλον, τουλάχιστον στις περιπτώσεις που χρησιμοποιεί τον δικό του υπολογιστή. Αυτό 

επιτυγχάνεται με κλήση ενός URL της μορφής mailto://person@domain. 

Για τις υπόλοιπες 3 λειτουργίες ανοίγει ένα καινούριο tab στον browser, το οποίο κατεβάζει το 

αρχείο που αντιστοιχεί σε κάθε μία από αυτές και περιέχει τις σχετικές πληροφορίες. 

196


6.4.9.7 Επιλογή Προέλευσης/Προορισμού με Geocoding. 

Πληκτρολογώντας μία διεύθυνση στο textbox που αντιστοιχεί στην προέλευση ή τον προορισμό, τότε 

η Εφαρμογή τίθεται στην κατάσταση ‗Geocoding‘, κι εμφανίζεται στον χρήστη μία λίστα με εώς και 

10 διευθύνσεις που ταιριάζουν σε αυτό που πληκτρολόγησε. Η λίστα εμφανίζεται από ένα DataGrid 

,στο οποίο έχει γίνει binded το αντικείμενο της απάντησης για το HTTP ερώτημα προς την υπηρεσία 

geocoding της Google. 

Ένα ερώτημα προς τον εξυπηρετητή μέσω HTTP έχει την ακόλουθη μορφή: 

http://maps.googleapis.com/maps/api/geocode/output?parameters 

όπου: 

output 

έιναι η αιτούμενη μορφοποίηση των αποτελεσμάτων, η οποία μπορεί να είναι είτε XML, είτε 

JSON (JavaScript Object Notation). Η δεύτερη μορφοποίηση ενδείκνυται περισσότερο, 

κυρίως λόγω του μειωμένου μεγέθους των data περιγραφής, και είναι αυτή που 

χρησιμοποείται. 

address (απαιτείται) 

Η διεύθυνση της οποίας ζητείται να βρεθεί η θέση στον χάρτη, ή σε μορφή κειμένου οι 

συντεταγμένες για την αντίστροφη λειτουργία. 

bounds (προαιρετικά) 

To ορθογώνιο παραλληλόγραμο μέσα στο οποίο θα επικεντρώνεται η λειτουργία. Κατά 

αυτόν τον τρόπο, μπορεί να δίνεται π.χ. προτεραιότητα στην εμφάνιση αποτελεσμάτων στην 

περιοχή της Αθήνας. Σο παραλληλόγραμμο ορίζεται από τις συντεταγμένες της 

Νοτιοδυτικής και της Βορειοανατολικής γωνίας. (π.χ. ‗37.70,23.45|38.2,24.05‘ είναι η 

τιμή που δίνεται για την περιοχή της Αθήνας). 

region (προαιρετικά) 

΋μοια με την παράμετρο bounds, προωθεί τα αποτελέσματα στον χώρο που καθορίζεται 

από τον κωδικό 2 χαρακτήρων των διευθύνσεων Internet . Π.χ. με το αλφαριθμητικό ‗gr‘ 

στην παραμετροποίηση, τα αποτελέσματα θα είναι εστιασμένα στην Ελλάδα. 

197


language (προαιρετικά) 

Επιλέγεται η γλώσσα των αποτελεσμάτων. Π.χ. με την παραμετροποίηση ‗en‘, τα 

αποτελέσματα θα είναι στην Αγγλική γλώσσα. Αν δεν δοθεί η παράμετρος, τότε τα 

αποτελέσματα επιστρέφονται ανάλογα με την χώρα στην οποία βρίσκεται το domain 

κλήσης. ΢την περίπτωσή μας, είναι απαραίτητο να τεθεί η παράμετρος, διαφορετικά σε 

έναν επισκέπτη της πόλης θα επιστρέφονταν τα αποτελέσματα μόνο στα ελληνικά εν όσο 

αυτός θα ήταν στην Ελλάδα, αφού θα χρησιμοποιούσε το Internet από ελληνικές IP 

διευθύνσεις. 

sensor (απαιτείται) 

Περιέχει την πληροφορία για το αν το ερώτημα προέρχεται από συσκευή με αισθητήρα 

θέσης (GPS). Η τιμή μπορεί να είναι true ή false. 

Ένα τυπικό παράδειγμα ερωτήματος της Εφαρμογής είναι το ακόλουθο: 

http://www.tsoopdomain.gr:8087/tsoop/Geocode.php?address=Aristotelous 

,22&bounds=37.70,23.45|38.20,24.05&language=en&sensor=false 

Η διαφοροποίηση που παρατηρείται οφείλεται στο ότι το ερώτημα υποβάλλεται με ενδιάμεσο την 

PHP στον HTTP Server του Tsoop!. ΢την πραγματικότητα το ερώτημα υποβάλλεται σε URL Encoded 

μορφή, έτσι ώστε να μπορούν να υπάρχουν π.χ. κενά διαστήματα. 

Σα αποτελέσματα που επιστρέφονται αφορούν 10 το πολύ διευθύνσεις, και σε μορφή JSON έχουν 

ενδεικτικά την εξής μορφή: 

(με το ερώτημα: 

http://maps.googleapis.com/maps/api/geocode/json?address=Aristotelous+22+Att 

iki&bounds=37.70,23.45|38.2,24.05&language=en&sensor=false: 

) 

198

{ 


"status": "OK", 

"results": [ { 

"types": [ "street_address" ], 

"formatted_address": "Aristotelous 22, Acharnes 13673, Greece", 

"address_components": [ { 

}, { 

}, { 

}, { 

}, { 

}, { 

}, { 

} ], 

"long_name": "22", 

"short_name": "22", 

"types": [ "street_number" ] 

"long_name": "Aristotelous", 

"short_name": "Aristotelous", 

"types": [ "route" ] 

"long_name": "Acharnes", 

"short_name": "Acharnes", 

"types": [ "locality", "political" ] 

"long_name": "East Attica", 

"short_name": "East Attica", 

"types": [ "administrative_area_level_2", "political" ] 

"long_name": "Attica", 

"short_name": "Attica", 

"types": [ "administrative_area_level_1", "political" ] 

"long_name": "Greece", 

"short_name": "GR", 

"types": [ "country", "political" ] 

"long_name": "13673", 

"short_name": "13673", 

"types": [ "postal_code" ] 

"geometry": { 

"location": { 

}, 

"lat": 38.0835003, 

"lng": 23.7302642 

"location_type": "RANGE_INTERPOLATED", 

"viewport": { 

"southwest": { 

"lat": 38.0803528, 

199

} 

}, { 

}, 


}, 

"lng": 23.7271068 

"northeast": { 

} 

"lat": 38.0866480, 

"lng": 23.7334021 

"bounds": { 

} 

"southwest": { 

}, 

"lat": 38.0835003, 

"lng": 23.7302447 

"northeast": { 

} 

"lat": 38.0835005, 

"lng": 23.7302642 

Σςνέσεια με άλλερ 9 διεςθύνζειρ καηά όμοιο ηπόπο: 

. 

. 

. 

. 

} 

"types": [ "street_address" ], 

"formatted_address": "Aristotelous 22, Athens 10433, Greece", 

} 

} ] 

} 

} 

΋πως γίνεται φανερό από το παραπάνω δείγμα, τα επιστρεφόμενα αποτελέσματα, περιέχουν τα 

στοιχεία της διεύθυνσης, τόσο συνοπτικά, όσο και αναλυτικά (οδό, αριθμό, ταχυδρομικό κώδικα), 

όπως επίσης τις συντεταγμένες, το είδος της θέσης ( οδός, περιοχή, σημείο ενδιαφέροντος, κ.α.), και 

την ακρίβεια της θέσης (π.χ. ‗RANGE_INTERPOLATED‘ που σημαίνει ότι το αποτέλεσμα είναι 

παρεμβολή στην αρίθμηση της οδού από διασταύρωση σε διασταύρωση). 

200


Εκτός από αυτήν την μορφή ερωτήματος και αποτελέσματος, το Google Geocoding παρέχει και 

λειτουργία μέσω SOAP (Simple Object Access Protocol). ΢την λειτουργία αυτή τα αποτελέσματα 

διαφοροποιούνται, αφού παρέχονται (σε μορφή KML), στοιχεία για την τοποθέτηση Placemarks 

πάνω στον χάρτη. Σο Adobe Flex κανονικά μπορεί να κάνει χρήση μόνο της SOAP λειτουργίας, 

καθώς διαφορετικα απαιτείται η ύπαρξη ενός αρχείου παροχής άδειας πρόσβασης στον server για 

την IP διεύθυνση του client, κάτι που παρακάμπτεται με χρήση της PHP ως ενδιάμεσου. 

Μόλις ο χρήστης επιλέξει κάποιο αντικείμενο της λίστας του DataGrid, τότε τοποθετείται ο 

προσωρινός Marker στην αντίστοιχη τοποθεσία, ενώ και ο Φάρτης κεντράρεται στην τοποθεσία 

αυτή. Αν ο χρήστης επιλέξει άλλο αντικείμενο, τότε γίνεται νέα τοποθέτηση του Μarker και νέο 

κεντράρισμα του χάρτη. Αν τελικά ο χρήστης βρει την τοποθεσία που θέλει, τότε πατώντας στο 

κουμπί ‗ΟΚ‘, to state της εφαρμογής γίνεται ‗Options‘ και τα στοιχεία του geocoding τίθονται ως 

στοιχεία προέλευσης ή προορισμού. Επίσης, ενημερώνονται το textbox και ο Marker επί του Φάρτη 

με το πράσινο ή κόκκινο χρώμα για την προέλευση και τον προορισμό αντίστοιχα. 

Ας σημειωθεί πως τα textboxes για την προέλευση και τον προορισμό είναι διπλά, άσχετα αν ο 

χρήστης βλέπει μόνο ένα ανά περίπτωση. Σο ένα textbox έχει binded την διεύθυνση η οποία είναι 

πράγματι έγκυρη, ενώ το άλλο textbox είναι αυτό στο οποίο ο χρήστης εισάγει την διεύθυνση προς 

geocoding. Με αυτόν τον τρόπο εξασφαλίζεται ότι στον χρήστη εμφανίζεται πάντα μία έγκυρη 

διεύθυνση, κι όχι οι διευθύνσεις π.χ. που δεν αντιστοιχούν πουθενά, έχουν μισο-συμπληρωθεί, κτλ.. 

6.4.9.8 Επιλογή Προέλευσης/Προορισμού Με Επιλογή Από ΢ημεία 

Ενδιαφέροντος. 

Ο Φρήστης μπορεί να επιλέξει μία τοποθεσία ως προέλευση ή προορισμό από μία κατηγοριοποιημένη 

λίστα σημείων ενδιαφέροντος (Points Of Interest: POIs). Για να το κάνει αυτό χρειάζεται να πατήσει 

σε ένα από τα δύο κουμπιά ‗POIs‘, δίπλα στα textboxes προέλευσης και προορισμού. Σότε η 

κατάσταση της Εφαρμογής τίθεται στο state ‗POIsSelection‘ κι εμφανίζεται ένα παράθυρο με ένα 

Tree και δύο κουμπιά: ‗ΟΚ‘ και ‗None of Them‘. 

Μέσα στο tree εμφανίζονται κατηγοριοποιημένα τα διάφορα σημεία ενδιαφέροντος. Η λίστα των 

σημείων περιέχεται αυτή την στιγμή εντός του βασικού Flash αρχείου, σε δομή XMLList. Αυτό έγινε 

λόγω του περιορισμένου μεγέθους που έχουν τα ενδεικτικά δεδομένα. ΢ε περίπτωση μεγάλης 

αύξησης του αριθμού των σημείων (δυστυχώς δεν υπήρχε κάποιο σχετικό dataset διαθέσιμο κατά 

την υλοποίηση), τότε τα δεδομένα αυτά θα πρέπει να τηρηθούν σε εξωτερικό XML αρχείο στον 

Server, έτσι ώστε να μην καθυστερεί πιθανόν άσκοπα το download και η πρώτη εμφάνιση της 

201


Εφαρμογής στον Φρήστη. Αυτό είναι απαραίτητο βέβαια και στην περίπτωση που υπάρχει διαφορά 

ανάμεσα στο ποιός κάνει το compiling και ποιός διαχειρίζεται το σύστημα. 

Ένα δείγμα της XMLList είναι το εξής: 

 

 

 

 

 


Κάθε ένα από τα ενεργά αντικείμενα έχει εναν event listener, μέσω του οποίου μπορούν να 

παρακολουθούνται διάφορα συμβάντα. ΢την συγκεκριμένη περίπτωση παρακολουθείται το click, 

οπότε όταν αυτό συμβαίνει, εκετελείται η σχετική function. Από αυτήν ανοίγει ένα InfoWindow μέσω 

του οποίου ο Φρήστης μπορεί να επιλέξει την επιλογή τού σημείου ως προέλευση ή προορισμό. 

Μετά την επιλογή αυτή, ενημερώνονται κατάλληλα τα αντικείμενα της προέλευσης και του 

προορισμού, οι σχετικοί Markers, τα textboxes, και η Εφαρμογή τίθεται εκ νέου στην κατάσταση 

‗Options‘. 

6.4.9.10 Επιλογή Προέλευσης/Προορισμού Με Λειτουργίες Φάρτη. 

Ένας εύκολος κι άμεσος τρόπος επιλογής μιας τοποθεσίας ως προέλευσης ή προορισμού είναι το να 

την δείξει κάποιος στον Φάρτη. Έτσι και κατά την συγκεκριμένη λειτουργία, ο Φάρτης επισημαίνει με 

double click το σημείο που επιθυμεί, τοποθετείται εκεί ο προσωρινός κίτρινος marker, κι έπειτα, από 

ένα InfoWindow που εμφανίζεται, επιλέγει αν θέλει το σημείο αυτό για προέλευση ή προορισμό. Σο 

double click πάνω στον Φάρτη γίνεται αντιληπτό μέσω ενός event listener που έχει τεθεί σε αυτόν. 

Έπειτα από την επιλογή του Φρήστη για τον αν επιθυμεί το σημείο αυτό ως προέλευση ή προορισμό, 

ενημερώνονται κατάλληλα τα αντίστοιχα αντικείμενα, οι Markers, τα textboxes, και η Εφαρμογή 

τίθεται εκ νέου στην κατάσταση ‗Options‘. Σα textboxes ενημερώνονται όχι με κάποια διεύθυνση ή 

άλλο κείμενο, αλλά με το ζεύγος συντεταγμένων του επιλεγμένου σημείου (πλάτος, μήκος). Πατώντας 

όμως ο Φρήστης μέσα σε αυτό, και χωρίς να πειράξει κάτι, τότε πραγματοποιείται αντίστροφο 

geocoding, κι έτσι πλέον εμφανίζεται η διεύθυνση που αντιστοιχεί σε αυτές τις συντεταγμένες. 

Ένα μειονέκτημα της λειτουργίας αυτής ώστε να γίνει δημοφιλής είναι πως απευθύνεται κατά 

κανόνα σε χρήστες που έχουν σχετική εξοικίωση με την περιοχή, κάτι που κατά κανόνα δεν ισχύει 

για τους επισκέπτες της πόλης. 

Ένα άλλο μειονέκτημα είναι αυτό που αναφέρεται και στην 6.4.9.9, δηλαδή πως σε μία τοποθεσία 

αναφοράς που εκτείνεται σε μεγάλη έκταση μπορεί να επιλέγεται οποιοδήποτε σημείο, χωρίς αυτό 

να είναι το απαραίτητα χρήσιμο, οδηγώντας σε όχι τόσο σωστές λύσεις, αφού π.χ. αυξάνει πολύ και 

χωρίς πραγματικό λόγο το μήκος διαδρομής πεζή. 

Ένα τέτοιο παράδειγμα παρουσιάζεται στην ακόλουθη εικόνα: 

203


Εικόνα 72: Ο χρήστης έχει επιλέξει ένα σημείο εντός του Αερολιμένα ως προέλευση, το οποίο όμως 

δεν αντιστοιχεί στο σημείο αφίξεων, αλλά στο Parking. 

΢το παράδειγμα αυτό, ο Φρήστης, χωρίς να γνωρίζει με λεπτομέρεια τους χώρους του Αερολιμένα, 

ή/και χωρίς να θέλει να δώσει ιδιαίτερη προσοχή, επέλεξε ένα τυχαίο σημείο του Αερολιμένα ως 

προορισμό. Σο σημείο αυτό αντιστοιχεί όμως στο Parking, ενώ στην πραγματικότητα ο Φρήστης 

ενδιαφερόταν για το σημείο εξόδου από τον Αεροσταθμό. Σο αποτέλεσμα είναι να εμφανίζεται μία 

μεγάλη διαδρομή πεζή, η οποία κατεπέκταση επηρεάζει συνολικά τις προσφερόμενες Προτάσεις 

Σαξιδίου. 

204


6.4.9.11 Επιλογή Προέλευσης Προορισμού Με Dragging Σων Markers. 

Ένας άλλος τρόπος άμεσης επιλογής της προέλευσης ή του προορισμού είναι με σύρσιμο (dragging) 

του πράσινου ή κόκκινου Marker που αντιστοιχεί σε αυτές τις τοποθεσίες. Σο dragging γίνεται 

αντιληπτό χάρη στην τοποθέτηση κατάλληλων event listeners στους Markers, μέσω των οποίων 

καλείται η σχετική function έπειτα από ένα DRAG_END. 

Μόλις ο Φρήστης αφήσει λοιπόν τον Marker σε κάποια τοποθεσία, τότε καλείται η προαναφέρομενη 

fuction, η οποία ενημερώνει κατάλληλα τo αντικείμενo προέλευσης προορισμού, το textbox, και η 

Εφαρμογή τίθεται εκ νέου σε κατάσταση ‗Options‘. To textbox δεν ενημερώνεται με κάποια 

διεύθυνση ή άλλο κείμενο, αλλά με το ζεύγος συντεταγμένων του επιλεγμένου σημείου (πλάτος, 

μήκος). Πατώντας όμως ο Φρήστης μέσα σε αυτό, και χωρίς να πειράξει κάτι, τότε πραγματοποιείται 

αντίστροφο geocoding, κι έτσι πλέον εμφανίζεται η διεύθυνση που αντιστοιχεί σε αυτές τις 

συντεταγμένες. 

΋πως και στην περίπτωση της επιλογής με double click (6.4.9.10), τα μειονεκτήματα της 

λειτουργίας είναι η απαιτούμενη εξοικίωση του Φρήστη με την περιοχή, και το ότι μπορεί να 

επιλέγεται σημείο μίας μεγάλης περιοχής, χωρίς να είναι αυτό το λειτουργικά χρήσιμο. 

6.4.9.12 Αντιστροφή Προέλευσης—Προορισμού. 

Με το πάτημα του κουμπιού ‗SWAP‘ από τον Φρήστη, μια μικρή function ανταλλάσει μεταξύ τους τα 

αντικείμενα προέλευσης-προορισμού. Με χρήση ενός ενδιάμεσου προσωρινού αντικειμένου της ίδιας 

κλάσης. ΢τη συνέχεια ενημερώνονται κατάλληλα και οι Markers πάνω στον Φαρτη. 

6.4.9.13 Επιλογές Για Σην Βελτιστοποίηση, Σα Επιθυμητά Μέσα, Σο Μέγιστο Μήκος 

Πεζή. 

Εκτός από την προέλευση και τον προορισμό, ο Φρήστης μπορεί να επιλέξει τον τρόπο με τον οποίο 

θα γίνει η βελτιστοποιήση των Προτάσεων Σαξιδίου (Δηλαδή για την γρηγορότερη άφιξη/αργότερη 

αναχώρηση), τα μέσα που επιθυμεί να χρησιμοποιήσει (΋λα, Μόνο Σρένα, Μόνο Λεωφορεία, ή μόνο 

Πεζή), καθώς και το μέγιστο μήκος της απόστασης που θέλει να διανύσει πεζή. 

205


Οι επιλογές αυτές γίνονται από DropDown Lists στις οποίες έχουν γίνει binded ArrayCollections με 

τις σχετικές τιμές ως αντικείμενα. Σα αντικείμενα αυτά περιέχουν δύο properties: Σο ένα είναι η 

ονομασία που εμφανίζεται στον Φρήστη, και η άλλη είναι η τιμή που χρησιμοποιείται 

προγραμματιστικά για την δημιουργία του HTTP ερωτήματος. 

Ψς παράδειγμα παρουσιάζεται η περίπτωση των δυνατών επιθυμητών μέσων: 

[Bindable] 

public var bdtddlGoBy:ArrayCollection = new ArrayCollection( 

[ {display:"Using Any Mean", value:"TRANSIT,WALK"}, 

{display:"Using Trains", value:"TRAINISH,WALK"}, 

{display:"Using Buses", value:"BUSISH,WALK"}, 

{display:"Walking Only", value:"WALK"}, 

]); 

6.4.9.14 Επιλογή Φρονικής ΢τιγμής Για Αναχώρηση ή Άφιξη. 

Η τελευταία επιλογή του Φρήστη είναι για την χρονική στιγμή, και το αν αυτή αφορά την επιθυμητή 

αναχώρηση από την προέλευση, ή την επιθυμητή αύξηση στον προορισμό. Πρακτικά αυτό σημαίνει 

ότι οι Προτάσεις Σαξιδίου δεν θα εκκινούν πριν, ή δεν θα τερματίζουν αργότερα από την χρονική 

στιγμή αντίστοιχα. ΢την δεύτερη περίπτωση προτιμώνται οι Προτάσεις που τερματίζουν πιο κοντά 

στην χρονική στιγμή άφιξης, έτσι ώστε να μην υπάρχει πιθανόν νεκρός χρόνος μετά το πέρας του 

ταξιδίου. 

Η επιλογή για το αν η χρονική στιγμή αφορά την αναχώρηση ή την άφιξη γίνεται από ένα ζεύγος 

radio buttons, με προεπιλεγμένο το ‗Depart‘, όπως προεπιλεγμένη είναι και η τρέχουσα κάθε φορά 

χρονική στιγμή, εκτός κι αν έχουν προκαθοριστεί αλλιώς από την σχετική λειτουργία. 

Η επιλογή της ημερομηνίας για την χρονική στιγμή γίνεται μέσω ενός calendar που ανοίγει με click 

του χρήστη. Οι ημερομηνίες που μπορούν να επιλεγούν είναι αυτές για τις οποίες υπάρχουν στοιχεία 

στο GT Feed. Η επιλογή της ώρας γίνεται μέσω ενός οριζόντιου slider με τιμές ανά 5‘. Σο συνολικό 

μήκος του slider αντιστοιχεί στο 24ωρο. 

Σέλος, με το πάτημα ενός κουμπιού ‗NOW‘, ο χρήστης μπορεί να (επανα)θέσει ως επιλογή την 

τρέχουσα χρονική στιγμή. Αυτό έχει πρακτικά νόημα για την αναχώρηση κι όχι για την άφιξη βέβαια. 

Θα μπορούσαν να υπάρχουν αντίστοιχα κουμπιά ‗in 10 minutes‘, ‗1 hour later‘, κτλ, όμως κρίθηκε 

ότι θα αύξαναν χωρίς σημαντικό κέρδος τα αντικείμενα στην οθόνη, κάνοντας δυσκολότερο να βρει 

κάποιος αυτό που θέλει. 

206


Ας σημειωθεί ότι η χρονική στιγμή είναι public μεταβλητή τύπου Date, πάνω στην οποία έχουν γίνει 

binded όλα τα σχετικά controls. 

6.4.9.15 Εμφάνιση Δικτύου Metro. 

Η εμφάνιση του δικτύου metro πάνω στον Φάρτη είναι μία παράλληλη λειτουργία, η οποία είναι 

διαθέσιμη τόσο κατά την κατάσταση ‗Options‘ και τις υποκαταστάσεις ‗Geocoding‘ και 

‗POIsSelection‘ αυτής, όσο και κατά την κατάσταση ‗Suggestions‘. 

Η επιλογή για την εμφάνιση ή όχι του δικτύου γίνεται από ένα toggle button που υπάρχει στην κάτω 

δεξιά γωνία του χάρτη. Πατώντας πάνω σε αυτό καλείται η σχετική function, η οποία αλλάζει την 

κατάσταση μίας public μεταβλητής boolean. 

Σα δεδομένα για την απεικόνιση του δικτύου περιέχονται μέσα στο κύριο Flash αρχείο, ως 

αντικείμενα ενός ArrayCollection όσον αφορά τους σταθμούς. Σα πεδία είναι 3: Ονομασία, 

γεωγραφικό πλάτος, γεωγραφικό μήκος. Οι polylines που συνδέουν τους σταθμούς μεταξύ τους 

δημιουργούνται από encoded polylines οι οποίες ορίζονται μέσα στην ίδια την function για την 

απεικόνιση του δικτύου. 

Ένα δείγμα των στοιχείων αυτών είναι το εξής: 

public var SystemMapStations:ArrayCollection = new ArrayCollection( 

[ 

{Name: 'PIRAEUS METRO STATION', Lat: 37.94797239, Lng: 23.64297478}, 

{Name: 'NEO FALIRO METRO STATION', Lat: 37.94446494, Lng: 

23.66391036}, 

{Name: 'MOSCHATO METRO STATION', Lat: 37.95531673, Lng: 23.68017257}, 

... 

Η εικόνα που χρησιμοποείται ως εικονίδιο είναι embedded, και σε κάθε τέτοιο εικονίδιο (Marker) 

αποδίδεται ένας event listener. Κατά αυτόν τον τρόπο, αν ο Φρήστης πατήσει με τον κέρσορα πάνω 

στο εικονίδιο ενός σταθμού, εμφανίζεται ένα InfoWindow για την επιλογή του ως προέλευση ή 

προορισμό, όπως περιγράφεται και στην 6.4.9.9. 

207


6.4.9.16 Δημιουργία Προτάσεων Σαξιδίου. 

Αφού ο Φρήστης έχει επιλέξει και ορίσει τις διάφορες παραμέτρους που αφορούν το ερώτημά του, 

τότε μπορεί πλέον να πατήσει πάνω στο κουμπί ‗Plan My Journey!‘. Με αυτόν τον τρόπο καλείται η 

Function η οποία είναι πρωταρχικά υπέυθυνη για την δημιουργία των Προτάσεων Σαξιδίου. 

Σο state της Εφαρμογής γίνεται ‗PleaseWait‘, κατά το οποίο έχουν απενεργοποιηθεί όλες οι 

λειτουργίες, ενώ στην οθόνη εμφανίζεται ένα παράθυρο όμοιο με του ‗About‘ δίνοντας κάποιες 

βασικές πληροφορίες για την Εφαρμογή. ΢το κάτω μέρος του παραθύρου υπάρχει μία progress bar, 

η οποία είναι ενδεικτική της εξέλιξης που πραγματοποιείται. Η ποσοστιαία εξέλιξη που φαίνεται στην 

progress bar είναι κατ‘εκτίμηση, όπου το ποσοστό αυξάνεται κατά ένα ποσό που έχει καθοριστεί για 

κάθε επιμέρους βήμα. 

΢το state ‗PleaseWait‘, όπως και στο ‗Suggestions‘ που ακολουθεί για την εμφάνιση των Προτάσεων 

Σαξιδίων, δεν εμφανίζεται πλέον το panel ‗Options‘, αλλά έχει προστεθεί ως μεσαίο αντικείμενο τού 

HBox ένα καινούριο Panel, αυτό των Προτάσεων. Η εμφάνισή του στο state ‗PleaseWait‘ γίνεται 

κυρίως για τεχνικούς λόγους (ώστε να έχουν δημιουργηθεί τα αντικείμενα και να μπορούν να 

συμπληρώνονται), αλλά και για να υπάρχει μια οπτικοποίηση της εξέλιξης προς τον Φρήστη, πέρα 

από την μέσω της progress bar. 

Διάγραμμα 13: Σα διάφορα αντικείμενα που αποτελούν την οθόνη της Εφαρμογής μετά την θέση 

του ερωτήματος, σε σχηματική παράσταση. Σο γαλάζιο παραλληλόγραμμο αντιστοιχεί στο panel 

εμφάνισης των Προτάσεων. 

208


Σο panel των Προτάσεων έχει στο πάνω σημείο του κάποια labels και textboxes για την εμφάνιση 

των σχετικών επιλογών που έχει κάνει ο Φρήστης. Πιο κάτω περιέχει ένα accordion με 3 panes, 

καθένα από τα οποία αντίστοιχει σε μία από τις εώς και 3 Προτάσεις Σαξιδίου. 

Μέσα στο κάθε pane, αρχικά περιέχονται labels για την εμφάνιση των ολικών στοιχείων της κάθε 

Πρότασης, δηλαδή της χρονικής στιγμής αναχώρησης, της άφιξης, της τιμής του απαιτούμενου 

κανονικού εισιτηρίου, και του μήκους διαδρομής πεζή. ΢τη συνέχεια του pane περιέχεται ένας 

scroller, ώστε να μπορούν να εμφανίζονται περιεχόμενα μεγάλου συνολικού μήκους, μέσω της 

κίνησης ενός κατακόρυφου scrollbar. Μέσα στον scroller υπάρχει ένα VBox container, στο οποίο 

τοποθετούνται τα RichText αντικείμενα για τα τμήματα κάθε Πρότασης. 

΢το τέλος του κατακόρυφου panel υπάρχουν 3 κουμπιά: για την επανεκκίνηση της Εφαρμογής και 

την δημιουργία ενός νέου ερωτήματος, για την τροποποίηση του παρόντος ερωτήματος, και για την 

εκτύπωση των αποτελεσμάτων. 

Από την Εφαρμογή Φρήστη, αρχικά γίνεται κλήση του Routing Engine. Η κλήση αυτή γίνεται 

σύμφωνα με τα όσα έχουν αναφερθεί στην 6.4.5. Μόλις το routing engine επιστρέψει πλήρως μία 

απάντηση, τότε καλείται η Function που αντιστοιχεί στο event (ResultEvent Handler). 

΢την Function αυτή γίνεται έλεγχος για το αν υπάρχουν όντως Προτάσεις στην απάντηση, κι έπειτα 

ακολοθεί η μετεπεξεργασία των Προτάσεων. Η μετεπεξεργασία κρίθηκε καλύτερο να συμβαίνει στην 

client εφαρμογή, αφενός ώστε να μην υπάρχει περαιτέρω τροποποιήση του routing engine, οπότε 

και θα καθίστατο μη αξιοποίησιμο πιθανόν σε άλλες παρόμοιες εφαρμογές, κι αφετέρου ώστε να 

αποφευχθεί η αύξηση του υπολογιστικού φόρτου στον server. 

Η κύρια δράση της μετεπεξεργασίας στην παρούσα στιγμή είναι η αποκοπή των τμημάτων 

Προτάσεων Σαξιδίου που αφορούν χρήση ΜΜΜ για μικρό μήκος. Σέτοια τμήματα δημιουργούνται 

λόγω του τρόπου λειτουργίας του routing engine, καθώς θεωρώντας ακριβείς χρόνους διέλευσης 

από τις στάσεις, έπεται ότι η αναμονή μπορεί να είναι σχεδόν μηδενική, κι άρα η χρήση ΜΜΜ μέχρι 

την επόμενη στάση είναι έντονα ανταγωνιστική της διαδρομής πεζή. Αυτό όμως δεν ισχύει στην 

πράξη για την περίπτωση της Αθήνας, κι έτσι αυτά τα τμήματα καταργούνται, με επέκταση του 

προηγούμενου τμήματος πεζή. Διάφορες προσπάθειες που έγιναν ώστε να αποφευχθεί αυτό από το 

ίδιο το routing engine, με επιβολή μεγαλύτερης ποινής στις μετεπιβιβάσεις, και με αύξηση της 

προτίμησης πραγματοποίησης μίας διαδρομής πεζή αντί της αναμονής στη στάση, δεν είχαν κάποια 

ικανοποιητική επιτυχία, δημιουργώντας μάλιστα έτσι προβλήματα σε άλλες περιπτώσεις. 

Η σποκοπή πραγματοποιείται με διαγραφή του τμήματος από το αντικείμενο της απάντησης που 

έχει δώσει το routing engine, κι αντικατάσταση του Pto αντικειμένου του προηγούμενου τμήματος 

με το αντίστοιχο από αυτό που διαγράφεται. Επίσης, τροποποιούνται κατάλληλα κάποια δεδομένα, 

όπως είναι ο αριθμός των μετεπιβιβάσεων, που μειώνονται κατά μία. 

209


΢την συνέχεια ενημερώνονται τα διάφορα γενικά στοιχεία του Panel των Προτάσεων, ενώ 

ενημερώνονται αμέσως μετά τα γενικά στοιχεία κάθε Πρότασης, με υπολογισμό και του 

απαραίτητου για κάθε μία κανονικού εισιτηρίου (6.4.9.19). 

(Η διαδικασία που περιγράφεται αναπαρίσταται σχηματικά στο διάγραμμα που ακολουθεί.) 

Έπειτα, συμπληρώνονται για κάθε Πρόταση τα τμήματα Σαξιδίου. Αυτό γίνεται με την δημιουργία 

RichTexts αντικειμένων που τοποθετούνται το ένα κάτω από το άλλο στο αντίστοιχο VBox. ΢ε αυτή 

την φάση δεν περιλαμβάνται οι εναλλακτικές Γραμμές που μπορούν να χρησιμοποιηθούν, όμως η 

απόδοση ενός χαρακτηριστικού ID στα RichTexts αντικείμενα στα οποία αναφέρεται το μέσο και η 

Γραμμή, κάνει εφικτή την μετέπειτα συμπληρωσή τους. Σο περιεχόμενο κάθε RichText 

διαμορφώνεται ανάλογα, ώστε να υπάρχει μία πιο «ανθρώπινη» περιγραφή. Αυτό επιτυγχάνεται μέσα 

από μία σειρά IF..THEN..ELSE.. διαδικασιών. 

210


Ερϊτθμα ςτο Route Engine. 

Βρζκθκαν Λφςεισ 

ΝΑΙ 

ΟΧΙ 

Συμπλιρωςθ Στοιχείων που αφοροφν όλεσ τισ Ρροτάςεισ. 

Μετεπεξεργαςία Κάκε Ρρόταςθσ. 

Μετεπεξεργαςία Κάκε Ρρόταςθσ 2. 

Εφρεςθ Απαραίτθτου Ειςιτθρίου. 

Συμπλιρωςθ Γενικϊν Στοιχείων Κάκε Ρρόταςθσ. 

Συμπλιρωςθ Λεκτικϊν Στοιχείων Κάκε Κλάδου. 

Ρεριοδικι 

Εκτζλεςθ ΢ουτινϊν. 

Επόμενθ Σελίδα 

ΝΑΙ 

ΝΑΙ 

Απάντηση 

Ασύγτρονοσ 

Ερωτήματος 

Ολοκληρώθηκε. 

Απάντηση 

Ασύγτρονοσ 

Ερωτήματος 

Ολοκληρώθηκε. 

Μινυμα Λάκουσ 

Επιςτροφι ςτθν 


Για Κάκε Κλάδο Σθσ Πρόταςθσ. 

Για Κάκε Πρόταςθ. 

211


Σο επόμενο στάδιο αφορά την δημιουργία των οπτικών απεικονίσεων, τόσο για τα τμήματα με ΜΜΜ, 

όσο και για αυτά που γίνονται πεζή, με χρήση της υπηρεσίας Google Directions σε αυτή την 

περίπτωση. Επίσης αφορά την συμπλήρωση των Γραμμών με τις εναλλακτικές που συνδέουν κάθε 

ζεύγος στάσεων. 

Συνζχεια από τθν Ρροθγοφμενθ Σελίδα 

Ολoκλθρϊκθκαν 

Τα ερωτιματα. 

ΝΑΙ 

ΟΧΙ 

Συμπλιρωςθ Λεκτικϊν Στοιχείων Κλάδου Με τα Στοιχεία των 

Εναλλακτικϊν Γραμμϊνν. 

Διαμόρφωςθ Και Αποκικευςθ Στοιχείων Απεικόνιςθσ Στον Χάρτθ. 

Εμφάνιςθ Ρρϊτθσ Ρρόταςθσ. 

Οι κλήσεις προς την Google Directions και προς τον Tsoop! Server γίνονται ασύγχρονα. Επειδή όμως 

στην συγκεκριμένη εφαρμογή γίνεται με σειριακό χαρακτήρα κι επαναληπτικό τρόπο θέση πολλών 

ερωτημάτων προς τους δύο HTTP servers (από ένα ερώτημα για κάθε κλάδο πρότασης ταξιδίου που 

αφορά διαδρομές πεζή ή με ΜΜΜ, στη σειρά για κάθε κλάδο), ήταν απαραίτητο να μην τίθεται ένα 

νέο ερώτημα πριν ολοκληρωθεί το προηγούμενο. 

Εκτζλεςθ Νζου 

Κφκλου. 

Διάγραμμα 14: ΢χηματική Απεικόνιση της Διαδικασίας Θέσης Ερωτημάτων, Λήψης Απαντήσεων, και 

διαχείρισής τους, από την Client Εφαρμογή. 

΢την γλώσσα Αctionscript που χρησιμοποιείται από το Flex, δεν υπάρχει η δυνατότητα παύσης 

εκτέλεσης του κώδικα για κάποιο χρονικό διάστημα, π.χ. με μία εντολή Pause(time) ή Wait(time). 

Έτσι υιοθετήθηκε η λύση τού να γίνεται περιοδική επανάκληση των σχετικών ρουτινών για την 

εύρεση των διαδρομών πεζή και των εναλλακτικών Γραμμών ΜΜΜ, όπου με χρήση μεταβλητών flag 

ως δεικτών για την ολοκλήρωση κάθε βήματος γίνεται ανάλογα εκτέλεση τού επόμενου, ή 

Για Κάκε Κλάδο Σθσ Πρόταςθσ. 

Για Κάκε Πρόταςθ. 

212


επανέλεγχος τής ολοκλήρωσης στην επόμενη κλήση των ρουτινών. Η διαδικασία εμφανίζεται 

σχηματικά στο προηγούμενο Διάγραμμα. 

Ο επανέλεγχος για την ολοκλήρωση των απαντήσεων γίνεται με χρήση ενός timer, το οποίο κάνει 

επανακλήσεις ανά κάποιο χρονικό διάστημα. Σο διάστημα αυτό είναι της τάξης των ms και τέθηκε 

ανάλογα με τον μέσο χρόνο ολοκλήρωσης των απαντήσεων. Πολύ μεγάλη τιμή δημιουργεί μεγάλους 

κύκλους, και συνεπώς μεγάλους νεκρούς χρόνους στο τέλος κάθε κύκλου. Πολύ μικρή τιμή από την 

άλλη δημιουργεί πολλές άσκοπες επανακλήσεις, με αποτέλεσμα να δαπανάται υπολογιστική ισχύ 

κατά τους ελέγχους ολοκλήρωσης. ΢την πράξη, οι όποιες καθυστερήσεις με λογικές τιμές του 

χρονικού διαστήματος, δεν είναι ορατές από τον Φρήστη. 

Κατά την διαδιακασία αυτή, για τα τμήματα των τμημάτων ταξιδίου που γίνονται με ΜΜΜ τα 

στοιχεία της οπτικοποίησης προκύπτουν από τα στοιχεία που περιέχονται στην απάντηση από το 

routing engine. Για τα τμήματα των τμημάτων ταξιδίου που γίνονται πεζή, τα στοιχεία της 

οτπικοποίησης προκύπτουν κάθε φορά από την απάντηση του ερωτήματος προς την υπηρεσία 

Google Directions. 

Κάθε φορά που ένα τμήμα ταξιδίου ολοκληρώνεται, τότε το αντικείμενο της κλάσης αυτής εισάγεται 

στο αντικείμενο της υπερκλάσης για ολόκληρη την Πρόταση Σαξιδίου, δηλαδή για όλα τα τμήματα 

αυτής. ΋μοια, κάθε αντικείμενο της υπερκλάσης ολοκληρώνεται, αυτό εισάγεται στο ένα και 

μοναδικό αντικείμενο της ακόμη υψηλότερης κλάσης, αυτής που είναι η συλλογή όλων των 

Προτάσεων Σαξιδίου. 

΢την περίπτωση των εναλλακτικών Γραμμών, αυτές επιστρέφονται για κάθε τμήμα με ΜΜΜ της 

Πρότασης Σαξιδίου μορφοποιημένες σε XML. ΢ύμφωνα με τα περιεχόμενα της XML απάντησης 

τροποποείται ανάλογα το RichText που αντιστοιχεί στο συγκεκριμένο τμήμα. Η αναγνώριση του 

κατάλληλου RichText αντικειμένου γίνεται μέσω του κωδικοποιοημένου ID που του έχει αποδοθεί 

κατά την δημιουργία του. 

΋πως φαίνεται στα προηγούμενα, τα αποτελέσματα που δημιουργούνται καθόλη την διαδικασία 

αποθηκεύονται είτε στους Visual Containers, είτε σε κατάλληλες μεταβλητές με κλάσεις που έχουν 

δημιουργηθεί. Κατά αυτόν τον τρόπο επιτυγχάνεται η όσο το δυνατόν μεγαλύτερη 

ανεξαρτητοποίηση της Client Εφαρμογής από τους Servers για την συνέχεια. Έτσι, αφενός 

μειώνονται οι κλήσεις προς τους servers, ο επεξεργαστικός φόρτος σε αυτούς και η κίνηση μέσω 

δικτύου, κι αφετέρου, περιορίζεται η ανάγκη συνεχούς επανεισόδου στο Internet για τον Φρήστη. 

ο χαρακτηριστικό αυτό είναι ιδιαίτερα σημαντικό για μια Εφαρμογή με έντονα φορητό χαρακτήρα, 

καθώς το δίκτυο μπορεί να μην είναι συνεχώς διαθέσιμο κατά την πραγματοποίηση τού ταξιδίου, ή 

213


να κοστίζει ιδίαιτερα ακριβά. Βέβαια, δεν γίνεται πλήρη ανεξαρτητοποίηση της Client Εφαρμογής σε 

λειτουργία απεικόνισης των λύσεων, καθώς ο Google Φάρτης μπορεί να απεικονίζεται offline, αλλά 

με προϋπόθεση την ύπαρξη αρκετών cached δεδομένων για την περιοχή. ΢ε κάθε περίπτωση 

βέβαια, η offline διατήρηση των Προτάσεων Σαξιδίου μπορεί να γίνει και με την εκτύπωση τους. 

6.4.9.17 Παρουσίαση Και Διαχείριση Προτάσεων Σαξιδίου. 

Μετά το τέλος της διαδικασίας για κάθε Κλάδο, όλων των Προτάσεων Σαξιδίου που έχουν δοθεί ως 

απάντηση από το Routing Engine, η εφαρμογή τίθεται στην κατάσταση παρουσίασης και διαχείρισης 

των Προτάσεων (state ‗Suggestions‘). 

Σα στοιχεία που αφορούν την λεκτική περιγραφή των προτάσεων έχουν ήδη δημιουργηθεί κατά την 

ανάκτηση και μετεπεξεργασία των Προτάσεων Σαξίδιου. Κατά το ίδιο στάδιο έχουν δημιουργηθεί τα 

αντικείμενα που αφορούν την οπτικοποίηση των τμημάτων κάθε Πρότασης Σαξιδίου. 

Ο Φρήστης μπορεί να επιλέξει ποιά Πρόταση θα εμφανίζεται μπροστά του, πατώντας απλός στο 

pane της πρότασης που επιθυμεί, μέσα στο accordion. Σα στοιχεία δεν ξαναδημιουργούνται, απλώς 

κρύβονται ή εμφανίζονται μαζί με το pane στο οποίο συμπεριλαμβάνονται. 

Η οπτικοποίηση γίνεται από μία function η οποία καλείται με ένα ID που αντιστοιχεί στην Πρόταση 

προς οπτικοποίηση. Αρχικά αυτό γίνεται για την πρώτη Πρόταση, όμως η διαδικασία 

επαναλαμβάνεται κάθε φορά που ο Φρήστης επιλέγει άλλη Πρόταση για να βλέπει. Εν αντιθέσει με 

την λεκτική περιγραφή, τα οπτικά στοιχεία πάνω στον χάρτη δημιουργούνται εκ νέου κάθε φορά. 

Αυτό δεν σήμαινει ότι γίνεται επανασύνδεση με τους servers, καθώς όπως περιγράφηκε, τα 

απαραίτητα στοιχεία αποθηκεύονται σε τοπικά αντικείμενα κατάλληλα δημιουργημένων κλάσεων. 

΋λα τα αντικείμενα οπτικοποίησης τοποθετούνται σαν overlays πάνω στον Φάρτη. Μαζί με την 

Πρόταση Σαξδίου οπτικοποείται στο τρέχον state και το ζεύγος προέλευσης – προορισμού, χωρίς 

όμως να είναι draggable. 

Γενικότερα, είναι απενεργοποιημένες οι λειτουργίες Φάρτη που αφορούν τις επιλογές προέλευσης και 

προορισμού, κι αν επιθυμεί ο Φρήστης να κάνει νέες επιλογές θα πρέπει να πατήσει στο σχετικό 

κουμπί. ΋μοια, μπορεί να επιλέξει να τροποποιήσει το ερώτημα, το οποίο γίνεται πατώντας στο 

σχετικό κουμπί που ―καθαρίζει‖ τον Φάρτη και τα αντικείμενα λεκτικής περιγραφής, κι επαναφέρει 

την Εφαρμογή στο state ‗Options‘. 

214


6.4.9.18 Εκτύπωση. 

΢την πραγματικότητα δεν γίνεται άμεσα εκτύπωση σε χαρτί, αλλά δημιουργείται ένα αρχέιο PDF, το 

οποίο μπορεί να αποθηκευθεί, μεταφερθεί, ή εκτυπωθεί. Η λειτουργία της «εκτύπωσης» γίνεται με 

την χρήση της open source βιλβιοθήκης AlivePDF. Με αυτήν προστίθενται στοιχεία για χρήση στο 

Flex όπως είναι π.χ. το PDF document, το page κτλ. Έτσι, αφού δημιουργηθεί ένα PDF document ως 

αντικείμενο, προστίθεται σε αυτό μία σελίδα μεγέθους Α4 portrait. Έπειτα δημιουργείται κείμενο 

πάνω στην σελίδα, μεταφέροντας τα στοιχεία από το pane της Πρότασης Σαξιδίου που είναι ενεργή. 

Παρέχονται πάρα πολλές ιδιότητες από την βιβλιοθήκα για την κατάλληλη μορφοποιήση του 

κειμένου. Δυστυχώς όμως, παρουσιάζονται πάρα πολλά προβλήματα, επειδή η βιβλιοθήκη είναι 

ακόμη σε πρώίμο στάδιο ανάπτυξης. Έτσι π.χ. αποτυγχάνει η προσπάθει εκτύπωσης εικόνων, κατά 

συνέπεια και των χαρτών για τις διαδρομές πεζή, καθώς αυτές εκτυπώνονται μερικώς. 

Λόγω των συνεχών τροποποιήσεων και δοκιμών που γίνονται για να παρακαμφτούν τα προβλήματα, 

δεν γίνεται μεγαλύτερη αναφορά στην λειτουργία αυτή. Να αναφερθεί όμως ότι στις πρόσφατες 

εκδόσεις είναι δυνατή η εκτύπωση προς το PDF αρχείο αποκλειστικά από την Εφαρμογή Φρήστη, 

χωρίς να απαιτείται η διαμεσολάβηση κάποιου PHP server. Κατά αυτόν τον τρόπο μειώνεται 

σημαντικά ο φόρτος στο δίκτυο από και προς τον Server. 

Παρόλη την προβληματική λειτουργία, ο Φρήστης δεν στερείται της δυνατότητας εκτύπωσης, αφού 

αυτήν μπορεί να την κάνει από τον Browser, ή τον ίδιο τον Flash Player, χωρίς βέβαια έτσι να 

επωφελείται της κατάλληλης μορφοποίησης που γίνεται από την Εφαρμογή. 

6.4.9.19 Τπολογισμός Απαραίτητου Εισιτηρίου. 

Αν κι ο υπολογισμός του κανονικού εισιτηρίου που απαιτείται για την πραγματοποίηση κάθε 

Πρότασης Σαξιδίου γίνεται από το routing engine λαμβάνοντας υπόψη τα στοιχεία που 

περιλαμβάνονται στο GT Feed, εν τούτοις αυτό δεν γίνεται απολύτως σωστά. Ακόμη, μεταβολές που 

έγιναν στην τιμολογιακή πολιτική του ΟΑ΢Α (ύπαρξη εκτός του ενιαίου εισιτηρίου 1:30‘ και 

μειωμένου εισιτηρίου για μία επιβίβαση σε λεωφορεία, trolleys, ή τραμ) δημιούργησαν μία 

κατάσταση που ήταν δύσκολο να μοντελοποιηθεί με ικανοποιητικό τρόπο στο GT Feed. 

Έτσι, κρίθηκε καλύτερο ο υπολογισμός του απαραίτητου κανονικού εισιτηρίου να γίνεται πλέον στην 

Εφαρμογή Φρήστη. Αυτό γίνεται από μία Function που καλείται με το ID της Πρότασης Σαξιδίου προς 

κοστολόγηση κι επιστρέφει την τιμή του εισιτηρίου. Η Function αυτή έχει ούτως ή άλλως πρόσβαση 

και στο public αντικείμενο με τις Προτάσεις Σαξιδιίου. 

215


Η λογική που ακολουθείται για τον υπολογισμό είναι μία διαδικασία με συνεχή IF..THEN..ELSE, κατά 

τα οποία η τιμή του εισιτηρίου είναι κάθε φορά η μέγιστη από την διαδικασία που μέχρι τότε έχει 

ολοκληρωθεί κι από αυτήν που προκύπτει από την τρέχουσα εξεταζόμενη συνθήκη. 

216


7Παράδειγμα Φρήσης. 

O John είχε γνωρίσει τον Μπάμπη όταν και οι δύο σπούδαζαν στο London. Ο John ήταν Άγγλος, όμως 

ήταν κι αυτός κατά κάποιο τρόπο ξένος στην πόλη, αφού είχε μεγαλώσει και ζούσε μέχρι τότε σε μία 

τυπική Αγγλική επαρχιακή πόλη, το Swindon. Μη όντας λοιπόν «ιθαγενής» κάτοικος της πόλης, έκανε 

αρκετή παρέα με τους συμφοιτητές του, πολλοί εκ των οποίων είχαν έρθει από διάφορες χώρες. Ο 

Μπάμπης ήταν αυτός με τον οποίον ταίριαζαν περισσότερο σαν παρέα. 

Σα χρόνια των σπουδών πέρασαν, και οι δύο φίλοι αποχαιρετίστηκαν, αφού και οι δυό τους 

αποφάσισαν να επιστρέψουν στις πόλεις τους. Από τότε κρατούσαν συνεχώς επαφή μέσω 

τηλεφώνου, email, Skype, κι οτιδήποτε άλλο η τεχνολογία σταδιακά πρόσθεσε στις δυνατότητες 

επικοινωνίας. ΋μως, για φέτος τα Φριστούγεννα, ο John αποφάσισε να ακολουθήσει την πρόσκληση 

του Μπάμπη, και να επισκεφθεί για πρώτη φορά την Αθήνα, φιλοξενούμενος από τον φίλο του, ο 

οποίος θα εκτελούσε και χρέη ξεναγού. Ο Μπάμπης έμενε σε ένα μεγάλο σπίτι, σε μία καλή και 

κεντρική περιοχή της Αθήνας όπως του είχε πει, και είχε αρκετό χώρο για να τον φιλοξενήσει. 

Κανονίζει λοιπόν εγκαίρως για τα αεροπορικά εισιτήρια, και περιμένει πως και πως για να έρθει η 

στιγμή του ταξιδιού. 

217


Λίγες ημέρες πριν το ταξίδι, μέσα σε μία άλλη συζήτηση που είχαν, ο Μπάμπης ενημερώνει τον John 

ότι παρόλο που τού το είχε υποσχεθεί, δυστυχώς δεν θα μπορέσει να πάει να τον πάρει από τον 

Αερολιμένα. Σού συνιστά να μην πάρει taxi, αλλά να χρησιμοποιήσει ΜΜΜ για την μετάβασή του 

από τον Αερολιμένα στο σπίτι. Ο ίδιος όμως δεν πολυχρησιμοποιεί ΜΜΜ, κι έτσι δεν γνωρίζει πως 

ακριβώς μπορεί να μετακινηθεί ο φίλος του. Σού δίνει όμως την διεύθυνση τού σπιτιού, κι επίσης την 

διεύθυνση ενός site που έχει ακούσει ότι είναι ιδιαίτερα χρήσιμο για τους επισκέπτες της πόλης που 

θέλουν να μετακινηθούν με ΜΜΜ. 

Ο John κάποια στιγμή αργότερα μπαίνει στο site που του είχε υποδείξει ο φίλος του, έτσι ώστε να δει 

πως μπορεί να μετακινηθεί από τον Αερολιμένα προς την διεύθυνση που του έχει δώσει. «Ελπίζω να 

μην είναι μόνο στα Ελληνικά, και να μην είναι ένα χάος από νούμερα, όπως την άλλη φορά», 

σκέπτεται από μέσα του, έχοντας κακή εμπειρία από παλαιότερο ταξίδι του. 

΢την αρχή βλέπει την εισαγωγική οθόνη: 

Εικόνα 73: Η εισαγωγική οθόνη του Tsoop! που βλέπει ο φανταστικός Φρήστης του Παραδείγματος. 

Παρατηρεί ότι υπάρχει επισήμανση για προγραμματισμένη απεργία στα Μέσα Μαζικής Μεταφοράς 

στις 16 Δεκεμβρίου! «Ουφ, παρά μία μέρα», σκέπτεται, ενώ ταυτόχρονα πατά στο πλήκτρο 

―Continue‖. «Tsoop!. Σι όνομα κι αυτό...» 

218


Σότε εμφανίζεται μπροστά του η οθόνη στην οποία μπορεί να δώσει τα στοιχεία του ταξιδιού που 

θέλει να πραγματοποιήσει: 

Εικόνα 74: Η οθόνη για την επιλογή διαφόρων παραμέτρων του ταξιδιού. 

Ο John, περιεργαζόμενος την οθόνη, παρατηρεί ότι υπάρχει ένα κουμπί με την ονομασία «To/From 

Airport». Σο πατάει, και σε ένα άλλο tab του browser εμφανίζονται κάποιες γενικές πληροφορίες για 

την εξυπηρέτηση του Αερολιμένα από τα ΜΜΜ. Φρήσιμα όλα αυτά, όμως και πάλι δεν ξέρει πως να 

πάει στο σπίτι του φίλου του. Γυρίζει λοιπόν στην οθόνη των επιλογών, και πατάει στο κουμπί POIs για 

την προέλευση. ΢την λίστα που εμφανίζεται υπάρχει η κατηγορία ‗AIRPORTS‘. Ανοίγει λοιπόν την 

κατηγορία αυτή, και εμφανίζεται η εγγραφή για τον Αερολιμένα ‗EL. Venizelos‘. «Αυτό είνα», 

σκέφτεται! ‗Έτσι κι αλλιώς, δεν υπάρχει άλλο, αποκλείεται να το μπέρδευα‖. Πατώντας πάνω στην 

εγγραφή, ο χάρτης μετατοπίζεται, κι ένας Marker του δείχνει την τοποθεσία: 

219


Εικόνα 75: Η επιλογή του Αερολιμένα ως προέλευση από την λίστα των ΢ημείων Ενδιαφέροντος. 

΢τη συνέχεια ο John πληκτρολογεί την διεύθυνση του σπιτιού τού Μπάμπη στο σχετικό πεδίο για τον 

προορισμό, κι ανοίγει ένα παράθυρο με μία λίστα με τις διευθύνσεις που ταιριάζουν. ΢την 

συγκεκριμένη περίπτωση υπάρχει μόνο μία. Πατώντας πάνω στην διεύθυνση που προτείνεται, ο 

Φάρτης μετακινείται, κι ένας Marker επισημαίνει την επιλεγμένη τοποθεσία.: 

220


Εικόνα 76: To Geocoding της διεύθυνσης προορισμού. 

΢τη συνέχεια ο John επιλέγει την ημερομηνία και την ώρα. «Xmm, η πτήση φτάνει γύρω στις 15:15 

στην Αθήνα, ένα μισάωρο περίπου να χρειαστώ για να βγω έξω και να πάρω τις βαλίτσες... ας πούμε 

ότι στις 16:00 θα είμαι έτοιμος. Ελπίζω να μην υπάρξει καθυστέρηση στην πτήση», σκέφτεται, κι 

έπειτα κάνει τις επιλογές του: 

221


Εικόνα 77: Επιλογή της ημερομηνίας και της ώρας. 

Έπειτα, ο John παρατηρεί τις υπόλοιπες επιλογές, κι αποφασίζει να επιλέξει να χρησιμοποιήσει μόνο 

metro, αφού από ότι είδε υπάρχει σταθμός κοντά στο σπίτι του φίλου του, κι επίσης, να κάνει τις 

λιγότερες δυνατές μετεπιβιβάσεις. «Καλύτερα να αλλάξω λιγότερα μέσα κι ας φτάσω λίγο αργότερα, 

αφού θα κουβαλάω και τις βαλίτσες», είπε από μέσα του, κι έκανε τις απαραίτητες απλές ενέργειες 

στην οθόνη: 

222


Εικόνα 78: Επιλογές για τα επιθυμητά μέσα πραγματοποίησης του ταξιδίου, και του τρόπου 

βελτιστοποίησης της αναζήτησης προτάσεων. 

Αφού λοιπόν έχουν πραγματοποιηθεί εύκολα οι απαραίτητες επιλογές, o John πατάει στο ‗Plan My 

Journey!‘ κι αναμένει, όπως ακριβώς του λέει η οθόνη με μία μπάρα που δείχνει την εξέλιξη της 

επεξεργασίας: 

223


Εικόνα 79: Αναμονή για την αναζήτηση προτάσεων ταξιδίου. 

Έπειτα από ελάχιστα δευτερόλεπτα, εμφανίζεται η οθόνη με τις Προτάσεις που έχει να κάνει το 

Tsoop! για το ταξίδι: 

224


Εικόνα 80: Η οθόνη των Προτάσεων Σαξιδίου όπως πρωτοεμφανίζεται. 

Η πρώτη Πρόταση χρησιμοποιεί τις Γραμμές Μ3 και Μ1 του metro, με 1 μετεπιβίβαση στον σταθμό 

‗Μονατηράκι‘. Η συνολική διάρκεια της διαδρομής εκτιμάται στα 70 min. Πατώντας πάνω στο pane 

της δεύτερης πρότασης, η οθόνη αλλάζει, εμφανίζοντας τα στοιχεία αυτής της Πρότασης: 

225


Εικόνα 81: Η οθόνη των Προτάσεων Σαξιδίου, εμφανίζοντας την δεύτερη Πρόταση. 

Η διαφοροποίηση από την Πρώτη Πρόταση είναι στην χρήση της Γραμμής Μ2 αντί της Μ1, με 

μετεπιβίβαση στον σταθμό ‗΢ύνταγμα‘, και σταθμό αποβίβασης τον ‗Μεταξουργείο‘ αντί του 

‗Ομόνοια‘. Ίδιος είναι πρακτικά ο συνολικός χρόνος διαδρομής, περίπου 70 min, όπως και το 

συνολικό μήκος διαδρομής πεζή, περίπου 1.8 km. 

(Παρατήρηση: Σο μήκος διαδρομής πεζή είναι στην πραγματικότητα περίπου 0.8 km, δηλαδή 1 km 

λιγότερο. Η λανθασμένη τιμή προέρχεται από την ελλιπή κάλυψη του OpenStreetMap στην περιοχή 

του Αερολιμένα, οπότε και το σχετικό routing κάνει έναν μεγάλο κύκλο από την τοποθεσία του 

Αερολιμένα μέχρι την τοποθεσία του σταθμού metro. Η διαφοροποίηση αυτή στο μήκος επηρεάζει 

και την επιλογή των Προτάσεων, καθώς στο συγκεκριμένο παράδειγμα ευνοούνται έτσι οι 

μετακινήσεις με λεωφορεία έναντι αυτών με metro. Σο πρόβλημα αυτό, όπως έχει ήδη αναφερθεί, 

συμβαίνει σε ελάχιστες περιπτώσεις, και η περιοχή του Αερολιμένα ανήκει δυστυχώς σε αυτές, 

καθώς δεν πρόκειται για μία τυπική αστική περιοχή. Σο πρόβλημα θα περιορίζεται όσο υπάρχει 

εμπλουτισμός και αύξηση της ποιότητας των δεδομένων του OSM.) 

226


Κάνοντας ο John zoom στην περιοχή του προορισμού (αλλά εμείς και στην οθόνη στην περιοχή 

εμφάνισης των στοιχείων της δεύτερης Πρότασης), προκύπτει η εξής εικόνα: 

Εικόνα 82: Zoom στην περιοχή προορισμού και στα στοιχεία της δεύτερης Πρότασης, με 

ενεργοποιημένη την εμφάνιση του Δικτύου metro. 

Έτσι, ο John βλέπει πλέον αναλυτικά την διαδρομή που πρέπει να διανύσει πεζή από τον σταθμό 

αποβίβασης μέχρι το σπίτι του φίλου του. Καθώς δεν υπάρχει Σρίτη Πρόταση και είναι 

ικανοποιημένος από την Πρόταση που βλέπει, ο John πατάει στο κουμπί ‗Print‘ και την εκτυπώνει για 

να την έχει μαζί του στο ταξίδι. «Μακάρι να υπήρχε κάτι ανάλογο κι εδώ στο Swindon! Θα ήταν πολύ 

εξυπηρετικό για κάποιον που χρησιμοποιεί τα ΜΜΜ της πόλης μας!» ήταν οι τελευταίες σκέψεις του 

λίγο πριν πάρει από τον εκτυπωτή την έτοιμη σελίδα. 

227


228


8΢υμπεράσματα – ΢κέψεις - 

8.1 Γενικά. 

Επόμενα βήματα. 

΢την σημερινή εποχή, τα προβλήματα που παρατηρούνται στις μεγάλες πόλεις από την υπερβολική 

κυκλοφορία αυτοκινήτων είναι τεράστια. ΋μως, η δημιουργία νέων δρόμων έχει αποδειχθεί ότι 

μεσοπρόθεσμα επιδεινώνει την κατάσταση, ενώ στις περισσότερες περιπτώσεις είναι κι ανέφικτη. 

Σην λύση έρχεται να δώσει η βελτιστοποίηση της απόδοσης των υπαρχόντων δικτύων, αλλά και η 

βελτιστοποίηση όσο είναι δυνατόν της χωροθέτησης των δραστηριοτήτων, οι οποίες φυσικά 

παράγουν τις μετακινήσεις. 

΢την διαφορετική αυτή από το παρελθόν προσέγγιση ιδιαίτερο ρόλο έχει η τεχνολογία, η οποία 

εμπλέκεται σε πάρα πολλά θέματα, όπως π.χ. από την λειτουργία εξελιγμένων συστημάτων 

σηματοδότησης και την χρήση μοντέλων προσομοίωσης, εώς την παροχή διαφόρων πληροφοριών 

προς τους πολίτε, μέσω ενός πλήθους επικοινωνιακών καναλιών. 

229


΢ημαντικότατο ρόλο στην βελτιστοποίηση της αξιοποίησης των διαθέσιμων δικτύων, και στην 

βελτίωση ευρύτερα της ποιότητας ζωής κα‘ επέκταση, έχουν τα Μέσα Μαζικής Μεταφοράς. 

Οποιαδήποτε λοιπόν τεχνολογική εφαρμογή διευκολύνει την χρήση τους, προσφέρει στην πόλη και 

τους κατοίκους της πολλά περισσότερα από αυτό που αρχικά φαίνεται. Μία τέτοια εφαρμογή είναι 

και η εύρεση προτάσεων ταξιδίων με ΜΜΜ. 

Οι υπάρχουσες εφαρμογές σε διάφορες πόλεις του κόσμου, αφορούν κατά κανόνα τους μόνιμους 

κατοίκους. ΋μως, ένας επισκέπτης (π.χ. τουρίστας) έχει ακόμη περισσότερο ανάγκη μία τέτοια 

εφαρμογή, καθώς γνωρίζει ελάχιστα για τα ΜΜΜ της πόλης και συνήθως δεν διαθέτει κατά την 

επίσκεψή του ΙΦ αυτοκίνητο. 

Η εφαρμογή λοιπόν που υλοποιήθηκε έρχεται να καλύψει την αναγκαιότητα αυτή για τους 

επισκέπτες της Αθήνας, χρησιμοποιώντας δωρεάν κι open source επιμέρους λύσεις, αξιολογώντας 

επίσης ερευνητικά τα διάφορα εμπλεκόμενα στοιχεία. 

Από την ανάπτυξη και την πρώιμη λειτουργία της γίνεται φανερό ότι σήμερα μπορούν να 

αναπτυχθούν εφαρμογές με ελάχιστο κόστος, οι οποίες να έχουν όλα ή και περισσότερα 

χαρακτηριστικά από αντίστοιχες εμπορικές εφαρμογές υψηλού κόστους. 

Θα πρέπει όμως να σημειωθεί ότι η ανάπτυξη της Εφαρμογής συνάντησε αρκετά προβλήματα από 

την χρησιμοποίηση κι εμπλοκή σε επιμέρους αντικείμενα όπου τα σχετικά λογισμικά βρίσκονταν σε 

πολύ νεαρό στάδιο, κάτι που αναμένεται φυσικά να περιοριστεί πάρα πολύ όσο θα περνάει ο χρόνος 

κι αυτά θα ωριμάζουν. 

Η λειτουργία των εφαρμογών σε δαδικτυακό περιβάλλον δείχνει να είναι μονόδρομος, για έναν πολύ 

μεγάλο αριθμό λόγων. ΋πως φάνηκε μάλιστα και κατά την διάρκεια υλοποίησης, σήμερα παρέχονται 

ολοένα και περισσότερα εργαλεία ανάπτυξης εφαρμογών για χρήση μέσω web, κάνοντας την όλη 

εργασία ευκολότερη κι αποδοτικότερη. 

8.2 Περιβάλλον Εφαρμογής. 

Η Εφαρμογή που παρουσιάστηκε δείχνει ότι μπορεί να παρέχει ικανοποιητικές Προτάσεις Σαξιδίου, 

ιδιαίτερα μάλιστα προς έναν επισκέπτη, ο οποίος στην πραγματικότητα δεν ενδιαφέρεται τόσο για 

την απόλυτα βέλτιστη Πρόταση, όσο για την ευκολία με την οποία μπορεί να έχει μία καλή Πρόταση. 

Η χρήση λοιπόν της Εφαρμογής είναι κατά το δυνατόν απλή, παρέχοντας με αποφυγή της 

υπερβολής διάφορες λειτουργίες. Έτσι π.χ. μπορεί κάποιος με πολλούς τρόπους να επιλέξει την 

προέλευση ή τον προορισμό, αλλά αυτοί οι τρόποι είναι οι προφανείς, κι αυτοί με τους οποίους είναι 

230


ήδη εξοικιωμένοι οι περισσότεροι χρήστες, όπως το απλό dragging ενός κέρσορα, ή το double click 

στην περιοχή που επιθυμείται. 

΋μοια και η παρουσίαση των αποτελεσμάτων, χαρακτηρίζεται από απλότητα και ανθρωποκεντρική 

προσέγγιση. Περαιτέρω βελτίωση του περιβάλλοντος της εφαρμογής μπορεί να γίνει κι αυτή με βάση 

τον άνθρωπο-χρήστη, δηλαδή αξιοποιώντας τις παρατηρήσεις, προτάσεις, κι επιθυμιές των 

πραγματικών χρηστών. Μία προφανής πάντως επέκταση του περιβάλλοντος χρήστη μπορεί να είναι 

η λειτουργία και σε άλλες γλώσσες, πέρα της Αγγλικής. 

Σο Flex framework δείχνει να είναι ιδιαίτερα χρήσιμο στην ανάπτυξη RIAs (Rich Internet 

Applications), καθώς παρέχει πολλά εργαλεία για την εύκολη ανάπτυξη εφαρμογών οι οποίες 

διαθέτουν περιβάλλοντα χρήστη χαρακτηριζόμενα από την υψηλή οπτική ικανοποίηση του χρήστη, 

τόσο καθαρά αισθητικά, όσο και λειτουργικά. 

Ένα ιδιαίτερα χρήσιμο στοιχείο είναι η δυνατότητα εύκολης προσαρμογής της εμφάνισης του 

περιβάλλοντος χρήστη σε διάφορα μεγέθη οθόνης. Έτσι, είναι δυνατή η χρήση της Εφαρμογής τόσο 

σε οθόνες μεγάλου μεγέθους, όσο και σε μικρότερες οθόνες netbook ή κινητών τηλεφώνων, χωρίς 

να υπάρχει μεγάλη διαφοροποίηση στην λειτουργικότητα. 

Γενικότερα μάλιστα, η ανάπτυξη των client εφαρμογών σε Flex έχει το σημαντικό πλεονέκτημα της 

εκτέλεσής τους σε μεγάλη ποικιλία συσκευών και λειτουργικών συστημάτων, με καθόλου ή ελάχιστες 

μεταβολές στον κώδικα. 

8.3 Προτάσεις Σαξιδίου. 

Οι Προτάσεις Σαξιδίου που παρέχονται από την Εφαρμογή είναι πολύ ικανοποιητικές, υπάρχουν 

όμως αρκετά περιθώρια για την βελτίωση του routing engine. 

Σα κυριότερα προβλήματα που παρατηρούνται και οι αιτίες τους, μαζί με κάποιες προτάσεις, είναι 

τα εξής: 

8.3.1 Δεδομένα Δικτύου ΜΜΜ. 

Οποιαδήποτε εφαρμογή του είδους βασίζεται πάρα πολύ στα δεδομένα που χρησιμοποιούνται. 

Ακόμη και η καλύτερη εφαρμογή από πλευράς λειτουργιών, δεν έχει καμία πρακτική αξία αν 

231


χρησιμοποιεί λάθος δεδομένα, ή δεδομένα χαμηλής ποιότητας, που μπορούν να επηρεάσουν ακόμη 

και την ίδια της την λειτουργία. Γενικότερα, μια εφαρμογή οφείλει να είναι προσαρμοσμένη στο είδος 

των διαθέσιμων στοιχείων. 

Σα πρωτογενή δεδομένα από τον ΟΑ΢Α χαρακτηρίζονται ότι τόσο από την έλλειψη εγκυρότητας ή 

πληρότητας, όσο από την έλλειψη τυποποίησης και σταθερής μορφής. Αυτό κατά συνέπεια 

δημιουργεί την ανάγκη πολλαπλών ελέγχων και χειρισμών ώστε να προκύψουν δεδομένα με 

ομοιομορφία και συνάφεια. ΋λοι αυτοί οι έλεγχοι και χειρισμοί δεν είναι εφικτό όμως να 

αυτοματοποιηθούν, και συνεπώς χρειάζονται συνεχώς ―manual‖ σκέψεις και ενέργειες. 

Σο πρόβλημα αυτό με τα δεδομένα δεν είναι στιγμίαιο, καθώς δυσκολεύεται η συνεχής ενημέρωση 

των στοιχείων που χρησιμοποιούνται από την εφαρμογή, όπως επίσης κι ο εντοπισμός των 

διαφοροποιήσεων που γίνονται σε αυτά. ΢υνεπώς, η διαρκής τροφοδότηση της εφαρμογής με 

επικαιροποιημένα στοιχεία είναι ιδιαίτερα δύσκολη, χωρίς να είναι πρακτικά εφικτή η δημιουργία 

μίας βοηθητικής εφαρμογής για τον έλεγχο αλλαγών στα στοιχεία δικτύου και την εύκολη κι 

αυτοματοποιημένη δημιουργία νέων GT feeds. 

Σα προβλήματα εγκυρότητας και πληρότητας δεν είναι τα κύρια, όμως κι αυτά δεν είναι λίγα, καθώς 

π.χ. δεν στάθηκε δυνατόν κατά την υλοποίηση της Εφαρμογής να βρεθούν στοιχεία δρομολογίων για 

τον Προαστιακό ΢ιδηρόδρομο. Επίσης, σε αρκετές περιπτώσεις οι χρόνοι διαδρομής π.χ. δεν 

ανταποκρίνονταν στην πραγματικότητα, και χρειάστηκε να τροποιηθούν με βάση την εμπειρία και 

την αξιοποίηση στοιχείων από διάφορες έρευνες. 

΋μοια με ότι ειπώθηκε για τον Προαστικό ΢ιδηρόδρομο, δεν υπάρχουν εύκολα προσβάσιμα κι 

αξιοποιήσιμα στοιχεία για τα δρομολόγια των Προαστιακών Λεωφορείων του ΚΣΕΛ Αττικής. Η 

χρησιμότητα του ΚΣΕΛ είναι όμως πολύ μικρή σε κάποιον επισκέπτη της πόλης. 

΢χετικά πρόσφατα ο ΟΑ΢Α έθεσε σε λειτουργία το καινούριο του portal. Είναι πιθανόν να μπορεί να 

γίνει προγραμματιστικά αξιοποίησή του για τον έλεγχο και την ενημέρωση κάποιων από τα στοιχεία 

της Εφαρμογής, όμως πριν από οποιαδήποτε σχετική προσπάθεια, κρίνεται σκόπιμο να είναι πιο 

οριστικοποιημένη η λειτουργία αυτού του νέου portal. 

Ένα άλλο πρόβλημα που σχετίζεται με τα δεδομένα είναι η μορφή του de facto προτύπου GTFS που 

έχει επικρατήσει. Σο πρότυπο καλείται να καλύψει περιπτώσεις δικτύων ΜΜΜ διαφόρων μορφών, 

όπως επίσης και τις συνδέσεις μεταξύ τους, καθώς το σύστημα routing της Google φιλοδοξεί να 

καλύψει όσο το δυνατόν περισσότερες περιοχές του πλανήτη. Σο γεγονός αυτό το κάνει όμως 

δύσχρηστο στην μοντελοποίηση διάφορων περιπτώσεων, όπως υπάρχουν π.χ. στο σύστημα ΜΜΜ 

της Αθήνας. Κρίθηκε καλύτερο όμως για την Εφαρμογή να ακολουθεί όσο το δυνατόν περισσότερο 

υπάρχοντα πρότυπα και να μπορεί να γίνεται αξιοποίηση έτσι όσο το δυνατόν περισσότερων 

υπαρχόντων εργαλείων. Θα μπορούσε να προταθεί η διερεύνηση δημιουργίας ενός πληρέστερου και 

232


προσαρμοστικότερου προτύπου, όμως είναι πιθανόν το ίδιο το GTFS να μετεξελλιχθεί σταδιακά σε 

κάτι καλύτερο. 

8.3.2 Φρησιμοποιούμενοι Φάρτες. 

Αν και για την απεικόνιση, αλλά και το τελικό routing των διαδρομών πεζή χρησιμοποιείται ο χάρτης 

της Google, εν τούτοις το αρχικό routing βασίζεται στο OpenStreetMaps. Δυστυχώς, τα στοιχεία του 

OSM για την περιοχή της Αθήνας δεν είναι επαρκώς συμπληρωμένα, με αποτέλεσμα να 

παρουσιάζονται κάποια προβλήματα εξαιτίας αυτού του γεγονότος. Ένα χαρακτηριστικό τέτοιο 

παράδειγμα είναι η μη ακριβής και λεπτομερής συμπερίληψη των διαφόρων διαβάσεων, με 

αποτέλεσμα να υπάρχει τελικά διαφοροποίηση του μήκους και του χρόνου διαδρομής που δίνεται 

από το routing engine του OTP και αυτών που ισχύουν για την διαδρομή που δίνεται από το Google 

Directions. Υυσικά, το πρόβλημα δεν είναι τόσο το ποιό μήκος θα παρουσιάζεται στον Φρήστη (είναι 

εύκολα εφικτό να παρουσιάζεται οποιοδήποτε από τα δύο), όσο το ότι λόγω των περιορισμένων 

στοιχείων του OSM επηρεάζεται η αναζήτηση των Προτάσεων Σαξιδίων, καθώς υπάρχει λανθασμένη 

εκτίμηση για τις αποστάσεις που πρέπει να διανυθούν πεζή από, προς, αλλά και μεταξύ των 

στάσεων. 

Σο πρόβλημα αυτό δεν παρουσιάζεται πάντως σημαντικό σε πολλά σημεία. Η λύση είναι φυσικά ο 

εμπλουτισμός του Φάρτη OSM. Διάφορες λύσεις που εξετάστηκαν αρχικά αυτοματοποιημένου 

ελέγχου και συμπλήρωσης, κυρίως ώστε να χρησιμοποιούταν αποκλειστικά ο OSM στην Εφαρμογή, 

συναντούν κατά κανόνα προβλήματα πνευματικών δικαιωμάτων, καθώς οι εναλλακτικοί χάρτες δεν 

διατίθενται ελεύθερα. 

8.3.3 Αλγόριθμοι Αναζήτησης Προτάσεων Σαξιδίου. 

Ακόμα κι αν υπήρχαν τα απολύτως τέλεια δεδομένα διαθέσιμα, τίποτα δεν εγγυάται την ποιότητα 

των Προτάσεων Σαξιδίου, καθώς αυτή εξαρτάται κι από τους αλγόριθμους αναζήτησης. 

Οι αλγόριθμοι γενικότερα δεν είναι συνήθως κατασκευασμένοι ώστε να δίνουν την τέλεια λύση, αλλά 

μία ικανοποιητική λύση στις περισσότερες των περιπτώσεων, και μέσα σε σύντομο χρόνο, κάνοντας 

όσο το δυνατόν εξοικονόμηση των διαθέσιμων πόρων. Λειτουργούν δηλαδή πάνω στον συμβιβασμό 

της τελειότητας τού αποτελέσματος και τού περιορισμού των χρησιμοποιούμενων, προσπαθώντας 

να εκμεταλλευτούν τις ιδιαιτερότητες που παρουσιάζονται. 

΢την Εφαρμογή που παρουσιάστηκε χρησιμοποιήθηκε για το routing engine (έπειτα από 

τροποποιήσεις) ο OpenTripPlanner, o οποίος λειτουργεί με βάση τον αλγόριθμο A*, κάνοντας πρώτα 

233


χρήση αλγόριθμου της τεχνικής Contraction Ηιerarchies για τον περιορισμό του μεγέθους του 

Γράφου. 

Ένα πρόβλημα που υπάρχει, αν κι όχι ορατό από τους Φρήστες, είναι η μη καλή απόδοση του A* σε 

ένα δίκτυο ΜΜΜ της μορφής που υπάρχει στην Αθήνα. Αυτό έχει ειπωθεί και σε άλλες εργασίες στο 

παρελθόν [Αναφορά #35: Αλιφέρη Λουκία (2009), ΢χεδιασμός Πληροφοριακού ΢υστήματος 

Ενημέρωσης Επιβατικού Κοινού Αστικών ΢υγκοινωνιών με έμφαση στις Αστικές ΢υγκοινωνίες της 

Αττικής, Διπλωματική Εργασία, Πανεπιστήμιο Αιγαίου, Σμήμα Μηχανικών ΢χεδίασης Προϊόντων και 

΢υστημάτων][Αναφορά #36: Κουτσογιάννη Μαριάννα (2006), Αλγόριθμοι Δρομολόγησης Με Μέσα 

Μαζικής Μεταφοράς ΢το Δίκτυο Σων Αθηνών, Διπλωματική Εργασία, Εθνικό Μετσόβιο Πολυτεχνείο, 

΢χολή Ηλεκτρολόγων Μηχανικών & Μηχανικών Η/Τ], και οφείλεται κυρίως στο ότι ευρετικά ο 

αλγόριθμος πηγαίνει ευκλίδεια από την προέλευση στον προορισμό, ενώ το δίκτυο της Αθήνας είναι 

έντονα ακτινικό. Έτσι, στην πραγματικότητα ο αλγόριθμος καθυστερεί στην εύρεση λύσης, αφού δεν 

ακουλουθεί την μορφή του δικτύου, αλλά τείνει συνεχώς να απομακρύνεται από την πορεία της 

λύσης. 

Ένα δεύτερο πρόβλημα, το οποίο επηρεάζει σημαντικά τις παραγόμενες Προτάσεις Σαξιδίου, είναι η 

αναζήτησή τους με βάση αυστηρούς χρόνους διέλευσης των ΜΜΜ από τις στάσεις. Δεν είναι μόνο η 

αναζήτηση αυτή καθαυτή που γίνεται έτσι, αλλά ακόμη και η δημιουργία του Γράφου. 

΢ε πολλές πόλεις ανά τον κόσμο, τα ΜΜΜ έχουν ακριβείς χρόνους διέλευσης από τις στάσεις. Έτσι 

π.χ., έχει νόημα η αναζήτηση συγκεκριμένων δρομολογίων, με χρήση των οποίων ελαχιστοποιείται ο 

χρόνος ταξιδίου, λαμβάνοντας υπόψη συγκεκριμένους χρόνους διαδρομής, αλλά και αναμονής στις 

στάσεις. 

΢την Αθήνα όμως, το δίκτυο των ΜΜΜ δεν βασίζεται σε συγκεκριμένα δρομολόγια και Γραμμές, 

αλλά σε άξονες ΜΜΜ και συχνότητες δρομολογίων. Δηλαδή, υπάρχουν πάρα πολλές Γραμμές που 

κινούνται κατά μήκος μιας διαδρομής, και κάποιος μπορεί να χρησιμοποιήσει οποιαδήποτε από 

αυτές για την μετακίνησή του στο κοινό τμήμα. Ο χρόνος διαδρομής είναι πρακτικά ίδιος για όλες 

αυτές τις Γραμμές. ΢ε σχέση με τις Γραμμές ενός άλλου εναλλακτικού άξονα, ο επιβάτης θα επιλέξει 

με βάση τον καθαρό χρόνο αναμονής αλλά και τον χρόνο αναμονής στη στάση, ο οποίος εξαρτάται 

απο τις συχνότητες διέλευσης. Ο επιβάτης δεν γνωρίζει και δεν δεν ενδιαφέρεται δηλαδή για τους 

ακριβείς χρόνους διέλευσης, οι οποίοι σχεδόν σε όλες τις περιπτώσεις δεν είναι ούτως ή άλλως 

προκαθορισμένοι. 

Ο Open Trip Planner, ακόμη και στις περιπτώσεις που δεν δίνονται συγκεκριμένα δρομολόγια ως 

δεδομένα, αλλά περίοδοι δρομολογίων, δημιουργεί στην πραγματικότητα βοηθητικά δρομολόγια 

ξεκινώντας από την χρονική στιγμή της αφετηρίας του πρώτου δρομολογίου, κι επαναλαμβάνοντάς 

αυτό ανά τον χρόνο περιόδου. 

234


Σο αποτέλεσμα είναι να προκρίνονται σε πολλές περιπτώσεις Προτάσεις απλά και μόνο επειδή 

θεωρητικά ο συνδυασμός των χρονικών στιγμών διελεύσεων παρέχουν γρηγορότερη άφιξη στον 

προορισμό, εις βάρος Προτάσεων που είναι πιο αξιόπιστες για την γρηγορότερη άφιξη. Επίσης, για 

τον ίδιο λόγο, παρατηρείται το φαινόμενο να υπάρχουν μετεπιβιβάσεις στις Προτάσεις εκεί που με 

βάση την εμπειρία δεν έχουν μεγάλο νόημα. ΋πως ειπώθηκε, κατά μήκος μίας κοινής διαδρομής τα 

οχήματα όλων των Γραμμών κινούνται κατά κανόνα με την ίδια μέση ταχύτητα. ΢ε συνδυασμό όμως 

με το ότι οι χρόνοι μεταξύ των στάσεων είναι άγνωστοι και προκύπτουν με παρεμβολή στον συνολικό 

χρόνου ταξιδίου του δρομολογίου, το routing engine, εξετάζοντας κάθε Γραμμή ξεχωριστά κι όχι 

όλες μαζί σαν ομάδα κατά το κοινό τμήμα, εκτιμά ότι η μετεπιβίβαση σε μία (εικονικά) ταχύτερη 

Γραμμή θα βελτιώσει τον συνολικό χρόνο της Πρότασης. Ακόμη και με μεγάλη αύξηση της ποινής 

που επιβάλλεται κατά το routing στην μετεπιβίβαση, είναι τελικά δυνατόν αυτή να προτείνεται, αν οι 

χρόνοι διέλευσης από μία κοινή στάση δύο Γραμμών είναι πολύ κοντά, οπότε και θεωρείται η 

δημιουργούμενη καθυστέρηση ότι είναι πολύ μικρότερη του κέρδους που προκύπτει από την 

αυξημένη ταχύτητα. 

΢υχνότερη είναι η εμφάνιση του προβλήματος στους άξονες που χρησιμοποιούνται από Γραμμές 

διαφορετικού συνολικά χαρακτήρα. Π.χ. αν σε ένα άξονα υπάρχει μία Γραμμή η οποία κατευθύνεται 

προς το Κέντρο, αλλά η αφετηρία της είναι αρκετά εκτός της πόλης (π.χ. Ιερά Οδός κι Ελευσίνα), 

τότε αυτή ευνοείται έναντι των υπολοίπων, καθώς μεταξύ ενός κοινού ζεύγους στάσεων παρουσιάζει 

τον μικρότερο χρόνο διαδρομής. Αυτό όμως δεν ανταποκρίνεται στην πραγματικότητα, αφού επί της 

ουσίας είναι η λανθασμένη μεταφορά στο πυκνό αστικό τμήμα της μεγαλύτερης ταχύτητας που έχει 

Γράμμη στο πιο αραιό αστικό τμήμα (π.χ. από την κίνησή της κατά μήκος της Λ. Αθηνών) λόγω της 

παρεμβολής με βάση την όλη διαδρομή. 

΢τα πλαίσια της εκπόνησης εξετάστηκαν διάφορες εναλλακτικές λύσεις, όπως π.χ. η δημιουργία 

εικονικών δρομολογίων που να αφορούν τα κοινά τμήματα Γραμμών. ΢ε όλες τις περιπτώσεις αυτές 

όμως υπήρχε σημαντική πολυπλοκότητα με προφανή μη ικανοποιητικά αποτελέσματα, αφού π.χ. 

εμφανίζονταν πολλές μετεπιβιβάσεις, οι οποίες μπορούσαν να περιοριστούν μόνο μέσω πολύπλοκων 

διαδικασιών. 

Αυτό που προτείνεται είναι η ανάπτυξη ενός καινούριου αλγόριθμου, ο οποίος θα αντιμετωπίζει 

αποτελεσματικά περιτπώσεις όπως αυτές της Αθήνας. Κατά την εκπόνηση της Εργασίας έγινε από 

περιέργεια επιφανειακή διερεύνηση ενός τέτοιου αλγόριθμου, χρησιμοποιώντας Visual Basic. 

Σα κύρια χαρακτηριστικά του προτεινόμενου αλγόριθμου είναι συνοπτικά τα εξής: 

Βελτιστοποίηση όχι με βάση μόνο τον χρόνο διαδρομής ή/και τον αριθμό των 

μετεπιβιβάσεων, αλλά με βάση μία άλλη τιμή, στην συνάρτηση της οποίας θα 

εμπλέκεται ως μία μεταβλητή ο χρόνος, ενώ άλλες μεταβλητές μπορούν να είναι 

235


π.χ. η ποιότητα και ευκολία της μετακίνησης (σαφώς μεγαλύτερη στο metro από 

ότι στα λεωφορεία), η αξιοπιστία, το κόστος, κτλ. 

Διαδιακασία εύρεσης με αναζήτηση 2 κατευθύνσεων, με βάση τις συνδέσεις. Η 

αναζήτηση μπορεί να γίνεται σε στάδια, με το πρώτο στάδιο να έχει έναν 

απλοποιημένο Γράφο π.χ., στον οποίο να υπάρχουν μόνο οι στάσεις που αποτελούν 

συνδέσεις, δηλαδή που είναι εφικτές οι μετεπιβιβάσεις. 

Ανάμεσα σε 2 κόμβους/στάσεις να αποδίδεται η τιμή βελτιστοποίησης που 

αναφέρθηκε προηγουμένως, και η οποία δεν αφορά μόνο τον χρόνο διαδρομής. Η 

τιμή αυτή για τις ίδιες δύο στάσεις δεν πρέπει να είναι μία ανά Γραμμή, αλλά μία 

ανά ομάδα Γραμμών που εμφανίζουν κοινά χαρακτηριστικά. 

΢την τιμή αυτή για την συγκεκριμένη δυάδα στάσεων θα πρέπει να περιέχεται και ο 

εκτιμώμενος χρόνος αναμονής με βάση την περίοδο διέλευσης των ΜΜΜ. 

Η αναζήτηση θα πρέπει να κατευθύνεται ευρετικά προς τις ακμές που 

παρουσιάζουν τις καλύτερες τιμές. Με αυτόν τον τρόπο μπορεί να επιτευχθεί 

σημαντική μείωση του χρόνου αναζήτησης, αλλά και να επιτευχθεί η επιλογή 

πραγματικά πολύ καλών λύσεων. Οι ακμές με τις καλύτερες τιμές θα είναι 

προφανώς αυτές που παρουσιάζουν την μεγαλύτερη κίνηση συχνών κι αξιόπιστων 

Γραμμών. 

Για την μείωση του συνολικού χρόνου αναζήτησης, θα μπορούσαν να 

προδημιουργούνται τα στοιχεία που αφορούν συγκεκριμένες χρονικές περιόδους, 

και για συγκεκριμένο χρονικό ορίζοντα. Π.χ. θα μπορούσαν να παράγονται 

αυτόματα στο background του server τα στοιχεία που αφορού δίωρες περιόδους 

για τις επόμενες 2 ημέρες. Κι αυτό γιατί, σπάνια ένα αστικό ταξίδι ξεπερνά τις 2 

ώρες σε διάρκεια, κι επίσης σπάνια κάποιος κάνει αναζήτηση για το πως θα 

πραγματοποιήσςι μία αστική μετακίνηση πολλές ημέρες πριν. 

Θα μπορούσαν να αξιοποιούνται προηγούμενες αναζητήσεις, ώστε να μειωθεί ο 

χρόνος και το υπολογιστικό κόστος. Θα μπορούσε δηλαδή να γίνεται χρήση των 

αποτελεσμάτων από αναζητήσεις που έχουν γίνει στο παρελθόν κι αφορούν 

παραπλήσιους χρόνους και προελεύσεις-προορισμούς. 

Σα αποτελέσματα από την επιφανειακή ερευνητική διερεύνηση ήταν αρκετά ενθαρρυντικά, όμως 

πρέπει να αντιμετωπιστούν διεξοδικά πάρα πολλά θέματα, κυρίως σε ότι έχει να κάνει με τον 

236


περιορισμό του απαιτούμενου χρόνου αναζήτησης. Κάτι τέτοιο ήταν αρκετά πέρα από το 

αντικείμενο της παρούσας Εργασίας, αφού στην ουσία το θέμα θα μπορούσε κάλλιστα να 

αποτελέσει αντικείμενο έρευνας αφιερωμένης αποκλειστικά σε αυτό. Η παρούσα απλά μπορεί να το 

αναδείξει. 

Άλλωστε, ακόμη κι αν ήταν εφικτό να χρησιμοποιηθεί ένας τέτοιος αλγόριθμος στην Εφαρμογή της 

παρούσας Εργασίας, αυτό θα παρουσίαζε το αρνητικό τού να μην μπορεί να χρησιμοποιηθεί η 

Εφαρμογή πρακτικά σε άλλες πόλεις, κάτι το οποίο τώρα είναι εφικτό. Έτσι, μπορεί η Εφαρμογή να 

τροποποιηθεί εύκολα και να γίνει χρήσιμη σε μία πόλη που να δέχεται αρκετούς επισκέπτες, και στην 

οποία τα ΜΜΜ λειτουργούν με βάση αυστηρούς χρόνους διέλευσης, που είναι ο κανόνας. Επίσης, με 

μικρές τροποποιήσεις η Εφαρμογή θα μπορούσε να χρησιμοποιηθεί κατά τον υπάρχοντα τρόπο 

λειτουργίας και σε αρκετά διαφορετικές περιπτώσεις intermodal routing, όπως π.χ. για υπεραστικές 

λεωφορειακές και σιδηροδρομικές μεταφορές, ακτοπλοϊκές μετακινήσεις, κτλ.., καθώς φυσικά και 

συνδυασμών τους. 

8.4 Βελτιώσεις – Μελλοντικές Επεκτάσεις. 

Οι βελτιώσεις που μπορούν να γίνουν, πέρα από τους αλγόριθμους και τα χρησιμοποιούμενα 

δεδομένα, μπορούν να διακριθούν στις εξής κατηγορίες: 

΢ε αυτές που δεν είναι αντιληπτές από τον χρήστη, ούτε έχουν άμεση επίδραση 

στην λειτουργία της Εφαρμογής. Μία τέτοια βελτίωση είναι π.χ. η καλύτερη 

οργάνωση του κώδικα, η συμπερίληψη σε αυτόν πληρέστερων και καλύτερων 

σημειώσεων, η καλύτερη εννοιολογική προσέγγιση, κτλ.. 

΢ε αυτές που δεν είναι άμεσα αντιληπτές από τον χρήστη, όμως επηρεάζουν την 

λειτουργία της Εφαρμογής. Για παράδειγμα, μπορεί σε κάποια σημεία να 

βελτιστοποιηθεί ο κώδικας ώστε να είναι περισσότερο αξιόπιστη η λειτουργία (όπως 

πληρέστερο error handling και validation), κάποια λειτουργία να προσεγγιστεί 

συνολικά αποδοτικότερα, ή να αυξηθεί η ασφάλεια. Σα περισσότερα τέτοια θέματα 

αφορούν το routing engine, το οποίο βέβαια συνεχώς εξελλίσεται. Θα μπορούσαν 

πάντως να πάψουν τελείως κάποιες λειτουργίες που δεν γίνονται σε αυτό αλλά με 

μετεπεξεργασία στην Client εφαρμογή, όπως επίσης να μειωθεί το μέγεθος του 

response, αφαιρώντας στοιχεία που δεν χρησιμοποιούνται. Επίσης, ένα άλλο 

παράδειγμα είναι το garbage collection, όπως είναι το να περιορίζονται οι event 

listeners που απομένουν χωρίς αντικείμενο. ΋λα αυτά τα θέματα όμως, συνήθως 

δεν έχουν μεγάλη πρακτική σημασία σε μία τέτοια εφαρμογή, καθώς αυτή 

εκτελείται μία ή λίγες μόνο συνεχόμενες φορές, 

237


΢ε αυτές που γίνονται άμεσα αντιληπτές από τον χρήστη, όπως είναι π.χ. η 

λειτουργική κι αισθητική βελτίωση του περιβάλλοντος χρήσης. Οι βελτιώσεις αυτές 

έχουν νόημα όμως να γίνουν ανθρωποκεντρικά, με βάση τις παρατηρήσεις και 

προτάσεις δηλαδή των ίδιων των χρηστών, ή με τη βοήθεια άλλων, πιο κατάλληλων 

σχετικά, όπως π.χ. με τη βοήθεια γραφιστών. Ακόμη, στην κατηγορία αυτή, όπως 

και στην προηγούμενη ανάλογα, μπορεί να ενταχθεί το θέμα της προσεχτικότερης 

τήρησης των Copyrights. 

΢τις μελλοντικές επεκτάσεις θα μπορούσε προφανώς να υπάρχει η Client Εφαρμογή σε περισσότερες 

γλώσσες, ακόμη και στα Ελληνικά, αφού δεν είναι απαραίτητο ο επισκέπτης της Αθήνας να είναι 

αλλοδαπός. 

Κάτι που μπορεί να γίνει όταν η Εφαρμογή σε πραγματική λειτουργία έχει πολλούς χρήστες, είναι η 

συγκέντρωση στατιστικών στοιχείων, όπως π.χ. για το τι επιλέγεται συνήθως ως προέλευση και 

προορισμός, τι αναζητάται ως σημείο ενδιαφέροντος, τι γίνεται geocoding και με ποιόν τρόπο 

γράφεται, κτλ.. Η συγκέντρωση αυτών των στοιχείων θα διευκόλυνε π.χ. στο να γίνονται geocoding 

διευθύνσεις που αναζητούνται συχνά με κάποιον λανθασμένο τρόπο γραφής, ή δεν υπάρχουν με 

αυτόν τον τρόπο στην υπηρεσία geocoding της Google. 

Ακόμη, θα μπορούσε και πρέπει να γίνει καλύτερη προσαρμογή για λειτουργία σε συσκευές όπως 

είναι τα κινητά τηλέφωνα. Η Εφαρμογή αφορά χρήστες που θέλουν να μεταινηθούν ή ήδη 

μετακινούνται, και συνεπώς είναι προφανής η σημαντικότητα τού να μπορεί να την χρησιμοποιεί 

κανείς εν κινήσει. 

Σο Flex δίνει την δυνατότητα η Client Εφαρμογή να μπορεί να χρησιμοποιηθεί σε ένα μεγάλο πλήθος 

διαφορετικών συσκευών και λειτουργικών συστημάτων. ΋λες οι Flex εφαρμογές μπορούν να 

εκτελεστούν είτε μέσω του Flash plugin των web browsers, είτε μέσω του Adobe Air που δίνεται 

δωρεάν. Θεωρητικά η Εφαρμογή μπορεί να τρέξει αυτή τη στιγμή σε όσες συσκευές παρέχουν Flash 

υποστήριξη, όμως το κάτα πόσο αυτό ανταποκρίνεται στην πραγματικότητα είναι άγνωστο. Κι αυτό 

γιατί οι περισσότερες τέτοιες συσκευές δεν παρέχουν υποστήριξη τελικά για τον Flash Player 10, 

αλλά για παλιότερη έκδοση με περιορισμένες δυνατότητες (Lite). 

Κατά την υλοποίηση της Εφαρμογής κρίθηκε σκόπιμη η αναμονή μέχρι να υπάρξουν πολύ σύντομα 

εξελίξεις. Ήδη η Adobe έχει ανακοινώσει την έλευση μίας νέας έκδοσης του Flash SDK (‗Hero‘), όπως 

και του Flash Builder (‗Burrito‘), τα οποία είναι προσανατολισμένα στις φορητές συσκευές, δίνοντας 

μάλιστα την δυνατότητα αξιοποίησης λειτουργιών όπως το ενσωματωμένο GPS. 

238


Είναι προφανής η αύξηση της χρηστικότητας της Εφαρμογής με αξιοποίηση του GPS, καθώς αυτός 

που κινείται θα μπορεί να κάνει αναζητήσεις Προτάσεων Σαξιδίου με βάση την θέση που βρίσκεται, 

ή να λαμβάνει οδηγίες κατά την πραγματοποίηση ενός ταξιδίου όπως του έχει προταθεί. 

Αρκετές εταιρείες κινητών τηλεφώνων έχουν ανακοινώσει συσκευές με υποστήριξη του Flash Player 

10, οι οποίες αναμένονται σύντομα. Οι περισσότερες από αυτές θα χρησιμοποιούν το Android ως 

λειτουργικό σύστημα. Επίσης, σταδιακά γίνεται ολοένα και φτηνότερη η πρόσβαση Internet μέσω 

κινητής τηλεφωνίας, γεγονός που συμβάλλει στην ανάπτυξη σχετικών εφαρμογών. Ακόμη το κόστος 

είναι ιδιαίτερα υψηλό, οπότε κι αν τεχνολογικά είναι κάτι εφικτό, αυτό μπορεί να μην έχει προς το 

παρόν απήχηση, για λόγους καθαρά οικονομικούς. ΢ύντομα όμως αναμένεται αυτό να μην υπάρχει 

ως πρόβλημα. 

Ιδιαίτερα σημαντική επέκταση της Εφαρμογής, θα την άλλαζε ριζικά, θα ήταν η αξιοποίηση live 

δεδομένων για την κίνηση των οχημάτων ΜΜΜ. Με αυτό τον τρόπο θα δινόταν η δυνατότητα 

δημιουργίας Προτάσεων Διαδρομής με βάση την πραγματική κατάσταση που θα επικρατούσε στο 

δίκτυο σε μία δεδομένη στιγμή. Γνωρίζοντας τις θέσεις και τις ταχύτητες των οχημάτων σε κάθε 

Γραμμή, ο χρήστης θα μπορούσε να λαμβάνει προτάσεις στο κινητό τηλέφωνο για το ταξίδι του, οι 

οποίες να είναι βελτιστοποιημένες ανάλογα με την επικρατούσα κατάσταση την στιγμή που αυτός 

είναι εν κινήσει, όπως επίσης να μπορεί να έχει ακριβή πληροφόρηση για την αναμονή στην στάση 

κτλ.. 

Ακόμη όμως και οι Προτάσεις Σαξιδίων που δεν θα γίνονταν από κάποιον που θα ήθελε να 

μετακινηθεί άμεσα, αλλά από κάποιον που από το σπίτι του θα σχεδίαζε ένα ταξίδι για να το 

πραγματοποιήσει κάποια από τις προσεχείς ημέρες, αυτές θα ήταν αρκετά πιο καλές με αξιοποίηση 

των συλλεγόμενων στοιχείων. Κι αυτό γιατί θα μπορούσε να γίνεται συνεχώς επανεκτίμηση των 

χρόνων διαδρομής, για διάφορες χρονικές περιόδους της ημέρας. 

Δυστυχώς όμως, ο ΟΑ΢Α δεν διαθέτει κάποιο ανάλογο πλήρες σύστημα τηλεματικής, παρά το μικρό 

σχετικά απαιτούμενο κόστος. 

239


240


ΑΝΑΥΟΡΕ΢ 

I

[01] Wikipedia. 


Διάφορα Άρθρα, η πρόσβαση στα οποία μπορεί να γίνει με λέξεις αναζήτησης. 

http://www.wikipedia.org 

[02] Amadeus IT Group SA. 

Προϊόντα σχετικά με Journey Planning αεροπορικών ταξιδίων. 

http://www.amadeus.net 

[03] Sabre Airline Solutions. 


http://www.sabreairlinesolutions.com/home/products_services/airline_reservations 

[04] Travelport Galileo. 


http://www.travelport.com/lob/gds/galileo.aspx 

[05] Transport for London. 

Υορέας για τις Αστικές ΢υγκοινωνίες στο London. 

http://www.tfl.gov.uk 

[06] EU-Spirit. 

Βασισμένη στο internet υπηρεσία πληροφόρησης για χρήστες δημόσιας συγκοινωνίας. 

http://www.eu-spirit.com 

[07] JourneyWeb. 

Πρωτόκολο διασύνδεσης για Journey Planners. 

http://www.journeyweb.org 

[08] Xephos. 

Intermodal Journey Planner για το Ηνωμένο Βασίλειο, με εφαρμογές σε διάφορα sites. 

http://www.internet.xephos.com 

[09] EFA (Elektronische Fahrplanauskunft). 

΢ύστημα IJP της εταιρείας Mentz Datenverarbeitung GmbH 

http://www.mentzdv.de/englisch/products/efa 

[10] Google Transit. 

[11] RATP. 

IJP της εταιρείας Google. 

http://www.google.com/transit 

Ο φορέας Αστικών ΢υγκοινωνιών για την Ευρύτερη Περιοχή του Paris. 

http://www.ratp.fr 

II

[12] ΟΑ΢Α. 


Οργανισμός Αστικών ΢υγκοινωνιών Αθήνας. 

http://www.oasa.gr 

[13] Πύλη Δρομολόγησης της Περιφέρειας Αττικής. 

Πύλη Δρομολόγησης της Περιφέρειας Αττικής. 

http://www.atticaroute.gr 

[14] youDrive. 

[15] TSP. 

IJP για την περιοχή της Αθήνας. 

http://www.youdrive.gr 

Site σχετικά με το πρόβλημα του Περιπλανώμενου Πωλητή. 

http://www.tsp.gatech.edu 

[16] Oberlin College / Department of Mathematics / Robert Bosch. 

OPT και TSP δημιουργία έργων ζωγραφικής. 

http://www.oberlin.edu/math/faculty/bosch.html 

[17] Contraction Hierarchies: Faster and Simpler Hierarchical Routing in Road Networks. 

Robert Geisberger, Peter Sanders, Domminik Schultes, Daniel Delling (2008). 

http://algo2.iti.kit.edu/download/contract.pdf 

[18] Java Computer Programming Language. 

Η γλώσσα προγραμματισμού Java. 

http://www.java.com 

[19] Eclipse. 

Περιβάλλον ανάπτυξης εφαρμογών Eclipse. 

http://www.eclipse.org 

[20] Subversion. 

΢ύστημα διαχείρισης εκδόσεων λογισμικού. 

http://subversion.apache.org 

[21] Apache Maven. 

Εργαλείο Διαχείρισης Projects λογισμικού. 

http://maven.apache.org 

[22] Apache Tomcat. 

Λογισμικό ανοικτού κώδικα για τις τεχνολογίες Java Servlet και JavaServer Pages. 

http://tomcat.apache.org 

III


[23] Apache HTTP Server. 

Project ανοικτού κώδικα για HTTP Server. 

http://httpd.apache.org 

[24] Adobe Flex. 

Σο πλαίσιο ανοικτού κώδικα της Adobe για την ανάπτυξη web εφαρμογών. 

http://www.adobe.com/products/flex 

[25] Adobe Flash Builder. 

Λογισμικό της Adobe για την ανάπτυξη Cross-Platform internet εφαρμογών με βάση το Flex. 

http://www.adobe.com/products/flashbuilder 

[26] Opentripplanner.org. 

Σο site για developers τού Open Trip Planner. 

http://www.opentripplanner.org 

[27] Opentripplanner.com. 

Σο site για την εμπορική προώθηση τού Open Trip Planner. 

http://www.opentripplanner.com 

[28] OpenPlans. 

Ο Οργανισμός OpenPlans εστιάζει στην ανοικτή διακυβέρνηση και αναπτύσει λογισμικό 

ανοικτού κώδικα. Ένας από τους κύριους συμμετέχοντες στον Open Trip Planner. 

http://www.openplans.org 

[29] OneBusAway. 

Project που παρέχει υποστήριξη στην βελτίωση της χρηστικότητας των ΜΜΜ. Ένας από 

τους κύριους συμμετέχοντες στον Open Trip Planner. 

http://www.onebusaway.org 

[30] FivePoints. 

Project το οποίο αφορά την ανάπτυξη λογισμικού ανοικτού κώδικα, με εστίαση σε εργαλεία 

για μετακίνηση πεζή, με ποδήλατο, και με ΜΜΜ. Ένας από τους κύριους συμμετέχοντες 

στον Open Trip Planner. 

http://www.fpdev.org 

[31] Graphserver. 

Project το οποίο αφορά την ανάπτυξη λογισμικού ανοικτού κώδικα για multi modal trip 

planning. Ένας από τους κύριους συμμετέχοντες στον Open Trip Planner. 

http://bmander.github.com/graphserver 

[32] byCycle. 

Διαδικτυακή εφαρμογή για τον σχεδιασμό διαδρομών με ποδήλατο στο Portland, στο 

Milwaukee και στο Pittsburgh. Ένας από τους κύριους συμμετέχοντες στον Open Trip 

Planner. 

IV


http://bicycle.org 

[33] General Transit Feed Specification. 

Η προδιαγραφή της Google για τα feeds με τα στοιχεία λειτουργίας των συγκοινωνιακών 

δικτύων. 

http://code.google.com/transit/spec/transit_feed_specification.html 

[34] A Data Model for Trip Planning in Multimodal Transportation Systems. 

[35] 

Joel Booth, Prasad Sistla, Ouri Wolfson, Isabel F. Cruz 

http://www.cs.uic.edu/~ifc/webpapers/edbt2009-submission.pdf 

΢χεδιασμός Πληροφοριακού ΢υστήματος Ενημέρωσης Επιβατικού Κοινού Αστικών 

΢υγκοινωνιών με έμφαση στις Αστικές ΢υγκοινωνίες της Αττικής. 

Διπλωματική Εργασία, Αλιφέρη Λουκία, Πανεπιστήμιο Αιγαίου, Σμήμα Μηχανικών ΢χεδίασης 

Προϊόντων και ΢υστημάτων (2009). 

http://www.syros.aegean.gr/de/dpsd03001.pdf 

[36] Αλγόριθμοι Δρομολόγησης Με Μέσα Μαζικής Μεταφοράς ΢το Δίκτυο Σων Αθηνών. 

Διπλωματική Εργασία, Κουτσογιάννη Μαριάννα, Εθνικό Μετσόβιο Πολυτεχνείο, ΢χολή 

Ηλεκτρολόγων Μηχανικών & Μηχανικών Η/Τ (2006). 

www.dblab.ntua.gr/pubs/uploads/DIPL-2006-2.doc 

[37] Σεχνολογίες Δημοσιοποίησης Φαρτογραφικού Περιεχομένου ΢τον Παγκόσμιο Ιστό. 

΢τεφανάκης Εμμανουήλ (2009). 

Εκδόσεις Νέων Σεχνολογιών, Έκδοση 1η, Αθήνα 2009, ISBN 978-960-6759-30-7. 

[38] Solutio problematis ad geometriam situs pertinentis. 

Euler Leonard (1741). 

Commentarii academiae scientiarum Petropolitanae. 

http://www.math.dartmouth.edu/~euler/docs/originals/E053.pdf 

[39] A note on two problems in connexion with graphs. 

Dijkstra Edsger Wybe (1959). 

Numerische Mathematik 1: 269–271. 

http://www-m3.ma.tum.de/foswiki/pub/MN0506/WebHome/dijkstra.pdf 

[40] Ueber eine Fläche der vierten Ordnung. 

Hierholzer Carl (1871). 

Mathematische Annalen IV. 

http://www-m3.ma.tum.de/foswiki/pub/MN0506/WebHome/dijkstra.pdf 

[41] A Formal Basis for the Heuristic Determination of Minimum Cost Paths. 

Hart, P. E.; Nilsson, N. J.; Raphael, B. (1968). 

IEEE Transactions on Systems Science and Cybernetics SSC4 4 (2): 100–107. 

doi:10.1109/TSSC.1968.300136 

V

[42] AlivePDF. 


Βιβλιοθήκη ανοικτού κώδικα για την εκτύπωση σε PDF αρχεία. 

http://www.alivepdf.org 

VI


ΚΑΣΑΛΟΓΟ΢ ΢ΣΟΙΦΕΙΩΝ 

VII


Πίνακας 1: Εκτιμήσεις απαιτήσεων του OTP σε υπολογιστικό εξοπλισμό. ......................................... 127 

Διάγραμμα 1: Λειτουργική Ροή της Εφαρμογής Φρήστη. .................................................................... 63 

Διάγραμμα 2: Σα διάφορα τμήματα που αποτελούν την υπηρεσία, και οι αλληλοσυσχετίσεις τους. . 68 

Διάγραμμα 3: Σο Διάγραμμα Οντοτήτων-΢υσχετίσων (E-R) που αντιστοιχεί στο GTFS (Με γαλάζιο 

χρώμα ή παχείς χαρακτήρες τα απαραίτητα στοιχεία). .................................................................... 105 

Διάγραμμα 4: Απεικόνιση της Αρχιτεκτονικής Client-Server, με έναν ή περισσότερους Servers, οι 

οποίοι ενδέχεται να επικοινωνούν άμεσα μεταξύ τους. ..................................................................... 134 

Διάγραμμα 5: Λειτουργική Ροή της Εφαρμογής Φρήστη. .................................................................. 137 

Διάγραμμα 6: Λειτουργίες κατά την παραμετροποίηση. ................................................................... 161 

Διάγραμμα 7: Εύρεση προτάσεων ταξιδίου, μετεπεξεργασία, εμπλουτισμός, κι άλλες ενέργειες. ... 162 

Διάγραμμα 8: Παρούσιαση Προτάσεων, διαχείρισή τους, και επιλογή συνέχειας. ............................ 162 

Διάγραμμα 9: Απεικόνιση τού ποιές λειτουργίες εκτελούνται σε κάθε τμήμα του ΢υστήματος. ....... 163 

Διάγραμμα 10: Οι εναλλακτικές συνδέσεις μεταξύ δύο στάσεων βρίσκονται μέσω PHP αρχείου που 

κάνει SQL ερώτημα σε πίνακα της PostgreSQL. ................................................................................ 182 

Διάγραμμα 11: ΢χηματική παράσταση των διαφόρων τμημάτων του συστήματος της Εφαρμογής και 

οι συνδέσεις μεταξύ τους. ................................................................................................................... 188 

Διάγραμμα 12: Σα διάφορα αντικείμενα που αποτελούν την βασική οθόνη της Εφαρμογής, σε 

σχηματική παράσταση. ....................................................................................................................... 196 

Διάγραμμα 13: Σα διάφορα αντικείμενα που αποτελούν την οθόνη της Εφαρμογής μετά την θέση 

του ερωτήματος, σε σχηματική παράσταση. Σο γαλάζιο παραλληλόγραμμο αντιστοιχεί στο panel 

εμφάνισης των Προτάσεων. ................................................................................................................ 208 

Διάγραμμα 14: ΢χηματική Απεικόνιση της Διαδικασίας Θέσης Ερωτημάτων, Λήψης Απαντήσεων, και 

διαχείρισής τους, από την Client Εφαρμογή. ..................................................................................... 212 

VIII


Εικόνα 1: Επίλυση ενός γράφου με τον αλγόριθμο του Dijkstra, με χρήση λογισμικού που οπτικοποιεί 

την διαδικασία επίλυσης κατά βήμα. Πηγή: http://www.uweschmidt.org. .......................................... 2 

Εικόνα 2: Ο πρώτος Διαγραμματικός Φάρτης του Harry Beck (1933) για το Metro του London. ....... 8 

Εικόνα 3: Οι διάφορες επιλογές στον ΢χεδιαστή Σαξιδιών του TfL. ..................................................... 11 

Εικόνα 4: ΢υνοπτικά οι διάφορες προτάσεις ταξιδίου από μία αναζήτηση στον Journey Planner του 

Tfl. .......................................................................................................................................................... 11 

Εικόνα 5: Εμφάνιση λεπτομερειών για μία πρόταση ταξιδίων του Journey Planner του Tfl. .............. 12 

Εικόνα 6: Ο ΢χεδιαστής Σαξιδιών για τηλεφωνικά κέντρα του EFA. .................................................... 13 

Εικόνα 7: Σο περιβάλλον του Google Transit με αποτελέσματα από αναζήτηση για αστική μετακίνηση 

στο Amsterdam. ΢τα αριστερά της εικόνας παρουσιάζονται 4 διαφορετικές προτάσεις, κι από κάτω, 

λεπτομέρειες για την επιλεγμένη από αυτές. ....................................................................................... 15 

Εικόνα 8: Φαρακτηριστική εικόνα από το Google Transit σε οθόνη κινητού. ..................................... 16 

Εικόνα 9: Σο περιβάλλον χρήσης για τον trip planner της RATP με βάση το κείμενο. ........................ 18 

Εικόνα 10: Αποτελέσματα του trip planner της RATP. ........................................................................ 19 

Εικόνα 11: Ο διαδραστικός χάρτης/trip planner της RATP. ................................................................ 20 

Εικόνα 12: Η εφαρμογή RATP Premium σε iPhone. ............................................................................ 21 

Εικόνα 13: Εισαγωγή/αναζήτηση Αφετηρίας-Σερματισμού στην εφαρμογή ΑΔΑΜΑ΢. ....................... 22 

Εικόνα 14: Φαρακτηριστική εικόνα προτεινόμενων διαδρομών από την εφαρμογή ΑΔΑΜΑ΢. .......... 24 

Εικόνα 15: Φαρακτηριστικό στιγμιότυπο από την Πύλη Δρομολόγησης της Περιφέρειας Αττικής. .... 26 

Εικόνα 16: Παράδειγμα εμφάνισης ΢ημείων Ενδιαφέροντος με ίδια ονομασία, χωρίς δυνατότητα 

άμεσης αναγνώρισής τους. ................................................................................................................... 27 

Εικόνα 17: Φαρακτηριστικό στιγμιότυπο από την εφαρμογή YouDrive, όπου εμφανίζεται μία πρόταση 

ταξιδίου. ................................................................................................................................................ 29 

IX


Εικόνα 18: Διάγραμμα ενός Γράφου. Ο Γράφος μπορεί να περιγραφεί ως V = {1, 2, 3, 4, 5, 6}, E = 

{{1, 2}, {1, 5}, {2, 3}, {2, 5}, {3, 4}, {4, 5}, {4, 6}}, δηλαδή από τα σύνολα των Κόμβων και των Ακμών 

αντίστοιχα. Σο μέγεθος του Γράφου είναι 7, κι ο Βαθμός π.χ. του Κόμβου 5 είναι 3. Οι Ακμές {4,5}, 

{2,5}, {5,1} είναι γειτονικές. Επίσης, οι Κόμβοι 1, 2, 4 είναι γειτονικοί του 5. .................................... 36 

Εικόνα 19: Φάρτης του Königsberg την εποχή του Euler, με τονισμένες τις γέφυρες και τον ποταμό. 

............................................................................................................................................................... 38 

Εικόνα 20: Η αφαιρετική διαδικασία στο πρόβλημα του Euler. .......................................................... 38 

Εικόνα 21: Δείγμα του Πίνακα ‗Γραμμές‘ των πρωτογενών δεδομένων ΜΜΜ. .................................. 70 

Εικόνα 22: Δείγμα του Πίνακα ‗ΚΛΑΔΟΙ‘ των πρωτογενών δεδομένων ΜΜΜ. ................................... 72 

Εικόνα 23: Η κυκλική κατά όλες τις απόψεις Γραμμή ‗100‘. .............................................................. 74 

Εικόνα 24: Η κυκλική σε λειτουργία αλλά όχι σε γεωμετρία Γραμμή ‗910‘. ........................................ 75 

Εικόνα 25: Δείγμα από τον πίνακα ‗΢ΣΑ΢ΕΙ΢‘ των πρωτογενών δεδομένων ΜΜΜ. ............................ 76 

Εικόνα 26: Δείγμα από τον πίνακα ‗ΑΛΛΗΛΟΤΦΙΑ ΢ΣΑ΢ΕΨΝ‘ των πρωτογενών δεδομένων ΜΜΜ. .... 77 

Εικόνα 27: Σο πλήρες αρχείο ‗agency.txt‘ όπως δημιουργήθηκε, σε πινακοποιημένη μορφή. ........... 80 

Εικόνα 28: Δείγμα από το αρχείο ‗stops.txt‘ όπως δημιουργήθηκε, σε πινακοποιημένη μορφή. ..... 82 

Εικόνα 29: Δείγμα από το αρχείο ‗routes.txt‘ όπως δημιουργήθηκε, σε πινακοποιημένη μορφή. .... 84 

Εικόνα 30: Δείγμα από το αρχείο ‗trips.txt‘ όπως δημιουργήθηκε, σε πινακοποιημένη μορφή. ....... 87 

Εικόνα 31: Δείγμα από το αρχείο ‗stop_times.txt‘ όπως δημιουργήθηκε, σε πινακοποιημένη μορφή. 

............................................................................................................................................................... 92 

Εικόνα 32: Σο πλήρες αρχείο ‗calendar.txt‘ όπως δημιουργήθηκε, σε πινακοποιημένη μορφή. ....... 94 

Εικόνα 33: To σύνολο του αρχείου ‗fare_attributes.txt‘ όπως δημιουργήθηκε, σε πινακοποιημένη 

μορφή. ................................................................................................................................................... 96 

Εικόνα 34: Σο πλήρες αρχείο ‗fare_rules.txt‘ όπως δημιουργήθηκε, σε πινακοποιημένη μορφή. .... 98 

Εικόνα 35: Δείγμα από το αρχείο ‗frequencies.txt‘ όπως δημιουργήθηκε, σε πινακοποιημένη μορφή. 

............................................................................................................................................................. 101 

Εικόνα 36: Απεικόνιση του κέντρου της Αθήνας με OpenStreetMap δεδομένα και Openlayers. .... 108 

X


Εικόνα 37: (Επανάληψη) Ο Γράφος της Εφαρμογής στο Κέντρο της Αθήνας όπως απεικονίζεται στο 

module GUI του OTP. Οι κίτρινες γραμμές αντιστοιχούν σε δρομολόγια των ΜΜΜ, ενώ οι γαλάζιες 

στο οδικό δίκτυο. ................................................................................................................................. 110 

Εικόνα 38: Σο κέντρο της Αθήνας, όπως φαίνεται στον οδικό χάρτη του Google Maps. ................. 119 

Εικόνα 39: ΢τιγμιότυπο από το Adobe Flash Builder κατά την ανάπτυξη της εφαρμογής. ............. 122 

Εικόνα 40: Φαρακτηριστικό στιγμιότυπο από τις επιλογές του χρήστη στο γραφικό περιβάλλον που 

συμπεριλαμβάνει ο OTP. ..................................................................................................................... 125 

Εικόνα 41: Φαρακτηριστικό στιγμιότυπο με στοιχεία καθοδήγησης από το web interface που 

συμπεριλαμβάνει ο OTP. ..................................................................................................................... 126 

Εικόνα 42: To User Interface της εφαρμογής του OpenTripPlanner στην Granada. Η οθόνη επιλογής 

των παραμέτρων διαδρομής. ............................................................................................................. 129 

Εικόνα 43: Οι επιλογές στο τυπικό UI του OTP, από την εφαρμογή στην Grenada. ......................... 129 

Εικόνα 44: Σο tab με την λίστα αποτελεσμάτων για την πρόταση ταξιδίου. ..................................... 130 

Εικόνα 45: Η οθόνη αποτελεσμάτων στο τυπικό UI του OTP, από την εφαρμογή στην Grenada. ... 130 

Εικόνα 46: Ο Γράφος της Εφαρμογής στο Κέντρο της Αθήνας όπως απεικονίζεται στο module GUI 

του OTP. Οι κίτρινες γραμμές αντιστοιχούν σε δρομολόγια των ΜΜΜ, ενώ οι γαλάζιες στο οδικό 

δίκτυο. ................................................................................................................................................. 132 

Εικόνα 47: Η αρχική εικόνα που εμφανίζεται στον Φρήστη κατά την έναρξη της Εφαρμογής. Εκτός 

του τίτλου, περιέχονται μηνύματα σχετικά με σημαντικά θέματα άμεσου ενδιαφέροντος, όπως π.χ. 

μία προγραμματισμένη απεργία. ........................................................................................................ 140 

Εικόνα 48: Η οθόνη για την παραμετροποίηση του Ερωτήματος, όπως αυτή πρωτοεμφανίζεται στον 

Φρήστη. ................................................................................................................................................ 141 

Εικόνα 49: Οπτικοποίηση του δικτύου Metro όταν είναι ενεργοποιημένο το σχετικό Toggle Button 

κάτω δεξιά στον Φάρτη. ...................................................................................................................... 142 

Εικόνα 50: Σα κουμπιά λειτουργιών στην αριστερή κατακόρυφη στήλη της Εφαρμογής. ............... 144 

Εικόνα 51: Σο modal παράθυρο About της Εφαρμογής, με βασικές πληροφορίες σχετικά με αυτήν, 

κι επίσης με links προς διάφορα σχετικά sites. ................................................................................. 145 

XI


Εικόνα 52: To modal παράθυρο Contact της Εφαρμογής, από το οποίο μπορεί να ενεργοποιηθεί ο 

Mail Client του Φρήστη, με προσυμπληρωμένη την διεύθυνση παραλήπτη. ..................................... 146 

Εικόνα 53: Σο κύριο παράθυρο από όπου γίνεται η παραμετροποίηση από τον Φρήστη του 

ερωτήματος. ........................................................................................................................................ 147 

Εικόνα 54: Η λειτουργία Geocoding για την προέλευση. ................................................................... 148 

Εικόνα 55: Με διπλό click σε κάποιο σημείο του Φάρτη εμφανίζεται ένας Marker με ένα Info Window 

για την δηλωσή του σημείου ως προέλευση ή προορισμό. ................................................................. 148 

Εικόνα 56: Επιλογή ενός ΢ημείου Ενδιαφέροντος ως Προέλευση ή Προορισμό, από 

κατηγοριοποιημένη λίστα. ................................................................................................................... 149 

Εικόνα 57: Επιλογή ενός Ενεργού ΢ημείο (΢ταθμός Μετρό) ως προέλευση ή προορισμό. ............... 150 

Εικόνα 58: Σα επιλεγμένα κάθε φορά σημεία προέλευσης και προορισμού επισημαίνονται με 

πράσινο και κόκκινο Marker αντίστοιχα, οι οποίοι είναι draggable. ................................................. 150 

Εικόνα 59: Με σύρσιμο (dragging) του Marker της προέλευσης ή του προορισμού, επιλέγεται μία 

τοποθεσία από τον Φάρτη. Σα αντίστοιχα πεδία ενημερώνονται με τις συντεταγμένες της τοποθεσίας. 

............................................................................................................................................................. 151 

Εικόνα 60: Αντικατάσταση της εμφάνισης των συντεταγμένων μιας τοποθεσίας, έπειτα από σύρσιμο 

του Marker σε αυτήν, από την διεύθυνση που τους αντιστοιχεί. ...................................................... 151 

Εικόνα 61: Σο List Box με τις επιλογές των επιθυμητών Μέσων για την πραγματοποίηση του ταξιδίου. 

............................................................................................................................................................. 152 

Εικόνα 62: Οι επιλογές βελτιστοποίησης που παρέχονται στον Φρήστη. .......................................... 152 

Εικόνα 63: Οι επιλογές για την μέγιστη απόσταση σε μέτρα που επιθυμεί ο Φρήστης να διανύσει πεζή. 

............................................................................................................................................................. 153 

Εικόνα 64: Οι επιλογές για την ημερομηνία και την ώρα αναχώρησης ή άφιξης. ............................ 153 

Εικόνα 65: ΢τιγμιότυπο από την οθόνη αναμονής καθόσο διαρκεί η αναζήτηση και επεξεργασία των 

προτάσεων ταξιδίου. ........................................................................................................................... 154 

Εικόνα 66: Η Client Εφαρμογή σε κατάσταση παρουσίασης και διαχείρισης των Προτάσεων 

Σαξιδίου. .............................................................................................................................................. 155 

XII


Εικόνα 67: Συπική Μορφή της Κατακόρυφης ΢τήλης με τα λεκτικά αποτελέσματα, μέσα από ένα 

τυχαίο παράδειγμα.............................................................................................................................. 156 

Εικόνα 68: Παράδειγμα περιγραφής αρχικού κλάδου διαδρομής πεζή. ........................................... 157 

Εικόνα 69: Παράδειγμα περιγραφής κλάδου με Μέσα Μαζικής Μεταφοράς. ................................. 157 

Εικόνα 70: Η οπτικοποίηση της Πρότασης Σαξιδίου στον Φάρτη. ..................................................... 159 

Εικόνα 71: Η γενική διάταξη που πρωτοβλέπει ο Φρήστης. ............................................................... 195 

Εικόνα 72: Ο χρήστης έχει επιλέξει ένα σημείο εντός του Αερολιμένα ως προέλευση, το οποίο όμως 

δεν αντιστοιχεί στο σημείο αφίξεων, αλλά στο Parking. .................................................................... 204 

Εικόνα 97: Η εισαγωγική οθόνη του Tsoop! που βλέπει ο φανταστικός Φρήστης του Παραδείγματος. 

............................................................................................................................................................. 218 

Εικόνα 98: Η οθόνη για την επιλογή διαφόρων παραμέτρων του ταξιδιού. ..................................... 219 

Εικόνα 99: Η επιλογή του Αερολιμένα ως προέλευση από την λίστα των ΢ημείων Ενδιαφέροντος. 220 

Εικόνα 100: To Geocoding της διεύθυνσης προορισμού. ................................................................. 221 

Εικόνα 101: Επιλογή της ημερομηνίας και της ώρας. ....................................................................... 222 

Εικόνα 102: Επιλογές για τα επιθυμητά μέσα πραγματοποίησης του ταξιδίου, και του τρόπου 

βελτιστοποίησης της αναζήτησης προτάσεων. .................................................................................. 223 

Εικόνα 103: Αναμονή για την αναζήτηση προτάσεων ταξιδίου. ....................................................... 224 

Εικόνα 104: Η οθόνη των Προτάσεων Σαξιδίου όπως πρωτοεμφανίζεται. ....................................... 225 

Εικόνα 105: Η οθόνη των Προτάσεων Σαξιδίου, εμφανίζοντας την δεύτερη Πρόταση. ................... 226 

Εικόνα 106: Zoom στην περιοχή προορισμού και στα στοιχεία της δεύτερης Πρότασης, με 

ενεργοποιημένη την εμφάνιση του Δικτύου metro. ........................................................................... 227 

XIII


XIV


XV


XVI

Michail Tziotis - Postgraduate Diploma Thesis - An Intermodal ...

Create successful ePaper yourself

Delete template?

Save as template?