팀플) 혜성 로직 짜기.

Encke의 혜성 주기가 3.3년으로 제일 짧다.

이걸로 계산을 해서 실제 다른 데이터와 검증해가면서 정확도를 올리고 다른 혜성들도 테스트 해보면 될듯.

우선은 API 측에서 3년치의 요청을 못받아드릴 수도 있으니까 요청을 해보고 시작하자.

음 아무 문제 없군.

개발 순서

• 가져온 데이터 정리 및 분석:
  • Horizons API에서 가져온 혜성 접근 이벤트 데이터를 기반으로, 필요한 시간, 위치(적경/적위), 거리 등의 데이터를 정리.
  • 데이터를 시간 순서대로 정렬하고, 접근 이벤트를 효율적으로 분석할 수 있도록 해야함.

• 접근 이벤트 계산 로직:
  • 혜성의 거리 변화율(deldot) 등을 이용해서 혜성이 가장 가까워질 때를 찾거나, 특정 위치에서 가시성이 가장 좋은 시점을 찾는 로직이 필요함.
  • 혜성의 적경(ra), 적위(dec) 정보를 통해 관측이 가능한 시간을 계산해야 함.
• 필터링 조건 설정:
  • 사용자가 요청할 때, 가시성이 좋은 시기를 예측하거나 혜성이 관측 가능한 위치로 접근하는 이벤트를 찾아야 할 텐데, 이때 필터링 조건이 중요함. 예를 들어, 태양과의 각도(s-o-t)가 특정 값 이상일 때 혜성이 더 잘 보인다거나, 혜성이 지구와 일정 거리 이내에 있을 때를 관측 조건으로 설정할 수 있음.
• 결과 저장:
  • 계산된 접근 이벤트 정보를 DB에 저장하여, 이후 동일한 혜성에 대한 예측 요청이 들어왔을 때 빠르게 응답할 수 있도록 해야 함. 여기서 신뢰도 정보도 같이 저장.

이렇게 진행할거고. 일단 1번부터 차근차근 해보자.

기존 get_comet_approach_data에서는 Horizon API에서 파싱된 결과를 가져오기만 한다.

그럼 이제 다른 메서드로 데이터 정리와 분석을 하는 로직을 짜보자.

로직을 짜고 확인을 해봤는데

deldot 값과 delta 값이 조금 이상한 것을 발견했다. 소수가 아니다. 그래도 짧은 거리를 찾아오는 것은 잘 작동하네. 이러면 만들었던 데이터 추출, 파싱과정이 이상하다는 뜻이니까 해당 로직을 고쳐보자.

2027-Oct-25 00:00 20 27 03.57 -21 43 17.4 20 28 41.91 -21 37 44.7 3.130519909441 10.4953834 2.91918483834651 37.5088250 92.8611
이게 우리가 타겟을 해야되는 부분인데 여기서 20 28을 넘겨온다. 다른 값으로 잘못 파싱중인거.

"time": f"{parts[0]} {parts[1]}",  # TIME
"ra": f"{parts[2]} {parts[3]} {parts[4]}",  # Right Ascension (RA)
"dec": f"{parts[5]} {parts[6]} {parts[7]}",  # Declination (DEC)
"delta": parts[8],  # Solar distance
"deldot": parts[9],  # Radial velocity
"s-o-t": parts[10]  # Sun-Observer-Target angle

이걸

"delta": parts[14],  # Solar distance
"deldot": parts[15],  # Radial velocity
"s-o-t": parts[16]  # Sun-Observer-Target angle

이렇게 고쳤다.

음 됐구만. 이제 계산 잘 할 수 있다.

근데 여기서 보면 visible_times가 비어있는데 이건 나중에 위치정보를 사용자에게서 받아서 판별해야된다. 이 로직도 분리가 되어야될듯.

암튼 그러면 지금 이렇게해서 받아온 데이터를 저장해 놓는 로직부터 짜고, 그걸 사용하는 식으로 가게끔 만들면 될 것 같다. 기간을 5년으로 늘려봐도 괜찮을듯..?

