• Willkommen im Geoclub - dem größten deutschsprachigen Geocaching-Forum. Registriere dich kostenlos, um alle Inhalte zu sehen und neue Beiträge zu erstellen.

[FR] Cachewolfe Suggestions for US users

T

tylosaurus

Geonewbie
Sorry, but I only speak English, Spanish, and Polish, no German.

Hi, I just discovered Cachewolf, and it looks like a great program. I noticed its open source. I'm not a programmer, but have 1 request for it, which will be nearly critical for most American users. Can we get the distance units in Miles and Feet, instead of Kilometers? If so, that would be great. For distances greater than 0.1 miles, miles is great. FOr distances less than 0.1 miles, feet should be used.

thanks

jjb
 
pfeffer

pfeffer

Geowizard
I cannot understand, why someone inside the civilised world uses a non metric system, but I have to admit that the english-speaking part so big that I think it is a good idea to have the option for the imperial system.

Now we only need someone to program that...

Maybe you know someone who can do that?

We are glad if we get new programmers and like to help them to get a comfortable development envirmonemt running.

please feel free to ask in english!

Pfeffer.

EDIT: the guide for programmers is already in english: http://www.geoclub.de/viewtopic.php?f=40&t=23210
 
OP
T

tylosaurus

Geonewbie
Unfortunately I'm not a programmer.

As for the metric system, I'm all for it. I use it all the time, as I am a scientist. However most geocachers, my wife included, roll their eyes at the metric system and will not even consider using Cachewolf because it won;t do distances in Miles and feet.

thanks

dino_hunters
 
MiK

MiK

Geoguru
Please make a central point for this conversion and don't implement it separately in every place we need it.
List, GotoPanel and Map should be easy. Do we want to implement it in the solver?

The CalcPanel already support miles, yards and feet.
 
Engywuck

Engywuck

Geowizard
I think in this case it would be a good idea to write a short implementation description first and to discuss it with the experts...

Greetings,
E.
 
pfeffer

pfeffer

Geowizard
I think if one wants to use the imperial system, he wants it everywhere, so one place in the preferences to switch should be enough. The default could be taken out of the Locale.

The question concerning the solver needs to be discussed further:
I would say: if in the preferences imperial ist selected then solver should accept imperial and give results in imperial., actually. But: That might render working Solver-Skripts broken, if a preference changes which is not really a good thing. A solution for the solver could be the same as for degree and rad: a command to switch beteween in the solver.

Pfeffer.
 
Engywuck

Engywuck

Geowizard
For the implementation details I switch to german:

Habe ein kleines Konzept geschrieben und es im Repository hier abgelegt. Der Text lautet wie folgt:

Konzept zur Meilenunterstützung
===============================

1. Verankerung in Preferences
CW bekommt eine zentrale Variable, die speichert, ob Entfernungen imperial
oder metrisch angegeben sind. Diese wird über die Preferences gesetzt und
gespeichert.

2. Interne Rechnungen
Alle internen Berechnungen verwenden das metrische System. D.h.: Funktionen,
die Entferungen als Argumente entgegennehmen, tun dies in km bzw. m.
Funktionsergebnisse sind stets in km bzw. m. Ausnahmen siehe 4.

3. Darstellung
Werden Entferungen auf der Oberfläche ausgegeben, so werden sie ggf.
in Meilen/Feet umgerechnet(*). Werden Entferungsdaten in der Oberfläche
eingegeben, so erfolgt vor der Verwendung ggf. eine Umrechnung in km
bzw. m.
Werden in der Oberfläche km verwendet, so werden im imperialen System
Meilen verwendet, analog m <-> Fuß.
(*) Dies erfordert die Identifikation aller Stellen, wo Entferungs-
angaben auf der Oberfläche aus- oder eingegeben werden.

4. Solver-Funktionen
Läuft CW im imperialen Modus, so erwartet der Anwender auch im Solver,
dass er Argumente als Meilen bzw. Fuß angeben kann.
Daher erwarten die vom Solver aufgerufenen Primärfunktionen (z.B.
Parser.funcProject() ) ggf. Entferungen in Meilen. Die dahinter
liegenden Arbeitsfunktionen verwenden Daten wie gehabt; die
Umrechnung findet in der Primärfunktion statt.

