Kleine Anleitung zum Solver (Entwurf)

[cacheboxer]

Dazu wären ein paar verschiedene Möglichkeiten denkbar:
* Koordinaten im Solver mit Copy in die Zwischenablage und in den Einstellungen der Wegpunkte einen Paste Befehl

Die anderen beiden Möglichkeiten wäre für den Solver praktischer, diese Möglichkeit wäre aber auch anderweitig verwendbar - würde mich freuen, wenn der das als "Abfallprodukt" noch dazukommt. Gerade bei älteren Caches stehen die Wegpunkte ja häufig nur als Text in der Description. Da wäre Copy&Paste echt praktisch.

Momentan kannst du mit "N 57° 22,"A+B:3 erzwinten, dass die letzte Berechnung mind. 3 Stellen bekommt.

Cool, wusste ich noch gar nicht. Wenn das durchgehend funktioniert, bin ich damit glücklich.

 

[klausundelke]

Hallo Hubert,
alle 3 Möglichkeiten haben was...

Korrigiere, die obige Lösung dürfte im Ergebnistext des Solvers N 57° 22,20 ergeben. Das denke ich sollte in den meisten Fällen als 22,020 angesehen werden

Ja, Nein, genau in dieser Reihenfolge....
Es steht 22,20 im Ergebnistext, wenn man das irgendwo einfügt wird das nun mal
als 22,200 interpretiert...

 

[Pegasus37]

In der rev 573 wird im Solver ^ nicht als Operator interpretiert, es wird die fehlende Variable a^b angeboten und eingefügt.

Ansonsten liebe ich den Solver! Hervorragende Arbeit.

Gruß
P37

 

[SurFan]

Hi,
ist vermutlich z.Zt. erst in WinCachebox implementiert
Ralph

 

[millimeterfuchser]

Kurze Frage an Silverio:

Was dagegen, wenn Deine Anleitung für den WCB-Solver ins Wiki übernommen wird?

Gruß, André

 

[GeoSilverio]

Nein nein, macht nur. Ich kann das natürlich auch als Text liefern.
Anfang der Woche will ich auch die neuesten Funktionen von GingBuh da mit rein nehmen.

 

[Wolli]

Hi

habe folgende Bonusformel:

N 48° 4xxxx, E 008° 3yyyy, wobei

xxxx = [(G+L+U+E+C+K) * (G+L+U+E+C+K) + 5 * (G+L+U+E+C+K) - 26] /1000
yyyy = [(G+L+U+E+C+K) * (G+L+U+E+C+K) + 12 * (G+L+U+E+C+K) + 34] /1000

Wie gebe ich diese "echte" Formel am Besten in den Solver ein, da ja (leider) Klammern ignoriert werden?

Gruß Wolli

 

[Pegasus37]

N 48° 4xxxx, E 008° 3yyyy
xxxx = [(G+L+U+E+C+K) * (G+L+U+E+C+K) + 5 * (G+L+U+E+C+K) - 26] /1000
yyyy = [(G+L+U+E+C+K) * (G+L+U+E+C+K) + 12 * (G+L+U+E+C+K) + 34] /1000

x=G+L+U+E+C+K
xx=x*x+5*x-26
yy=x*x+12*x+34
"N 48° 4"xx/1000
"E 008° 3"yy/1000

sollte das richtige Ergebnis bringen

Gruss
P37

 

[klausundelke]

Ich hätte auch noch eine Bitte zum Solver:
Ich hab grade für einen Mystery die Koordinaten ermittelt.
Irgendwas bei den Antworten war offensichtlich falsch, jedenfalls
bringt der Solver eine Meldung "Koordinate not valid"
Ich würde mir trotzdem eine Ausgabe der errechneten Zahlen wünschen,
dann könnte man das Problem viel leichter eingrenzen.

 

[Ging-Buh]

Ich hätte auch noch eine Bitte zum Solver:
Ich hab grade für einen Mystery die Koordinaten ermittelt.
Irgendwas bei den Antworten war offensichtlich falsch, jedenfalls
bringt der Solver eine Meldung "Koordinate not valid"
Ich würde mir trotzdem eine Ausgabe der errechneten Zahlen wünschen,
dann könnte man das Problem viel leichter eingrenzen.

Könntest du bitte mal einstellen, was du eingegeben hast?

 

[millimeterfuchser]

Mein häufigstes Problem war das fehlende Leerzeichen zwischen Grad und Minute der Koordinate (richtig:N51° 23.222 falsch:N51°23.222, alternativ sollte man das ° weglassen, somit wirds automatisch richtig: N51 23.222). Das gilt natürlich auch für den Ostwert.

Gruß, André

 

[CacheBiker]

@Hubert ...

ist im Solver eine Waypoint-Generierung via UTM-Koordinaten angedacht ?

Gestern hat mir der Solver wieder mal viel Rechenarbeit erspart !
Ein klasse Tool ... vielen Dank nochmal dafür

Gruß, Peter

 

[Ging-Buh]

@Hubert ...

ist im Solver eine Waypoint-Generierung via UTM-Koordinaten angedacht ?

Kann man sicher mal drüber nachdenken.
Das beste wäre es, wenn du in SourceForge dafür einen FeatureRequest schreibst. Da wird nichts vergessen...

 

[klausundelke]

Könntest du bitte mal einstellen, was du eingegeben hast?

Hallo Hubert,
Ich wollte einen Wegpunkt zuweisen in der Art:
$GC12345="N 50° 50.123 E08° 24."A/B
A/B ergab einen Wert 234,256 das konnte nicht gehen.
(Die Formel war bei mir deutlich länger, da waren auch die Vorkomma-Stellen drin....)
Wenn nach dem Hinweis "Invalid Koordinate" die falschen errechneten Werte
ausgegeben würden, dann wäre die Fehlersuche leichter.
Ich hab mir halt so beholfen, daß ich die Formeln in neue Variablen
eingesetzt hab z.B. H=A/B, so hab ich ein Ergebnis angezeigt und kann das
auf Korrektheit prüfen.

 

