Änderung im Dateiformat

greiol · 8 Mai 2009

wo wir gerade bei dateiformaten sind ...

ist vermutlich nicht ganz neu, verwirrt mich aber gerade:
in der waypoint.xml findet sich im abschnitt <LOGS> neben den <LOG> einträgen auch noch <OWNLOG> und <OWNLOGID>. die beiden OWN* scheinen mir singulär ausgelegt zu sein (oder ich versteh es gerade nicht). pro cache kann ich ja zum einen mehr als ein log schreiben und auch mehr als ein foundit log. wäre es da nicht besser die ownlogs auch als liste abzulegen und als <OWNLOG id="">text</OWNLOG> ähnlich wie die übrigen logs abzulegen?

MiK · 8 Mai 2009

Verwendet wird dies bisher nur für den GPX-(MyFinds)-Export. Dabei wird pro Cache immer nur ein Eintrag erzeugt. Wie macht das eigentlich GC.com, wenn man einen Cache mehrmals gefunden hat?

greiol · 8 Mai 2009

in der my finds pq sind alle meine logs die ich jemals zu einem gefundenen cache geschrieben habe. egal welcher logtyp das war. egal wie oft ich ein log vom jeweiligen typ geschrieben habe. auch foundits sind mehrmals möglich. deshalb weisen viele statistiktool den unterschied zwischen "funden" und "unique caches" aus

Engywuck · 8 Mai 2009

LogList.java nicht aktualisiert in Eclipse?

arbor95 · 8 Mai 2009

bei clean up erhalte ich, dass Dateien "out of sync" mit dem Dateisystem seien. Aber wo kann ich die syncen ? Da kommt kein Schalter!

wie nutze ich svn - update innerhalb von Eclipse?

Warum stört sich Eclipse nicht an das Dateisystem ?
Das Dateisystem war für mich bisher immer das, worauf ich mich verlassen konnte.

Fragen über Fragen. ! Sorry

Nachtrag :
Über das Menü : Project/Clean hat er jetzt wohl alles verstanden.

UncleOwen · 9 Mai 2009

So ganz abwärtskompatibel ist's aber nicht... Beim Export aufs Garmin wirft er mir 'ne Exception:

Code:

java.lang.StringIndexOutOfBoundsException: String index out of range: 1
        at java.lang.String.substring(String.java:1946)
        at exp.Exporter.getShortDetails(Exporter.java:429)
        at exp.LocExporter.record(LocExporter.java:60)
        at exp.Exporter.doIt(Exporter.java:111)
java.lang.StringIndexOutOfBoundsException: String index out of range: 1
        at java.lang.String.substring(String.java:1946)
        at exp.Exporter.getShortDetails(Exporter.java:429)
        at exp.LocExporter.record(LocExporter.java:60)
        at exp.Exporter.doIt(Exporter.java:111)
        at CacheWolf.MainMenu.onEvent(MainMenu.java:409)
        at ewe.ui.Control.postEvent(Control.java)
        at ewe.ui.MenuState.onEvent(MenuState.java)
        at ewe.ui.Control.sendToListeners(Control.java)
        at ewe.ui.Control.postEvent(Control.java)
        at ewe.ui.Menu.postEvent(Menu.java)
        at ewe.ui.Menu.onEvent(Menu.java)
        at ewe.ui.Control.sendToListeners(Control.java)
        at ewe.ui.Control.postEvent(Control.java)
        at ewe.ui.Menu.postEvent(Menu.java)
        at ewe.ui.Control.notifyAction(Control.java)
        at ewe.ui.Menu.penReleased(Menu.java)
        at ewe.ui.Control.penClicked(Control.java)
        at ewe.ui.Control.onPenEvent(Control.java)
        at ewe.ui.Menu.onPenEvent(Menu.java)
        at ewe.ui.Control.onEvent(Control.java)
        at ewe.ui.Menu.onEvent(Menu.java)
        at ewe.ui.Control.postEvent(Control.java)
        at ewe.ui.Menu.postEvent(Menu.java)
        at ewe.ui.Window.doPostEvent(Window.java)
        at ewe.ui.Window$windowThread.run(Window.java)
        at ewe.sys.mThread.run(mThread.java)
        at ewe.sys.Coroutine.run(Coroutine.java)

Und zwar bei dem angehängten Cache. Eventuell wegen dem size = "Not chosen"? (Das hatte der erste Cache, an dem er sich aufgehängt hat, auch - hab den dann manuell aktualisiert, und dann hat er sich an dem hier aufgehängt)

*edit* Ja, wenn ich die 5 caches mit size = "Not chosen" aktualisiere, läuft der export durch.

