을 하기 전에 방위는 계속 해서 쓸 것 같아서 util
로 빼서 새로 만들어서 갖다 쓸 수 있게 했다.
from app.services.directions_utils import azimuth_to_direction
direction = azimuth_to_direction(azimuth)
뭐 이렇게 갖다 쓸 수 있게.. 아니면 8방위에 대한 코드가 별자리에도 행성에도 유성우에도 있을테니까 로직을 짜는 와중에 빼는게 좋겠다고 판단해서 빼줬다.
당연히 기능이 정상작동하는지도 확인했다.
우선 이전에 calculate_altitude_azimuth
고도를 구하는 메서드(방위각 계산 까지 추가함)도 기존에 있었고, parse_ra_dec
적경과 적위를 구하는 로직도 만들어뒀어서 빨리 결과를 뽑았다. 근데 뭔가 부족하다는 느낌이 들어서 달의 위상을 구해서 결과에 대조하면 어떨까? 라는 생각을 갖게 되었다. 그럼 달의 위상을 구하는 로직을 만들면된다.
달이라는 천체는 지구랑 가장 가까운 천체중 하나니까 분명히 skyfield에 존재할 터. 그리고 달의 위상은 지구의 어디에서 봐도 큰 오차 없이 동일하기 때문에 굉장히 쉽게 구해낼 수 있는 데이터다.
그래서 그냥 공식문서 활용하니까 값은 바로 도출해냈다.
{
"date": "2024-10-25",
"moon_phase": 0.7871338491145035,
"phase_description": "Waning Crescent"
}
여기서 이제 고민해야될 것은 조명율을 구하는 로직인데.
그렇게 계산을 하면서 이제 생각을 해본건데 이거 호라이즌 API에 없나..? 확인해봐야지
없다. 조명률을 구하는 로직을 만들긴했는데, 실제 데이터랑 내가 계산해낸 데이터랑 오차가 생각보다 좀 크다.
이를 조금 더 정확하게 하려면 달에 대한 정보를 호라이즌 API에서 가져와서 계산해야될 것 같은데..
난 또 하기 싫다.
달의 위상으로도 얼추 달의 조명률은 직관적으로 알 수 있으니 그냥 생략하자.
라고 생각했는데 잘 보니까 1에서 내가 구한 평균 값을 빼주면 정확도가 올라갈 것 같아서 그렇게 해봤다.
오.. 오히려 조명률의 정확도가 더 올라갔다. 달의 위상은 기록하는 곳이 많아서 23-04-06(랜덤날짜)로 검색해서 조명률 100에 보름달이라는 것을 알아냈고, 그날에 대한 요청을 해봤는데.
음 결과값이 예상한 값이 아니긴한데 얼추 맞긴하다 양쪽 다.
그래도 조금 조건을 다시 확인해봤는데
def get_phase_description(moon_phase, phase_angle_degrees):
"""
달의 위상에 따라 설명을 제공하는 함수
Args:
moon_phase (float): 달의 위상 (0 ~ 1).
phase_angle_degrees (float): 위상 각도 (0 ~ 360).
Returns:
str: 달의 위상 설명
"""
if phase_angle_degrees == 0 or phase_angle_degrees == 360:
return "New Moon"
elif 0 < phase_angle_degrees < 90:
return "Waxing Crescent"
elif phase_angle_degrees == 90:
return "First Quarter"
elif 90 < phase_angle_degrees < 180:
return "Waxing Gibbous"
elif phase_angle_degrees == 180:
return "Full Moon"
elif 180 < phase_angle_degrees < 270:
return "Waning Gibbous"
elif phase_angle_degrees == 270:
return "Last Quarter"
elif 270 < phase_angle_degrees < 360:
return "Waning Crescent"
else:
return "Unknown Phase"
full moon이 딱 180도여야하는건 아무래도 너무 빡빡한 조건 같아서 ==들에 다 오차를 조금씩 주기로 했다.
보정을 하니까 full moon이 반환되네 굳.
보름달에서 뉴문이나 다크문이 나오려면 대략 14~15일 뒤니까. 그것도 요청을 해보면.
오케이 이것도 잘뜬다.
랜덤한 날짜로 한번만 더 해보자.
2018년 6월 17일의 달의 위상은 Waxing Crescent, 그리고 조명률은 32퍼 정도가 된다고 한다.
약간의 차이가 있긴하지만 어찌 됐든간에 하강 초승달에 조명률 2차이니까 이정도면 충분히 쓸만하다고 판단된다.
그럼 이제 유성우의 결과값에 태워보내기만 하면 된다.
오케이 끝..
이러면 이제 슬슬 api 마무리 하고 프로젝트에 어떻게 적용시킬지 생각하면 될 것 같다.
'Coding History > Team Project' 카테고리의 다른 글
팀플) API 서버 배포 (Oracle Cloud 무료 서버 사용) (0) | 2024.10.31 |
---|---|
팀플) 별자리 데이터 검증. (0) | 2024.10.30 |
팀플) 유성우데이터 DB 저장, 조회기능 SQLAlchemy (0) | 2024.10.25 |
팀플) 기존 행성 데이터 DB 저장, 조회기능 SQLAlchemy로 적용해보기. (4) | 2024.10.25 |
팀플) 혜성데이터를 활용해 유성우를 정밀하게 계산하기 위한 전략. (긴 주기의 혜성의 멀어짐과 가까워짐을 판단.) (1) | 2024.10.23 |