Geschwindigkeit des Imports

[dfx]

nicht jeder verwendet GSAK, oder kann es ueberhaupt verwenden (linux/mac).

nicht jeder laesst immer die gleichen PQs zu immer der gleichen zeit laufen.

ich koennt mir natuerlich einen satz scripte schreiben, die die cache-db von GSAK simulieren und entsprechende files fuer den import auswerfen. an sich ne gute idee, aber 1) viel arbeit und 2) ist das alles nur ein workaround fuer das eigentliche grundlegende problem

 

[dfx]

so hab jetzt mal mitgestoppt, bei deaktiviertem WLAN (fuer alle faelle):

eine PQ mit 485 caches importieren nach frisch geloeschter DB und frisch rebootetem PDA:

cachebox: 4 mins 30 sek.

beelineGPS: 40 sek.

das kann doch nicht sein

 

[GeoSilverio]

Jo, langsam ists schon, da hast du recht und schneller wäre immer schön. Ist aber derzeit so... Vielleicht entdecken hannes und/oder tower noch eine Möglichkeit, das "anzudüsen".

Allerdings kommt es ja auch immer drauf an, WIE die Daten importiert werden. Also in welche Struktur sie importiert werden.
Cachebox legt seine Daten in einer Datenbank ab. Der Vorteil darin ist, dass die Datenmenge keine besondere Rolle spielt im Programmbetrieb. Ob man nun 500 Caches oder 5000 Caches drin hat hat ist fast egal.

Versuch mal, ein GPX-File mit 2500 Caches in BeeLineGPS zu importieren. Bei mir gibts dann einen "out of memory"-Fehler und das Ding stürzt ab...

Wie gesagt: schneller darfs immer gerne werden. Allerdings sind für mich andere Dinge wichtiger, die den langsamen Import mehr als aufwiegen.

 

[Joe_M]

mag es aus deiner perspektive vielleicht sein, aus meiner aber nicht. ich halt meine cachedaten eben gern aktuell, mit beelineGPS kann ich das, mit cachebox leider nicht. ob das sinnvoll ist oder nicht lass bitte meine entscheidung bleiben.

Aber gern. Wie gesagt war nur meine Perspektive

Dein Name bei Grundsprech wär vielleicht auch interessant (Du bist nicht der dfx aus Ontario, oder?).

doch, genau der.

Das erklärt natürlich die Cachedichte Ich komme in Ostthüringen mit einer PQ schon auf einen Radius von knapp 30km. Um deutsche Großstädte sieht das sicherlich auch anders aus. Die eine PQ aktualisiere ich dann alle 2-3 Wochen oder wenn's eine neue Dose gibt, die ich machen will. Wenn's mal über's Wochenende fort geht, kommt noch eine PQ dazu.
Fertig. Völlig stressfrei.
Aber wie gesagt, jeder gern so wie er will.

das gleiche problem hab ich mit ner anderen software gehabt (weiss den namen nicht mehr), die ebenfalls in .net geschrieben war und compact SQL verwendet hat. vielleicht geht's damit ja einfach nicht schneller?

cachebox: 4 mins 30 sek.

beelineGPS: 40 sek.

Dafür ist's kostenlos. BeelineGPS kostet nach 30 Tagen $29,95.

Grüße,
Joe

 

[Dahla]

Wie löst man es mit cachebox eigentlich am besten, wenn man schnell ein paar Caches nachladen möchte?

Wenn ich spontan einen Ausflug außerhalb meines regulär in Cachebox vorgehaltenen Radius mache, möchte ich gerne innerhalb weniger Minuten eine PQ mit vielleicht 5-10 Caches dazuladen; möglichst inklusive Description images und maps. Wenn ich das versuche, geht Cachebox alle ca. 1000 in der Datenbank liegenden Caches wieder durch um die Description images zu laden, bei denen der Ladevorgang bisher nicht geklappt hat. Und da es nunmal so einige Caches bei mir gibt, die zwischen 10 und 20 Bilder haben, die aufgrund nicht mehr vorhandener Server nicht geladen werden können, dauert das ganz schön, bis er die wieder alle durch hat. Gestern habe ich dann notgedrungen auf die description images verzichtet, aber kann man dem Programm nicht auch irgendwie mitteilen, dass er die Images / Maps / GCVotes nur von den neu hinzukommenden Caches laden soll?

Viele Grüße,
Dahla

 

[GeoSilverio]

Ja, das mit dem "Nachimportieren" ist noch so eine Sache...
Die Caches aus einer neuen GPX werden ja schön upgedatet bzw. hinzugefügt. Je nachdem ob der Cache schon da war oder nicht.
Bie den GcVotes verstehe ich noch, dass alle neu geladen werden, da sich die Wertung ja im Laufer der Zeit bei allen Caches ändert (ändern könnte).

