Pravilen format GPS pozicije za izračune v programih

[Aleksander]

Programi za pametne telefone nam omogočajo prenos formul v posebne programe, avtomatično obdelavo, ki je enostavna in bolj zanesljiva od napak, ki jih storimo s človeškim faktorjem.

Pravilno zapisane formate znajo programi razčleniti na neizračunane pozicije in na vse neznanke, ki se v njih pojavijo. Ko posamenznim neznankam vpišemo vrednosti nam program v glavnem programu spremeni pozicijo na izračunano.

Postavljalce zakladov (tudi revizorja) prosim in pozivam, če v tekste vključijo predvsem znak za stopinje ° Brez tega znaka programi ne znajo izločiti formul.

Primer pravilnega zapisa:
N 45° 44.(X-2)XY′ E 014° 44.((Z+3)*34))′

Primer nepravilnega zapisa:
N 45 44.(Y+45)XY E 014 44.((Z+3)*34))

Formule naj bodo zapisane tako, kot bi jih zapisali v program za preglednice, brez presledkov, znak x naj nadomesti znak množenja:

YYY = A x (D+C-B) x (D - 2 x B) + (21+F)/(2 x G) popravimo v format YYY=A*(D+C-B)*(D-2*B)+(21+F)/(2*G)

Formati za tri ali štirimestna števila niso problematična. Reševalcu dajo informacijo, koliko mestno številko mora prepisati ali z izračunom pridobiti. Za reševanju v programu moramo YYYY spremeniti v en Y, sicer je za matematične operacije YYYY pomeni lahko štiri štirimestna števila.

[bucar]

Za tiste malo bolj programersko naravnane lastnike še opomba, da lahko v opis zaklada vključijo kodo, ki jo program(i) za lažje reševanje prepoznajo, kot je to na primer pri zakladu https://coord.info/GC47DMD. V njegovi izvorni kodi najdemo naslednje:

Koda: Izberi vse

<!-- solver_json: [{ "GC47DMD": { "cname": "Leichte Kost ;-)", "listing": "", "waypoints": [ { "gccode": "PK47DMD", "name": "GC47DMD Parking", "type": "c", "final": false, "ref": "", "f1": "N 48°13.716", "f1mod": "N 48°13.716", "f2": "E 12°49.686", "f2mod": "E 12°49.686", "lat": "N 48°13.716", "lon": "E 12°49.686" }, { "gccode": "F147DMD", "name": "Final", "type": "c", "final": true, "ref": "", "f1": "N48° (14.127)+X*Y/1000", "f1mod": "N48° (14.127)+X*Y/1000", "f2": "E12° (49.044)+(X+Y)/100+X*Y/1000", "f2mod": "E12° (49.044)+(X+Y)/100+X*Y/1000", "lat": "", "lon": "" }], "variables": [ { "name": "X", "text": "", "note": "", "value": "", "functions": [ ] }, { "name": "Y", "text": "", "note": "", "value": "", "functions": [ ] } ]}}] -->

Tak vpis povzroči, da program sam prepozna pravilne enačbe, spremenljivke, kot tudi tipe točk v zakladu:

[icabrian]

Hja, za formule v opisih svojih zakladov želim, da so dobro berljive predvsem za človeka, tako da prikaza ne bom spreminjal zato, da jih bo lažje prebral nek program. Zagotavljanje zapisa v formatu, primernem za prenos v take programe, vidim bolj kot bonus in ne kot standard.

Mimogrede, a bi program znal pobrati iz opisa formulo, ki bi bila v HTML kodirana kot komentar med oznakama <!-- in --> ?

[Aleksander]

Saj tudi sam nisem šel spreminjati opisov svojih zakladov. Poziv je bil mišljen za prihodnje zaklade. Tudi v geocachingu se tehnologija spreminja in razvija in nikoli ni narobe, če je v informacijskih zapisih enoten red. Oznaka za stopinje naredi že veliko razliko.

[bucar]

Mimogrede, a bi program znal pobrati iz opisa formulo, ki bi bila v HTML kodirana kot komentar med oznakama <!-- in --> ?

Ravno to sem napisal zgoraj in dodal vzorčno kodo. Programu lahko v HTML komentraju podtakneš podatke v JSON obliki, za ljudi pa pustiš tisto, kar se ti zdi, da jim bolj paše. Opis se ne spreminja, program pa dobi svoje.

[krossnik]

Saj tudi sam nisem šel spreminjati opisov svojih zakladov. Poziv je bil mišljen za prihodnje zaklade. Tudi v geocachingu se tehnologija spreminja in razvija in nikoli ni narobe, če je v informacijskih zapisih enoten red. Oznaka za stopinje naredi že veliko razliko.

Aleksander, se strinjam s tvojim zapisom in vem, da želiš s to temo samo dobro vsem, predvsem tistim, ki uporabljajo razne elektronske solverje in mislim, da vem za kater vtičnik gre v tvojem primeru. Dejstvo je, da večina pri pisanju koordinatenga zapisa izpušča stopinje je tako bolj "komot" (tudi sam sem večkrat med njimi), vendar je za navadnega geolovca tak format brez stopinj berljiv, kot tudi formule, ki uporabljajo X namesto *. Na koncu se mučijo predvsem tisti, ki potem prenašajo te formule v solverje, ki pa so po navadi "togi" in striktno delajo s samo določenimi formati, kar največkrat pomeni popravljanje formul.
Po mojem boš več in predvsem lažje dosegel če boš pritisnil na avtorja programa, vtičnika ali česarkoli že, da bo njegov program znal prebrati take "anomalije". Ni pa nič narobe s tako pobudo, vendar je potrebno vzeti v obzir faktor samoodločanja, ki gre po navadi po liniji najmanjšega odpora.

[Aleksander]

Zaklade z vsebovanimi formulami in neznankami si ponavadi takšni uporabniki pripravimo že doma in potem na terenu spremenljivkam samo določimo vrednosti. Kompleksnost formule ne igra praktično nobene vloge. Popravljanje formul je manj zoprno kot zapisovanje in računanje na terenu. Mislim, da se bo delež takih geolovcev z leti povečeval. Gotovo se bo k temu prilagajala strojno programska oprema.

[icabrian]

Ravno to sem napisal zgoraj in dodal vzorčno kodo. Programu lahko v HTML komentraju podtakneš podatke v JSON obliki, za ljudi pa pustiš tisto, kar se ti zdi, da jim bolj paše. Opis se ne spreminja, program pa dobi svoje.

Ne tisti JSON, mislil sem, ali bi solver znal iz commenta pobrati formulo, ki bi bila zapisana v stroju prijaznejšem formatu. Da človek vidi a x b, stroj pa ven iz HTML kode izbrska a*b. Glede znaka za stopinje se strinjam, bom bolj pazil in popravil. Pri zapisu formul pa bo imela berljivost za človeka prednost pred aplikacijami. Sem pripravljen kaj skriti v HTML kodo, da bo lažje za solverje, ne zdi pa se mi pametno narediti zaradi solverjev zapis slabše berljiv za ljudi.

A je za to kodo kje razloženo, kaj je kaj?

[bucar]

A je za to kodo kje razloženo, kaj je kaj?

Nisem našel opisa, je bolj v smislu self-explanatory.