5. Rechner
Ist das imperiale System eingestellt, so ist "Fuß" der Vorgabewert
für die Einheit.

6. Moving Map
Da ich die Map nicht nutze, habe ich keine Erfahrung, was dort an
Entferungen aus- oder eingegeben wird und ob irgendwelche Spezialitäten
zu beachten sind.

7. Anpassung der Oberfläche
Teilweise erscheinen auf der Oberfläche Einheiten, z.b. beim
Spiderradius. Diese Einheit muss entsprechend angepasst werden.
Kann man das im laufenden Betrieb (d.h. nach Erzeugen der Form)
noch ändern? Sonst wäre 1. ein Fall für "Änderungen werden
erst nach Neustart wirksam."

Kommentare? Was hab ich vergessen, was geht anders/besser/doch nicht?

Grüße,
E.
 
pfeffer

pfeffer

Geowizard
kurz gesagt: wir brauchen eine (von Locale) abgeleitete Funktion, der wir den Wert in km übergeben, die ihn lokalisiert gegebenenfalls mit Einheitenangabe als String (dafür evtl. ne extra Funktion (damit man das entsprechende Einheitenzeichen bei Eingabefelder dahinter setzen kann) wiedergibt.
Evtl. gibt so eine schon?

In der MovingMap wird unten links die Entfernung angezeigt. Ansonsten sehe ich kein Problem.
Wie das im Solver zu lösen ist, dazu kann am besten SKG was sagen Bin allerdings dafür, dass der Solver einen Befehl zum Umschalten erhält.

Gruß,
Pfeffer.
 
MiK

MiK

Geoguru
Zu 3.: Wie von Pfeffer schon erwähnt: Am besten eine global einsetzbare Funktion, der man eine Wert in km gibt und die einen String daraus macht, abhängig vom Wert und der erwähnten Pref.

Zu 4.: Entweder zum Umschalten oder man man dupliziert die Funktionen, die es betrifft und hängt bei der imperialen Form ein "i" an. Das ist aber wahrscheinlich eher fehlerträchtig. Man könnte dann aber beides gemischt verwenden.

Zu 6.: Da muss nur an der von Pfeffer erwähnten Stelle die Funktion aus 4. benutzt werden

Zu 7.: Gerade beim Spidern ist dabei zu beachten, dass sowieso nicht CW die Einheit vorgibt, sondern wie es bei GC eingestellt ist. Vielleicht sollte man dort gar keine Einheit erwähnen ;-). Oder "km/mi".
 
Engywuck

Engywuck

Geowizard
pfeffer schrieb:
Bin allerdings dafür, dass der Solver einen Befehl zum Umschalten erhält.
Zum Vergrößern anklicken....
Mir fällt gerade ein: Im Solver muss man es etwas flexibilisieren. Für die Fälle, wo es heisst "Gehe A*B+3 Meter in C Grad" ist man ja nicht frei in der Wahl des Systems, sondern das Format des Inputs der Funktion (hier: project) wird vom Cache vorgegeben. Andererseit möchte man (evtl. im selben Skript) auch Berechnungen durchführen wie "Gehe 200 Fuß nach Norden". Das spricht eher dafür, eine Konvertierungsfunktion auch für den Solver bereitszustellen (meter2feet).
Einen Button im Solver hielte ich für keine gute Idee, weil es das Solver-Fenster zukleistert mit Funktionen, die nur selten benötigt werden. I.d.R. wird man immer mit dem einen oder andern System arbeiten. Evtl. könnte man eine Funktion bauen, die das metrische System für die Dauer des Solver-Skripts setzt, also setMetric und setImperial. Oder meintest Du dies mit "Befehl" ?

Gruß,
E.
 
pfeffer

pfeffer

Geowizard
Engywuck schrieb:
pfeffer schrieb:
Evtl. könnte man eine Funktion bauen, die das metrische System für die Dauer des Solver-Skripts setzt, also setMetric und setImperial. Oder meintest Du dies mit "Befehl"
Zum Vergrößern anklicken....
Zum Vergrößern anklicken....
ja. Sollte nur genauso sein wie bei deg und rad (ich dachte jedenfalls, dass es dafür entsprechende Umschalt-befehle gibt).
Eine Umrechnungsfunktion würde sich natürlich zusätzlich gehören.

