home zurück Inhaltsverzeichnis

erste Version am 22.04.2017
letzte Änderung am 13.01.2022

OpenStreetMap in einem wx.Window - Seite 4

Ganz so wichtig ist die asynchrone Map-Berechnung eigentlich gar nicht.
Praktisch macht es nämlich wenig Sinn, einen Tack in einer Zoom-Stufe >15 nachzufahren.
Und bei <=15 braucht es den scrollMapToPoint() nicht, wenn in den Tracks alle 5 Sekunden ein Punkt gesetzt wurde (wie es mein RasPi-Tracker ja tut).

Erweiterungen bzw. Erweiterungsideen

Entfernung bei den AP-Sichtungspunkten zum berechneten AP-Standort mit anzeigen.	fertig
Die AP-Sichtungspunkte mit der geringsten Dämpfung in anderer Farbe (und über den anderen) darstellen.	fertig
Kontext-Menü einbauen, um z.B. die Anzeige der AP-Koordinaten ein- oder auszuschalten.	fertig
Alle aktuell angezeigten Tiles neu vom Server laden (als Funktion aus dem Kontext-Menü).	fertig
Positions-Infos von nominatim.openstreetmap.org nachladen und anzeigen.	fertig
Pausen-Punkte von einem Track erkennen und mittels Points markieren. Samt Datum und Dauer.	fertig
Track-Parameter anzeigbar (Datum, Dauer, gefahrene Kilometer, Durchschnittsgeschwindigkeit, ...)
Bei letzter (oder n'ter) Wardriving-Tour neu gesehene APs farblich (oder durch Größe) hervorheben.
Schnelldurchlauf durch einen Track (ggf. mittels Slider-Control).	fertig
Beliebig viele GPX-Dateien per drag&drop laden. Dazu dann ein Popup-Fenster zum ein- und ausschalten einzelner Tracks (Code-Vorlage in LoggerView/KurvenSettings).	fertig
Zwangs-Caching der Tiles abschaltbar durch SOURCE/"cache_dir"=None - z.B. für lokalen Tile-Server.	fertig
AP's mit crypto=="None" hervorheben (größer und anders-farbig).	fertig

Heute habe ich wenig am Programm verändert.
Stattdessen habe ich einen Spaziergang durch einen Teil unseres Dorfes, das in OSM bisher noch komplett ohne Hausnummer erschien, gemacht und dabei einen ganzen Schwung Hausnummern erfasst. Die Dateneingabe per JOSM ging sehr viel einfacher, als ich erwartet hatte. Vorab musste ich mir nur kurz einen OSM-Account klicken und schon konnte es losgehen. Die ersten geänderten Tiles waren bereits wenige Minuten nach Upload unter openstreetmap.org sichtbar.

Version 1.3d

Mittlerweile bin ich bei Version 1.3d angekommen.
Keine großen Änderungen, aber zumindest befinden sich jetzt ein paar mehr der obigen Erweiterungsideen im Status fertig.
Für die v1.4 plane ich, die Track- und Punkte-Listen nicht mehr bei jedem drawMap() neu in die Ausgabe-Bitmap zu zeichnen.
Oder eigentlich schon - aber es wird dann einen zweiten Modus geben:
Wird eine Track- oder Punkte-Liste im [neuen] Permanent-Modus an OSMscr2 übergeben, ist vorgesehen, diese Daten direkt auf die Tiles zu zeichnen. Die so aufbereiteten Tiles werden dann solange im RAM gehalten, bis eine definierbare Tile-Anzahl überschritten wird. Dieser Cache wäre als Dictionary zu implementieren. Key wäre (x, y, z) vom Tile, Value wäre dessen erweiterte Bitmap.
Damit sollte die CPU-Last im Auto-Follow-Modus nochmal weiter runter gehen bzw. sich die Map-Neuaufbau-Geschwindigkeit erhöhen lassen.
Weiterhin werde ich mal messen, ob sich die Nutzung von numpy (das ja schon bei der wieder verworfenen Version 2.0 zum Einsatz kam) so positiv auf die Verarbeitungsgeschwindigkeit auswirkt, dass sich dafür eine zusätzliche Library-Abhängigkeit rechtfertigen ließe. Vielleicht könnte sogar dynamisch auf numpy-Nutzung umgeschaltet werden, wenn der import numpy keine Exception wirft.

Eben habe ich ein paar Messungen zur CPU-Belastung durch den __drawPointsDC() durchgeführt.
Der __drawTracksDC() war dabei auskommentiert und es wurde ein Track im Zoom-Level 13 bei Slider-Geschwindigkeit 9 nachgefahren.
Dann habe ich mir die Änderung der CPU-Last bzw. konkret des idle-Wertes laut top angesehen, wenn der Wardriving-Mode ein- oder ausgeschaltet wurde. Ein temporär eingebauter Punkte-Zähler hat dabei gemeldet, dass pro Bitmap zwischen 20.000 und 21.000 Punkte auf die Bitmap gezeichnet wurden.
Ohne Punkte lag der idle-Wert konstant zwischen 82% bis 83%.
Mussten jeweils zusätzlich 20.000 Punkte gezeichnet werden, lag er hingegen konstant zwischen 77% bis 80%.
75% wäre Volllast auf einem CPU-Kern. Im Leerlauf bzw. bei Grundlast wird 99% gemeldet.
Bei etwa 5% Last-Unterschied aufs Gesamtsystem bezogen ergäbe das immerhin 20% Unterschied für einen CPU-Kern.
Anderseits ist die Anzeige von 20.000 Punkten praktisch vollkommen wertlos. Der Wardriving-Mode macht erst bei einem Zoom-Level >=16 Sinn. Und da komme ich selbst im Gebiet mit den meisten AP-Sichtungen auf maximal 2400 darzustellende Punkte pro Bitmap.
So gesehen würde der für die Version 1.4 angedachte Umbau keine sonderlich praxisrelevante Verbesserung bedeuten....das Script jedoch deutlich komplexer werden lassen.

Version 1.4c

Nun ist mehr als ein Monat seit dem letzten Update vergangen - aber dafür habe ich jetzt eine völlig überarbeitete Version. Und sie ist -wie erwartet- etwas komplexer geworden (1.115 Zeilen in OSMscr3 gegenüber 539 Zeilen in OSMscr2).
Jedoch: deutlich schneller, weniger CPU-Last und ganz sanftes Scrollen beim Autofollow eines Tracks.
Wie bereits bei der v1.3d angedacht, werden Tracks und Points jetzt direkt auf die einzelnen Tiles gezeichnet. Außerdem kommt OSMscr3 nun komplett ohne wxPython aus. Stattdessen werden die ImageDraw-Funktionen von Pillow genutzt. Damit stellt es kein Problem mehr dar, ein Folge-Bitmap asynchron vorzuberechnen, während das andere Bitmap in einem wx.PaintDC() angezeigt und erweitert wird. Pillow sollte allerdings mindestens in der Versionsnummer 2.9.x installiert sein.
Ein gewisser Nachteil an OSMscr3 ist vielleicht, dass es deutlich mehr RAM-Speicher in Beschlag nimmt - weil jedes Tile im Speicher gehalten wird, sobald Track-Abschnitte oder Points darauf gezeichnet wurden.

Anbei die Version 1.4c.
(Erfolgreich getestet mit python-wxWidgets-2.8.12.1-10.4.1.x86_64 und python-wxWidgets-3_0-3.0.2.0-3.3.x86_64)

Nachtrag 2022: Sollte Pillow in einer neueren Version installiert sein (z.B. python2-Pillow-5.0.0-3.3.1.x86_64) gibts einen NotImplementedError in OSMscr3.py.
In diesem Fall ist in Zeile 314 das img.tostring() zu ersetzen durch img.tobytes().
Ich bin zwar bereits bei der Version 1.6 von wxOSM angekommen, jedoch ist diese bereits zu sehr auf meine Bedürfnisse und Infrastruktur angepasst - sodass es m.E. keinen Sinn macht, diese Version hier zu veröffentlichen.