1071 odpovědí na toto téma

[petulinka1]

A taky by tim zpusobil problemy svymu aktivnimu debuggeru Takze zadny zakodovani se konat nebude

[gord]

zakodovat jde az distribuovanou verzi, ladici to mohou mit nekodovane.

[petulinka1]

A co kdyz budu chtet ladit ostry verze?

[gord]

tak to neni ladeni 

[lusk665]

Jedna z nových věcí ve Statoru je diagram 360° odlovených sektorů. Vím že existuje challenge keš uprostřed republiky, která má podobný cíl, odlovit všechny stupně, a kontrola této podminky je udělaná přes gc-project.

Jen se chci zeptat, jestli je tak jako u zmiňované keše možnost toto na gc.project zjistit na domácí souřadnice... Zkoušel jsem to nějak zjistit, a nedaří se mi to....

Omlouvám se, že to píšu do téma Statoru, ale vlastně díky němu mě napadlo tímto se zaobírat ...

 

Reseni od tarmara je tady http://www.geocachin...czech-republic/ , Misto souradnic Challenge zadej svoje vychozi souradnice. Filtr funguje dobre, jen oproti Statoru se vypocty/vybery rozcházeji u kesi blizkych hranici jednotlivých sektoru, Je to asi jinym zaokrouhlovani vypoctu. 

[lusk665]

Dotaz asi na gorda: bylo by mozno poskytnout cast kodu pro samotny vypocet azimutu pro Challenge? Filtr od tarmara pro vyber kesi v chybejicich sektorech se lehce rozchazi se Statorem a tarmara je ochoten udelat u sebe upravu. Predem diky

[petulinka1]

Straci se preci podivat do zdrojaku Statoru Resp. do modulu FindsByBearing

[tarmara]

nazdarek, resim s Lusk665 uz dva dny proc se mu rozchazi vysledek 

