Как получить от Skyfield координаты, привязанные к земле?

Недавно я начал использовать Skyfield (python) для поиска (x, y, z) координат вещей в космосе. Теперь я хотел бы преобразовать между координатами, ориентированными на Землю, фиксированными на Земле (вращающимися) и инерциальными (невращающимися) на Земле, поскольку «скорости ракет» иногда могут транслироваться в Интернете в фиксированных на земле (вращающихся) кадрах. Смотрите этот ответ и этот ответ

Это то, что у меня есть до сих пор. Барицентрические положения взяты прямо из Skyfield, но я просто вычитаю положение Земли из положения Луны, чтобы получить инерционное положение по центру Земли - я думаю, что это нормально для неточных результатов, я не знаю, действительно ли это так. легко или если есть что-то тонкое, что мне не хватает.

Тем не менее, мне интересно, существует ли «официальный» фиксированный (вращающийся) кадр Земли, и есть ли у Skyfield метод преобразования в него или в любой вращающийся кадр в целом?

Питон:

from skyfield.api import load, JulianDate

de421 = load('de421.bsp')

earth = de421['earth']
moon  = de421['moon']
slc40 = earth.topos('28.562 N', '80.577 W')

jd = JulianDate(utc=(2015,12, 22, 1, 48, 0))

epos     = earth.at(jd).position.km # barycentric (ICRS) position of earth
mpos     = moon.at(jd).position.km  # barycentric (ICRS) position of moon
slc40pos = slc40.at(jd).position.km # barycentric (ICRS) position of SLC-40

mpos_ec     = mpos     - epos # earth centered (inertial) position of moon
slc40pos_ec = slc40pos - epos # earth centered (inertial) position of SLC-40
Для тех, кто заинтересован: этот вопрос в GIS stackexchange Характеристики различных методов преобразования ECEF в LLA ссылки на этот pdf , где GIS = Географические информационные системы, а ECEF = Earth-Centered, Earth Fixed.

Ответы (1)

Скайфилд ≥1,34

Самые последние версии Skyfield вводят явную itrsсистему отсчета, которая вращается вместе с Землей. Вы можете узнать об этом, начиная здесь:

Скайфилд <1,34

Во-первых: основная проблема с вашей техникой вычитания двух положений заключается в том, что она не учитывает путешествие света во времени. В случае наблюдения Луны, которое вы настроили в своем коде, ошибка составляет всего около 38 км, что вполне может быть в ваших допусках. Способ запросить относительное положение, которое правильно датировано световым временем задним числом, — это observe()метод:

mpos_ec = earth.at(jd).observe(moon).position.km

Во-вторых: вы правы в том, что Skyfield в настоящее время не имеет встроенной первоклассной поддержки системы отсчета, которая вращается вместе с Землей. Я, вероятно, должен добавить один. Тем не менее, обходной путь, который должен немедленно запустить вас, — сообщить Skyfield, что вы хотите наблюдать:

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

Одна хитрость заключается в том, что мы должны сделать вращение сами, потому что, как вы заметили, то, как в настоящее время написано Skyfield, готово применить вращение только в том случае, если оно собирается уменьшить координаты до полярных alt/az для вас. Поэтому попробуйте следующее:

# Create an observer at the center of the Earth,
# rotated zero degrees from the Earth's reference frame:

gcrs = earth.topos(
    latitude_degrees=0,
    longitude_degrees=0,
    elevation_m=-6378136.6,
    )

# Ask where the observer was at a given time:

g = gcrs.at(jd)

# Then ask for a relative position as usual:

p = g.observe(moon).position.km
print p

# Now the tricky part: each observer.at() has
# an attribute `altaz_rotation` which is the rotation
# matrix you want to apply:

print einsum('ij...,j...->i...', g.altaz_rotation, p)

Дайте мне знать, если цифры, которые вы получили, работают! И как только я закончу переписывать систему времени и смогу выпустить Skyfield 1.0, я обращу внимание на то, чтобы сделать эти вычисления немного более удобными.

Большой! Спасибо за ответ плюс подробное объяснение. Я отчитаюсь. Онлайн-документы прекрасно объясняют влияние конечной скорости света на наблюдения, но это нельзя повторять достаточно часто — об этом так легко забыть! Прямо сейчас я рисую и анимирую орбиты космических аппаратов в 3D с помощью matplotlibи Blender(см. это и это )` с разных точек зрения. Нужно помнить, что это разные кадры и луна появится в другом месте!
Я знаю np.einsum, очень популярен для тех, кто знает, как его использовать. Для тех, кто не знаком (например, я), четыре ответа на этот вопрос будут полезны.
Я просто вырезал и вставил einsumпример из собственного исходного кода, я не пытаюсь каждый раз вспоминать, как это работает с нуля. :)
Если вы рисуете вид Солнечной системы «снаружи», то, возможно observe(), это не имеет смысла — люди, наблюдающие за анимацией движения планет, возможно, в которой движется и камера, обычно ожидают увидеть, «где все на самом деле происходит». есть» без какой-либо регулировки светового времени.
Это очень интересный вопрос/проблема для размышлений, и я рад, что вы подняли его! Я упомянул Луну, потому что она была видна со 2-й ступени SpaceX, когда она развертывала одиннадцать спутников Orbcomm-2 (см. этот вопрос и этот GIF ). Для этой «сцены» включение светового времени было бы правильным, и использование g.observe(), надеюсь, было бы достаточно близко для «астрономической полиции» :)
Для тех, кто заинтересован: этот вопрос в GIS stackexchange Характеристики различных методов преобразования ECEF в LLA ссылки на этот pdf , где GIS = Географические информационные системы, а ECEF = Earth-Centered, Earth Fixed.