행성별로 대접근 이벤트의 주기가 존재한다. 내가 보여주려던 데이터는 틀린 데이터다. 빨리 알아채서 다행..
행성별 대접근 주기.
- 수성 (Mercury): 약 116일
- 수성은 지구와 매우 빠른 공전 주기를 가지고 있어 자주 대접근합니다.
- 금성 (Venus): 약 584일
- 금성은 약 1년 반마다 지구와 대접근을 합니다. 이 주기는 지구와 금성의 공전 주기 차이에 의해 결정됩니다.
- 화성 (Mars): 약 780일 (2년 1개월)
- 화성은 약 26개월마다 지구와 대접근합니다. 이 시점에 화성은 관측하기에 가장 적합하며 밝고 크게 보입니다.
- 목성 (Jupiter): 약 399일 (1년 1개월)
- 목성의 경우 대접근 주기는 약 13개월 정도입니다. 지구의 공전 궤도와 목성의 공전 궤도 간의 주기적 관계에 의해 결정됩니다.
- 토성 (Saturn): 약 378일 (1년 2주)
- 토성도 대체로 1년에 한 번 대접근이 발생합니다. 다만 토성의 공전 주기가 길기 때문에 대접근 간의 거리 변화가 크지 않습니다.
- 천왕성 (Uranus): 약 370일 (1년 정도)
- 천왕성은 상대적으로 멀기 때문에 대접근 시점의 변화가 크지 않으며, 지구에서 볼 때 약 1년에 한 번씩 대접근을 합니다.
- 해왕성 (Neptune): 약 367일 (1년)
- 해왕성 역시 1년 주기로 대접근을 경험합니다. 다만 해왕성은 너무 멀리 떨어져 있어 대접근의 관측 효과는 다른 행성들에 비해 미미합니다.
- 명왕성 (Pluto): 약 365일 (1년)
- 명왕성은 지구와의 거리가 매우 멀기 때문에 대접근의 의미가 크지 않지만, 지구와의 대접근 주기는 거의 1년입니다.
이렇다고 한다.
그럼 대체적으로 1년주기니까 그게 아닌 행성을 꾸려보면 금성과 화성정도가 되겠네.
그렇다면 금성과 화성의 요청이 들어올 시에는 2년의 데이터를 요청하고 검증해야한다.
데이터 조회 전략.
생각해보면 아마 행성별로 대접근에 AU는 어느정도 정해져 있을 것이다. 지금 로우데이터 전부를 다 조회하려고 시도하면 시간이 조금 소요되는데 여기서 가까운 AU를 어느정도 파악해서 요청시 행성별로 조건을 주면 조금 더 효율적으로 데이터를 찾지 않을까? 하는 생각이 들었다.
# 행성별 대접근 기준 AU 값을 정의하는 매핑 함수
def get_opposition_au_threshold(planet_name):
opposition_au_thresholds = {
"Mercury": 0.30,
"Venus": 0.28,
"Mars": 0.38,
"Jupiter": 4.20,
"Saturn": 8.00,
"Uranus": 18.00,
"Neptune": 30.00,
"Pluto": 33.00
}
return opposition_au_thresholds.get(planet_name, None)
그래서 이렇게 AU의 기준을 정해줬다.
그리고 DB 조회 로직까지 작성을 했고,
여기서 고민이 드는게 화성 금성은 2년의 로우데이터가 필요한데, 행성의 가시성에서 테이블을 사용자가 요청시에 없으면 생성하게끔 해두었다.
이런 로직으로는 대접근 이벤트 조회 요청시에 치명적일 수가 있다. (사실 억지로 엮으려고 했던 이유도 엮지 않으면 치명적이여서 엮으려고 했었다.)
그렇다면 로우데이터를 따로 생성하는 메서드가 필요했다.
주기별로 자동으로 요청하고 DB에 저장하는 자동화 메서드가 필요하다..
데이터 자동 삽입.
매년 1월 1일에 데이터를 자동으로 삽입하게 스케줄러라는 것을 도입하기로 했다.
스케줄러 apscheduler 다운받고,,, freeze했다.
그리고 이제 로직을 테스트용으로 사용했던 planet_event_storage_service.py
에 작성했다.
다 했다. 일단 해당 메서드로 DB 삽입이 가능하니까, 일단은 DB 싹 다 지우고 Postman으로 요청해보자.
하하하하하
하하하하 다 넣었다.
이제 년도 바뀔 때 마다 자동으로 들어갈 것이다.
이제는 대접근 이벤트의 로직을 좀 건들여볼 필요가 있는데 일단은 들어온 데이터를 살펴보았다.
아까 임의로 설정한 AU를 좀 조절할 필요가 있어보였다.
데이터를 전부 다 까보니까 특정 행성은 제일 가까웠던 거리가 점점 더 가까워지는 애들이 있고, 반대로 제일 가까웠던 거리가 점점 더 멀어지는 애들이 있었다.
그래서 이걸 그냥 AU 설정 자체를 느슨한 놈과 빡빡한 놈을 나누어서 표기하고 조회하는게 데이터상으로 보여줄 때 더 좋은 데이터를 보여줄 것 같아서 그렇게 해보기로 결정.
# 행성별 대접근 기준 AU 값을 정의하는 매핑 함수
def get_opposition_au_threshold(planet_name, strict=False):
opposition_au_thresholds = {
"Mercury": (0.56, 0.60),
"Venus": (0.30, 0.50),
"Mars": (0.642, 0.70),
"Jupiter": (4.1, 4.4),
"Saturn": (8.33, 8.66),
"Uranus": (18.40, 18.60),
"Neptune": (28.87, 28.90),
"Pluto": (34.1, 34.8)
}
return opposition_au_thresholds.get(planet_name, (None, None))[0 if strict else 1]
데이터 하나하나 까 보고 조금 더 세밀하게 조절했고,
대접근과 그냥 접근으로 나누어서 보여줄 수 있게 로직을 짰다.
쿼리도 조금 더 디테일하게 요구할 수 있게 바꿨다,
결과를 보면
결과에 따라서 대접근과
그냥 접근으로 잘 나누어 진다.
AU 를 기준으로 조건을 달아줬고 잘 작동한다.
이제 가시성 판단 로직에서 DB조회만 하도록 바꿔주면 될 것 같다.
'Coding History > Team Project' 카테고리의 다른 글
팀플) 별자리 데이터 수정. (0) | 2024.10.19 |
---|---|
팀플) 행성의 가시성 -> DB 생성 로직 삭제, DB 조회만. (가시성 판단 로직 정교화) (5) | 2024.10.18 |
팀플) 행성 대접근 로직 수정. (LIST 반환.. xxx 데이터 간략화 하기, 행성별로 나누자는 생각 도달.) (0) | 2024.10.18 |
팀플) 로우데이터 저장 전략. (0) | 2024.10.18 |
팀플) 행성 대접근 이벤트 만들기. (도커에서의 DB 포트와 서버 이해) (6) | 2024.10.17 |