home    zurück    Inhaltsverzeichnis
erste Version am 16.04.2017
letzte Änderung am 17.04.2017

OpenStreetMap in einem wx.Window - Seite 2


Ostern ist verregnet, die Frau mit Singen oder ihrem Heiland beschäftigt und meine ersten Tests mit wx.MemoryDC() zeigten ein deutlich flüssigeres Scroll-Verhalten.
Daher also jetzt direkt die Version 2.0 hinterher, bei der ich die Planung mal gleich in html erfasse.


Funktionen von OSMscr2.py

Rückgabe
Name
Zweck

Init oder Parameter-Änderung
-
__init__(sizeXY, posLL, zoomLvl, borderTiles) Zusammenfassung der drei folgenden Funktionenen
-
setCenter(posLL) Geo-Koordinate auf Fenster-Mittelpunkt einstellen
-
setSize(newSizeXY)
Fenster-Größenänderung verarbeiten
-
setZoom(zoomLvl, mousePosXY)
Zoom-Level mit Fixpunkt ändern

Service-Funktionen
posLL
getLatLonForPixel(posXY) Liefert zu Pixel-Koordinaten die Geo-Koordinaten
posXY
getPixelForLatLon(posLL)
Liefert zu Geo-Koordinaten die Pixel-Koordinaten
distXY
distanceLatLonToPixel(pos1LL, pos2LL)
Liefert den Pixel-Abstand von zwei Geo-Koordinaten
(pos1LL, pos2LL) getVisibleRectangle()
Liefert die Fenster-Eckpunkte als Geo-Koordinaten
-
getZoomAndCenterForAllPointsVisible(listLL)
Ändert Zoom-Level und Karten-Ausschnitt gemäß einer Liste von Geo-Koordinaten.

Darstellungs-Funktionen
needs_refresh
drawMap() Karte aufbereiten
-
loadTracks(tracks(LL))
Tracks in der Karte aufnehmen [[(lat, lon), (lat, lon), ...], ...]
-
unloadTracks()
Tracks aus der Karte löschen
-
setTrackPen(pen)
den wx.Pen zur Track-Darstellung einstellen
-
loadPoints(list(LL))
Punkte auf Karte zeichnen [((lat, lon), radius, color, text), (), ...]
-
unloadPoints() Points auf der Karte löschen
-
doMoveMap(distXY)
Karten-Ausschnitt verschieben (in Pixeln)
-
endMoveMap()
Aktuelle Kartenverschiebung als neue Basis einstellen
(bmp, distXY) getBitmap()
Karte (ggf. + Track + Points liefern)


Problem:
drawMap() hat noch nicht alle Tiles.
Lösung:
drawMap() liefert needs_refresh=True, Aufrufer prüft via Timer und ruft bei needs_refresh==True self.Refresh() auf.
OSMscr2 macht den Test auf needs_refresh==True jetzt ebenfalls - und zwar in dem Test, ob ein neues Bitmap erstellt werden muss.


Problem:
bei doMoveMap() wird die Bitmap verlassen.
Lösung:
analog zur v1.2 -> es wird eine leere Fläche angezeigt


Idee:
für eine pointList sollte die Klasse zu einer posXY melden können, ob posXY über einem point[n] liegt.
Idee:
Point-Listen sollten vor der Übergabe an den dc.DrawCirclePoint() noch insofern gekürzt werden, dass nur sichtbare Koordinaten berücksichtigt werden.
Bei Tracks wird sowas eher nix bringen, weil die im Stück an dc.DrawLines() übergeben werden. Aber vielleicht sollten zumindest solche Tracks ausgeblendet werden, die komplett außerhalb des Fensters liegen. Das bräuchte pro Track die Bestimmung und Speicherung des konvexen Rechtecks.


Der Tag ist noch nicht um, aber es klappt mit der neuen Version schon alles bestens. Dafür lohnt es fast nicht, direkt auf 2.0 zu springen....
Jedenfalls ist die CPU-Last deutlich runter gegangen, das Scrollen ist nicht mehr ruckelig und die Verarbeitung von Track- und Punkte-Listen ist in OSMscr2 reingewandert.
Weil alles so schön performant ist, habe ich spaßeshalber gleich mal meine Wardriving-DB mit 23.352 AccessPoint-Geo-Koordinaten angeklemmt.
Die Gesamtansicht aller Wardriving-Tracks (~45.300 Geo-Koordinaten) und den 23.352 AccessPoints sieht so aus (Bild anklicken für volle Größe):
Screenshot von wxOSM mit Anzeige
        aller beim Wardriving bisher gefundenen AccessPoints