Gruß,
Pfeffer.
 
MiK

MiK

Geoguru
Generell würden mir ein paar Konvertierungsfunktionen im Solver genügen. Die vorhandenen Funktionen blieben wie sie sind. Ob das aber unsere imperialen Freunde zufrieden stellt? Ein Kompromiss wären die von mir vorgeschlagenen zusätzlichen Funktionen, die im imperialen System arbeiten.

Pfeffer meint übrigens ein ähnliches System, wie die jetzige Lösung für Rad<->Deg. Dafür gibt es sowohl einen GUI-Sachalter als auch Befehle in Wolflanguage.
 
MiK

MiK

Geoguru
Bei den Umrechnungsfunktionen bräuchte man dann natürlich auch welche innerhalb des imperialen Systems. Das ist da ja alles nicht so einfach wie im metrischen System.
 
pfeffer

pfeffer

Geowizard
Im Unterschied zu deg-rad würde ich allerdings den GUI-Schalter für metrisch-imperial in die Präferenzen legen.

Gruß,
Pfeffer.
 
Engywuck

Engywuck

Geowizard
MiK schrieb:
Generell würden mir ein paar Konvertierungsfunktionen im Solver genügen.
Zum Vergrößern anklicken....
Das fände ich inkonsequent. Dann würde der gesamte CW mit Meilen arbeiten, nur im Solver müsste ich Eingaben erst konvertieren? Da würde ich als Ami schräg gucken.

MiK schrieb:
Die vorhandenen Funktionen blieben wie sie sind.
Zum Vergrößern anklicken....
Das Berücksichtigen des generellen Schalters wäre kein Problem.

MiK schrieb:
Ein Kompromiss wären die von mir vorgeschlagenen zusätzlichen Funktionen, die im imperialen System arbeiten.
Zum Vergrößern anklicken....
Das hielte ich allerdings für unübersichtlich.

Grundlegend gilt ja folgendes: Entweder ich lebe und denke in Metern, oder in Meilen/Fuß. D.h. ich schalte nicht dauernd zwischen den Einstellungen hin und her. Der Solver sollte sich deshalb also auch möglichst intuitiv verhalten, egal in welchem System man arbeitet.
Cache ich im Meilen-Land, so werden auch die Caches in der Regel sagen "Gehe A*B+3 Fuß in Richtung ...". D.h. wenn ich den CW einmal auf Meilen umstelle, erwarte ich, dass er das ohne Mucken und konsequent überall macht, weil ich ja auch gar nicht mehr dran denke, dass er eigentlich aus einer Gegend mit vernünftigen Einheiten kommt. Da will ich nicht um jede meiner Ergebnisse noch eine Konvertierungsfunktion rumbasteln, das soll er gefälligst selbst - die Informationen sind ja vorhanden.
Umrechnungsfunktionen zwischen den Systemen wären praktisch, aber nicht lebensnotwendig. Wesentlich notwendiger sind vermutlich Umrechnungsfunktionen zwischen Meilen, Yards und Fuß. In jede Richtung.
pfeffer schrieb:
Im Unterschied zu deg-rad würde ich allerdings den GUI-Schalter für metrisch-imperial in die Präferenzen legen.
Zum Vergrößern anklicken....
Auf jeden Fall. Das meinte ich mit Punkt 1 meiner Beschreibung.

Gruß,
E.
 
MiK

MiK

