TISK HLEDÁNÍ PŘIDAT VZKAZ NÁVŠTĚVNÍ KNIHA - FÓRUM
 
Nejnovější Novější StaršíNejstarší
Jan Cinert (Pondělí 9. ledna 2017)  
Včera mi z Horizons přišla odpověď v podstatě v zápětí, na druhý dotaz odpověď nepřišla. Totéž se opakuje dnes. Tentokrát jsem nejprve zkusil kostel na Děvíně:
Azor - 06:49, 122.28°
Hor. - 06:51, 122.2898°
Cel. - 06:40, 120.34°

Tady by zase byla shoda mezi Azorem a Horizonts v azimutu, ale v minutách je rozdíl -2. Celestials je dost jinde.


ZH (Pondělí 9. ledna 2017)  
Dal jsem do Azoruk jeho pátým narozeninám ;-) odkazy na moji mapu pro bod A či B, dosud tam byly odkazy jen na Google Maps, které neskýtají tolik možností – jako měření azimutů a vzdáleností (dvojklikem se rozšíří info pole), a další mapové podklady.


ZH (Pondělí 9. ledna 2017)  
Date_sunrise už jsme diskutovali několikrát - (např.),
možná je od té doby pokrok, nicméně třeba pro náhodně zvolený rok 1050 to vyplivlo dost chybný výsledek, ostatně jde o čas, ne azimut.
Mimochodem, zenith by měl být nastaven na 90.8333, protože je fakticky Slunce ještě pod obzorem (to si jen tak dělám poznámku).

Jestli není to tvrzení o PHP kvůli takovýmto funkcím, jinak běžné výpočty by snad měly být v pořádku, na rozdíl od javascriptu.

Zkuste kouknout na to převýšení, jestli je to v pořádku.


Franta (Pondělí 9. ledna 2017)  
Já myslím, že Azor je víc než dobrá pomůcka, se kterou se člověk dokáže velmi rychle zorientovat a formulovat nějakou hypotézu. Pokud je to myšleno vážně, což asi Jan Cinert tak myslí, je asi nezbytné opřít "to" o NASA, zvlášť když JPL poskytuje svoji renomovanou výpočetní kapacitu na internetu.

PS: mimochodem, na internetu lze najít, že PHP vůbec není vhodný nástroj pro astronomické výpočty...

"výpočet sunrise" - předpokládám, že je to použití funkce: date_sunrise



ZH (Pondělí 9. ledna 2017)  
První výsledek Jana Cinerta byl zřejmě ještě před tím, než jsem upravil vzorec pro převýšení. Mně taky vychází 0530-Dec-19 05:36,*,r,122.2147, 0.5925, což téměř odpovídá 122.4, které JC vyměřil pro azimut HS.
Mimochodem na dlouhé vzdálenosti je zajímavé, že Google Earth má mapový podklad podle eliptoidního modelu, ale výpočet azimutu podle kulového modelu.

Azor byl původně dělaný podle onoho jednoduchého vzorce z Ministrovy knihy, ovšem byl to jednoduchý oblouk podle myslím kulového modelu, který mj. vypisoval o letním slunovratu dva dny se stejným azimutem, tedy dva slunovraty. Našel jsem asi dva tři dlouhatánské vzorce, které asi měly zohledňovat lépe skutečnost, ale stejně slunovraty nevycházejí přesně, tudíž jsou i odchylky u jiných dnů.
I proto jsem tehdy udělal vstup do Celestial sféry, ale myslím i její tvůrce psal, že tam nejsou uplatněny všechny odchylky, které lze najít v knize Astronomical Algorithms (mimochodem jsem si ji koupil), protože by to server nestačil zpracovat. I kdybych to uměl, Azor to v jednom okamžiku zpracovává 365x, takže je to neřešitelné.
Tady je zajímavý článek, který dokumentuje, jak je to problematické, asi už se to tu kdysi probíralo.

Nezbývá tedy, než využívat Horizons, přičemž můj vklad je onen výpočet převýšení obzoru, to by mohl Franta zkontrolovat, používám jednoduchý arctangens poměru výšky obzoru a jeho vzdálenosti při předpokladu, že je Země placatá, ono zakřivení je předpokládám obsaženo ve výpočtu sunrise.

Úlohu samozřejmě hrají momentální atmosférické vlivy, pro arecho potřeby je to však irrelevantní, jen je nutno počítat s možnou odchylkou kvůli nim.


Franta (Pondělí 9. ledna 2017)  
Mě vychází azimut 122,2


Franta (Pondělí 9. ledna 2017)  
Můj poslední údaj je založen na uložené stránce Hagia Sophia - je tedy včetně převýšení obzoru. Můj první údaj byl s nulovým převýšením, tomu, řekl bych, odpovídá i výsledek Jana Cinerta: 0530-Dec-19 05:30,*,r,121.2344, -0.2164 - viz poslední číslo, záporná altituda, ale (0530-Dec-19 05:33,*,r,19 27 12.61,-22 06 38.0, 121.7233, 0.1848, ). u ZH už má kladné převýšení obzoru.
Z ZH je to ještě se starým zadáním

Date__(UT)__HR:MN, , ,R.A._(ICRF/J2000.0), DEC_(ICRF/J2000.0), Azi_(r-appr), Elev_(r-appr), APmag, S-brt, delta, deldot,

