한재중 : [CAS18N] CAS18N-EXT-006 (2018-12-05) - Meeting with G3/PXR

Created by 한재중, last modified on 12월 05, 2018

315. 참석자

  • 김주현 (G3)
  • 이형주, 장광호 (픽소니어)
  • 최재승, 한재중 (SI)

316. 일시/장소

  •  13:00 ~ / 픽소니어 서울 연구소 (남부터미널)

317. 회의 내용

논의 주제논의 내용
CDR 준비
  • SI 에서 모두 발표
    • 서브시스템 별 발표 자료는 제공된 템플릿을 기반으로 G3/PXR 에서 준비해야 함 ~
  • 수집시스템 종료 보고와 함께 진행될 예정임
설계서 v0.9 버전
  • G3/PXR 에서  까지 작성하여 SI 에 전달
Product ID (L0F Catalog ID) 논의
  • 수집에서 촬영한 영역에 대해 자동으로 처리한 표준(Shift 0) 제품과 PGR 에 의해 생성된 제품을 구분해서 관리가 필요함
  • 검색주문관리에서는 위의 내용을 알 필요가 없음. Catalog 만 관리하면 됨
  • 배포관리에서는 어떤 주문에 대해 어떤 제품이 배포되었는지 관리해야 하기 때문에 구분된 정보를 알 수 있어야 함
  • 예를 들이 TB_Catalog, TB_Product 를 별도로 관리하고 자료관리가 해당 정보를 기록
표준 Product 관련 논의
  • L1R, L2
  • Shift 0, Default 처리 옵션 (OD/AD)
  • 자료관리에서 관리
  • 그 이외에 배포주문에 의해 생성된 (PGR 에 의해 생성된) 데이터는 임시의 공간에 저장
    • 배포처리에서는 해당 데이터를 이용해서 배포 패키지 생성
    • 임시의 공간에 저장된 Product 는 특정 시간이 지난 후에 삭제됨
    • 자료관리에서는 관리하지 않는 데이터임
촬영주문의 형식
  • 일반 사용자와 기관 사용자가 선택할 수 있는 제품의 처리 옵션이 다름
  • 촬영주문 시, POD/PAD 적용 여부를 사용할 수 있음
  • 이 경우, 수집에서 POD/PAD 를 기다렸다가 제품 생성 시, 적용하여 표준 Product 를 생성해줘야 함
  • 수집 회의 시에 표준 Product 의 기본 옵션은 POD/PAD 적용이었다고 함. 하루 정도 기다리는 것이 큰 문제 없었다고 했다고 함 (by 최재승)
  • 촬영주문에서는 OD/AD, POD/PAD 를 선택할 수 있는 것이 삭제되어야 함
  • Product Type
    • BUNDLE 기본
  • Product Format
    • GEOTIFF 기본
운영자 주문 방식
  • 현재 KARI 운영자는 Catalog 를 검색할 수 있는 기능을 제공받지 못함 (김주현)
    • 그래서 운영자가 Arirang 을 통해 주문을 하고 내부에서 다시 해당 데이터를 처리한다고 함
  • 지금까지 주문처리에서는 지도를 사용하지 않는 것으로 설계를 하고 있었음
    • 운영자 주문 입력 시, 지도가 꼭 필요한지 확인이 필요함
    • 지도를 사용하지 않을 경우, 아래와 같이 진행이 가능함
      • 촬영주문은 Shape File 기반으로 주문 입력
      • 배포주문은 Catalog ID 를 운영자가 알고 있다고 전제하고 해당 Catalog ID 로 주문을 해야 함 (리스트는 제공이 가능함)
        • 또는 Shape File, 촬영 기간, 위성으로 검색 후, 검색 결과 리스트를 기반으로 Browse Image 확인 후, 주문을 넣는 방법이 있음
      • 활용물생산 주문은 Shape File 과 특정 기간을 기반으로 주문 입력
  • 지도를 사용해야 하는 경우, KARI 처럼 운영자가 외부에서 주문을 넣는 방법이 있음
  • 또 다른 안은 운영자가 주문을 넣을 수 있어야 한다는 요구사항을 검색주문관리 쪽으로 브레이크다운 하는 방법
    • 기본설계 내용이 변경되어야 할 수 있음
    • 운영자 주문은 주문처리 쪽에서 바이패스하여 수집으로 전달될 수 있으면 좋음
  • 현재 상태 유지하고 운영자가 외부에서 일반 사용자처럼 주문을 넣는 방법이 있음. 검색주문관리에서 운영자 주문을 식별할 수 있어야 함
  • 행정망/일반망
    • 주문의 ID 형식만 다르게 줘서 주문한 주체가 누구인지 알 수 있어야 함
  • 본 회의에서 최종 결정된 방법
    • 주문처리에서 운영자 주문 입력 기능 구현 (현재 설계대로 지도 없이)
    • 검색주문관리에서 운영자가 주문을 넣을 수 있는 기능 구현
      • 운영자 주문에 대한 처리 흐름 정리 필요
주문에 기록된 주문자 정보 내부 관리 방법
  • 주문처리 쪽에서 관리하는 주문 Table 에 주문을 입력할 때, 주문자에 대한 정보를 어디까지 기록해야 하는가?
    • 주문처리에서는 처리를 위해서는 주문자 정보를 알 필요가 없음
    • 하지만 운영자의 판단을 돕기 위해서 사용자 이름/소속/전화번호가 존재하면 됨
      • SOS → OPS 주문 전달 시, 위의 정보를 포함시켜줘야 함
      • OPS 에서 수동으로 주문을 넣을 경우, 자동으로 운영자 정보가 입력되도록 해야 함. 수정 불가.
주문에 대한 제품 배포 주기
  • 제품 생성이 되는대로 배포
  • 촬영/배포 한 주문에 대해 n 회 배포가 이루어질 수 있음
  • 활용물은 1회 배포
주문의 상태
  • OPS 에서 주문의 진행 상태를 SOS 로 전달해 줌. 완료 정보도 당연히 전달됨
  • OPS 에서 주문의 진행 상태에 대해 '실패' 를 기록할 수 있어야 함

318. AI

319. 다음 회의

  •  14:00 @ SI