Τεχνικές σημειώσεις για τις διαδρομές και τον χάρτη – O.O’Brien

Τεχνικές σημειώσεις για τις διαδρομές και τον χάρτη – O.O’Brien

Januar 23, 2023 0 Von admin

Διαδρομές

Δημιούργησα αρχεία διαδρομής GPX για την πρόκληση. Αυτά δημιουργήθηκαν με μη αυτόματο τρόπο στο QGIS, χρησιμοποιώντας την τυπική απόδοση OpenStreetMap „Mapnik“ ως φόντο, σχεδιάζοντας γραμμές, με εικόνες Google Street View που χρησιμοποιούνται για τον έλεγχο περιορισμών.

Χώρισα τη διαδρομή κάθε ομάδας σε 12 στάδια (άρα 36 συνολικά), τα οποία αρχικά ήταν λίγο πάνω από 10 χιλιόμετρα το καθένα και κατέληγαν σε ένα σταθμό αποβάθρας. Κάθε στάδιο περιείχε μεταξύ 10 και 40 διαδοχικά σκέλη σε σταθμούς σύνδεσης. Δεν είμαι σίγουρος ότι θα εμπιστευόμουν τις κατάλληλες μηχανές δρομολόγησης (με βάση τους Χάρτες Google ή το OpenStreetMap, κανονικά) ότι θα είχαν βρει καλύτερες διαδρομές σε κάθε σκέλος μεταξύ κάθε βάσης σύνδεσης, από εμένα και το Google Street View, κυρίως επειδή πολλοί δήμοι του Λονδίνου έχουν πειραματιστεί παρτίδα πρόσφατα με γειτονιές χαμηλής κυκλοφορίας (LTN) και φίλτρα τύπου (π.χ. αμφίδρομη για ποδήλατα/μονόδρομος για αυτοκίνητα). Αλλά όντως έτρεξα έναν λύτη TSP (RouteXL) σε 3 από τα στάδια και σε 2 περιπτώσεις βρήκε μια ελαφρώς μικρότερη διάταξη των ποδιών, εντός της σκηνής. Επομένως, θα χρησιμοποιούσα πιθανώς έναν λύτη TSP περισσότερο για μια μελλοντική επανάληψη της πρόκλησης.

Τα τρία αρχεία διαδρομής/ομάδας αποθηκεύτηκαν στο British National Grid (EPSG27700) GeoJSON (τεχνικά δεν επιτρέπεται από τις προδιαγραφές) ώστε να μπορώ να ενημερώνω αυτόματα τις κατάλληλες αποστάσεις μετρητών ($length) σε μια στήλη, για κάθε στάδιο, κατά τον προγραμματισμό. Τα στάδια είχαν στήλη αριθμών και αριθμήθηκαν διαδοχικά. Η ύπαρξη στήλης αριθμών έχει ως αποτέλεσμα LineStrings στις διαδρομές/σημεία διαδρομής GeoJSON και GPX και όχι μεμονωμένα ίχνη/σημεία διαδρομής MultiLineStrings και GPX. Στη συνέχεια σώθηκαν ως Αρχεία WGS84 GPX. Χρησιμοποίησα (κατά λάθος) ένα πολύ περιορισμένο σύνολο ονομάτων στηλών (όνομα, αριθμός, src, desc, cmt), λόγω των περιορισμών με την προδιαγραφή GPX – δεν ήθελα να χρησιμοποιήσω επεκτάσεις GPX.

Ήταν σημαντικό να υπάρχουν τρία ξεχωριστά αρχεία GPX, έτσι ώστε κάθε ομάδα να χρειάζεται να φορτώνει μόνο ένα αρχείο στη συσκευή πλοήγησής της και να μην βλέπει σταθμούς σύνδεσης/διαδρομές από άλλες ομάδες). Αλλά έκανε τις προετοιμασίες λίγο πιο δύσκολες για τον διαδικτυακό χάρτη.

Οι σταθμοί σύνδεσης εισήχθησαν μέσω αρχείου TSV, στη συνέχεια αποθηκεύτηκαν ως σημεία διαδρομής GPX (τα ονόματα στηλών περιορίζονται και πάλι σε src, desc, name και cmt) και τα σχετικά προστέθηκαν μη αυτόματα στα αρχεία της ομάδας GPX. Τα GeoJSON διατηρήθηκαν ως κύρια αρχεία επεξεργασίας μου, καθώς το QGIS δεν μπορεί να επεξεργαστεί εύκολα αρχεία GPX επειδή περιέχουν πολλούς τύπους γεωμετρίας.