[Ging-Buh]

@Hubert ...

ist im Solver eine Waypoint-Generierung via UTM-Koordinaten angedacht ?

Gestern hat mir der Solver wieder mal viel Rechenarbeit erspart !
Ein klasse Tool ... vielen Dank nochmal dafür

Gruß, Peter

Hallo Peter,

hast du (oder jemand anders) Erfahrung mit UTM? Weißt du ob es einen Standard gibt, in dem UTM Koordinaten angegeben werden? Ich finde immer verschiedene Varianten:

Einmal. mit Buchstanben nach der Zone und extra E und N bei den Koordinaten (wird in GC.com so angezeigt)
32U E 714934 N 5324276

Einmal nur mit N oder S nach der Zone und sonst keinem N-O-S-W Buchstaben
32 N 0639899 5365223

Ich denke mal, dass in der 2. Variante alle Informationen enthalten sind. Frag mich aber dann warum GC.com dies anders angibt.

Was wäre das Format, dass hier akzeptiert werden sollte?

 

[CacheBiker]

Hallo Hubert,

freut mich, daß Du schon an den UTM-WPs arbeitest.

Ja, auch mir sind inzwischen diverse UTM Formate begegnet, aber auch bei den WGS84-Darstellungen habe ich die Buchstaben N und E schon mal am Ende des Strings gesehen ...

Die Frage ist, ob man wirklich alle Schreibweisen abdecken muß. Aus meiner Sicht würde es genügen, wenn ein Format unterstützt wird und immer dann, wenn dieses Format nicht eingehalten wird in der Fehlermeldung ein Beispielstring angezeigt wird, an dem der Cacher erkennt, wie er den String umbauen sollte.

Mein Vorschlag wäre, das einfache UTM-Format zu unterstützen, also in der Form
Zone Ostwert/Rechtswert Nordwert/Hochwert (Bsp: 32T 533378 5279588).

Interessante Infos zu UTM gibts auch noch hier
http://de.wikipedia.org/wiki/UTM-Koordinatensystem

Gruß, Peter

 

[millimeterfuchser]

Dann mal in ganz kurz:

die 32U geben eigentlich schon alles an, was Du zum Ost/Nordwert wissen musst
32 ist die Zone für den Rechtswert und U die Angabe für Nord oder Süd (C-M Süd, N-X Nord)

danach kommt immer der Rechtswert bezogen auf den Mittelmeridian, aber um negative
Koordinaten zu verhindern werden mal glatt 500km drauf addiert irgendeine Zusatzinformation wäre nicht notwendig

zuletzt kommt der Nordwert, hier wirds doof. Hier setzt man den Äquator auf 10.000.000m um ebenfalls negative Koordinaten zu vermeiden.

Gibst du also die Koordinate folgend an: 32U 714934 5324276
ist diese eigentlich klar definiert.

ABER: hier wird dann immer wieder jemand nerven und sagen: das sieht aber anders aus als bei GC.........


Gruß, André

 

[Ging-Buh]

Dann mal in ganz kurz:

die 32U geben eigentlich schon alles an, was Du zum Ost/Nordwert wissen musst
32 ist die Zone für den Rechtswert und U die Angabe für Nord oder Süd (C-M Süd, N-X Nord)

Braucht man diese Angabe für Nord oder Süd so genau? Ich denke mal grundsätzlich nicht. Die Information ob nördlich oder südlich würde reichen.

Ich bin teilweise auf Darstellungen gestoßen, bei denen nur 32S oder 32N angegeben wird (S für südlich, N für nördlich), z.B. bei manchen UTM-Konvertern im Internet. Was dann natürlich ein Problem darstellt, da einerseits "S" für südlich stehen könnte oder andererseits für nördlich [Angabe für Nord oder Süd (C-M Süd, N-X Nord)].

Mit dem Parsen von UTM-Koordinaten habe ich in WinCB schon mal angefangen. Meine Routinen zum Konvertieren von Lat/Lon in UTM und umgekehrt funktionieren aber leider auch mit dem System (nur "N" oder "S"). Das müsste wahrscheinlich geändert werden?

Ich könnte das sicherlich entsprechend umbauen, wenn ein Format gefunden ist, auf das man sich hier beschränken kann...
Dieses Format sollte wahrscheinlich dann dieses sein:

Mein Vorschlag wäre, das einfache UTM-Format zu unterstützen, also in der Form
Zone Ostwert/Rechtswert Nordwert/Hochwert (Bsp: 32T 533378 5279588).

Oder?

 

[Ging-Buh]

OK, ich denke, das Format

32T 533378 5279588

sollte das beste sein.
Ich werde es in WinCB ändern und CB im Solver als Zuweisung auch aktzeptieren...

 

[millimeterfuchser]

So, da wir uns ja indirekt sowieso an Grundsprech orientieren hab ich mir mal 4 Punkte und deren Umrechnung mal angesehen:

Nordhalbkugel, östlich von 0°
32U E 689665 N 5697734 für N 51° 23.945 E 011° 43.598

Nordhalbkugel, westlich von 0°
30U E 356219 N 5736152 für N 51° 45.467 W 005° 04.996

Südhalbkugel, westlich von 0°
22J E 481849 N -3333996 für S 30° 08.228 W 051° 11.307

Südhalbkugel, östlich von 0°
56H E 335612 N -3746414 für S 33° 50.713 E 151° 13.394

soviel zum Thema Nord und Süd, das wird bei GS durch die negative Koordinate geregelt.

Gruß, André