Bei den Bilder weiß ich auch nicht, wie man das machen sollte.
Vielleicht einen Schalter in den Settings hinterlegen, mit dem man wählen kann:
- alle images überprüfen oder
- images nur für caches ohne images laden

Wobei dann beim image-Import auch wieder irgendwo in der DB vermekrt werden müsste, bei welchen Caches alle Bilder schon vorliegen bzw. wenigstens versucht wurde, diese zu laden...

 

[Dahla]

Gut, die GCvotes hatte ich der Vollständigheit halber mit aufgezählt, sind aber völlig unproblematisch, da zum einen das Importieren ja auch bei 1000 Caches noch sehr schnell vonstatten geht. Zum anderen sind sie zwar ein nettes Feature, aber zumindest für mich nicht essentiell (kann ich bei einer spontanen Tour also auch gut drauf verzichten, wenn es extra schnell gehen soll).
Bei den Images siehts da schon anders aus. Meistens sind sie zwar auch nicht wichtig, manchmal enthalten sie aber eben doch wichtige Infos.

Die von mir bevorzugte Auswahl wäre eher:
- Images für alle Caches aktualisieren
- Images für neue Caches laden

Aber vermutlich enthält die Datenbank die Info gar nicht, welche Caches wann importiert wurden?

 

[Joe_M]

Aber vermutlich enthält die Datenbank die Info gar nicht, welche Caches wann importiert wurden?

Falls nicht, müsste man die Importfunktionen erweitern.
Es werden ja vermutlich erst alle GPX Dateien importiert, dann alle GC-Votes, dann alle Bilder und dann alle Karten? Das ist auch sinnvoll, wenn man die ganze Datenbank durchackert.
Aber falls es zu einer Auswahl
"Ganze DB aktualisieren" oder
"Daten nur für GPX Datei aktualisieren"
kommt und der Zeitpunkt der Aktualisierung nicht gespeichert wird, sollte man den Import von Bildern/GCVotes/Karten cacheweise während der Verarbeitung der neuen GPX vornehmen. Das bedeutet natürlich wieder mehr Aufwand für's Entwicklerteam. Wo wären wir nur ohne Euch ...

Grüße,
Joe

 

[bender2004]

Ich habe etwas mit dem Greasemonkey-Script "GCTour" gespielt. Dort kann man sich z.B. eine Tour mit den 4-5 neuen Caches, die man gerade suchen will, erstellen und die gpx-Datei downloaden. Dann ganz normal in CB importieren und schon hat man die DB aktuell.
Mich stört die Import-Zeit weniger. Wenn ich zum Cachen gehe, lade ich die PQ sowieso schon vorher und lass Cachebox die Arbeit machen. Wenn ich dann einige Stunden "draußen" bin, machen die paar Minuten für den Import vorher auch nichts aus.

 

[tower27]

In der nächsten Version wird man im Cachebox nach den GPX-Dateinamen filtern können.
Dann kann man sich z.b. nur die Caches einer GC-tour anzeigen lassen oder die eines entfernten Gebietes problemlos wieder löschen.

Der einzige Nachteil ist, dass natürlich immer der letzte GPX-Dateiname "gewinnt". Wenn sich also PocketQueries überlappen, dann tragen die Caches der Schnittmenge die Dateikennung der letzten Datei.

 

[Dahla]

@bender2004: Danke für die Info, aber das angesprochene Problem war nicht, die GPX-Datei zu bekommen, sondern sie in Cachebox mit Images und Maps in kurzer Zeit einzulesen.

@tower27: Zum "aufräumen" ist das schon mal ganz nützlich. Aber kann man dann denn auch nur für die gefilterte GPX-Datei Images und Maps runterladen? Ansonsten versteh ich grad nicht, was das für das angesprochene Problem bringen könnte? Oder bezieht sich dein Beitrag nicht auf die letzten Beiträge?

 

[dfx]

Allerdings kommt es ja auch immer drauf an, WIE die Daten importiert werden. Also in welche Struktur sie importiert werden.
Cachebox legt seine Daten in einer Datenbank ab. Der Vorteil darin ist, dass die Datenmenge keine besondere Rolle spielt im Programmbetrieb. Ob man nun 500 Caches oder 5000 Caches drin hat hat ist fast egal.

Versuch mal, ein GPX-File mit 2500 Caches in BeeLineGPS zu importieren. Bei mir gibts dann einen "out of memory"-Fehler und das Ding stürzt ab...

