Suche Programm mit offline Karten zur Ansicht von POI

[1234xy]

Hallo zusammen,
ich habe gpx und kml Dateien in denen sehr viele (50.000) POI (Point of Interest) gespeichert sind. Jetzt suche ich ein Programm mit offline Karten, was mir die Wegpunkte anzeigt. Ich brauche nicht zwingend eine Routing Funktion. Mir geht es hauptsächlich darum auf einer offline Karte zu sehen, wo sich die POI befinden.
Ich habe das in der Vergangenheit mit QMapshack gelöst, das braucht aber mehrere Minuten um die POI zu laden und den Rest des Programms brauche ich nicht.

Grüße

[MSfree]

ich habe gpx und kml Dateien in denen sehr viele (50.000) POI (Point of Interest) gespeichert sind.
...
Ich habe das in der Vergangenheit mit QMapshack gelöst, das braucht aber mehrere Minuten um die POI zu laden

An der Ladezeit wirst du kaum etwas drehen können. Pi mal Daumen kann man von einer Festplatte ca. 10 Dateien pro Sekunde öffnen und lesen. Von einer SSD geht es 10-100 mal schneller, was bei 50000 Dateien immer noch 1-9 Minuten Ladezeit bedeutet.

Es geht halt sehr viel schneller, wenn man 50000 POI von einer einzigen Datei lädt, als 50000 Dateien mit jeweils einem POI.

[1234xy]

Da hast du natürlich recht, je nach Hardware dauert es eben. Ich habe 3 gpx Datei die ca. 15 MB groß sind. Wo bei ich nicht denke, das die 15 MB das Problem sind sondern die große Anzahl an Wegpunkten. Ich habe heute noch mal etwas gegoogelt und habe gelesen das es vielleicht besser ist die POI in der Datenbank von QMapshack zu importieren.
Trotzdem, vielleicht kennt jemand noch ein anderes Programm.
Danke und Grüße.

[kiozen]

Das einzige was mir da einfällt ist GPXSee. Das kann auch Offline Karten. Ob's besser ist? Keine Ahnung. War mir bisher zu viel Fehlermeldung beim Installieren

15MB XML Dateien einlesen und auswerten dauert, wenn man keinen flotten Rechner hat. Ich würde hier auch keine allzu großen Erwartungen an die Datenbank stellen.

Vielleicht auch mal die Strategie überdenken, warum man solche großen Dateien hat. Braucht man die komplette Information aus den Dateien immer? Oder ist das eher ein Jäger und Sammlerproblem? (He who dies with the most wins.) Kann man die Dateien in kleinere Teilgebiete unterteilen? Oder thematisch?

[MSfree]

15MB XML Dateien einlesen und auswerten dauert, wenn man keinen flotten Rechner hat.

Das reine Einlesen der Datei dauert weniger als eine Sekunde. 15MB sind rund 150.000-300.000 Punkte. Die geographischen Koordinaten (Länge, Breite) müssen zwar in das Pixelsystem des Bildschirms transformiert werden, was einigermassen rechenaufwändig ist, aber das sollte selbst auf einem Raspberry Pi maximal 5 Sekunden dauern.

Der größte Zeitfresser sind in der Regel die GUI-Elemente. Jedem Punkt wird ein Symbol zugewiesen und diverse Attribute (Farbe, Beschriftung...) angehängt, was Zeit und Speicher kostet. Das übersteigt die reine Rechenzeit für die Koordinatentransformation um ein vielfaches.

[kiozen]

Das reine Einlesen der Datei in einen XML Parser geht schnell. Sich den DOM Tree entlanghangeln, die Information von Text in Datentypen umwandeln ist aufwändig. Rendern der Information geht wieder recht flott.

Ein Beisiel aus Jos Hüttenliste mit ca 19k Einträgen und einem recht flotten Rechner:

XML in den Parser einlesen: ca 270ms
Anlegen der internen Datenstrukturen: ca 5000ms

Kann auf schwächeren Rechnern deutlich länger dauern.