Geoguru
Engywuck schrieb:
Grundlegend gilt ja folgendes: Entweder ich lebe und denke in Metern, oder in Meilen/Fuß. D.h. ich schalte nicht dauernd zwischen den Einstellungen hin und her. Der Solver sollte sich deshalb also auch möglichst intuitiv verhalten, egal in welchem System man arbeitet.
Cache ich im Meilen-Land, so werden auch die Caches in der Regel sagen "Gehe A*B+3 Fuß in Richtung ...". D.h. wenn ich den CW einmal auf Meilen umstelle, erwarte ich, dass er das ohne Mucken und konsequent überall macht, weil ich ja auch gar nicht mehr dran denke, dass er eigentlich aus einer Gegend mit vernünftigen Einheiten kommt. Da will ich nicht um jede meiner Ergebnisse noch eine Konvertierungsfunktion rumbasteln, das soll er gefälligst selbst - die Informationen sind ja vorhanden.
Umrechnungsfunktionen zwischen den Systemen wären praktisch, aber nicht lebensnotwendig. Wesentlich notwendiger sind vermutlich Umrechnungsfunktionen zwischen Meilen, Yards und Fuß. In jede Richtung.
Zum Vergrößern anklicken....
Gerade wegen letzterem kann eigentlich ein Rechnen im imperialen System nie intuitiv funktionieren. Man muss ständig umständlich zwischen den Einheiten umrechnen. Un woher weiß ich intuitiv, ob die Funktionen gerade Meilen, Yards oder Feet erwarten? Deswegen mein Vorschlag, bei dem man das immer explizit angeben muss. Entweder durch Umrechnen oder durch anders benannte Funktionen. Welche Solverfunktionen betrifft es überhaupt? Distance und Project, sonst noch etwas?
 
Engywuck

Engywuck

Geowizard
MiK schrieb:
Un woher weiß ich intuitiv, ob die Funktionen gerade Meilen, Yards oder Feet erwarten?
Zum Vergrößern anklicken....
Aus der gleichen Intuition, aus der ich weiß, dass die Distance-Funktion heutzutage Meter erwartet und nicht Kilometer. Im Zweifel: In der Beschreibung nachgucken.
MiK schrieb:
Deswegen mein Vorschlag, bei dem man das immer explizit angeben muss. Entweder durch Umrechnen oder durch anders benannte Funktionen.
Zum Vergrößern anklicken....
Ich bin mir immer noch nicht sicher, wie Du das meinst. Heisst "umrechnen" jetzt umrechnen innerhalb des imperialen Systems?
Das es Umrechnungsfunktionen innerhalb des imperialen Systems geben muss, ist unstrittig. Wenn man an den Solver-Funktionen selbst nichts ändert, braucht man auf jeden Fall auch die Umrechnungsfunktionen zwischen den Systemen.
Ich muss allerdings gestehen, dass ich es etwas lästig und unübersichtlich fände, wenn ich immer
Code: 
Meter2Miles(distance(WP1, WP2))
schreiben muss. Mein Solver-Code für einen nicht näher benannten Mystery z.B sieht wie folgt aus
Code: 
A="Zensur1" # Zensiert, um nicht zu spoilern
B="Zensur2"
C="Zensur2"
AB=distance(A,B); 
AC=distance(A,C);
BC=distance(B,C);
"Strecke AB: "AB
alpha=bearing(A,C)-bearing(A,B)
gamma=bearing(C,B)-bearing(C,A)
"Winkel alpha: "alpha
h=sin(alpha)*AB
"Höhe h auf AC: "h
F=h*AC/2
"Fläche F: "F
r=2*F/(AB + AC + BC)
"Inkreisradius r: "r
Xa=tan(gamma/2)*AC/(tan(alpha/2)+tan(gamma/2))
"Xa ist: "Xa
P1=project(A, bearing(A,C), Xa)
P2=project(P1, bearing(C,A)+90, r)
SF=project(P2, 0, r)
"Final bei: "SF
Da sollte schon vieles automatisiert laufen, sonst blickt man gar nicht mehr durch. Und die Festlegung "distance und project benutzen Yards" (oder was auch immer) lernt man ein mal und hat dann keinen Stress mehr damit. Dein Vorschlag, die Funktionen zu vermehrfachen (distanceMet, distanceKMet, distanceMil, distanceYd, distanceFt) ist in der Anwendung zwar übersichtlicher als das Verwenden der Konvertierungsfunktionen, allerdings nicht weniger fehleranfällig, wie von Dir schon festgestellt.

Was meint denn der Rest dazu?

MiK schrieb:
Welche Solverfunktionen betrifft es überhaupt? Distance und Project, sonst noch etwas?
Zum Vergrößern anklicken....
Ich sehe auch nur die beiden.

Weitere Interessante Frage: In EWE oder in EVE ? Aufgrund der konkreten Anfrage würde ich lieber in EWE anfangen und es nachher nach EVE (so es noch dazu kommt ;-) ) übertragen.

Gruß,
E.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Oben