meho query (http://www.geocachin...czech-republic/) a statistik ve statoru. Uz jsem prisel na to, ze se ve statoru pouziva na zaokrouhleni misto fce FLOOR fce (nebo jeji opis pres trunc) CEIL (coz nepovazuju za spravne) ale i tak pry nesedi vysledky. Shanim tedy ve zdrojakach Statoru vzorecek kterym pocitate uhel (angle, bearing) kese od zadanych souradnic.Muzete poradit kde ho najdu....moje aktualni analyza je dole...

 

 

Je treba zjistit jak se plni sloupec Angle v tabulce temp.Stator ktera je zminovana v FindsByBearingChallenge.Stator.pas - nasel jsem jen jeji vytvoreni v StatorGen.Engine.pas ale tam se do Angle sloupce vezme y hodnota z Geocache tabulky a pak se updateuje z nejake bindovane ang promenne....ale tuhle promennou uz jsem nikde nenasel

Tento příspěvek byl upraven od tarmara: 23 červenec 2014 - 8:53

[gord]

temp.Stator obsahuje sloupec angle. Vypocet uhlu a zapis do tabulky probiha v souboru StatorGen.Engine.pas. Na radku 200 se pocita vzdalenost a uhel mezi dvema body (HC a souradnice kese) pomoci funkce 

fd:=PointDistanceEx(fHomeX,fHomeY,fx,fy,fu);

Vypoctene hodnoty se nastavi jako parametr a pak se spusti SQL. Zadna veda

 

EDIT: [pokud si odpoznamkujes radek s Log(...) budes mit vsechny vypoctene uhly v Log souboru a muzes si to pak kontrolovat proti jinym vypoctum.

 

EDIT2: Vypocet probiha bez zaokrouhleni, zaokrouhluje se az pro vypis hodnoty. (Pokud tedy oba mluvime o tomtez.)

Tento příspěvek byl upraven od gord: 23 červenec 2014 - 9:19

[tarmara]

Pokousim se zatim marne najit zdrojak te PointDistanceEx funkce abych zjistil, proc se rozchazi vysledky z SQL query a vystupu ze Statoru. Protoze ten zdrojak bude asi jen primo ve zdrojovych kodech geoget.exe, vznesu jednoduchou prosbu: Muzete mi prosim, drazi vyvojari poslat vzorecek kterym fce PointDistanceEx pocita hodnotu Azimut??

[gord]

To neni moje funkce, tato funkce je ze ScriptEngine, poskytuje mi ji GeoGet. Funkce, jsou popsane na araratu (ale neni tam zadny popis algoritmu ani nic podobneho). Asi bych postupoval tak, ze bych podovnal vypocet tech uhluz z tveho SQL a toho, co bude vypsano v log souboru. Nemyslim si, ze by GG pocital tyto hodnoty spatne. Zkousel jsem vypocty azimutu i na docela velke vzdalenosti a nenasel jsem problem. Pokud vim, pocitaji se vzdalenosti a uhlu na referencnim elipsoidu pro WGS8č. Pocitas je take trak? Nebo je pocitas na kouli? Tam by asi nejaky rozdil byt mohl. (Nevim o jak velkych rozdilech se bavime, netusim, kde a o kolik se vypocty obou algoritmu rozchazeji.)

 

Pro zajimavost muzes zkusit svym algortimem spocitat souradnice kese Look_asova pomsta #1 a pak je muzem porovnat spolu (soukromou postou, abychom nespoilovali).

 

A vubec, nechces se presunout na mail nebo ICQ? Tohle asi je mimo moznost pochopeni bezneho ctenare tohoto vlakna

Tento příspěvek byl upraven od gord: 23 červenec 2014 - 10:39

[kiReGPS]

No jen tak na první pohled bych řekl, že tvoje query počítá vzdálenost sférickou (tj. na kouli). Protože GeoGet má funkci PointDistance pro sférickou projekci, tak se celkem logicky zdá, že PointDistanceEx bude počítána na elipsoidu WGS 84. Výsledky proto nemohou být stejné. Jedině, že bys do SQL zamontoval Vincentyho vzorec...

 

 

EDIT: Byl jsem pomalej. Nemohl jsem najít toho Tadeáše Vincentyho...

Tento příspěvek byl upraven od kiReGPS: 23 červenec 2014 - 9:57

[gord]

Ackoli je tpsano, ze PointDistance vraci sferickou vzdalenost, domnivam se, ze obe funkce pracuji s referencnim elipsoidem WGS 84 (dokud se k tomu nevyjadri Haluma, jsou to jen nase dohady), Obe funkce se lisi jen vracenou hodnotu vypocteneho uhlu.

[gord]

Tak podle vyjadreni Halumy obe funkce pracuji s Vyncentyho formuli, tedy WGS84. Na araratu to opravim, aby nevznikly dalsi dohady.

[HaLuMa]

Ono to nekdy kdysi bylo sfericke, ale uz je to hodne dlouho predelane na toho Vincentyho po WGS84 sferoidu.

[tarmara]

Diky panove za vyjadreni, ja tam mam evidentne kouli a zadny geoid, takze v tom bude asi chybka a rozdil ve vypoctenych hodnotach. Zkusim kouknout na tu Vincentyho formuli a treba se mi ji podari ohnout do SQL.... abych nevymyslel kolo, a HaLuMa se nezlobil, tak bych byl moc rad, kdyby mi ten kousek kodu z GG ktery pocita azimut hodil do SZ....timto povazuji z me strany toto subtema za uzavrene.

[gord]

Nemyslim, ze je to uloha pro SQL, Pokud vim, prochazi algoritmus iteracema pro zvyseni presnosti, to se bude v SQL delat opravdu tezko. Jedine nalinkovat nejakou knihovnu do SQLite.

[kiReGPS]

Diky panove za vyjadreni, ja tam mam evidentne kouli a zadny geoid, takze v tom bude asi chybka a rozdil ve vypoctenych hodnotach. Zkusim kouknout na tu Vincentyho formuli a treba se mi ji podari ohnout do SQL.... abych nevymyslel kolo, a HaLuMa se nezlobil, tak bych byl moc rad, kdyby mi ten kousek kodu z GG ktery pocita azimut hodil do SZ....timto povazuji z me strany toto subtema za uzavrene.

 

Ta poznámka o Vincentyho formuli byla z mé strany trochu zlomyslná, omlouvám se. Dobře vím, že je to iterační výpočet, který nastřelí projekci podle sféroidu a pak ji dost drsným přepočtem iteračně dopřesňuje. Užil jsem si tohoto počítání dosytosti na GC58MX2 (mimochodem doporučuji si vyzkoušet princip luštění). Jak píše Gord, Vincentyho formule pro SQL určitě vhodný postup výpočtu není...

Tento příspěvek byl upraven od kiReGPS: 23 červenec 2014 - 11:03

[tarmara]

JJ, vim, ze to je iteracni postup, ale SQLite umi prilinkovat knihovny s funkcemi a dle googlu jsem nenasel ze by nekdo takovou knihovnu vytvoril....a mozna je to slepa ulicka, mozna to bude zatracene pomale i pro par iteraci....ale nechte me nabit si hubu

[kiReGPS]

Pokud přilinkuješ knihovnu s funkcí, která to výše uvedeným postupem spočítá, pak bys měl dosáhnout správného výsledku. To je asi jediná možná cesta...