Das Scrollen im Bild geht verzögerungsfrei, Zoom-Stufen-Änderung oder allgemeiner Bild-Neuaufbau ist unter einer Sekunde.
Beim reinzoomen wird es schneller und übersichtlicher.
Auch bekommt man mittels Mouse-Over die Metadaten eines APs angezeigt (Bild anklicken für volle Größe):
Screenshot wxOSM mit
        Metadaten-Anzeige bei Mouse-Over

Was bisher erst rudimentär funktioniert, ist die Darstellung der AP-Sichtungs-Koordinaten nach Klick auf einen AP.
Nur rudimentär deshalb, weil ich mir noch nicht im Klaren darüber bin, wie die Punkte angezeigt werden sollen.
Derzeit erweitere ich die Liste für loadPoints() einfach um weitere blaue Sichtungs-Punkte. Weil sie in der Gesamt-Liste hinter den roten AP-Punkten kommen, liegen die blauen Punkte über den roten - sind also sichtbar. Eigentlich möchte ich aber noch dünne Linien von dem AP zu jedem seiner Sichtungs-Koordinaten haben. Vielleicht sogar mit Entfernungsangabe. Sowas gehört aber garantiert nicht in OSMscr2 mit rein. Derzeit sieht es nach Klick auf einen roten Punkt etwa so aus (Bild anklicken für volle Größe):
Screenshot wxOSM mit temporär
        nachgeladenen Sichtungs-Punkten
Und da fehlt mir noch die Idee, wie ich das machen kann, ohne diverse Funktionen in OSMscr2 und in OSMwin2 haben zu müssen.
Aber morgen ist ja Ostermontag - also noch mehr Bastel-Zeit. :-)


Version 1.3

So...Mittag...obwohl....ist ja schon 16:00 Uhr durch. Aber dafür sind nun auch beide Scripte umgebaut.
Beim Laden von Punkte-Listen bekommt man von OSMscr2 jetzt ein Handle geliefert, mit dem man diese Punkte-Liste wieder löschen kann - und zwar ohne sich um andere, ebenfalls geladene, Punkte-Listen kümmern zu müssen.
Die Routine zum Zeichnen der Linien von einem AP zu seinen Sichtungs-Koordinaten befindet sich in OSMwin2, alles weitere in OSMscr2.
Sieht dann so aus, nachdem ich den Radius der Markierungspunkte von 5 auf 3 Pixel geändert habe (Bild anklicken für volle Größe):
Screenshot wxOSM mit Linien zwischen
        AP-Standort und allen Sichtungs-Punkten

Damit ist die Version 1.3a von wxOSM erstmal fertig.
Die Nutzung meiner Wardriving-Datenbank erfolgt bedingt. Bei USE_DB=False werden stattdessen nur drei Demo-Koordinaten mit Popup-Text eingetragen, damit das Script auch ohne die DB getestet werden kann.
Weiterhin habe ich noch schnell einen wxOSM-Mini-Demonstrator zusammenkopiert, der mit 109 Zeilen ein wx.Window anzeigt, in dem die scroll- und zoombare OpenStreetMap zur Verfügung steht. Außerdem ein 3-Punkte-Mini-Track und eine aus einem Punkt bestehende Punkt-Liste.

Was mir jetzt noch nicht ganz so gut gefällt, ist das gelegentliche ruckeln bei Nachfahren eines Tracks. Die Linie zwischen zwei Track-Punkten wird mit der Funktion scrollMapToPoint() nachgefahren - und führt zu einem sehr sanftem Scrollen. Wurde der zweite Track-Punkt erreicht, wird eine neue Bitmap angefordert, bei der dieser zweite Punkt im Zentrum liegt. Da die Erzeugung dieser Bitmap jedoch einige Millisekunden benötigt, kommt das sanfte Scrollen aus dem Tritt.
So nach dem Motto: sanft - sanft - sanft - sanft - Ruckler - sanft - sanft - sanft - Ruckler - sanft - .....
Es wäre genug Zeit, diese neue Bitmap vorzubereiten, während scrollMapToPoint() noch läuft. Alle dazu benötigten Daten wäre verfügbar. Allerdings müsste die gesamte Klasse OSMsrc2 asynchron neben dem Hauptprogramm laufen, um parallel zum Hauptprogramm Bitmaps berechnen zu können. Auch müsste OSMscr2 mehr als ein Karten-Bitmap verwalten können.
Damit gehts dann auf der nächsten Seite weiter.