Σίγουρα θα ήθελα να δοκιμάσω μια πιο αυτοματοποιημένη προσέγγιση στη δρομολόγηση. Χρειάστηκε όντως πολύς χρόνος – πιθανώς δύο βράδια για καθεμία από τις τρεις διαδρομές και ένα ακόμη απόγευμα για κάθε διαδρομή για να απαριθμήσετε τους σταθμούς σύνδεσης, να ρυθμίσετε με ακρίβεια τις διαδρομές και να αναδιατάξετε τυχόν τμήματα GeoJSON LineString (μερικά στάδια) πίσω στη σωστή σειρά. Η αναδιάταξη χρειαζόταν, καθώς το QGIS θα αναδιάταξη λανθασμένα τμημάτων της διαδρομής που διέσχιζε τον εαυτό της, όταν κόπηκε σε φέτες.

Αλλά μια αυτοματοποιημένη προσέγγιση θα απαιτούσε μια μέθοδο που ασχολείται με σταθμούς σύνδεσης που βρίσκονται μόλις 10 μέτρα κάτω από έναν δρόμο απαγορευμένης εισόδου (οπότε απλά θα τον περπατούσατε), κάτι που είναι δύσκολο. Επί του παρόντος, αντιπροσωπεύονται ως ένα σημείο που ορίζεται από το TfL μέσω του API τους (και χωριστά στο OpenStreetMap), το οποίο μπορεί να είναι η θέση του περιπτέρου „τοτέμ pole“ αλλά όχι τα ίδια τα σημεία σύνδεσης. Στα συστήματα δρομολόγησης ή GIS, ο σταθμός σύνδεσης πρέπει να αντιπροσωπεύεται ως μια περιοχή (μέσα στην οποία θα περπατούσατε τα ποδήλατα) συν μια (πολλαπλή) γραμμή (που αντιπροσωπεύει τη γραμμή των σημείων αποβάθρας – μερικά από αυτά είναι αρκετά μεγάλα – ορισμένα έχουν σημαντικές κενά, και μερικές φορές χωρίζονται σε κάθε πλευρά ενός δρόμου). Δυνητικά, το σημείο που αντιπροσωπεύει έναν σταθμό σύνδεσης πρέπει πραγματικά να είναι μια περιοχή και αυτή η περιοχή μπορεί να εκτείνεται μέχρι τον κοντινό οδικό κόμβο για να αντιμετωπίσει το μονόδρομο ζήτημα.

Μελλοντικές Βελτιώσεις

Όσον αφορά τον γενικό σχεδιασμό, μερικά πράγματα θα μπορούσαν να αλλάξουν για μια μελλοντική πρόκληση (μερικά από αυτά τα ανέφερα στην προηγούμενη ανάρτησή μου στο blog):

  • Εξασφάλιση ότι οι συμμετέχοντες απέχουν πολύ από τον τερματισμό στο στάδιο περίπου 60-80%, έτσι ώστε να είναι λιγότερο πιθανό να αποδεσμευτούν εκείνη τη δύσκολη στιγμή της ημέρας, επειδή το υπόλοιπο της πρόκλησης είναι τότε ένα είδος «τρέξιμο» για να τον τερματισμό, αντί να τους δρομολογήσετε σε μεταγενέστερο στάδιο.
  • Όταν οι συμμετέχοντες περάσουν από έναν άλλο σταθμό σύνδεσης δύο φορές, θα πρέπει να τον επισκεφτούν την πρώτη φορά, όχι τη δεύτερη. (Εξαίρεση είναι όταν βρίσκεται στη λάθος πλευρά ενός διπλού οδοστρώματος, ιδιαίτερα ενός με μεσαίο φράγμα). Διαφορετικά υπάρχει κίνδυνος να χαθεί κατά την επιστροφή.
  • Δημιουργήστε συγκεκριμένες στάσεις για γεύματα.
  • Μέγιστος αριθμός 200 θέσεων σύνδεσης/10 ώρες ανά ομάδα.

Ο Χάρτης Ιστού