Engywuck · 9 Mai 2009

Hast Du mit den size-not-chosen-Caches irgendwas gemacht, dass sie in den Zustand gekommen sind?

Edit: Ich habe mal eine kleine Änderung eingebaut. Jetzt gibt es keine Leerstrings mehr als Cachegröße - im Zweifel ist's "None".

UncleOwen · 9 Mai 2009

Nicht, dass ich wüsste... Ist ja z.B. bei events auch nichts ungewöhnliches.

Engywuck · 9 Mai 2009

araber95 schrieb:
bei clean up erhalte ich, dass Dateien "out of sync" mit dem Dateisystem seien. Aber wo kann ich die syncen ? Da kommt kein Schalter!

Das macht Eclipse dann eigentlich automatisch. Viel zu syncen gibts da auch nicht - Eclipse lädt die Datei neu, wenn sie gerade im Editor angezeigt wird.

araber95 schrieb:
wie nutze ich svn - update innerhalb von Eclipse?

Im Package-Explorer, Rechte Maustaste, Team->Update

araber95 schrieb:
Warum stört sich Eclipse nicht an das Dateisystem ?
Das Dateisystem war für mich bisher immer das, worauf ich mich verlassen konnte.

Das ist bei Eclipse nicht immer so. Es verwaltet selbständig, wann Änderungen an den Dateien vorgenommen wurden und überprüft die nicht ständig, ob andere Programme dran gefummelt haben. Normalerweise hilft in so einem Fall ein Refresh auf Projektebene. Dann guckt er sich nämlich alle Dateien an, ob sich was dran getan hat. Wenn das nicht hilft, hilft sicher ein Clean. Denn dann wirft Eclipse alle kompilierten Class-dateien weg und macht sie neu. Und bei dem Vorgang muss es zwangsläufig mal auf die Platte gucken und die Dateien laden.

Gruß,
E.

arbor95 · 9 Mai 2009

Hallo E.
vielen Dank für deine Geduld. Es sieht so aus, als ob Eclipse nicht mitkriegt, wenn neue Dateien über turtoise-svn geholt werden (update) (ausser man öffnet diese im Editor) (bzw sie werden nicht neu kompiliert). Erst ein neues manuelles Erstellen des Projektes mit dem Project/clean hat geholfen. Dann werde ich in Zukunft auf Team/update klicken (was hoffentlich diese Probleme beseitigt).
mfg
Franz

greiol · 9 Mai 2009

wie hast du eigentlich die 453 von einem megaevent in ein byte bekommen? :???:

auch CachTypes.java verwirrt mich derzeit zu tiefst. mal ist der WhereIGo als 200 (würde in ein byte passen) angegeben und mal als 1858 (passt nicht rein). leider erkenne ich in der datei nicht ohne weiteres wann welches mapping in welche richtung angezogen wird.

Engywuck · 9 Mai 2009

Ganz einfach. Guggst Du CacheHolder.getType/setType

Gruß,
E.

greiol · 9 Mai 2009

Engywuck schrieb:
Ganz einfach. Guggst Du CacheHolder.getType/setType

wie du meiner frage entnehmen kannst, entsprach eine umrechung von cachetypen an dieser stelle nicht wirklich meinem erwartungswert. vor allem wenn ich eine CacheType klasse habe, die alle anderen notwendigen umrechungen vornimmt.

in der cachetype klasse haben wir auch viele schöne konstanten die man benutzen könnte. CW_WHERIGO liest sich einfach besser als 1848. vor allem weil 1848 falsch ist und es 1858 sein müsste.

dass wir whereigos im einen fall auf 100 mappen und in einem anderen auf 200 macht es nicht übersichtlicher.

Edit: nicht dass wir uns falsch verstehen, die änderungen waren gut und richtig. ich bitte nur darum die eine oder andere konkrete implementierung im hinblick auf wartbarkeit durch jemanden der den code nicht selber geschrieben hat zu prüfen.

Engywuck · 9 Mai 2009

Ich guck's mir mal an.
Bislang hab ich es erstmal minimalinvasiv eingebaut - also möglichst so, dass alle anderen Teile die Daten so sehen wie bisher. Optimierungsmöglichkeiten gibt es da sicher noch...

Gruß,
E.

greiol · 9 Mai 2009

was mich zur nächsten frage bringt.

was ist der vorteil der jetzigen gettype/settype lösung gegenüber einer simplen tabelle / funktion die die ein- und ausgaben eins zu eins matcht so in der form