s upraveným
Date__(UT)__HR:MN, , ,Azi_(r-appr), Elev_(r-appr),

parametzry pro azimut a altitudu jsou stejné

Teď odesláno - elevace 0,73 stupně
0530-Dec-19 05:36,*,r,122.2147, 0.5925,

vrátil se mi stejný výsledek jako minule


Jan Cinert (Pondělí 9. ledna 2017)  
Přichází výsledky s jinými minutami: Já - 05:30, ZH - 05:33, Franta - 05:36. Zkusil jsem znova poslat dotaz a čekám tentokrát už půl hodiny a nic.


Franta (Neděle 8. ledna 2017)  
Já jsem vybral stránku
kliknul na datum u označeného slunovratového řádku, v CS jsem doplnit zpáteční adresu a přišlo mi tohle:

0530-Dec-19 05:36,*,r,122.2147, 0.5925,

výsledek odpovídá maximálnímu azimutu mezi došlými daty. V čem je problém?
Je to tedy třetí výsledek?


ZH (Neděle 8. ledna 2017)  
Je tam volba 9 dní/rok.
Docela mě to jednou za čas baví, dělat něco neomšelého.

Ještě zkušenost (i pro sebe pro příště): přijdou mi data v proporcionálním písmu, teda dost nepřehledná, jsou ale v CSV formátu vhodném pro tabulkový procesor jako Excel nebo Libre Office Calc (já Excel t.č. nemám). Data se dají (v Calcu) zkopírovat do schránky a pak volbou "Úpravy/Vložit jinak/Neformátovaný text" nakopírovat do tabulky.


ZH (Neděle 8. ledna 2017)  
Mezitím jsem lépe promyslel zadávání převýšení obzoru (hory), Azor vypisoval několik údajů, ovlivněných refrakcí atd., teď je tam jen prostý geometrický úhel (arctangens), což snad odpovídá tomu, že s refkrakcí počítají už Horizons. Tak proto ten rozdíl.

Zkusím tam dát volbu, zda celý rok, nebo plus minus 4 dny, oboje má své výhody.

Kdysi jsem sepsal tohle, někde v počítači to mám ještě lépe zformulované (to když mě přátelé nutili, abych vydal třetí knížku, ale odešla mi múza...).


Jan Cinert (Neděle 8. ledna 2017)  
Jak píši: V takovém případě..., myslím tu nynější situaci se zohledněním menšího azimutu východu Slunce.


Jan Cinert (Neděle 8. ledna 2017)  
Přátelé, velmi děkuji, že jste se do problému tak zakousli a vyřešili jej. Obdivuji vaše schopnosti. Zkusil jsem postup a na centrum.cz mi přišla odpověď poměrně rychle. Asi záleží, jak jsou zrovna ucpané dráty.

Hlavně mi přišlo: 0530-Dec-19 05:30,*,r,121.2344, -0.2164, takže jiný výsledek, nežli níže uvádí ZH: 0530-Dec-19 05:33,*,r,19 27 12.61,-22 06 38.0, 121.7233, 0.1840. V zadání na Celestial pro Hagia Sophia jsem jen doplnil Zpátečku.

Pokud je mě přišlý výsledek 121.23° správný, liší se od Azoru se 121.54° jen o -0.31°. To by pořád ještě šlo. Dávno jsem si všiml, že mi azimuty kostelů vychází často v intervalu mezi objevením kotouče a polovinou, což je rozmezí 0.27°. V takovém případě by vytyčení azimutu kostelů probíhalo po polovině kotouče až objevení se celého kotouče. To by byl myslím i logičtější postup, celý proces by byl viditelnější. Takže Fred to asi bude mít správně, když i mně by to takto vycházelo. :-) Budu tedy muset v rámci časových možností projít dosavadní výsledky, ale velkou katastrofu v tom zatím nevidím.

Z mého pohledu by stačil rozsah jen +- 4 dny, ne celý rok, už jen kvůli tomu ucpávání drátů. Ale chápu, že Azor je určen i pro jiné. I přes tohle zpřesnění systému pořád zůstává ono přejetí za mezní slunovratové body. Zatím se mi pořád jeví zajímavá níže nadhozená souvislost s přísluním a odsluním. Což může být i souvislost se stanovením narození Ježíše až na 25. 12.


ZH (Neděle 8. ledna 2017)  
OK, dal jsem tam jen quantitu 4 a celý rok.

Jinak rozdíl GEO versus TVH se u sunrise neprojeví, ze známého důvodu.

Projeví se ale elevace obzoru, tedy kopec atd., takže můj prubířský kámen,východ Slunce nad Krkonošemi z Ládví 23.6.2012 vychází docela přesně.


Franta (Neděle 8. ledna 2017)  
a taky mám ve výpisu méně údajů, parametr:
$mail_body .="QUANTITIES = '4,10'n";
*4. Apparent AZ & EL
10. Illuminated fraction
výstup vypadá takto:
Date__(UT)__HR:MN, , ,Azi_(r-appr), Elev_(r-appr), Illu%,
************************************************************
$$SOE
0530-Jan-01 05:34,*,r,120.3683, -0.1645, 100.000,
0530-Jan-01 10:13,*,t,180.1743, 26.0712, 100.000,

tu 10 tam mám kvůli měsíci, takže by možná stačila 4



Nejnovější Novější StaršíNejstarší

PŘIDAT VZKAZ