함께 알아가는 IT 정보

이제는 유성우 데이터 DB 저장과 조회가 될 수 있게 만들면 된다.지금까지 만들어둔 로직은 이제 로우데이터를 생성만 하는 것이고. 메서드를 분리해서 자동으로 로우데이터를 저장하게끔 설계할 생각이다.# services/comets/meteor_shower_info_storage_service.pyfrom apscheduler.schedulers.background import BackgroundSchedulerfrom datetime import datetimefrom app.models.meteor_shower_raw_data import MeteorShowerInfofrom app.services.comets.meteor_shower_info import get_meteor_shower_infofrom..

이게 생각보다 요청이 오래 걸려서 DB에 저장하고 꺼내와서 위치데이터 기반으로 가시성에 대한 계산 로직을 짜야할 것 같았다.그래서 유성우 요청시에 혜성의 데이터까지 표시하도록 한 이유가 바로 DB에 저장하기 위해서 일부러 그렇게 한 것이다.암튼! 이번에는 수동으로 DB에 넣는 로직이 아닌 SQLAlchemy를 써볼 생각이다.이게 그.. Spring에서 JPA 같은 역할을 수행한다고 한다.SQLAlchemy로의 전환은 조금 큰 작업이 될 것 같다. 이전에 행성 DB 저장 로직도 다 고쳐야하고, 기존에 저장해둔 도커 볼륨의 데이터도 지켜야하기 때문에 일단은 백업을 하는 방법부터 알아냈다.docker run --rm --volumes-from -v $(pwd):/backup ubuntu tar cvf /ba..

혜성 접근 데이터 저장:각 혜성의 접근 데이터를 1년 단위로 요청하고, 이를 최대 50년~100년로 DB에 저장할 계획.이렇게 하면 각 혜성별로 50~100개의 접근 데이터가 저장되게 된다. 지금 다루고 있는 혜성이 총 8개이기 때문에 총 400~800개의 접근 데이터가 생김.유성우 가시성 평가에 접근 데이터 활용:저장된 혜성 접근 데이터를 바탕으로 유성우 가시성 평가에 적용.유성우 발생 시기와 혜성 접근 시기를 비교하여 혜성이 가까울수록 유성우 가시성 평가에 높은 점수를 부여함.이렇게 함으로써 가까운 혜성일수록 더 잘 보인다는 점을 반영할 수 있음.가시성 평가 기준 설정:유성우가 발생하는 시기가 반드시 혜성이 지구에 가까이 접근하는 시기와 일치하지는 않지만, 혜성이 지구에 가까운 경우 가시성이 더 좋아..

지금 뽑아놓은 데이터는 나름 의미가 있다. 매년 관측 가능한 유성우:21P/Giacobini-Zinner (드라코니드 유성우) - 매년 10월 초.109P/Swift-Tuttle (페르세우스 유성우) - 매년 8월 중순.1P/Halley (오리온자리 유성우) - 매년 10월 중순.1P/Halley (에타 아쿠아리드 유성우) - 매년 5월 초.매년 관측되지 않는 유성우:55P/Tempel-Tuttle (레오니드 유성우) - 11월 중순, 주기적으로 강한 유성우 발생.2P/Encke (타우 헤르쿨리드 유성우) - 혜성 접근 시기에 강한 유성우.8P/Tuttle (우르시드 유성우) - 혜성의 접근 주기에 따라 강도 차이.73P/Schwassmann-Wachmann (타우 헤르쿨리드 유성우) - 5월 말에서 6..

Encke의 혜성 주기가 3.3년으로 제일 짧다.이걸로 계산을 해서 실제 다른 데이터와 검증해가면서 정확도를 올리고 다른 혜성들도 테스트 해보면 될듯.우선은 API 측에서 3년치의 요청을 못받아드릴 수도 있으니까 요청을 해보고 시작하자.음 아무 문제 없군.개발 순서가져온 데이터 정리 및 분석:Horizons API에서 가져온 혜성 접근 이벤트 데이터를 기반으로, 필요한 시간, 위치(적경/적위), 거리 등의 데이터를 정리.데이터를 시간 순서대로 정렬하고, 접근 이벤트를 효율적으로 분석할 수 있도록 해야함.접근 이벤트 계산 로직:혜성의 거리 변화율(deldot) 등을 이용해서 혜성이 가장 가까워질 때를 찾거나, 특정 위치에서 가시성이 가장 좋은 시점을 찾는 로직이 필요함.혜성의 적경(ra), 적위(dec) ..

