함께 알아가는 IT 정보

1. /api/constellations (GET)요청 방식: GET필요한 파라미터:lat (필수, float): 위도lon (필수, float): 경도start_date (선택, str, YYYY-MM-DD): 시작 날짜end_date (선택, str, YYYY-MM-DD): 종료 날짜설명: 사용자가 요청한 위도, 경도, 날짜 범위에 따라 해당 위치에서 관측할 수 있는 별자리 정보를 반환한다. 별자리의 가시성도 함께 계산함.2. /api/sunrise_sunset (GET)요청 방식: GET필요한 파라미터:lat (필수, float): 위도lon (필수, float): 경도start_date (선택, str, YYYY-MM-DD): 시작 날짜end_date (선택, str, YYYY-MM-DD): 종료..

컴퓨터로 서버를 지정할까 했는데 아무래도 괜히 또 문제 생길까 무서워서 그냥 Oracle Cloud로 무료로 할 수 있다고 해서 해보려고 한다.계정도 다 만들었고, 신용카드 등록가지 하고 로그인하니까 이런 창이 떴다. 서버는 일본의 오사카에 있는 서버를 골랐다.이런게 떴는데 보안 관련된거라고.여기서 앱 다운 받아서 설정해주면 된다.다하니까 이런 창으로 넘어갔다. 뭔지 하나도 모르겠네일단 나는 API를 배포하려는 것이 목적이기 때문에Cloud-native developer: 클라우드 환경에서 컨테이너와 같이 클라우드 기반 애플리케이션을 배포하고 관리하는 경우에 적합해. 네가 Docker 컨테이너로 API 서버를 배포하려는 경우에 맞는 선택이야.DevOps engineer: 서버 배포 및 운영, CI/CD와..

검증하겠다고 전부터 말을 해놨는데 계속 못갔던게 대전이 그 때 부터 쭉 흐렸다. 이번주 수목이 맑길래..새벽 1시 35분에 나왔다. 이제 성차산을 찍어두고,,갔다왔다.사진이 흔들리긴 했는데 2시 20분 언저리에 도착했고,차안에 노트북으로 2시 35분인 것 확인.남서쪽에 Ari(양자리)를 볼 수 있다는 것도 확인.별이 진짜 잘 보였다. 뭐 당연히 빛이 거의 없는 산골로 들어오기도 했고.. 근데 난 사실 별자리를 볼 줄 모른다.그래서 뭐 어떻게 했냐.앱 다운 받고 남서쪽을 찾아봤다. 다운 받은 앱이 Skyview Lite 라는 앱이였는데 폰으로 내 위치에서 볼 수 있는 별자리를 증강현실로 표시해준다. 그니까 폰을고 이리저리 카메라로 찍드시 비추면서 보면 대강 내가 찾을 별자리나 행성의 위치를 알 수 있다.우..

을 하기 전에 방위는 계속 해서 쓸 것 같아서 util로 빼서 새로 만들어서 갖다 쓸 수 있게 했다.from app.services.directions_utils import azimuth_to_directiondirection = azimuth_to_direction(azimuth)뭐 이렇게 갖다 쓸 수 있게.. 아니면 8방위에 대한 코드가 별자리에도 행성에도 유성우에도 있을테니까 로직을 짜는 와중에 빼는게 좋겠다고 판단해서 빼줬다.당연히 기능이 정상작동하는지도 확인했다.우선 이전에 calculate_altitude_azimuth고도를 구하는 메서드(방위각 계산 까지 추가함)도 기존에 있었고, parse_ra_dec적경과 적위를 구하는 로직도 만들어뒀어서 빨리 결과를 뽑았다. 근데 뭔가 부족하다는 느낌..

이제는 유성우 데이터 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년마다, 혹은 짧은 혜성 주기마다) 이루어지고, 사용자 요청이 들어오는 순간 빠르게 제공할 수 있는 게 핵심.계산 결과를 데이터베이스에 저장: 계산이 끝난 예측 결과를 데이터베이스에 저장해둬. 이렇게 하면, 사용자들이 특정 혜성의 접근 이벤트를 요청할 때 이미 계산된 예측 데이터..