ja und nein. ich hab mit beelineGPS schon mal ein einzelnes GPX mit 6000+ waypoints importiert, war an sich kein problem und ist ganz durchgelaufen. allerdings ist es bei dieser anzahl an waypoints zu laufzeit instabil geworden und hat sich nach einem edit verabschiedet

aber natuerlich hat eine richtige DB klare vorteile. in beelineGPS zB besteht die "DB" aus einer primitiven liste von waypoints zzgl einfachen eigenschaften. fuer meine zwecke reichts, aber von erweiterten such- und filter-moeglichkeiten wie in cachebox fehlt da jede spur. suche oder filter nach D/T/S, oder gar attributen? fehlanzeige. und das ist auch einer der hauptgruende wieso ich gern auf cachebox wechseln wuerde.

allerding ist's mir der krasse tradeoff fuer einen derart langsamen import nicht wert, persoenlich sind mir weniger such/filtermoeglichkeiten und dafuer ein schneller import wichtiger als umgekehrt.

Dafür ist's kostenlos. BeelineGPS kostet nach 30 Tagen $29,95.

soll das heissen, dass freie software per definition schlechter ist? das glaub ich nicht, tim.



die beste loesung waere wie gesagt das .sdf file auf dem PC zu generieren und dann einfach auf den PDA zu kopieren, aber mangels spezifikation wird das wohl nicht moeglich sein. andere ideen die ich so haett:

• ein paar schalter in den optionen, die uU den import beschleunigen koennten, fuer den preis fuer spaeter limiterte suchoptionen? uU kann man das rausparsen der ganzen details ja auf spaeter "on demand" verschieben.
• uU import aus einem "intermediate" file format, das die gleichen infos beinhaltet aber schneller geparst werden kann?
• umstellung auf eine andere SQL engine? SQLite kaeme da in den sinn, aber kA ob's das fuer pocketPC gibt. eine selbstgemachte engine (wenn richtig gemacht) koennte auch funktionieren.
• "outsourcen" der parsing engine in eine in C/assembler geschriebene library.

dafuer muesste man erstmal analysieren, wieso das ganze so langsam ist und welche komponente dran schuld ist. bin leider kein windows (mobile) entwickler, sonst koennte ich da ja helfen...

 

[Joe_M]

Dafür ist's kostenlos. BeelineGPS kostet nach 30 Tagen $29,95.

soll das heissen, dass freie software per definition schlechter ist? das glaub ich nicht, tim.

Nein, das soll heißen, dass es die eierlegende Wollmilchsau nicht gibt:
-schnell beim Import
-schnell im Betrieb
-komfortabel in der Bedienung
-umfangreich bei den Funktionen
-DB von Windows und Linux aus konfigurierbar
-kostenlos
-jetzt sofort verfügbar

cachebox schafft davon schon viel!

die beste loesung waere wie gesagt das .sdf file auf dem PC zu generieren und dann einfach auf den PDA zu kopieren, aber mangels spezifikation wird das wohl nicht moeglich sein.

zumindest nicht unter Linux.
Du könntest warten, bis das Windowstool fertig ist und es dann in irgendeiner VM laufen lassen. cachebox ist ja nicht das erste Programm, das einem Linuxanwender fehlt.
Alternativ könntest Du natürlich auch hannes mal nach den Spezifikationen fragen bzw. anbieten selbst eine Linuxversion der cachebox@home zu erstellen.

andere ideen die ich so haett:

• ein paar schalter in den optionen, die uU den import beschleunigen koennten, fuer den preis fuer spaeter limiterte suchoptionen? uU kann man das rausparsen der ganzen details ja auf spaeter "on demand" verschieben.

• 
  Genau das würde aber die vielgelobte Geschwindigkeit im Betrieb senken und diesen Preis will hier kaum jemand zahlen.
  

  • uU import aus einem "intermediate" file format, das die gleichen infos beinhaltet aber schneller geparst werden kann?

  • 
    Die GPX Dateien sind in XML. Schneller ist da vermutlich nur eine angepasste Lösung und an der wird ja bereits gearbeitet.
    

    • umstellung auf eine andere SQL engine? SQLite kaeme da in den sinn, aber kA ob's das fuer pocketPC gibt. eine selbstgemachte engine (wenn richtig gemacht) koennte auch funktionieren.
    • "outsourcen" der parsing engine in eine in C/assembler geschriebene library.

dafuer muesste man erstmal analysieren, wieso das ganze so langsam ist und welche komponente dran schuld ist.

Das bedeutet alles wieder mehr Aufwand, den man genauso gut in andere Funktionen stecken könnte.