Συγκριτικά, η κατασκευή του χάρτη ιστού ήταν απλή, πιθανότατα ήταν μια δουλειά μόνο ένα απόγευμα για τη δημιουργία της ίδιας της σελίδας του χάρτη ως βασικής ανάγνωσης χάρτη OpenLayers σε αρχεία GPX και με απλό γεωγραφικό εντοπισμό βάσει προγράμματος περιήγησης, και ένα ακόμη απόγευμα για τη δημιουργία μιας έκδοσης „ομάδας“ ο χάρτης που επέτρεπε την αποσύνδεση των σταθμών, την αποθήκευση της ενέργειας σε μια βάση δεδομένων και μια συμβολοσειρά χρόνου που αντηχούσε πίσω στον χάρτη ιστού (και σε άλλους θεατές, σε ένα χρονόμετρο Javascript) ως επιβεβαίωση. Η βάση δεδομένων είχε δύο πίνακες, έναν συνοπτικό πίνακα με μια σειρά ανά σταθμό σύνδεσης και ένα αρχείο καταγραφής ενεργειών που κατέγραφε το αναγνωριστικό TfL, τη χρονική σήμανση, τον τύπο συμβάντος και τη συμβολοσειρά παράγοντα χρήστη του προγράμματος περιήγησης του υποβάλλοντος ($_SERVER[‘HTTP_USER_AGENT’]) αντί για logins/ID. Ήταν αρκετά εύκολο να εκχωρήσετε μια μη αυτόματη ανάθεση σε κάθε παράγοντα χρήστη στην ομάδα, μετά την εκδήλωση.

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

  • ένα ακέραιο TfL ID (π.χ. 761)
  • το όνομα TfL που εμφανίζεται στον πόλο τοτέμ (π.χ. Gower Place, Bloomsbury)
  • έναν σύντομο κωδικό που ήταν ο αριθμός σειράς και τα αρχικά του πρώτου μέρους του ονόματος TfL (π.χ. 37.GP). Υπήρχαν μερικά αντίγραφα σε όλη την ομάδα. Το FIN.HS ήταν ένας ειδικός σύντομος κωδικός για τον τερματισμό για τις δύο ομάδες που δεν το είχαν ως βάση στη «ζώνη» τους. Σε έναν σταθμό σύνδεσης που προστέθηκε πρόσφατα είχε προστεθεί το „A“ στον αριθμό σειράς του προηγούμενου, αντί να χρειάζεται να επαναριθμήσετε τα πάντα.
  • ένας μοναδικός κωδικός ακολουθίας που ήταν η σειρά της ομάδας, του σταδίου και του σταθμού σύνδεσης σε αυτό το στάδιο, (π.χ. W02.15). Αυτό χρησιμοποιήθηκε ως λογική διάταξη του αρχείου και για να βοηθήσει στην αντιστοίχιση κάθε σταθμού σύνδεσης στη σκηνή του στον διαδικτυακό χάρτη.

Παρέθεσα επίσης μια σειρά „πραγματικής ακολουθίας“ μετά το συμβάν, π.χ. W038, στο αρχείο τελικών αποτελεσμάτων.

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

Δημιούργησα μια ειδική ιστοσελίδα «διαφορών» που συγκρίνει το αρχείο docks μας με τα ζωντανά δεδομένα (μέσω BikeShareMap) κάθε 2 λεπτά και αυτό μας ειδοποίησε για τυχόν νέους, κλειστούς ή μηδενικής χωρητικότητας σταθμούς σύνδεσης, συν μια λίστα με πλήρεις. Υπήρχε ένα που άνοιξε λίγες μέρες πριν, αλλά καμία την ημέρα, ευτυχώς!

Μελλοντικές Βελτιώσεις

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

Είχαμε χάρτες σε χαρτί (μόνο στιγμιότυπα οθόνης του ιστότοπου) ως αντίγραφο ασφαλείας. Δεν τα χρησιμοποίησα ποτέ και νομίζω ότι η Team South χρησιμοποίησε τον ιστότοπο. Η Team West τα χρησιμοποίησε αποκλειστικά, με ένα ξεχωριστό άτομο να χρησιμοποιεί τον ιστότοπο για να επισημάνει.

Θα ήθελα να είχα μια μοναδική πηγή τοποθεσιών σταθμών σύνδεσης. Τελικά ήταν:

  1. στο API του TfL, το οποίο τροφοδοτείται σε ένα CSV στο BikeShareMap κάθε δύο λεπτά,
  2. σε ένα αρχείο CSV στο Github,
  3. ως σημεία GPX που προσαρτώνται στο αρχείο διαδρομών GPX κάθε ομάδας και
  4. στη βάση δεδομένων μου για χρόνους εγγραφής στον ιστότοπο του ATDMap.

Τα 1 και 2 συγκρίθηκαν αυτόματα (δείτε παραπάνω), το 2 θα μπορούσε να προστεθεί στο QGIS για σύγκριση και δημιουργία GPX για 3, και επίσης να εισαχθεί στον πίνακα της βάσης δεδομένων (4), αλλά όλα αυτά θα ήταν χειροκίνητα βήματα.

Συνδέσεις

Χάρτης ιστότοπου με τους χρόνους: https://misc.oomap.co.uk/atdmap/

Διαδρομή αρχείων GPX και χρονισμών CSV: https://github.com/oobrien/allthedocks

Σύνδεσμος Strava (Ομάδα Ανατολή): https://www.strava.com/activities/7908548122