뭐 코드를 작성하고 그런게 아니고 계획을 좀 제대로 짜고 데이터의 흐름이나 계산 로직의 계획? 같은거다.혜성 예측데이터 요청 및 계산: 혜성의 예측 데이터를 계산하기 위해 필요한 모든 데이터를 특정 기간 동안 요청하고, 필요한 모든 요소(혜성의 궤도 요소, 접근 거리, S-O-T 등)를 고려해서 계산 시작.시간이 오래 걸리더라도 전체 예측 진행: 이 단계에서 계산이 조금 오래 걸리더라도 괜찮음. 왜냐하면 계산은 주기적으로(예: 1년마다, 혹은 짧은 혜성 주기마다) 이루어지고, 사용자 요청이 들어오는 순간 빠르게 제공할 수 있는 게 핵심.계산 결과를 데이터베이스에 저장: 계산이 끝난 예측 결과를 데이터베이스에 저장해둬. 이렇게 하면, 사용자들이 특정 혜성의 접근 이벤트를 요청할 때 이미 계산된 예측 데이터..

이젠 혜성 이벤트로직을 만들면 된다. 해당 정보도 이제 호라이즌 API 에서 반환 받고, 계산을 하면 된다.우선은 행성에 대한 로직을 짤 때 사용했던 파일에서 혜성에 대한 정보를 가져오기로 헀다.COMET_CODES = { "Halley": "1P", "Encke": "2P", "Biela": "3P"}def get_comet_approach_events(comet_name, date, range_days): comet_code = COMET_CODES.get(comet_name) if not comet_code: return {"error": "Invalid comet name."} # 포맷 전 로그 # print(f"Formatted Date Befo..

행성 데이터를 좀 잘 만들었으니까 별자리 데이터도 좀 더 수정하고 싶었다.결과부터 보면 이렇게 표기되게끔 바꿨다.대충 뭘 했냐면 관측자가 바라보는 곳을 애매하게 지정해서 계산중이였는데 constellation_service에서 가져온 별자리 이름과 적경과 적위를 사용해서 계산하게끔 하고 관측자의 시선도 해당 별자리로 고정시켜서 계산하게끔 바꾸었다.방위에 대한 설정도 해주었다.근데 계산 로직이 좀 많아져서 그런가 데이터를 반환하는데 시간이 조금 오래 걸렸다.이것도 DB에...? ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ 일단은 시간을 줄일 방법을 찾아보자.multiprocessing.Pool찾아보니까 이런게 있네. 계산을 병렬처리 한다고 한다.원래는 별자리를 찾는 로직과, 해당 데이터로 계산하는 로직 두개였는데, 계산쪽에서 너무..

이제 로우데이터는 자동생성하게끔 로직을 만들었으니까.기존의 행성의 가시성에 접근했을 때 DB 테이블 생성과 데이터를 삽입하는 로직은 지우고 데이터 조회만 하면 된다.기존의 DB 테이블 생성, 삽입 로직은 지웠고, 데이터 조회만 남겼다.확인만 해보면 됨.금성에 대한 7일치 데이터화성에 대한 7일치 데이터.근데 좀 이상하다 11시면 해가 져있을 시간인데 visibility_judgment에 대한 데이터가 좀 그렇네. 코드 수정이 필요해보인다.코드 수정후!! 이제 고쳤구만근데 좀 데이터가 지저분해서 몇개 지우고 더 관측에 필요한 데이터를 계산해서 보여주는 로직을 넣고 싶은 마음이 들어서,고도와 방위각을 계산하는 로직을 넣겠다는 결심이 섰다. # 행성의 고도와 방위각 계산 ..

행성별로 대접근 이벤트의 주기가 존재한다. 내가 보여주려던 데이터는 틀린 데이터다. 빨리 알아채서 다행..행성별 대접근 주기.수성 (Mercury): 약 116일수성은 지구와 매우 빠른 공전 주기를 가지고 있어 자주 대접근합니다.금성 (Venus): 약 584일금성은 약 1년 반마다 지구와 대접근을 합니다. 이 주기는 지구와 금성의 공전 주기 차이에 의해 결정됩니다.화성 (Mars): 약 780일 (2년 1개월)화성은 약 26개월마다 지구와 대접근합니다. 이 시점에 화성은 관측하기에 가장 적합하며 밝고 크게 보입니다.목성 (Jupiter): 약 399일 (1년 1개월)목성의 경우 대접근 주기는 약 13개월 정도입니다. 지구의 공전 궤도와 목성의 공전 궤도 간의 주기적 관계에 의해 결정됩니다.토성 (Sat..