함께 알아가는 IT 정보

이젠 혜성 이벤트로직을 만들면 된다. 해당 정보도 이제 호라이즌 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..

지금은 년도중 제일 가까운 날 하루만 반환하는데 이러면 프론트에서 써먹을 소스가 좀 부족할 것 같아서 로직 수정하기로 결정했다.우선은# services/planet_opposition_service.pyfrom datetime import datetimefrom app.services.planet_visibility_service import calculate_planet_infoimport logging# 로깅 설정logging.basicConfig(level=logging.DEBUG, format='%(asctime)s - %(levelname)s - %(message)s')def predict_opposition_events_with_visibility(planet_name, year, latitu..

일단 DB연결 문제를 겪으면서 계속 들었던 생각이 테이블을 행성별로 나눠야할 것 같다는 생각이 들었다.왜?1년이 365일이니까 행성 8개를 저장하면 365 * 8 = 2920 즉, 칼럼이 2920개나 된다.그래서 년도 별로 나누고 행성별로 나눠서 관리하는 편이 용이할 것 같다는 생각이 들었다. 우선은 24년도 데이터를 넣을거고 정상적으로 작동되는 것이 확인되면 매년 말일에 자동으로 테이블 생성, 그리고 1년치 8개의 행성의 데이터를 넣는 로직도 짜야한다. 가 계획이다.일단은 지금 당장 쓸 데이터를 넣어야하니까 테이블을 수정했다.-- 행성 정보 테이블 생성CREATE TABLE planet_info ( planet_code INT PRIMARY KEY, ..

행성의 가시성의 대한 정보는 업데이트 되었다. 이제 행성 대접근을 계산하면 되고, 내 계획은 이렇다.행성 대접근은 따로 만들고, 지구와의 거리가 가장 가까운 시기를 알아낸다.이게 끝이다.그리고 이걸 알아내려면 6개월이나 1년치를 한꺼번에 가져와야되는데 지금 2주치만 요청해도 시간은 꽤 오래 걸린다.Horizon-api에서 가져오는 데이터 량이 많아서 그렇다.그럼 사용사가 요청할 때 마다 한참을 기다려야된다는건데 이러면 안되니까 일단 로직을 제대로 짠 다음 미리 DB에 저장을 해두는 식으로 접근해야될 것 같다.일단은 만들어야지..우선 데이터는 잘 뜬다. 일단 내가 짠 로직을 설명하자면 (과부하 때문에 2주밖에 요청을 하지 않긴했다)요청한 기간 안에서 제일 distance_to_earth 즉, 지구와 가장 ..

우선 나중에 화면에 보여줄 것을 생각해 요청 일자를 로직에 추가했다.다음은 검증해볼시간.뭘 검증하냐?지금 # 가시성 판단 추가 로직 visibility_judgment = "Unknown" if delta 30: visibility_judgment = "Good visibility" elif 1.5 20: visibility_judgment = "Moderate visibility" else: visibility_judgment = "Poor visibility"해당 값을 결과 값에 추가했는데 이게 제대로 작동하는가 검증해보는 것.Mercury (수성): http://localh..

우선 전의 포스팅에 어떻게 정제할지는 생각을 해뒀고, 이제 천천히 구현을 해보면 된다.그렇게 거름망을 만들어서 여러번 테스트를 해봤는데 아무런 데이터도 나오지 않는게 이상해서 공식문서를 좀 더 자세하게 읽어보니까 예측보다는 기록에 중점을 둔 api였다. 이거 지워야겠네..유성우 데이터는 예측하기가 굉장히 어려워서 예측을 중점으로 둔 api는 존재하지 않는 것 같다. 우주 이벤트 관련된 정보를 나는 제공하고 싶기 때문에 유성우가 아닌 다른 대체할 데이터를 만들든 api를 찾든 해야될 것 같은데 우주 이벤트면 뭐가 있을까예측이 가능한가?내가 이제 시간을 허비한 이유는 이 대전제가 틀렸기 때문이였다.그러니까 천문지식의 부재로 내가 추출하고 싶은데이터가 현실적으로 예측이 가능한가에 대한 고민이 조금 부족했던 것..

NASA API 연결하기.데이터에 공신력을 갖기 위해, NASA API 연결을 결정했다.여기서 제일 적절한 것 같은 api는 EONET가 가장 적절해 보인다. 지구에서 관측한다. 자연적인 이벤트를 트랙킹. 이라고 써져 있으니까.그럼 일단 고민하지말고 바로 연결부터 해보자.일단 .env 변수로 API KEY 저장부터 하고,이후에 services.meteor_shower_service.py생성. -> get_meteor_shower_forecast() 작성.routes에 엔드포인트까지 작성했다.일단은 내가 요청할 것이 뭔지 정확히 알아야했다.그래서 읽어봤는데...엄 메테오는 없는 것 같은데.데이터를 다 까봐도 없다.그래서 다른 공신력 있는 정보를 찾아야했다.웹 뒤져보는중..한참 뒤지다보니까 "Global M..