Code:

	public static Integer byteTypeToCwType(byte type) {
		switch (type) {
			case 0: return CW_CUSTOM;
			case 1: return CW_TRADITIONAL;
			// ...
		}
		
		return 0;
	}
	
	public static byte cwTypeToByteType(Integer type) {
		switch (type) {
			case CW_CUSTOM: return 0;
			case CW_TRADITIONAL: return 1;
			// ...
		}
		return 0;
	}

der "+128 trick" hilft zwar ein wenig weiter, aber sobald ein cachetyp 228 auftaucht ist die kollision imho vorprogrammiert, weil die software dann über "die ausnahme" 100 stolpert und den nicht verarbeiten kann. damit hat die umsetzung ein gewisses zukünftiges problempotential.

je länger ich darüber nachdenke desto mehr bauchschmerzen macht mir auch, dass vermutlich eine menge anwender mutig auf die NB gehen und wir ein echtes problem an der backe haben wenn wir das noch mal ordentlich anpacken müssen. dann stehen die user vor einem datenverlust oder wir vor dem nächsten konverter.

MiK · 9 Mai 2009

Ich komme zur Zeit nicht dazu, mir das genauer anzuschauen. Aber das Mapping, das Greiol vorschlägt erscheint mir sinnvoller.

Ich stimme auch zu, dass wir jetzt schnell das "endgültige" Format beschließen sollten, denn noch können wir "guten Gewissens" etwas ändern ohne die Zwischenversionen später beachten zu müssen. Ich habe auch "The Hawks" gebeten, eine deutliche Warnung vor den aktuellen Versionen auf dem NB-Server zu platzieren.

König Moderig · 10 Mai 2009

Ich hab das auf Bitte von MiK auf der NB-Website mal angemerkt, damit sich später keiner beschwert wenn es Datenverlust beim Update gibt

Das Mapping erscheint mir auch sehr sinnvoll!

-nik

greiol · 10 Mai 2009

evtl. haben wir auch noch etwas bei der size.

für einen funktionierenden (möglichst vollständigen) gpx export müssten wir "Micro", "Small", "Regular", "Large", "Not chosen", "Other", "Virtual" liefern können. auf anhieb finde ich die so erst mal nicht in den neuen routinen abgebildet. das liegt allerdings vermutlich daran, dass cw noch nie mit allen vollständig umgehen (anzeigen) konnte, aber zumindest brav die strings in die index.xml zurück geschrieben hat. im neuen format würde uns das allerdings beissen.

zu einer experientellen bestätigung komme ich aber erst am montag.

Engywuck · 10 Mai 2009

greiol schrieb:
was ist der vorteil der jetzigen gettype/settype lösung gegenüber einer simplen tabelle / funktion die die ein- und ausgaben eins zu eins matcht so in der form
...
der "+128 trick" hilft zwar ein wenig weiter, aber sobald ein cachetyp 228 auftaucht ist die kollision imho vorprogrammiert, weil die software dann über "die ausnahme" 100 stolpert und den nicht verarbeiten kann. damit hat die umsetzung ein gewisses zukünftiges problempotential.

Zum ersten Punkt: Weils schneller zu programmieren ist ;-)
Das Problem im zweiten Punkt sehe ich allerdings nicht (oder ich habs nicht verstanden): Ich habe folgendes Mapping gemacht: Ziehe vom Typ 128 ab und nimm das als Byte. Für die Werte, die da nicht reinpassen, gibts ein spezielles Mapping.
Du willst nun die Konvertierung "-128" rauswerfen und das für jeden Typ extra im Code machen? Den Vorteil sehe ich nicht.
Wir haben maximal dann ein kleines Problem, wenn plötzlich ein neuer Cachetyp rauskommt, der den gleichen Wert hat wie ein "umgemappter" alter Wert (wie von Dir erläutert) - aber beim manuellen Mapping bist Du doch da auch nicht besser dran, oder?

Gruß,
E.

Engywuck · 10 Mai 2009

greiol schrieb:
für einen funktionierenden (möglichst vollständigen) gpx export müssten wir "Micro", "Small", "Regular", "Large", "Not chosen", "Other", "Virtual" liefern können.

Bei meinem GPX-Export klappt das. Zumindest mit den Standard-Größen - für die anderen hatte ich keine Beispieldaten.

Gruß,
E.

Änderung im Dateiformat

Geoguru

Geoguru

Geoguru

Geowizard

Geoguru

Geocacher

Anhänge

Geowizard

Geocacher

Geowizard

Geoguru

Geoguru

Geowizard

Geoguru

Geowizard

Geoguru

Geoguru

Geowizard

Geoguru

Geowizard

Geowizard