Nur wer braucht solche Sammlungen? Immer und bei jedem laden. Man kann auch einfach über rechte Maus auf der Karte->"Elemente auf der Karte auswählen" -> linke Maus drücken und Bereich auswählen. Die Auswahl kann über die Ecken angepasst werden. Wenn es passt, die Auswahl in eine neue Datei kopieren (Tool Button links oben mit den 2 blauen Rechtecken). Jetzt hat man schon eine deutlich reduzierte Auswahl, die sicherlich für die Ziele der nächsten Tage reicht.

[MSfree]

XML in den Parser einlesen: ca 270ms
Anlegen der internen Datenstrukturen: ca 5000ms

Eigentlich sollte das Entlanghangeln am DOM-Tree auch recht flott gehen. Das Anlegen der Datenstrukturen mit den Daten aus dem DOM-Tree ist das, was ich oben mit den GUI-Elementen meinte.

Aber das widerspricht deiner Aussage ja nicht. Da ist programmintern sicherlich noch eine Menge Potential für Optimierungen.

[uname]

Alternativer Ansatz - bei deiner Datenmenge wahrscheinlich nicht zielführend:

Falls du lokal einen Webserver installieren kannst, kannst du OpenLayers, Leaflet oder GPX Viewer mit Leaflet jeweils mit Offline - OpenStreetMap - Tiles und JavaScript-Einbindung deiner GPX-POI-Dateien verwenden. Ob das performant ist, weiß ich nicht. OpenLayers oder Leaflet mit OSM-Offline-Tiles zu verwenden ist auch nicht ganz trivial.

Leaflet bzw. GPX Viewer mit Leaflet kannst du mal testweise hier mit einen Auszug deiner GPX-Datei verwenden. Die GPX-Datei wird per JavaScript lokal verwendet. Die Software sowie die OpenStreetMap - Tiles stammen jedoch von Internetservern. Würde aber lokal ähnlich aussehen. Aber ich denke da ist JavaScript wohl nicht performant genug. Ich verwende das maximal mit einigen Hundert Wegpunkten bzw. mit einigen Tracks gleichzeitig

Was hast du denn für POI? Was ist dein Ziel? Vielleicht kann es auch etwas anders gelöst werden.

[kiozen]

Da ist programmintern sicherlich noch eine Menge Potential für Optimierungen.

Der Allgemeinplatz gilt natürlich immer. Ich würde aber keine Wunder erwarten. Der Wunsch große Sammlungen zu laden ist ja nicht neu. Über den Code wurde schon mehrmals gegangen, mit Hinblick auf Optimierung. Will man allen Features gerecht werden, nicht die Bibliothek wechseln und den Code wartbar und verständlich halten, dann schrumpfen die Möglichkeiten. Aber es darf mich natürlich jeder mit einem Pull Request eines Besseren belehren

[MSfree]

Ich würde aber keine Wunder erwarten.

Das sage ich unseren Kunden auch immer

Mir ist auch klar, wenn es um Rechenprozeße geht, daß man da nicht viel rausholen kann. Wenn etwas 20 Multiplikationen benötigt, dann ist das so, das ist nicht reduzierbar, sondern bestenfalls parallelisierbar, so daß man Gebrauch von seiner Mehrkern-CPU machen kann.

Viele Dinge sind aber ganz anders limitiert, z.B. das Einlesen von Daten, bei dem die gelesenen Daten auf wachsende Datenstrukturen kopiert werden müssen. Zwischen einer ungeschickten Implementierung und einer besseren Lösung können locker Faktor 100 im Zeitverhalten liegen. Das Einlesen eines Datensatzes kann dann quälende 3 Minuten oder erträgliche 2 Sekunden dauern.

Ich kann, ohne den Code gesehen und nachvollzogen zu haben, natülich nicht urteilen, ob da ein ungeschickter oder ein schneller Ansatz gewählt wurde. Viele Softwareprojekte sind aber mal entstanden mit ein paar zig bis hundert Datensätzen im Hintergrund. Entsprechend einfache Verarbeitungsansätze skalieren aber nicht linear in den zig-Tausenderbereich und werden dann grottenlah.