---

일단은 정확한 가시성 판단을 위해서 위도 경도의 값까지 받게 만들었고,

위도 경도 값까지 잘 받아온다 이제는 가시성 판단의 로직을 정확하게 짜면 된다.

일단 가시성 판단의 로직을 짜긴 했는데,

데이터를 단 하나만 쓰니까 조건에 부합하는 것이 뜰리가 없다.

---

우선 계속 수정중에 있긴한데 가만 생각해보니까 한국에서 관측이 되는지 안되는지 검증할 방법이 없어서 일단은 한국에서 관측 가능성이 제일 근접한 혜성의 정보를 알아봤다.

근데 이 데이터가 내가 지금 파싱하는 형태와 많이 다르고 만들어 놓더래도 이번에 지나가면서 소멸할 가능성이 있는 혜성이라 만드는 의미가 없다.

---

결론

지금 혜성의 로직은 그냥 그대로 두고 (시간이 9시로만 뜨는 것은 수정해야한다.) 제일 가까운 때는 계속 DB에 저장을 시키자. 그리고 요청시 결과는 그냥 이대로 보여줘야할 것 같다.

근데 계속 알아보면서 다른 정보를 알아냈다. 저번에 포기한 유성우 데이터를 구할 수 있을 것 같다.

어떻게 구할건데?

매년 관측 가능한 유성우:

1. 21P/Giacobini-Zinner (드라코니드 유성우) - 매년 10월 초.
2. 109P/Swift-Tuttle (페르세우스 유성우) - 매년 8월 중순.
3. 1P/Halley (오리온자리 유성우) - 매년 10월 중순.
4. 1P/Halley (에타 아쿠아리드 유성우) - 매년 5월 초.

   매년 관측되지 않는 유성우:

5. 55P/Tempel-Tuttle (레오니드 유성우) - 11월 중순, 주기적으로 강한 유성우 발생.
6. 2P/Encke (타우 헤르쿨리드 유성우) - 혜성 접근 시기에 강한 유성우.
7. 8P/Tuttle (우르시드 유성우) - 혜성의 접근 주기에 따라 강도 차이.
8. 73P/Schwassmann-Wachmann (타우 헤르쿨리드 유성우) - 5월 말에서 6월 초, 혜성 접근 시기에 따라 유성우 발생.
   매년 관측되지 않는 유성우와 관련된 혜성들의 주기:

9. 55P/Tempel-Tuttle (레오니드 유성우) - 33.2년.
10. 2P/Encke (타우 헤르쿨리드 유성우) - 3.3년.
11. 8P/Tuttle (우르시드 유성우) - 13.5년.
12. 73P/Schwassmann-Wachmann (타우 헤르쿨리드 유성우) - 5.4년.

이걸 사용해서 혜성은 관측이 되지 않더라도 유성우의 관측에 대한 정보를 뽑아주면 사용가능할 것 같다.

---

일단은 혜성의 로직이 정확하게 되어야하기 때문에 로직이 오류 없이 완벽하게 진행될 때 까지 수정을 해서 결과를 얻어냈다.

그렇게 해서 데이터를 뽑았다.

뽑은 데이터를 대충 보다 보니까. 혜성마다 기준 조건이 달라져야될 것 같다고 생각했다. Encke 같은 경우에는 원래 태양과 인접한 혜성이라서 visible_times 자체가 생성되지 않는다.

반면에 Halley 같은 경우에는 visible_times가 엄청 많이 생성된다. 이를 혜성 각 특성에 맞게 조건을 달아서 DB에 저장해야지 효율적으로 데이터를 꺼낼 수 있을 것 같다.

암튼 최종적으로 뽑아낸 데이터는 이렇다.

조건은 관측가능성이 있는 혜성이 지구와 제일 가까운 날의 데이터를 계산해서 뽑았다. 이제 이 날을 유성우와 혜성을 볼 수 있다는 느낌으로 이해하면 될 것 같다.