Формулы сферической тригонометрии точные или приближенные ?

[ser100]

Занимаясь вопросом эфемеридной поправки ET-UT для современных теорий и для теорий древних астрономов, я создал еще одну форму для своей программы Solsys7 (скриншот смотрите ниже), где у меня воспроизводится анимация солнечных и лунных затмений и транзита планет по диску Солнца. Проверяя время наступления затмений или транзита планет, я заметил, что в экваториальных координатах по анимационной картинке (нижняя картинка на скриншоте) получаются хорошие результаты, как для современных наблюдений, так и для древних, а в горизонтальных координатах наблюдается какая то странность. Большинство наблюдений тоже хорошо воспроизводилось и в горизонтальных координатах, но иногда наблюдения очень сильно расходились с расчетными данными, которые я получал, наблюдая анимационную картинку затмения или транзита.






Скриншот формы 16 программы Solsys7, где воспроизводится транзит Венеры 8.6.2004 (на нижней картинке анимация в горизонтальных координатах), где точками 0…7 обозначены восемь точек на диске Солнца, координаты которых определены в экваториальной системе координат и затем пересчитаны в горизонтальные координаты. Кружок на диске Солнца это Венера.


В центре картинки я рисовал видимый диаметр Солнца (для солнечных затмений и транзитов), а затем по разности координат (экваториальных или горизонтальных) между центром диска Солнца и планеты или Луны находил положение на картинке центра планеты или Луны и рисовал их видимый диаметр. При этом, первоначально я получал для современных теорий Ньюкома или JPL (Лаборатория реактивного движения – подразделение НАСА) гелиоцентрические эклиптические координаты планет (или в эпохе даты или в стандартной эпохе J2000) для планет и геоцентрические эклиптические координаты Луны по теории Брауна (в эпохе даты), а затем приводил их к видимым координатам, т.е. к наблюдаемым с конкретной точки Земли. Аналогичные преобразования я делал и с расчетными данными, полученными по таблицам древних астрономов (Птолемей, Аль Хорезми, Кеплер и т.д.). На скриншоте в окошках справа отражена последовательность преобразований. Цепочка преобразований получается довольно таки длинной по этому в первую очередь я, конечно же, заподозрил какую то ошибку в коде программы, но проверка (прямое преобразование координат и обратное) показала, что ошибки нет.