Ja, der Import ist langsam, aber bis jetzt konnte sich damit noch jeder arrangieren.


Gruß,
Joe

 

[Starfiii]

Also ich werde versuchen Cb@H so zu bauen das es unter WINE läuft, also alles was es braucht mit rein zu kompilieren.
Nutze ja auch gerne Ubuntu.

 

[dfx]

Nein, das soll heißen, dass es die eierlegende Wollmilchsau nicht gibt

stimmt zu einem gewissen grad wohl, aber ob frei/gratis oder nicht spielt dabei keine rolle.

Du könntest warten, bis das Windowstool fertig ist und es dann in irgendeiner VM laufen lassen.

das geht dann auch irgendwie am sinn der sache vorbei. ob ich jetzt warte bis am PDA der import fertig ist, oder darauf warte bis die VM hochgefahren ist, kommt dann aufs gleiche raus.

Alternativ könntest Du natürlich auch hannes mal nach den Spezifikationen fragen bzw. anbieten selbst eine Linuxversion der cachebox@home zu erstellen.

das wird so einfach nicht gehen. das .sdf file wird ja von der SQL compact engine erzeugt, da kennt wohl nur MS die spezifikationen dafuer und unter linux gibt's die engine gar nicht, d.h. unter linux ist's gar nicht moeglich ein .sdf file zu generieren, und daher wird's wohl auch keine linuxversion von c@h geben.

Genau das würde aber die vielgelobte Geschwindigkeit im Betrieb senken und diesen Preis will hier kaum jemand zahlen.

deswegen auch die "schalter", damit jeder selbst entscheiden kann, wie er's gern haett.

Die GPX Dateien sind in XML. Schneller ist da vermutlich nur eine angepasste Lösung und an der wird ja bereits gearbeitet.

XML ist eines der aufgeblasensten, umstaendlichsten und langsamsten formate die es gibt, vor allem wenn man einen parser verwendet, der alle features unterstuetzt. von dem her wuerd's mich nicht wundern wenn das die bremse des imports waere. fast jedes andere format, vor allem ein einfaches, spezialisiertes binaer-format waere da schneller. (wuerde aber natuerlich nichts helfen wenn die bremse woanders waere, zB die SQL engine.)

Das bedeutet alles wieder mehr Aufwand, den man genauso gut in andere Funktionen stecken könnte.

natuerlich. nun waer's interessant zu wissen, wie das "offizielle" statement zu der sache ausschaut. wenn's von der seite keine plaene gibt den import zu beschleunigen, dann ist mir das recht und ich werd cachebox einfach beiseite legen. nur wissen wuerd ich's gern.

Ja, der Import ist langsam, aber bis jetzt konnte sich damit noch jeder arrangieren.

das wuerd ich so nicht sagen und halte ich fuer einen fehlschluss. nicht jeder, dem der import zu langsam ist, meldet sich hier (oder sonstwo) zu wort. im gegenteil, die meisten leute werden das prog wohl einfach mal probieren, es dann fuer unbrauchbar abstempeln und einfach wieder loeschen. vor allem in der englischsprachigen userschaft, da's da ja nich mal ein forum dafuer gibt.

 

[Starfiii]

@Joe_M:
Cachebox@Home ist meins, ausser villeicht der eine der mir momentan hilft.

 

[quercus]

ich habe gestern 600 caches in eine neue DB eingetragen und war mit den 5 minuten, die das in etwa gedauert hat sehr zufrieden.

 

[Toette]

Ich kann auch nicht wirklich klagen.

Der reine Import geht doch angemessen schnell, langsam wird die Sache erst beim Import von den Bildern der Cachebeschreibung.

Deswegen wurde ja Cachebox@home ins Leben gerufen, um aus einer GPX von Groundspeak das Futter für Cachebox zu generieren.

Aber mal ehrlich,
ich hab gestern 2PQs a 500 Caches eingelesen, weil ich nächstes Wochenende weg fahren werde und wegen der ganzen 10 Jahres-Events damit rechne, dass bei GS mal wieder gar nix geht.
Gemessen an der Zeit, die ich pro Cache suchen werde, fallen die paar Sekunden Import doch gar nicht ins Gewicht

95% der Caches werde ich nicht mal suchen gehen, wozu muss man eigentlich immer diese riesigen Datenmengen mit sich führen?
Es könnte ja sein, dass ich morgen früh irgendwo anders aufwache, weil ich nachts von Aliens entführt wurde. Ich hab nix dabei, ausser meinem Pyjama und meinem PDA und mein erster Gedanke wird sein...Geilgeilgeil, hier war ich noch nicht, erstma cachen gehen....

In diesem Sinne...

Toette