Тогда я занялся проверкой стандартных функций преобразования, которые я взял из книги О. Монтенбрук и Т. Пфлегер – Астрономия с персональным компьютером и перевел их с языка программирования Pascal на язык Visual Basic 6.0, а в первую очередь я занялся функцией перевода экваториальных координат в горизонтальные и необходимой для этого функцией расчета Гринвичского звездного времени GMST (в коде функций после апострофа ` идет комментарий к коду).


Private Sub EQU_HOR(ByVal j As Integer)
TAU = ObsLMST - GeoL(j): If TAU < 0 Then TAU = TAU + 360 'часовой угол в градусах
Call EQUHOR(j) 'функция перевода координат из книги О. Монтенбрук и Т. Пфлегер
Call AlfaBetta(15, j) 'находим по декартовым координатам полярные координаты
Azimut(j) = AlfaGR(j): If Azimut(j) > 180 Then Azimut(j) = Azimut(j) - 360
Visota(j) = Betta1
End Sub


Public Sub EQUHOR(i As Integer) 'conversion of equatorial into horizontal coordinates
'аналог PROCEDURE EQUHOR (DEC,TAU,PHI: REAL; VAR H,AZ: REAL);
'(* DEC = GeoB(I) : declination (-90 deg .. +90 deg) *)
'(* TAU : hour angle (0 deg .. 360 deg) *)
'(* PHI = ObsB : geographical latitude (in deg) *)
Dim CS_PHI#, SN_PHI#, CS_DEC#, SN_DEC#, CS_TAU#
CS_PHI = Cos(ObsB / kUgol): SN_PHI = Sin(ObsB / kUgol)
CS_DEC = Cos(GeoB(i) / kUgol): SN_DEC = Sin(GeoB(i) / kUgol)
CS_TAU = Cos(TAU / kUgol)
X(i) = CS_DEC * SN_PHI * CS_TAU - SN_DEC * CS_PHI
Y(i) = CS_DEC * Sin(TAU / kUgol)
Z(i) = CS_DEC * CS_PHI * CS_TAU + SN_DEC * SN_PHI
'POLAR (X,Y,Z, DUMMY,H,AZ)
End Sub


Public Function LMST(MJD As Double) As Double ' рассчитывается GMST в часах
'FUNCTION LMST(MJD,LAMBDA:REAL):REAL; local mean sidereal time
'MJD = JD - 2400000.5
T2 = (MJD - Fix(MJD)) * 24: T1 = (Fix(MJD) - 51544.5) / 36525
LMST = 6.697374558 + 1.0027379093 * T2 + (8640184.812866 + (0.093104 - 0.0000062 * T1) * T1) * T1 / 3600# End Function

К сжалению, проверка показала, что функции дают те же результаты, что и примеры описанные в литературе, например, в книге Jean Meeus – Astronomical algorithmus. В книге даются расчетные топоцентрические экваториальные координаты Венеры на 19:21:00 UT для обсерватории USNO (ObsL= -77,0656 ObsB= 38,9214) - долгота 347,3193 градусов и широта -6,72 градуса при GMST=08:34:56,853. А у меня программа дает расчетные экваториальные координаты – долгота 347,3168 и широта -6,7216 при GMST=08:34:57 (секунды округлены и GMST посчитано без учета нутационной поправки). При этих исходных данных в книге получаются следующие горизонтальные координаты – азимут 68,0337 и высота 15,1249, а у меня программа дает – азимут 68,035 и высота 15,1211. Расхождения получились в пятом знаке, что вполне допустимо при небольших различиях в исходных экваториальных координатах и при отсутствие у меня нутационной поправки при расчете GMST.


Вообще-то проведенная мною проверка была просто шагом отчаяния, т.к. все эти функции я и так многократно тестировал на других формах программы Solsys и никаких замечаний они у меня не вызывали. Но так как полученные мною результаты в экваториальных и горизонтальных координатах сильно отличались (чего не должно быть в принципе) я решил воспользоваться еще и формулами перевода экваториальных координат в горизонтальные и в полярных координатах (приведенная выше процедура EQUHOR производит перевод координат в декартовой системе координат, а потом вычисляются полярные координаты). Я взял стандартные функции перевода (приводятся в любом учебнике) и написал процедуру EQU_HOR2. При этом, т.к. в языке программирования Visual Basic 6.0 нет многих тригонометрических функций (как и во многих других языках), например, нужных мне arcsin и arccos, а есть только arctan (в коде Atn), то мне пришлось написать для них код самому (используя известные тригонометрические преобразования).


Private Sub EQU_HOR2(ByVal j As Integer)
TAU = ObsLMST - GeoL(j): If TAU < 0 Then TAU = TAU + 360 ' TAU часовой угол в градусах
'H=sin(Visota(j)) – временная переменная
H = Sin(GeoB(j) / kUgol) * Sin(ObsB / kUgol) + Cos(GeoB(j) / kUgol) * Cos(ObsB / kUgol) * Cos(TAU / kUgol)
Visota(j) = Atn(H / (1 - H * H) ^ 0.5) * kUgol ' функция arcsin -1...+1
H = Sin(GeoB(j) / kUgol) - Sin(ObsB / kUgol) * Sin(Visota(j) / kUgol)
H = H / Cos(ObsB / kUgol) / Cos(Visota(j) / kUgol) ' H=cos(Azimut(j)) – временная переменная
Azimut(j) = Atn((1 - H * H) ^ 0.5 / H) * kUgol ' функция arccos 0...+1
AZ = Azimut(j)
If AZ >= 0 And TAU <= 180 Then Azimut(j) = 180 - AZ
If AZ >= 0 And TAU > 180 Then Azimut(j) = AZ - 180
If AZ < 0 And TAU <= 90 Then Azimut(j) = -AZ
If AZ < 0 And TAU > 90 Then Azimut(j) = AZ
End Sub


Результаты получились те же самые, что и при преобразованиях в декартовой системе координат, и я был просто в тупике не зная, что можно еще проверить. Тогда я решил просто тупо посмотреть, а как переводятся из экваториальных координат в горизонтальные не только координаты центра Солнца, но еще и восьми точек расположенных на диске Солнца. И тут оказалось, что в каких то положениях Солнца на горизонте точки расположенные по окружности Солнца в экваториальных координатах переводятся в горизонтальные правильно и мы видим ту же окружность, а в каких то положениях мы видим в горизонтальных координатах эллипс. Например, на скриншоте, показан вид Солнца при азимуте 0 градусов (направление на Юг), а при азимутах -90, +90 и +/-180 градусов приведен на рисунке ниже.





Как видим при азимуте +/-180 градусов координаты точек переводятся так, что совпадают с диском Солнца нарисованном относительно центра Солнца, координаты которого тоже пересчитаны в горизонтальные координаты, а при азимутах -90 и +90 градусов у нас координаты восьми точек незначительно отстоят от окружности, т.е. переводятся почти без ошибки. Но в разное время года максимальная ошибка при переводе координат получается при разных азимутах и, например, в декабре она будет максимальной уже не при 0 градусов как летом, а при азимуте +/-180, а в марте и сентябре и при 0 градусов и при +/-180 градусов. Вот только при этом величина максимальной ошибки по видимому радиусу Солнца в марте и сентябре будет только 0,1 градуса, а в июне и декабре уже почти 0,4 градуса, что очень много и сопоставимо с видимым диаметром Солнца (0,5 градуса). И если мы будем обрабатывать данные наблюдений за Солнцем, которые выполнены не по центру диска, а по какому-то его краю, то мы получим очень не точные данные.



Таким образом, я понял откуда у меня получаются разные данные в разных системах координат для затмений и транзитов планет и возникает вопрос. А может быть, формулы сферической тригонометрии являются не точными, а приближенными и при определенных углах дают значительную погрешность, что я и получил. Вот ответ на этот вопрос я бы и хотел получить. Или может быть кто-то знает более точные формулы перевода экваториальных координат в горизонтальные. А если кто-то считает, что у меня в программе имеется какой то глюк, то у меня к нему будет просьба взять экваториальные координаты 8-и точек по окружности Солнца 22 июня в 12 часов местного времени для пункта наблюдения находящегося в северном полушарии, перевести их своими программами или обычным расчетом в горизонтальные и нанести их на рисунок.



Кстати, замеченный мною эффект эллипсности Солнца в горизонтальных координатах можно наблюдать и в культовой программе StarCalc (у меня версия 5.7) если отслеживать движение Солнца при очень большом масштабе (20000%…40000%), как это показано на скриншоте ниже. При этом в настройках для координат лучше выбрать для изображения неба не параллельную, а коническую сетку координат, т.к. при этом на анимационной картинке Солнце будет рисоваться в виде окружности, а его эллипсность можно будет определить по координатной сетке (при параллельной проекции будет и неравномерность масштаба координатной сетки и эллипсность Солнца, что смажет этот эффект). На скриншоте даже визуально видно, что по координатной сетке размер по азимуту примерно в два раза больше чем по высоте, а конкретно по высоте размер будет 67 градусов 17 минут – 66 градусов 45 минут = 32 минуты (реальный видимый диаметр Солнца), а по азимуту 0 градусов 40 минут – (-0 градусов 40 минут) = 80 минут. В результате получаем, что ошибка по видимому радиусу Солнца получается (80-32)/2=24 минуты, т.е. те же самые 0,4 градуса, что я получил по анимационной картинке программы Solsys7.





Таким образом, мы еще раз убеждаемся, что при переводе экваториальных координат нескольких точек расположенных по окружности Солнца в горизонтальные мы получаем не окружность, а эллипс, чего не должно быть в принципе, т.к. при простом повороте системы координат (масштабы по осям остались неизменными) такой эффект не должен наблюдаться. Но, если у Вас при таком переводе координат получится окружность, то Вы обязательно сообщите мне какими формулами Вы пользовались. А, если какая то ошибка имеется в моих рассуждениях, то укажите где у меня ошибка в рассуждениях, по тому, что я, например, не понимаю почему программа StarCalc при использовании функции определения углового расстояния между двумя точками дает по азимуту результат 32 минуты, хотя по координатной сетке между этими же двумя точками мы получили 80 минут. Хотя, быть может, такой проблемы с формулами сферической тригонометрии и не существует и просто не хватает точности вычислений компьютера. Я, например, использую в программе 16 разрядов, а в программе StarCalc, как я догадываюсь, используется 32 разряда, но по грубому прикиду для устранения ошибки в десятых долях градуса хватило бы и 8 разрядов (или я не прав).


С наилучшими пожеланиями Сергей Юдин.

[May]

1) Формулы сферической тригонометрии точные.
2) Не поняла, как вы брали точки на окружности Солнца для перевода их из одной системы координат в другую и что потом сравнивали и в каких координатах.

[ser100]

Сообщение от May

Не поняла, как вы брали точки на окружности Солнца для перевода их из одной системы координат в другую и что потом сравнивали и в каких координатах.

Зная топоцентрические экваториальные координаты центра Солнца, например, 22 июня 2010 года в 12:01:57 для того места, где Вы находитесь (примерно ObsL=45 градусов и ObsB=45 градусов) это будет GeoL=90,929278 градуса GeoB=23,434178 градуса при GMST=03:03:43, зная видимый радиус Солнца Rsol=0,262306 градуса, я вычислил на диске Солнца через 45 градусов (начиная с точки расположенной слева от центра Солнца и по ходу часовой стрелки, как показано на рисунке) топоцентрические экваториальные координаты этих точек. Затем я перевел их в горизонтальные координаты и вывел на тот же рисунок и в том же масштабе, но уже по разности горизонтальных координат этих точек и центра Солнца, которые в горизонтальной системе координат получились Azimut=0,000005 градуса и Visota=68,434178 градуса.




Как видно из рисунка, положение точек 2 и 6 относительно центра Солнца осталось неизменным и в горизонтальной системе координат, а вот остальные точки расположились не на окружности Солнца радиусом Rsol, т.е. не там где мы их должны видеть, глядя на небо в естественной для нас горизонтальной системе координат, а по контуру эллипса. Вот у меня и вопрос - откуда взялся этот эллипс. Причем, для большей наглядности я взял время наблюдения, когда линия пересечения экватора с горизонтом перпендикулярна плоскости высот и по этому высоту центра Солнца можно вычислять не используя сложные преобразования, а просто прибавив к склонению широту точки наблюдения и убрал поправки на нутацию и рефракцию. А, кроме того, у нас на анимации не будет наклона плоскости экватора к горизонту и положения точек в экваториальной и горизонтальной системах координат должны полностью совпасть. Да, еще (для ясности), т.к. экваториальные координаты увеличиваются справа налево, на анимацию я вывожу разницу координат восьми точек и центра Солнца с обратным знаком, т.е. так как это будет в горизонтальной системе координат.

С наилучшими пожеланиями Сергей Юдин.

[May]

я вычислил на диске Солнца через 45 градусов (начиная с точки расположенной слева от центра Солнца и по ходу часовой стрелки, как показано на рисунке) топоцентрические экваториальные координаты этих точек

Только не говорите, что вы их вычислили так, как будто вы работаете с плоской фигурой, а не с проекцией диска Солнца на сферу.

Вообщем так... Границы диска Солнца - это малый круг на сфере. Точки на окружности Солнца должны лежать на одном малом круге (МК), полюсом которого является центр Солнца, а радиус МК равен радиусу Солнца. Как получить координаты границы диска Солнца, то есть точки МК?
1) Создаем МК с полюсом в полюсе системе координат, это просто: если посмотреть на глобус, то круг широты 89.737694(=90-0.262306) - это малый круг нужного нам радиуса. Координаты точек, лежащих на этом круге, мы вычислить можем спокойно. Вычисляем.
2) Но нам нужен МК с полюсом в произвольной точке, в нашем случе в точке с координатами GeoL=90,929278, GeoB=23,434178. Для этого вектора точек малого круга, вычисленного ранее, нам нужно повернуть на угол 90-GeoB вокруг оcи Y и на угол GeoL вокруг оси Z. Получаем точки на границе диска Солнца.
3) Вычисляем угловое расстояние между точками МК и центром Солнца. Оно равно радиусу Солнца, никакой эллиптичности.

Прицепляю для примера программку на VB, которая считает точки МК и угловое расстояние в экваториальных и азимутальных координатах. Нет там никакой эллиптичности. Как это корректно нарисовать - не могу сейчас придумать, но точно не на плоскости, т.к. проекция сферических фигур на плоскость искажает расстояния.

[ser100]

Сообщение от May

Только не говорите, что вы их вычислили так, как будто вы работаете с плоской фигурой, а не с проекцией диска Солнца на сферу.

Вообще то я так не говорил и вычислял их как сферические (так проще), но вполне мог их вычислить и как координаты плоской фигуры (так сложнее) по тому, что погрешность от такого вычисления будет просто мизерной (где-то в 10-м или 15-м знаке, что соизмеримо с точностью вычислений компьютера). Но речь у нас идет не о 15-м знаке, а о 2-м или 3-м, по этому не будем отвлекаться на этот нюанс, тем более, что при работе с полярными координатами ни Вы, ни я не использовали расстояние от Земли до Солнца, которое нужно для вычислений координат плоской фигуры. По этому, давайте перейдем к существу дела, а начать я хотел с благодарности за оказанное внимание к моей проблеме и особенно поблагодарить за программу, т.к. не так уж и часто при ответах мне пишут специальные программы, где можно говорить уже о конкретных цифрах. А так как по образованию я инженер-механик, то предпочитаю один раз увидеть, чем сто раз услышать. Вот и для Вашей программы я немного доработал код, чтобы и полученные Вами результаты можно было тоже увидеть.


Исходники программы и исполняемый файл прикрепляю к сообщению. Исполняемый файл это для тех, у кого нет языка Visual Basic 6.0, и они могут запускать его на исполнение, также как и все остальные программы, двойным кликом мышки по нему. Вот только, если у Вас старая версия Windows и в ней установлена виртуальная машина для 5-ой версии языка (файл msvbvm50.dll), то Вам надо будет поместить в папку WINDOWS/system32 файл msvbvm60.dll (скачать можно с моей домашней страницы http://ser.t-k.ru из раздела Программы). А кроме графики в код Вашей программы я еще добавил и свой код расчета экваториальных координат на диске Солнца и перевод их в горизонтальные. Выбирая нужный переключатель May или Ser в рамке Автор можно произвести расчет или по Вашим формулам или по моим и сравнить на двух рисунках (слева в экваториальных координатах, а справа в горизонтальных), что у нас получилось. Сразу скажу, что по Вашим формулам получается эллипс с еще большим эксцентриситетом, чем у меня.


Да у Вас даже в экваториальных координатах получился небольшой эллипс, по этому я не знаю зачем Вы вычисляли геоцентрические координаты МК, а затем переводили их в топоцентрические. Ведь 2/3 Вашего кода из основной программы можно выкинуть и сразу определить топоцентрические экваториальные координаты 8-и точек на диске Солнца.

For i = 0 To 7
DugaEcv = i * 45
RA2(i) = RASun + RadiusSun * Cos(DugaEcv * qq)
DEC2(i) = DecSun + RadiusSun * Sin(DugaEcv * qq)
Next i

А затем перейти именно к тому, что нас и интересует, т.е. к переводу экваториальных координат в горизонтальные. А, если учесть, что для определения дугового расстояния между центром Солнца и 8-ю точками на его диске в горизонтальных координатах Вы применили просто умопомрачительную формулу

cosa = Sin(DEC1 * qq) * Sin(DEC2 * qq) + Cos(DEC1 * qq) * Cos(DEC2 * qq) * Cos((RA1 - RA2) * qq)
Angle_Distance = ArcCos(cosa) / qq

то сразу становится ясно, что Вы математик, т.к. так запутать вопрос можно только с очень хорошей математической подготовкой. А ведь можно было просто написать

DugaEcv = Sqr((RASun - RA2(i)) ^ 2 + (DecSun - DEC2(i)) ^ 2)
DugaAz = Sqr((AzSun - Az(i)) ^ 2 + (HSun - H(i)) ^ 2)

Вы, конечно же, будете возражать, что эти формулы справедливы только для плоской фигуры, но при тех разностях в углах, что мы используем, вполне можно считать, что синус угла равен углу. Кстати, очень интересно узнать как это по Вашей формуле для точки №2, которая имеет у Вас высоту примерно равную высоте Солнца (68,4327 и 68,4342), а азимут -0,7138 (у Солнца -0,0003) получилась разность в координатах 0,2623. Ведь при одинаковой высоте двух точек длина дуги между ними будет равна разности координат по азимуту, т.е. будет 0,7135. По этому, я сделал в программе еще одну кнопку dAlfaSer, нажав которую можно определить длину дуги между центром Солнца и точкой по моим формулам (используя полученные Вами координаты).


Я не собираюсь оспаривать справедливость Вашей формулы, для определения дуги между двумя точками и возможно, она полностью соответствует всем постулатам сферической тригонометрии. Но тогда объясните мне как изобразить на проекции неба горизонтальные координаты 8-и точек, полученные в Вашем расчете, чтобы, глядя на эту проекцию, я видел круглое Солнца так, как я его вижу, глядя на небо, а не эллипс, как это получается на рисунке справа. Да у меня на рисунке используется параллельная проекция неба, а не коническая, как это должно быть, но в таком случае на рисунке должна получиться фигура Солнца напоминающая грушу, а не эллипс, как это получается. Да и форма этой груши будет почти круглой и отклонения составят сотые или тысячные доли градуса, но никак не 0,4 градуса (а по Вашим расчетам вообще получается 0,45). Т.е. опять таки мы упираемся в вопрос о точности формул сферической тригонометрии. Хотя, я по прежнему не отбрасываю и версию о неточности вычисления тригонометрических функций при каких то определенных углах.


С наилучшими пожеланиями Сергей Юдин.

[May]

Но речь у нас идет не о 15-м знаке, а о 2-м или 3-м, по этому не будем отвлекаться на этот нюанс

Ваша эллиптичность появилась именно потому, что вы почему-то считаете, что сферичностью можно пренебречь. Видели ли вы, как на глобусе координатная сетка сужается по направлению к полюсам? При этом изменяется масштаб по долготе. Небесная сфера - то же глобус, там тоже чем дальше от экватора - тем сильнее изменяется масштаб по прямому восхождению. Если при визуализации координат этим сужением сетки пренебречь, то появляется эллиптичность по прямому восхождению. Когда рисуют проекцию сферической системы координат на плоскость, прямоугольную систему координат не используют, она неадекватна ситуации: ошибки вылезают сразу, стоит чуть отползти от экватора, и порядок ошибки отнюдь не в 10-15 знаке. Загляните в 12-ую главу того же Монтенбрука. В этой главе описывается, как измеряют координаты на фотографиях неба с учетом того, что была сфотографирована не плоскость, а кусочек сферы. У вас обратная задача: вы хотите нарисовать картинку, какую вы бы получили при фотографировании неба. Координатное преобразование туда-обратно известно, это вообще азбука астрометрии.

Да у Вас даже в экваториальных координатах получился небольшой эллипс, по этому я не знаю зачем Вы вычисляли геоцентрические координаты МК, а затем переводили их в топоцентрические. Ведь 2/3 Вашего кода из основной программы можно выкинуть и сразу определить топоцентрические экваториальные координаты 8-и точек на диске Солнца.

Я не переводила геоцентрические координаты в топоцентрические. Я решила, что координаты Солнца у вас уже топоцентрические, с ними и работала. Вычисление МК - это всего лишь вычисление границы диска Солнца в сферической системе координат. Я не могу сказать Бейсику Form1.picture1.Circle(X,Y), меня от этого, извините, коробит. Потому что Circle - это рисование плоской окружности, а я хочу корректно нарисовать сечение сферы плоскостью - малый круг на сфере. Координаты этого круга и вычисляются.

А, если учесть, что для определения дугового расстояния между центром Солнца и 8-ю точками на его диске в горизонтальных координатах Вы применили просто умопомрачительную формулу
cosa = Sin(DEC1 * qq) * Sin(DEC2 * qq) + Cos(DEC1 * qq) * Cos(DEC2 * qq) * Cos((RA1 - RA2) * qq)
Angle_Distance = ArcCos(cosa) / qq
то сразу становится ясно, что Вы математик, т.к. так запутать вопрос можно только с очень хорошей математической подготовкой. А ведь можно было просто написать
DugaEcv = Sqr((RASun - RA2(i)) ^ 2 + (DecSun - DEC2(i)) ^ 2)
DugaAz = Sqr((AzSun - Az(i)) ^ 2 + (HSun - H(i)) ^ 2)

Это умопомрачительная формула вообще-то самая главная в сферической тригонометрии . Именно так измеряют расстояния между двумя точками на сфере - по дуге большого круга, проходящего через эти точки. Забудьте теорему Пифагора, он с плоской геометрией баловался, а вы на сфере развлекаетесь.

Кстати, очень интересно узнать как это по Вашей формуле для точки №2, которая имеет у Вас высоту примерно равную высоте Солнца (68,4327 и 68,4342), а азимут -0,7138 (у Солнца -0,0003) получилась разность в координатах 0,2623. Ведь при одинаковой высоте двух точек длина дуги между ними будет равна разности координат по азимуту, т.е. будет 0,7135.

Длина дуги была бы равна разности координат, если бы обе точки лежали на экваторе системы координат. А вне экватора масштаб по одной из координат изменяется. Это изменение масштаба можно учесть путем умножения разности азимутов на косинус высоты, но угловое расстояние вы все равно не получите, потому что угловые расстояния меряются по дуге большого круга; если измерять разность азимутов - будет длина дуги малого круга .

Прицепляю вариант программы, в котором все ваше я не трогала, а для своего блока сделала свою графику (Module3), в которой используется сферическая проекция на плоскости. Обратите внимание на координатную сетку, по прямому восхождению и азимуту масштаб не такой, как по склонению/высоте, это эффект сферичности. Причем в азимутальных координатах сужение сетки видно уже хорошо и глазками, потому что высота 68 градусов - это намного ближе к полюсу, чем склонение в 23 градуса.

[ser100]

Сообщение от May

Длина дуги была бы равна разности координат, если бы обе точки лежали на экваторе системы координат. А вне экватора масштаб по одной из координат изменяется. Это изменение масштаба можно учесть путем умножения разности азимутов на косинус высоты, но угловое расстояние вы все равно не получите, потому что угловые расстояния меряются по дуге большого круга; если измерять разность азимутов - будет длина дуги малого круга .

May, огромное спасибо за помощь в решение моей проблемы.

И хотя, я уже сам (после вчерашнего сообщения Вам) стал догадываться, что видимая длина дуги параллели на поверхности Земли между двумя меридианами при увеличение широты уменьшается и даже набросал код для учета этого эффекта при анимации в программе Solsys7, но Ваше решение, конечно же, круче. А я просто ввел коэффициенты для вывода на картинку в параллельной проекции неба координат по прямому восхождению и по азимуту.

kMFequ = 1 / Cos(DecSun * qq)
kMFhor = 1 / Cos(HSun * qq)

Picture1.Circle ((RaSun - Ra2(i)) / kMFequ, Dec2(i) - DecSun), 0.005, RGB(0, 0, 250)
Picture2.Circle ((Az(i) - AzSun) / kMFhor, H(i) - HSun), 0.005, RGB(0, 0, 250)

Да, мое решение примитивно и дает погрешность, но использовать Ваше решение именно в программе Solsys7 я, наверное, не буду. Дело в том, что в программе у меня воспроизводится не просто картинка, а анимация, т.е. объекты на картинке движутся, и Ваш код надо будет значительно усложнить. А, учитывая то, что у меня в программе несколько тысяч строк кода и сотни переменных, мне бы не хотелось добавлять туда еще несколько десятков переменных и более сотни строчек кода. Я ведь уже сейчас не помню всех переменных в своей программе и, когда приходится возвращаться для модернизации к формам программы, которые я писал давно, то я долго-долго изучаю свой же код, а потом вношу в него изменения.


Да, и потом, угловое расстояние между двумя точками мне вычислять не надо, т.к. в программе, например, начало Солнечного затмения я определяю чисто визуально по моменту касания дисков Солнца и Луны. По этому, меня вполне устроит при анимации учет коэффициента широты при выводе координат центров объектов по долготе на картинку с линейной сеткой координат и с одинаковым масштабом по осям. Да, при этом будет какая то погрешность (особенно при больших высотах) от замены конической сетки на параллельную, но на небольшом участке неба (около одного градуса по долготе и по широте) эта погрешность будет не большой. А учитывая, то, что и солнечные и лунные затмения, а также транзиты планет по диску Солнца происходят тогда, когда все они незначительно удаляются от эклиптики, то и в экваториальных координатах они будут все наблюдаться при изменение склонения на +/- 23 градуса, и нелинейность в координатах будет не большой.


Вот в горизонтальных координатах в местах наблюдения близких к экватору погрешность от замены конической сетки на параллельную будет уже значительной. Но, т.к. у меня в программе анимация выводится или в экваториальной или в горизонтальной системах координат, то всегда можно уточнить результат, полученный в горизонтальных координатах, в экваториальных координатах. И потом, если мы даже возьмем широту места наблюдения 24 градуса и произведем на программе TestSun3 вычисления сначала с переключателем May, а потом Ser2, то мы не увидим на картинке, где будут изображены точки и по вашему и по моему расчету, очень больших отличий в координатах.


Да, и потом, эта форма 16 является у меня в программе вспомогательной, т.е. почти демонстрационной, то и сильно усложнять код для этой формы не очень хочется. Ведь основное назначение программы создание реальной теории планет, а не смоделированной, как все современные теории, и затем нахождение по вековым смещениям параметров планет скорости распространения гравитации. Вот на формах, отвечающих за эти действия, я, конечно же, не допускаю таких погрешностей, как на форме 16 и, если там требуется усложнить код хоть в два раза, то я это делаю. По этому, еще раз спасибо за помощь и, если мне потребуется в программе на основных формах Ваш код, то я им обязательно воспользуюсь.


P.S. Прикрепляю исходники и исполняемый код программы TestSun3, где я добавил к своему предыдущему расчету (переключатель Ser1) расчет с учетом масштабных коэффициентов по долготе (переключатель Ser2) и сохранил код Mayв программе TestSun2. А, если у Вас не запускаются на исполнение мои файлы TestSun.exe и TestSun3.exe или файл MayTestSun2.exe (компьютер выдает ошибку 13), то измените настройки на форме Язык и региональные стандарты в Панели управления. Конкретно жмете на вкладке Региональные параметры на кнопку Настройка и на вкладке Числа в окошке Разделитель целой и дробной части заменяете точку на запятую или наоборот. Я, например, использую запятую, а May точку и, по этому, прежде чем запустить ее программу TestSun2.exe я тоже меняю запятую на точку.


С наилучшими пожеланиями Сергей Юдин.

[May]

Да, мое решение примитивно и дает погрешность, но использовать Ваше решение именно в программе Solsys7 я, наверное, не буду.

Для рисования ваше решение приемлимо, тут я не спорю.

А, если у Вас не запускаются на исполнение мои файлы TestSun.exe и TestSun3.exe или файл MayTestSun2.exe (компьютер выдает ошибку 13), то измените настройки на форме Язык и региональные стандарты в Панели управления

Совет хотите? Сделайте автоматическую обработку значений текстовых окон: заменять запятые на точки. Зависимости от настроек Виндов не будет.
Вот так:

...
RaSun = Razdilitel(Text4.Text)
....

Public Function Razdilitel(s As String) As Variant
 Razdilitel = Val(Replace(s, ",", "."))
End Function

Точка в качестве разделителя дроби Бейсику более родная, ее он всегда поймет, даже если в настройках Виндов стоит запятая.

[ser100]

Сообщение от May

Совет хотите? Сделайте автоматическую обработку значений текстовых окон: заменять запятые на точки. Зависимости от настроек Виндов не будет.

Совет, конечно же, хочу, а еще я хочу еще раз поблагодарить Вас за очень компетентную помощь в решение моей проблемы с видимым изображением Солнца. Да, эта замена разделителя мелочь, но иногда от таких мелочей зависит очень многое. По этому, я обязательно постараюсь использовать этот Ваш совет в своей работе с программами.

С наилучшими пожеланиями Сергей Юдин.