'전체보기'에 해당되는 글 1600건

  1. 2021.11.26 코로나 자가격리 면제 체험기
  2. 2021.11.19 우즈베키스탄 현지 유심카드 사용기
  3. 2021.10.23 OGC내의 개념적 모델 활용에 대한 토론
  4. 2021.05.30 Epub 에디터 Sigil 투토리얼
  5. 2020.12.19 JSON 스키마 이해하기
  6. 2020.12.19 JSON 스키마
  7. 2020.12.19 JSON 위키
  8. 2020.09.25 AHG 5 "자동 문서화" 특별 그룹
  9. 2020.01.10 UML 모범사례
  10. 2020.01.10 ISO/TC211 HMMG 위키
  11. 2019.10.11 공간정보표준과 기술기준
  12. 2019.03.05 INSPIRE 데이터 사양 개요
  13. 2018.12.21 INSPIRE 개요
  14. 2018.12.04 INSPIRE 란
  15. 2018.08.09 제품사양서, 품질평가, 메타데이터
  16. 2018.06.20 UML로부터 GML Schema 및 지형지물 카탈로그 제작방법
  17. 2018.06.18 ShapeChange를 이용하여 UML 모델에서 XML 스키마 생성하기
  18. 2018.06.17 ISO TC211 표준 저장소로부터 UML 모델 가져오기
  19. 2018.06.12 Enterprise Architect로 공간정보표준 클래스 다이어그램
  20. 2018.06.05 공간정보 응용스키마 만들기
  21. 2018.05.27 공간정보 유통과 표준에 대하여
  22. 2018.05.15 ISO/TC 211 공간정보 표준 가이드
  23. 2018.04.20 기어360 파노라마 경험담
  24. 2018.04.06 360 파노라마 카메라의 시차(Parallax)
  25. 2018.04.02 360VR 액션캠 비교
  26. 2018.03.30 XML 스키마 라이브러리 설계(Designing XML Schema Libraries)
  27. 2018.03.30 XML Schema 의 이해
  28. 2018.03.26 자동360VR 서비스 소개 - CUPIX.COM (3)
  29. 2018.03.22 XML Schema 간단 가이드
  30. 2018.03.19 XML 네임스페이스의 이해
기타/여행기2021. 11. 26. 18:32

올해 국토교통부에서 발주한 공적개발원조(ODA: Official Development Assistance) 사업과 관련해서 세번째 우즈베키스탄을 다녀왔습니다.

우즈베키스탄은 변이 바이러스로 인해 위험국가로 지정되어 있습니다. 그런데, 거의 모든 사람이 마스크를 끼는 우리나라와는 달리 그 나라에서는 마스크를 끼는 비율이 그다지 높지 않습니다. 그나마 처음 갔을 때는 한 30%정도 끼고 다니는 것 같더니, 이번에는 10%도 안되었습니다. 우즈베키스탄에서는 하루에 1천명정도 감염된다고 하는데, 우리나라처럼 철저한 추적조사를 하지 않기 떄문에 훨씬 많은 사람이 감염되었을 거라고 추정하는데, 우리 일행이 만난 공무원들도 마스크를 전혀 끼지 않았습니다. (처음 방문했을 때는 몇명 끼고 있었는데, 이번엔 정말 아무도 안끼더군요) 

첫번째 출장은 6월로 총 14일간의 일정이었습니다. 그때 국토부 담당자께서 우리 일행이 귀국했을 때 자가격리하지 않도록 해주겠다하여 서류를 제출했지만, 우즈베키스탄에서 변이 바이러스가 발생하는 바람에 승인을 받지 못했고, 그래서 꼼짝없이 14일간 자가격리를 해야 했습니다.

그때는 델타변이가 문제가 될 때 즈음이라 출장가기 직전에 잔여백신으로 미리 백신을 한 번 맞고 출국을 했습니다. 한번이라도 맞아둬야 혹시 감염이 되었을 경우에도 증상이 완화된다고 알고 있었기 떄문입니다.

해외를 다녀오려면 출발전에 PCR 검사를 받고 영문 음성확인서를 받아야 비행기 탑승이 가능하고, 해외에서 귀국하기 전에도 PCR 음성확인서를 받아야 합니다. 공항에서 나와서는 대중교통을 이용하지 못하고, 방역 택시를 타고 이동해서 보건소에 들러 PCR 검사를 받고 집으로 가서 자가격리를 해야 하고요, 자가격리가 끝나기 하루전에 최종적으로 다시 PCR 검사를 받아야 하고요. 따라서 총 4번에 걸쳐 PCR 검사를 받아야 하는데, 물론 항상 음성만 나왔습니다.

두번째 출장은 9월말이었습니다. 백신을 두번 다 맞은 상태였지만, 그때는 상황이 변하지 않았기 때문에 자가격리 면제신청 자체를 하지 않았고, 총 10일간의 출장후 14일간 자가격리하였죠. 물론 PCR 검사는 역시 4번 받아야 했구요.

이번 세번쨰 출장은 11월 중순에 출발해 오늘 아침에 도착한 일주일간의 일정이었습니다. 그런데, 백신 접종률이 70%를 넘어가 방역조치가 완화되면서 다시 자가격리면제 신청을 헀고, 이번에는 신청이 받아들여졌습니다. 아래가 격리면제서입니다. 귀국하기 2-3일 전 우즈베키스탄 대사 명의로 자가격리면제서를 받아서 편한 마음으로 비행기를 탈 수 있었죠. 비행기를 내리자마자 전철을 타고 집에 가야겠다... 계속 방역택시만 탔으니, 이번에는 대중교통으로 귀가해야지 하고 다짐했었습니다.

자가격리 면제서

입국 심사 동안에는 아무 문제가 없었습니다. 그냥 내라는 서류 주니까 여권에 스티커를 붙여줬고, 그래서 안내하는 대로 따라서 전철을 타러 갔습니다. 그리고 열차가 도착한다고 삐리리거릴 때 모르는 번호로 전화를 받았습니다. 이게 악몽의 시작이었습니다. 우즈베키스탄은 위험국가라서 바로 귀가를 할 수 없고, 임시격리시설에서 PCR 검사를 받고 결과가 나온 뒤 방역이 되는 교통수단으로 귀가를 해야 한다는 것이었습니다. 결국 열린 전철문을 뒤로 하고 길을 되짚어 출국 게이트로 가서... 함께 출장을 간 일행들이 억류?? 되어 있는 곳으로 갔습니다.

10여분이 지나고 나서 버스를 타고 임시격리시설로 이동했습니다. 신세계 백화점에서 멀지 않은 곳에 있는 소테츠호텔즈더스프라지르 서울명동이었죠. 크기는 비즈니스 호텔 수준으로 아기자기 하지만 싱글침대 두개랑 화장실이 있는 정도였습니다. 서울 시내 한복판에 있어, 아마도 코로나 사태전에는 외국인 관광객을 대상으로 짭짤하게 영업을 했을 듯 싶은 호텔이었습니다. (현재는 완전히 격리전용으로 사용되는지 휴업중으로 나옵니다.)

소테츠호텔즈더스프라지르 서울명동 위치

도착하니 정말 갑갑해 보이는 방역복을 입고 있는 방역요원이 간단히 안내를 하고, 각자 방을 하나씩 배정받았습니다. 절대로 밖으로 나와서는 안된다는 다짐을 받았고요. 처음에는 당일로 검사 결과가 나와서 그날 저녁 귀가할 수 있다고 해서 짐도 안풀었는데, 검사 결과가 늦게 나와서 다음날 8:30에 방역택시를 타고 귀가하라더군요... 뭐... 그래도 그 정도는 참을만 했습니다.  빨리 집에 가고 싶기는 하지만, 어쩔 수 없다는 심정이었죠.

그런데... 잠시 후, 제가 사는 구청 담당자가 연락이 오더니 우즈베키스탄은 11월 자가격리 면제가 안된다고 집에 돌아가서 다시 격리를 해야 한다는 청천벽력같은 소리를 하는 것이었습니다. 아래가 내세운 근거였습니다. 국가 사업때문에 출국했고, 국토부/외교부로부터 격리면제서를 받았다고 해도 막무가내였습니다. 이탈을 하면 고발을 하겠다는 말도 들었습니다.

열좀 받았습니다. 국토부/외교부가 서류를 잘못 발급한 건가, 공항 검역 요원들이 처리를 잘못한 건가... 아무리 생각해도 말이 안되는 상황이었거든요. 차라리 자가격리 면제가 안된다고 했다면 공항에서 방역택시를 타고 집으로 갔지, 왜 임시 격리시설까지 와서 고문을 당하겠냐고 항의해도 마찬가지였죠.

그래서 먼저 여기 격리시설 상황실에 전화를 했습니다. 자기네는 모른다고 하더군요. 당연하겠죠. 그래서 알려준 1339 질병관리청으로 전화를 했습니다. 상담원이 몇가지를 물어보더니, 자기는 잘 모른다고 알아보고 전화를 준다고 했습니다. 얼마후 온 소식은 자가격리 면제 불가랍니다. 물론 근거는 위에 있는 사이트와 동일하고요. (제가 그때는 열받은 상태라 기억을 못했는데, 공항 방역도 질병관리청 소관일텐데, 왜 현장과 다르게 처리하느냐고 물어봐야 했네요.) 좀더 더 자세히... 이 말이 안되는 상황을 설명하면 다시 알아보겠다고 하는데, 잠시후에는 불가. 그래서 높은 분 연결해 달라고 했더니 결국 불가라고 하더군요.

그런데... 저하고 함께 출장을 가서 함께 격리되어 있던 (물론 얼굴은 못보는) 동료들에게 연락을 해보니, 모두 해당 구청으로부터 연락을 받았고 다 격리 면제로 처리되었다고 하더군요. 참... 어이가 없었습니다.  그래서 다시 우리동네 구청에 연락을 했습니다. 자세히 설명하니 보건소에 알아보겠다고 하더니 잠시후 자가격리 면제라고 다만 사람이 많은 곳으로는 되도록 가지 말라고 하더군요. 헐... 처음에 저에게 전화를 했던 그 구청 공무원 덕분에 거의 한시간을 혼자 열받아했던 거였습니다. 

제가 도움을 받은 동료에게 감사 인사를 하고 넋두리를 했습니다. 그런데 그 분은 내일 아침이 아니라 오늘 밤에 나간다고 하더군요. 그래서 상황실에 연락을 해봤죠. 그랬더니... 검사결과는 11시쯤 나온다고 하고 12시에는 나갈 수 있다고 해서 당연히 방역택시 예약을 변경했습니다. 

ㅎㅎㅎㅎ 그래서 이제 몇시간 후면 집에 갈 수 있습니다. 날라갈 것 같애요. 그런데... 처음 저에게 연락을 했던 구청 공무원과 질병관리청 담당 팀장은 어떻게 하는 게 좋을까요? 혹시 이 글 읽으시면 댓글로 의견 부탁드립니다.

민, 푸른하늘

 

Posted by 푸른하늘 푸른하늘이

댓글을 달아 주세요

기타/여행기2021. 11. 19. 20:09

올해 우즈벡으로 세번째 출장왔습니다. 제가 수행하고 있는 국토교통부 발주 ODA 사업 때문입니다. 저는 전체 사업중 아주 작은 일부만 담당하고 있는데, 다른 교수님들은 모두 자가격리 때문에 출장이 힘들어서 할 수 없이 제가 세번다 출장에 따라오게 되었습니다. 이번 마지막 출장은 정말 오기 싫었는데 할수 없이... ㅠㅠ

출장 혹은 여행 올때 챙겨야 할 것중 가장 중요한 중 하나가 핸드폰 로밍입니다. 요즘 연결이 끊어지면 엄청 힘들잖아요. 맨 처음 출장 올 때는 당연히 통신사 제공 로밍을 사용했습니다. 하루에 1만원 정도로 기억합니다만, 통화/문자/데이터가 대부분 충분하게 사용할 수 있습니다.

두 번째 출장 올 때는 통신사 제공 무료 로밍을 사용했습니다. 속도가 100kbps 정도이고 대략 카톡 사용할 정도라고 했는데, 어차피 WIFI 도 중간중간 있을테니 그냥 견뎌보자 하는 마음이었습니다. 그 결과.... 한마디로 힘들었습니다. 문자는 문제가 없는데 이미지는 아주 느려서... 전송중 에러가 발생하기 일쑤였습니다. 다시는 경험하고 싶지 않은 정도 라고 말씀드릴 수 있겠네요. 

그런데, 같이 출장 온 동료중 한분은 처음부터 현지 U-sim 카드를 사용하고 있었습니다. 저는 불편할 것 같기도 하고, 제 핸드폰에 USIM을 갈아끼우면 전화/문자가 아얘 연결이 안될테니 사용하기 힘들다고 생각했었죠. 그런데... 가만히 생각해보니, 저는 해외 나올 때마다 핸드폰을 하나더 가지고 다닌다는 게 생각났습니다. 제가 삼성 기어360을 사용해 360도 파노라마 사진을 촬영하는데, 이게 예전 삼성 핸드폰에만 연동하기 때문에(신형 삼성 핸드폰은 안드로이드 보안 정책이 바뀌어서 안된답니다.ㅠㅠ) 여분으로 꼭 챙겨두고 있기 때문입니다.

아니... 그렇다면 여분의 핸드폰에 현지 USIM 사드를 꽂고 사용하면 되겠네? 

유레카!!!!

왜 예전엔 생각을 못했는지 저도 이해가 안갑니다만, 어쨌든 이번 출장에는 우즈벡 현재 USIM 카드를 사용하기로 결정했습니다. 그래서 도착한 다음 날, 예전부터 현지 USIM 카드를 사용해왔다는 동료분과 함께 USIM 카드를 구입하러 나섰습니다.

구입은 어렵지 않았습니다. Beeline이라는 우즈벡에서 제일 큰 통신사 대리점? 에 찾아가서, 영어는 할 줄 모르는 직원을 배정받았어도 핸드폰 보여주고 "유심"이라고만 하니 다 알아듣고 처리해 주더군요. (반드시 여권을 챙겨가야 합니다!!!) 가격은 2만숨. 우리나라 돈으로 2천원 정도입니다. 우리나라 통신사 바꿀 때 유심비를 7000원 받은데, 그것도 안되는 돈으로 총 3GB 데이터를 사용할 수 있게 된 겁니다. 정말 싸네요. ㅎㅎ 다음부터는 (적어도 저개발국에 갈 경우에는) 현지 USIM을 적극적으로 사용해야겠다고 결심했습니다.

우즈베키스탄 유심 USIM 카드


그런데... 문제가 발생했습니다. 저는 아무 문제가 없는데, 같이 간 동료분이 아무리 폰을 리부팅해도 안된다는 메시지만 뜨는 겁니다. 그래서 영어가 조금 되는 지원부? 직원에게 물어봤는데... 핸드폰이 락이 걸렸다는 겁니다. 지난 번 출장때도 사용했는데 무슨소리냐? 그럼 지난번 USIM 카드에 충전해서 사용하면 되느냐? 여러가지로 물어보니, 핸드폰 자체에 락이 걸린거라, 자기네는 해결할 수 없고 센트랄 오피스에 가서 락을 풀어야 한다는 거였습니다.

그래서 할 수 없이 "Yandex Go" - Uber 비슷한 앱입니다. - 로 택시 아닌 자가용을 호출해서 37000 숨(3700원)을 주고 찾아 갔습니다. 그런데 아무리 봐도 Beeline Central Office 는 없고... 대신 Central Post Office 그러니까 중앙 우체국만 있더군요. 센트랄 오피스라고 해서 통신사인줄 알았더니 우체국.... 저 혼자였으면 포기했을 것 같네요.\

아무튼 그렇게 들어가서 보니... IMEI를 등록해야한다는 거였습니다. 제 핸드폰에 온 문자를 살펴보니 한달 내? 로 IMEI를 등록해야 한다는 내용이 있더군요. 그런데 같이 간 동료분은 그걸 무시하고 등록을 하지 않았기 때문에 핸드폰에 락이 걸린 거였구요. 

머.. 그래서 등록했습니다. 저는 54000숨, 같이 간 동료분은 67000숨을 내고 등록했습니다. 다음번 우즈벡을 오게 되더라도 문제 없을 것 같습니다. 다시 오게 될 가능성은 매우 낮은 것 같지만요. ㅎㅎㅎ

결국... 한달 3GB 무선 데이터 사용에 20000 숨 + 54000 숨 해서 약 7400원으로 사용하게 되었네요. 저는 생각지도 않게 54000 숨을 추가 지출한 셈이지만, 그래도 다른 방법보다는 매우 저렴하다는 걸 아실 수 있을 겁니다.

누군가... 현지 USIM을 사용할 경우, 이런 과정이 필요할 수도 있다... 는 걸 아시고 (다른 나라는 IMEI 등록이 필요 없을 수도 있지만요) 시행착오를 줄였으면 하는 마음으로 기록 남깁니다.

아래는 오늘 등장한 장소를 표시한 지도입니다. 참고하시길~~

민, 푸른하늘

Posted by 푸른하늘 푸른하늘이

댓글을 달아 주세요

공간정보/표준2021. 10. 23. 22:59

관련 용어

  - 개념적 모델 : 정보교환을 촉진하기 위한 공통 개념 및 그 관계에 대한 설명.
  - 논리적 모델 : 물리적 산물을 생산하는데 사용될 수 있는 인터페이스/데이터 모델의 추상 표현
  - 물리적 모델 : 구현 가능한 산물

개념적 모델링의 장점

  - 구현 주도의 표준과 독립적으로 개념에 관한 합의를 도출한다.

  - 개념과 그 의도를 소통할 수 있다. 이는 인코딩을 읽는 것보다 쉽다.

  - 다양한 구현간의 호환성을 보장하는데 도움이 된다.

현재 OGC내 개념적 모델 상황

- OGC 내에 개념적 모델링에 관한 요구가 존재한다. , 범위와 요구사항은 불명확하다

- OGC 표준에 개념적 모델의 포함 여부는 전적으로 제안팀 혹은 SWG에 달려있다.

- 모델을 기술하기 위한 개념적/논리적이라는 용어는 많은 경우 합치되거나 상호 교환되어 사용된다.

- 일부 표준은 (특히 CityGML 3.0) 규정적인 UML 모델을 가지고 있다.

- 제공되는 모델은 반드시 접근 가능한 것은 아니며, 따라서 원래 의도만큼 유용하지 않다.

- 걱정스럽게도 사용 가능한 UML 모델중 일부는 구성의 관점에서 정확하지 않으며, ISO TC211에서 온 다른 모델, 지원 모델과 반드시 조화되는 것은 아니다.

현재 OGC는 물리적 모델이 중심이므로, 인코딩에 초점이 맞춰져 있다. 과거에는 XML로만 표현되어서 문제가 없었으나? 현재는 JSON, YAML 등 다양한 인코딩이 필요하다. 따라서 개념적 모델을 분리할 필요가 있다. 이렇게되면 개념적 모델을 통해 관련 표준간에 의미론적으로 조화가 가능하게 된다.

- SOS(Sensor Observation Service) 표준은 개념적/논리적/물리적 모델을 가지고 있다.

- OWS ContextXML, JSON으로 변환하는 모델이 있다.

- O&W(https://www.ogc.org/standards/om)CDB(https://www.ogc.org/standards/cdb)도 비슷한 접근법을 가지고 있다.

- Testbed-16에서는 MDA 방식을 고려중이다.

UML은 객체지향이나, JSON YAML은 아니기 때문에 모델링중 타협이 발생한다.
개념적 모델에 물리적 구현을 위한 세세한 내용을 넣은 것이 논리적 모델인가?

추천사항

- 개념적 모델과 논리적 모델이라는 용어를 잘 정의하고 적절하게 사용하는 것이 좋다.

- 개념적 모델이 가치를 더할 경우, 표준에 추천되는 것이 좋다.

- 객체, 관계, 구조를 기술할 때, 개념적 모델은 UML 클래스 다이어그램이 좋다.

- 적절하다면 MDA를 사용하는 것이 좋고, 적어도 구현자를 위한 선택이 되어야 한다

- MDA는 새로운 표준과 새로운 구현에 유용하다.

- SWG DWG를 지원하기 위해 새로운 개념 모델링 그룹을 설립하는 것이 좋다.

 

이 글은 OGC에서 발행된 Conceptual Modeling Discussion Paper 에서 제가 필요한 부분만 요약한 것입니다.

21-041r2+-+Conceptual+Modeling+Discussion+Paper+(Architecture+DWG).pdf
0.95MB

Posted by 푸른하늘 푸른하늘이

댓글을 달아 주세요

기타/웹 2.02021. 5. 30. 23:53

이 절에서는 여러분의 첫번째 EPUB 이북을 생성하고, Sigil 사용법을 배운다.

Sigil의 기능에 대한 자세한 사항은 "기능" 장을 참고하라.

먼저 EPUB를 만들 때 무엇이 필요한지에 대해 간략하게 알아보기위해, 여러분이 해야할 작업을 순서대로 나열하면 다음과 같다.

  • (EPUB 문서가 없을 경우) 문서를 HTML로 변환하여, Sigil로 불러들인다.
  • 저자(Author), 제목(Title)을 비롯한 자세한 사항을 입력한다.
  • 표지 그림을 추가한다.
  • 목차(Table of Contents)를 생성한다.
  • 생성한 이북이 EPUB 표준에 적합한지 검증한다.
  • Sigil에서 형태 등 모든 것을 테스트한다.
  • 실제 이북 리더에서 테스트한다. - 어떤 리더에서는 작동되지만, 다른 리더에서는 작동되지 않는 경우가 있다.

 

EPUB이 어떤 건지도 모르겠고, Sigil을 테스트해보고 싶다면 먼저 Sigil User Guide를 다운로드 하고 Sigil로 열어보라.(이 문서도 Sigil User Guide의 일부임)

 

EPUB 이란?

EPUB 이북을 생성하고 싶다면, 먼저 EPUB이 무엇이고, Sigil을 사용하면 무엇이 좋은지 알아보는 것이 좋을 것이다.

EPUB은 책을 표시하기 위한 표준 파일 포맷이며, Sigil은 EPUB을 생성하는데 사용되는 프로그램이다. Sigil를 사용하면 여러분이 워드프로세서로 생성한 책을 읽어들여, 표준 EPUB 파일로 변환할 수 있다. 이렇게 간행된 파일은 이북 리더에서 읽을 수 있다. 또한 기존의 EPUB 파일을 정리하거나 포맷을 바꾸는데도 사용할 수 있다.

EPUB 파일을 얼마나 깨끗하게 정리할 지는 자신에게 달려있다. 그냥 이북의 포맷만 맞추는 정도라면 Sigil을 사용해서 금방 이북 리더용으로 변환할 수 있다. 하지만, 출판을 위해 포맷을 정리할 경우라면, Sigil을 사용해 이북에 필요한 모든 자세한 사항을 쉽게 변경할 수 있다.

일반적인 워드프로세서의 문서를 편집할 경우, 대부분 파일이 1개일 것이다. 이 파일에는 문서에 관한 모든 정보가 포함된다. 하지만, EPUB은 약간다르다. 1개의 파일에 모든 정보를 담는 대신, 각 장, 이미지, 목차 등 문서를 구성하는 각각의 부분을 별도의 파일로 저장한다. 하지만, 이처럼 여러개의 파일을 다른 사람과 공유하기는 쉽지 않으므로, 실제로는 확장자가 .epub인 하나의 압축 zip 파일로 저장한다. 즉, EPUB 파일은 여러분의 책을 구성하는 모든 파일을 포함하는 zip 파일일 뿐이다.

Sigil은 EPUB 파일을 열고 생성할 수 있으며, EPUB에 포함된 모든 파일(본문, 목차 등)을 편집하고, 재배열하고 형태를 바꿀 수 있다.

자신의 문서를 Sigil에 복사하거나 불러들이면, EPUB 파일의 일부가 된다. 책을 Sigil에 저장하면, 문서는 EPUB 파일로 저장된다.

참고로, Sigil은 예전 EPUB 2 표준 또는 새로운 EPUB 3 표준 모두를 지원하도록 설계되어 있다. 오래된 이북 리더들은 EPUB 2 만 지원하지만, 새로운 EPUB 3 버전에 Guide와 NCX만을 추가하고 EPUB 2 기능에는 제한함으로써, EPUB 3는 완전한 하위 호환성을 갖는 EPUB 3 파일을 생성함으로써, 모는 이북 리더에서 잘 작동할 수 있다.

EPUB 3 이북은 오른쪽방향(Left-To_Right) 및 왼쪽방향(Right-To_Left) 문서를 지원하며, 오디오, 비디오, 내 외부 자원 등을 지원할 뿐 만 아니라, 멀티미디어 오버레이, Themantic role labelling, 대화식 기능을 위하여 일부 javascript까지 지원 함으로써 더 나은 접근성을 지원한다.

파일 준비

이미 EPUB 파일이나 HTML 파일이 있다면, 혹은 Sigil 에서 문서를 직접 만들 예정이라면 이 단계를 건너 뛰어도 된다.

워드 프로세서로 생성한 문서를 사용해 EPUB 문서를 만들 경우, 가장 먼저 해야할 일은 자신의 문서를 HTML로 변환하여 Sigil로 읽어 들이는 것이다. 일부 프로그램에서는 문서를 EPUB 파일로 생성할 수 있다. HTML 출력을 정리하는 기능이 있는 애드온이 있는 프로그램도 있다. HTML을 사용할지, EPUB을 사용할지 (혹은 일반 Text를 사용할지)는 자신의 프로그램에 달려있다. 여러가지 방법을 테스트해봐서 가장 최적의 방법을 찾아야 한다.

HTML 파일이 깨끗하게 정리되어 있을 수록 EPUB으로 변환하기 쉬우며, 여러 장치에서 올바르게 표시될 가능성이 올라간다. 문서 형태 작업시 스타일을 사용하는 것이 좋으며, 예쁜 치장이나 배치는 삼가하는 것이 좋다.
EPUB 파일이 인쇄 책과 비슷하게 보일 것이라는 기대는 버려라. EPUB은 사용자들이 책의 형태를 마음대로 바꿀 수 있도록 설계되어 있다.

Sigil은 이러한 변환과는 관련이 없지만, 파일을 Sigil로 변환할 때 필요한 조언을 나열한다.

워드 문서

MS Word 에서 File->Save As Filtered HTML 메뉴를 사용하라 아니면 MS Word Macro @MobileRead를 사용하라.

이 두가지 모두 MS Word에서 HTML로 내보낼 때 발생하는 추가 코드의 양을 줄이는 것으로, 여러분의 HTML 파일을 Sigil 에서 편집할 때 더 깨끗하고 간단해 진다. MS Word는 (별로 필요하지 않아 언젠가는 지우고 싶어할) 여분의 코드를 엄청나게 많이 추가하므로, 가능한한 코드를 깨끗하게 만들 필요가 있다. Word 또는 어떤 다른 워드 프로세서를 사용하더라도, 일부분을 강조하거나 큰 폰트를 사용하는 등 따로따로 편집하는 것이 아니라, 스타일을 사용해야 한다. EPUB에서도 스타일이 매우 중요한 개념이기 때문이다.

인터넷에는 MS Word 파일을 EPUB 포맷으로 변환해주는 사이트가 많다. 아래는 몇몇 예시이다.

Microsoft 와 Apple용으로 제작된 무료 앱도 많다.

LIBREOFFICE ODF/ODT

LibreOffice 앱은 MS Word와 마찬가지로 ODT 파일을 html로 저장하는 기능이 있다. File->Save a Copy(단, 필터를 HTML Document (Writer) (.html)로 설정) 또는 File->Exprot(단, 필터를 XHTML(.html, .xhtmml)로 설정)

EPUB 용으로 사용할 경우, Save a Copy 명령을 사용하는 것이 좋다. Export 명령보다 깨끗한 결과물을 만들어 내며, 문서 형태를 위한 데이터가 적기 때문이다. Save a Copy 명령은 또한 이미지를 링크로 만들지만, Export는 이미지 데이터를 파일내에 포함(embed)시키기 때문이다.

특별히 EPUB과 관련된 정보는 존재하지 않지만, LibreOffice 온라인 문서는 여기를 참고하라.

DOCXIMPORT 플러그인

MS Word 파일에서 직접 EPUB 문서를 생성하려면, DiapDealer에서 개발한 DOCXImport 플로그인을 사용할 수 있다. 이 플러그인을 추가하면, 어떤 docx 문서를 html로 Sigil에 내보낼 수 있다. DOCXImport 플러그인 매뉴얼을 참고하라. (플러그인 설치는 Manage Plugin 장을 참고하라)

참고: 이 플러그인을 사용하면 새로운 EPUB이 생성된다. Sigil에서 기존의 EPUB 문서가 열려있는 상태라면, 이를 대체해서 저장되지 않은 작업은 사라진다.

이 플러그인을 실행하려면, Plugins->Input->DOCXImport 메뉴를 클릭하면 된다.

파일을 선택하기 전, EPUB의 버전을 선택하거나, 자체 Style Map 혹은 StyleSheet를 사용할지를 선택할 수 있다.

그 다음 "DOCX File to import"을 클릭하고 변환하고자 하는 DOCX 파일을 선택한다.

현재 작업내용이 대체된다는 경고가 나타난다.

이제 파일이 변환되고 Sigil에서 편집할 수 있다.

텍스트 파일

텍스트 파일은 특별히 HTML로 변환할 필요가 없다. Sigil은 .txt 파일을 직접 열 수 있기 때문이다.

텍스트 파일의 경우, 단락사이에 빈 줄이 있어야만 Sigil이 별도의 단락으로 구분할 수 있다.

텍스트 파일은 EPUB으로 변환하기 좋지 않지만, 불필요한 HTML 태그가 잔뜩붙어 있는 포맷보다는 더 낫다. 특히 다른 포맷을 사용할 때 많은 문제가 있었다면 텍스트 파일이 편할 수 있다. 깨끗한 문서에 스타일을 추가하는 것이, 변환된 파일을 정리하는 것보다 빠를 수 있다.

기타 포맷

LibreOffice를 비롯한 기타 수많은 워드프로세서들도 HTML로 저장하거나 내보내는 기능이 있으며, 심지어는 EPUB으로 저장하는 기능이 있는 경우도 있다. MS Word와 마찬가지로 인터넷에서 다양한 정보를 찾을 수 있을 것이다.

Calibre와 같은 소프트웨어를 사용하면 다른 포맷도 HTML이나 EPUB으로 저장할 수 있다. Calibre의 경우, 대부분의 이북 포맷을 처리할 수 있고 많은 플랫폼상에서 동작하며 이북 라이브러리가 내장되어 있다. 아울러 Pandoc의 경우, 문서 변환 전용 어플리케이션으로서, EPUB2, EPUB3, docx, odt, 기타 다양한 Markdown 변종을 포함한 엄청나게 많은 문서 포맷을 지원한다. Pandoc은 무료, 오픈소스, 다중 플랫폼 앱으로서, Haskell(GHC)로 작성되어 있다.

참고로, 자동으로 파일을 변환하면, 필요 없는 코드들이 많이 추가된다. 개인적인 목적으로 변환할 경우에는 크게 문제가 되지 않지만, 전문적인 목적으로 변환하거나, EPUB에 쓸데 없는 코드를 가능한 한 줄이려면  자동 변환을 하지 않는 것이 좋다.

Sigil은 EPUB 포맷 외에도 HTML과 Text 파일 불러오기를 지원한다(HTML의 경우 이미지링크, CSS, 미디어파일 포함). 다른 포맷으로부터 변환하는 것은 상당히 전문성이 필요하므로 외부 도구를 사용하는 것이 바람직하다. MarkDown, Kindle, docx, 기타 포맷을 직접 읽어 들일 수 있는 Sigil 용 플러그인도 존재한다.

Sigil로 파일 열기

HTML 또는 EPUB 파일이 준비되었다면, Sigil로 불러와야한다. EPUB 파일이 있을 경우에도 여기에 있는 내용을 따라하면 Sigil에 대해 빠르게 파악할 수 있을 것이다.

EPUB 파일을 사용하려는 경우, Sigil로 열기전 미리 백업해두는 것이 좋다.

Sigil 시작

Sigil을 시작하면 아래와 같이 여러개의 윈도로 구성된 스크린이 나타난다.

왼쪽 "Book Browser"윈도에는 EPUB에 포함된 모든 파일이 나타나고, 가운데에는 현재 선택된 파일의 코드를 수정할 수 있다.

아래는 EPUB 파일을 읽어 들였을 때의 모습이다.

Book Browser 윈도에 있는 파일명을 더블 클릭하면 이 파일이 열린다.

파일 불러오기

Sigil에 HTML이나 EPUB 문서를 불러오려면, 아래 아이콘을 클릭하거나, File->Open (Cntl+O)를 선택한다.

그 다음 파일 매니저에서 원하는 파일(예: testbook.html)을 선택한다. 그러면 해당 파일이 "Book Brower" 윈도내의 "Text" 폴더 내로 들어가고, 가운데 있는 Code View 윈도에 그 파일이 열린다. 

이제 HTML 파일이 EPUB 파일의 일부가 된다. 즉, 이제부터의 편집은 HTML 파일 자체가 아니라, EPUB 문서를 편집하게 되는 것이다. 아울러 Sigil에서 파일을 열면 "Book Browser" 윈도내에서 볼 수 있는 것처럼, EPUB 포맷에 필요한 여러가지 다른 파일들이 추가로 생성된다.

불러오는 파일에 이미지나 스타일시트가 포함되어 있는 경우, Sigil은 이들도 열어서 적절한 파일로 저장한다. Sigil에서 파일을 변환하거나 EPUB 파일을 여는 경우, 필요한 파일을 추가하거나, 기존의 파일들을 표준 폴더 명에 재배치할 수 있다.

EPUB 파일 저장하기

파일을 Sigil에 불러들였으면, 먼저 저장하는 것이 좋다.

파일을 처음 불러들인 후, 즉시 저장하는 것이 좋다. EPUB을 불러들였을 경우에도, 저장시 문제점이 없는지 확인하기 위해 저장하는 것이 좋다.

파일을 불러들인 후에는 (HTML 파일을 읽어 들였을 때에도) EPUB 포맷이 되므로, Sigil에서 저장하면 EPUB 포맷의 파일로 저장된다. (필수 정보가 빠져있을 경우에도 EPUB으로 저장됨)

파일을 저장하려면 아래의 아이콘이나, File->Save(Cntl+S)를 선택하면 된다.  (File->Save As, File->Save A Copy 명령을 사용하는 방법도 있다.)

HTML 파일을 읽어 들였을 경우에는 파일명이 지정되지 않았으므로, 파일명을 입력하는 다이얼로그가 나타난다. 확장자는 .epub으로 지정된다.

SAVE 아이콘은 언제든지 눌러도 된다. 가능한 한 자주 눌러주자.

이제 여러분의 파일은 EPUB 포맷이 되었다. 하지만, 추가 정보를 입력해야 한다.

저자(Author)와 제목(Title) 입력

이북의 실제 내용과 더불어, EPUB에는 제목, 저자 등과 같은 상세 정보를 포함한다. 이러한 정보는 Sigil에서 입력할 수 있다.

이북의 상세정보(메타데이터 라고 함)를 입력하려면, 아래의 메타데이터 아이콘을 누르거나, 메뉴에서 Tools->Metadata Editor를 선택한다.

다음과 같이 메타데이터 창이 나타난다.

EPUB에서 필수적인 정보는 제목(Title), 저자(Author), 및 언어(Language)이다. 기본적으로 메타데이터 에디터는 위 그림과 같이 언어와 제목 필드를 포함한다.

언어를 바꾸러면 Language 행에서 값(Value)열 (현재 English로 되어 있는 부분)을 더블클릭한다. 드롭다운이 나타나면 원하는 언어를 선택하면 된다.

제목(Title) 행의 값(Value) 열을 더블클릭하면 해당 필드를 편집할 수 있다. 아래의 예에서는 책의 제목을 "Alice in Wonderland"로 입력하였다.

저자를 입력하려면, 먼저 우측의 메타데이터 추가(Add Metadata) 버튼을 누르고 목록에서 저자(Author)를 선택한다.

그러면 아래와 같이 창작자(Creator) 필드가 추가된다. 이 필드에 저자인 Lewis Carroll을 입력한다.

다음으로 창작자의 구체적인 역할을 입력한다. Role 행의 [Place value here] 를 더블클릭하면 목록이 나오는데, 여기에서 저자(Author)를 선택한다.

Creator 아이템에 File-As 속성을 추가한다. 이는 선택사항으로서, 저자명을 정렬하는 방식을 지정한다. 우측의 속성 추가(Add Property)를 클릭하고 File-As 속성을 선택한다.

새로 추가된 File-As 속성에 Carroll, Lewis를 입력한다.

이제까지 입력한 메타데이터의 결과는 아래와 같다.

정보 입력이 끝났으니 OK 버튼을 누르고, EPUB 파일을 다시 저장한다.

메터데이터에는 이외에도 아주 많은 항목이 있다. EPUB에는 제목, 저자, 언어만이 필수이지만, 더 많은 정보를 입력하고 싶다면 Add Metadata 혹은 Add Property 단추를 누르고 추가하면 된다.

표지 이미지 추가

모든 이북에는 표지가 있는 게 좋다. Sigil을 이용하면 쉽게 표지를 추가할 수 있다. 먼저 표지에 사용할 이미지(그리고 필요한 허가)가 필요하다. 이미지의 크기는 마음대로이지만, 아래는 일반적으로 참고할 만한 크기이다.

  • 킨들 다이렉트 출판 – 2,560px × 1,600px (1.6:1 비율)
  • 소설과 논픽션 – 2,560px × 1,600px (1.5:1 비율)
  • 그림 책 – 2,800px × 3,920px (1.4:1 비율) 또는 3,000px × 3,600px (1.2:1 비율)
  • 오디오 북 – 3,200px × 3,200px (1:1 비율)

출판사와 협의하여 목표로하는 기기가 어떤 것인지, 종이책 크기는 어떤지 등에 협의하는 것이 좋다.

표지 이미지를 추가하려면 도구->표지 추가(Tools->Add Cover) 를 선택한다. 그러면 아래와 같은 윈도가 나타난다.

이 윈도에는 이미 추가되어 있는 이미지들이 나타나지만, 현재는 아무 이미지도 없어서 빈 화면만 나타난 것이다. 이 화면에서 "기타 파일(Other Files)" 버튼을 누르면, EPUB 파일에 이미지를 추가하면서 바로 표지로 지정할 수 있다.

파일매니저 윈도에서 원하는 이미지를 선택하고 OK를 누른다. 그러면 Sigil은 해당 이미지를 EPUB에 추가한 후, 표지 이미지로 지정한다. 아울러 책 맨 앞에 html 파일을 생성하고, 표지 이미지를 삽입한다.

그 결과 "책 찾아보기(Book Browser)" 목차의 Text 폴더에  cover.xhtml 파일이 추가되며, Images 폴더에 cover.img 이미지가 추가된다. 

작업이 완료되면 다시 저장(Save) 아이콘을 눌러준다.

장(Chapter) 생성

일반적으로 HTML 파일을 불러들이면, 모든 텍스트와 장이 하나의 파일로 들어가게 된다. 이것도 물론 허용되지만, EPUB에서는 각장을 별도의 파일로 넣는 것이 일반적이다. 기기에 따라서는 파일 크기의 제한이 있을 수 있으며, 파일이 작으면 표시도 빨라지고 편집도 쉬워진다.

장당 하나의 파일 생성하기

파일을 분리하는 가장 쉬운 방법은 새로 파일을 생성하고자 하는 곳에 커서를 둔 뒤, 아래의 아이콘 (커서위치에서 나누기(Split At Cursor))버튼을 누르는 것이다.

예를 들어 새로운 페이지에서 장을 분리하려는 경우, 장 제목 맨왼쪽, 해당 줄의 맨 앞에 커서를 클릭한다.

그 다음 "커서위치에서 나누기(Split At Cursor)" 아이콘을 클릭하면 텍스트가 두 부분으로 분리된다. 이제 커서가 있던 지점 이후의 모든 내용이 Section0001.xhtml이라는 새로운 파일로 분리됨을 알 수 있다.

이상과 같은 작업을 반복하면, 어떤 부분도 새로운 파일로 저장되고, 새로운 페이지가 되도록 설정된다.

파일 이름을 바꾸러면 "Rename" 절을 참고하라. 이 절에는 Chapter_1, Chapter_2와 같이 여러개의 파일을 한꺼번에 이름을 변경하는 방법도 있다. 

자세한 사항은 "Splitting and Merging" 장을 참고하라. 나누기 표시(Split Marker)만 생성해두었다가 나중에 한꺼번에 분리하는 방법도 있다.

장(Chapter) 식별하기

EPUB은 독자들이 이북의 전체적인 구조를 파악하기 쉽도록 목차(TOC, Table of Contents)를 제공할 수 있다. Sigil은 여러분의 이북에서 자동으로 목차를 추출해서 생성하고 표시한다. 

Sigil에서 목차(Table of Contents) 맨 오른쪽 윈도에 별도로 표시된다.

장(Chapter) 표시하기

목차를 생성하려면, 어떤 것이 장의 이름인지 알려주어야 한다. 그냥 각각의 장들 제목을 선택한 후, 툴바 버튼을 이용해 장 heading임을 표시하면 된다.

장 이름중에서 어떤 곳이든 클릭한다. 그 다음 h1 을 누르면 가장 높은 수준의 장으로 표시된다.

이를 반복하면 나머지 부분도 장으로 표시할 수 있다.

h2, h3 등의 다른 헤딩 레벨을 사용하면 하위 장을 생성할 수 있다. 장 제목으로 설정된 부분을 다시 일반 텍스트로 돌리려면 단락 버튼을 누르면 된다.

목차 생성하기

Sigil에서 목차를 생성하려면 이전 절에서 설명한 방식으로 입력된 장 이름이 식별되어 있어야 한다. 모든 장의 heading을 표시했다면, 목차 생성 아이콘 또는 Tools->Table of Contents->Generate Table of Contents를 선택한다. 그러면 아래와 같은 다이얼로그가 뜬다.

이 다이얼로그를 이용하면 어떠한 heading을 목차에 포함시킬 것인지 결정할 수 있다. 

어떤 표제(heading)을 목차에서 제외시키면 영구적으로 보존된다. 즉, 다음번 목차를 만들 때, 선택 사항이 보존된다.

결정이 끝나면 OK 버튼을 누른다. 목차(Table of Contents) 윈도가 갱신되고 목차가 나타나게 된다. 

목차에서 클릭을 하면 그 지점으로 옮겨가게 된다. 표제(heading)을 수정하면 다시 목차를 갱신해야 한다. 완료되면 다시 저장한다.

링크와 노트 추가하기

Sigil을 사용하면 텍스트를 다른 부분(장 이름 혹은 노트 등)에 쉽게 링크할 수 있다. 이를 통해 독자들은 링크를 사용해 식별된 텍스트로 즉시 접근할 수 있다.

IDs

Sigil에서 링크를 만들기 위해서는 먼저 링크가 가고자 하는 텍스트에 ID(유일한 명칭)을 생성해야 한다. 다만, 링크 대상이 이북 맨 처음일 경우에는, 새로운 아이디를 만들 필요없이 파일명을 대상 ID로 사용하면 된다. 

ID는 'note1'과 같은 고유한 명칭이면 된다. 이 이름을 원하는 텍스트에 연결하면 나중에 참조할 수 있다. ID는 HTML 파일 내에서 유일해야 하지만(또한 반드시 문자로 시작해야 함), 여러 HTML로 구성된 이북에서 이리저리 탐색이 가능하려면, EPUB 전체에서 유일하는 게 좋다. 
ID와 링크는 html 앵커 태그 <a>를 사용해서 생성하는 것이 일반적이며, 따라서 ID는 링크를 위한 앵커 ID로 간주되는 경우가 많다. 

 ID 생성

ID를 생성하려면, 먼저 원하는 부분을 선택한 후, 아래의 ID 추가(Insert ID) 아이콘을 클릭하거나, Insert->ID 명령을 선택하면 된다.

그러면 다음과 같이 ID 다이얼로그가 나타나며, 여기에 이름을 입력한다.

링크

링크는 ID 를 가리키는 방법이다. 독자가 ID를 클릭하면 ID가 있는 위치로 이동된다. Sigil에서 링크를 생성하려면, 원하는 부분을 선택한 후, 링크 추가(Insert Link) 아이콘을 누르거나, Insert->Link를 선택하면 된다.

그러면 대상을 선택하라는 다이얼로그가 뜨며, 윈도에 기 입력한 ID가 나열된다. 

나열되어 있는 ID는 여러분이 입력한 것과 다르게 보인다. 이를 이해하기 위해서는 ID가 어떤 형태로 표현되는지 이해할 필요가 있다.

  • Filename.html : 이는 링크 대상을 파일명으로 지정하는 것으로서, 이를 클릭하면 해당 파일의 맨 꼭대기로 이동된다. 목차(Table of Contents)는 이를 이용하여 생성하는 것이다.
  • Filename.html#name1 : 어떤 파일에 포함된 특정 ID를 가리킨다. 이러한 방식의 아이디를 링크 대상으로 사용하면, 해당 파일속에 포함된 ID로 정확히 이동된다.
  • #ID1 : 그냥 ID만을 사용할 경우, 해당 ID가 링크와 동일한 파일 내에 존재한다고 간주한다.

새로 만든 링크를 클릭해보면 ID가 있는 곳으로 이동된다. 뒤로(Back)버튼을 누르면 링크가 있는 곳으로 되돌아 갈 수 있다.

역 링크

대부분의 이북에는 뒤로(Back)버튼을 사용해 원래 링크된 텍스트로 되돌아갈 수 있다. 하지만, 뒤로(Back)버튼이 없는 이북을 고려하여 원래의 위치로 되돌아갈 수 있는 링크를 생성할 수 있다. 이를 역 링크(Reverse Linking)라고 한다.

역 링크도 일반 링크와 다르지 않다.; 즉, 출발지에서 목적지로 가는 ID와 링크를 만들고, 반대쪽으로 목적지에서 출발지로 가는 ID와 링크를 만들어야 한다는 뜻이다. 결국 원래의 텍스트와 대상 텍스트에 각각 ID와 링크를 생성해야 한다. 

예를 들어 책의 맨뒤에 역링크 노트를 추가하려면 다음과 같이 수행한다.

  • 책 맨뒤에 원하는 노트를 선택하고 ID(예 note1)를 부여한다.
  • 연결시킬 이북 텍스트를 선택하고 ID(예 text1)를 부여한다.
  • 동일한 선택 텍스트에 대해, 노트의 ID에 대한 링크를 생성한다.
  • 마지막으로 해당 링크로 이동하여, 마지막 노트에 대해 text1에 대한 링크를 생성한다.
  • 이제 링크를 클릭하면 원래의 텍스트로 되돌아간다.

 

Posted by 푸른하늘 푸른하늘이

댓글을 달아 주세요

공간정보/표준2020. 12. 19. 17:59

JSON 스키마는 JSON 데이터의 구조를 검증하기 위한 강력한 도구이다. 그러나, 사양만 읽고 사용법을 익히려는 것은 설계도를 보고 운전을 배우는 것과 유사하다. 식료품을 사러가야 한다면, 전기 모터가 어떻게 맞물려 돌아가는지 알 필요가 없다. 이 책은 따라서, JSON 스키마를 위한 친절한 운전교본을 목표로 한다. 즉, 이 문서는 JSON 스키마를 작성하고자 하지만, 차를 제작하고자 하려는 것은 아닌 사람(JSON 스키마 검증기 개발자)을 위한 것이다.

****참고****
이 책은 JSON 스키마 초안 7을 기술한다. 이전 버전의 경우, 여기에서 기술하는 포맷과 완벽하게 
호환되지는 않지만, 대부분 그 차이는 문서중에 설명된다.

시작방법

  • 이 책에서 사용하는 스키마 예제 및 JSON 스키마를 자신의 프로그래밍 언어와 연관시키기 위한 규약은 여기를 참고하라.
  • 스키마가 무엇인지 모르겠다면, 스키마란 무엇인가를 확인하라.
  • 기본 장을 보면 코어 JSON 스키마 참조문서를 이해하는데 충분할 것이다.
  • 많이 중첩되고 반복되는 부분이 많은 대형 스키마를 개발하기 시작한다면, 복잡한 스키마 구조화하기를 참조하라.
  • https://json-schema.org/에는 공식 사양 및 여러가지 프로그래밍 언어로 JSON 스키마를 사용할 수 있는 도구까지 다양한 자원이 존재한다.
  • http://jsonschema.net/은 JSON 스키마와 예제 문서를 돌려볼 수 있는 온라인 응용이다. 소프트웨어를 설치하지 않고 뭔가 해보고자한다면 매우 유용할 것이다.

목차

  • 이 책에서 사용하는 규약
    • 언어 별 주의사항
    • 초판 별 주의사항
    • 예제
  • 스키마란?
  • 기본
    • Hello, World!
    • 유형 키워드
    • JSON 스키마 선언
    • 고유 식별자 선언
  • JSON 스키마 레퍼런스
    • 유형 별 키워드
    • 문자열
      • 길이(Length)
      • 정규 표현식
      • 포맷
    • 정규 표현식
      • 예제
    • 숫자 유형
      • integer(정수)
      • number(수)
      • Multiples
      • Range
    • 객체
      • Properties(특질)
      • Required Properties(필수 특질)
      • Property names(특질 명)
      • Size
      • Dependencies(의존)
      • Pattern Properties(패턴 특질)
    • 배열
      • Items(항목)
      • Length
      • Uniqueness(유일성)
    • 불린
    • null
    • 포괄 키워드(Generic keywords)
      • Annotations(범례)
      • Comments(코멘트)
      • Enumerated values(열거 값)
      • Constant values(상수 값)
    • Media: 문자열-인코딩 비 JSON 데이터
      • contentMedia Type
      • contentEncoding
      • 예제
    • 스키마 결합
      • allOf
      • anyOf
      • oneOf
      • not
    • 하위 스키마를 조건적으로 적용하기
    • $schema 키워드
      • 고급
  • 복잡한 스키마 구조화
    • 재사용
      • 재귀
    • $id 특질
      • $id 를 $ref와 함께 사용하기
    • 확장

인쇄 버전은 여기에 있다.

==
원문 https://json-schema.org/understanding-json-schema/

Posted by 푸른하늘 푸른하늘이

댓글을 달아 주세요

공간정보/표준2020. 12. 19. 17:30

JSON 스키마 는 JSON 문서에 주석을 달고 유효성을 검승할 수 있는 어휘이다.

장점

JSON 스키마

  • 기존 데이터 포맷을 설명한다.
  • 인간 및 기계가 일을 수 있는 깔끔한 문서화를 제공한다.
  • 데이터의 유효성 검증
    • 자동 테스트 및 클라이언트가 제출한 데이터의 품질 보증 하는 데 유용하다.

JSON 하이퍼 스키마

  • JSON 포맷을 문서 구조에 제한을 걸지 않고 하이퍼미디어 포맷으로 만든다.
  • 인스턴스 데이터에 URI 템플릿을 사용할 수 있다.
  • 클라이언트 데이터를 JSON 스키마를 이용한 링크를 사용하도록 해준다.
  • 콜렉션과 콜렉션 항목을 인식한다.

프로젝트 상태

2019년 9월 16일 : Draft 2019-09 가 발행되었다(이전 버전은 draft-08).

IETF 문서 ID는 draft-handrews-*-02 형태이다. 우리는 현재 메타 스키마를 위해 날짜를 사용하는데, 그것이 구현에서 행태를 결정하는데 사용되어야 하는것이므로, 우리는 이 웹사이트에서 항상 2019-09 로 참조할 예정이다.

이름체계와 번호체계에 대한 상세한 사항은 사양 페이지를 참조하라.

표준화 경로

JSON 스키마 프로젝트는 RFC 상태에 4가지 초안 시리즈의 길잡이 의도이다. 현재 우리닌 우리의 셀프-발행 인터넷 초안(Internet-Draft)을 향상시키고 있다. 다음 단계에서는 IETF 워킹 그룹에서 채택받은 초안이 만들어질 것이다. 이를 달성하기 위한 방법을 적극적으로 조사중이다.

이런 일에 경험이 있다면, 도와주기 바란다.

당분간 인터넷 초안 문서의 발행은 IEFT를 통해 추적할 수 있다.

  • JSON 스키마(코어)
  • JSON 스키마 검증
  • JSON 하이퍼 스키마
  • 상대적 JSON 포인터

인터넷 초안은 6개월 후 만료되므로, 우리의 목표는 항상 만료되지 않은 초안을 사용할 수 있도록 자주 발행하는 것이다. 그러나 이들은 아직 초안이므로, 사용자 커뮤니티에서 검증을 받은 명백한 요구가 주어질 경우, 주요 변화가 발생할 수 있다.

퀵스타트

유효성 검증 대상 혹은 설명 대상 JSON 문서를 인스턴스라고 하며, 설명이 담겨져 있는 문서를 스키마라고 한다.

가장 기본 스키마는 비어있는 JSON 객체로, 아무것도 포함하지 않고, 무엇이나 허용하며, 아무것도 설명하지 않는다.

{}

인스턴스에 제한을 가하려면 스키마에 검증 키워드를 추가하면 된다. 예를 들어 "tyep" 키워드를 사용하면 인스턴스에 객체, 배열, 문자열, 숫자, 불린, null로 제한한다.

{"type" : "string" }

JSON 스키마는 하이퍼미디어를 사용할 수 있으며, 기존 JSON기반의 HTTP API에 주석을 다는데 최고이다. JSON 스키마 문서는 URI에 의해 식별되는데, HTTP 링크 헤더에 URI를 사용할 수 있으며, JSON 스키마 내무 문서에 사용하면 재귀적 정의가 가능하다.

더보기

다음 문서를 참조하라.

질문이 있거나 도움이 된다 싶으면 참여하라.

Posted by 푸른하늘 푸른하늘이

댓글을 달아 주세요

공간정보/표준2020. 12. 19. 13:56

JSON(JavaScript Object Notation)은 속성-값 쌍과 속성 데이터 유형(혹은 다른 직렬화 값)으로 구성되는 데이터 객체를 저장하고 전송하는, 인간이 읽을 수 있는 텍스트를 사용하는 개방형 표준 파일 포맷이자 데이터 교환 포맷이다. JSON은 매우 흔한 데이터 포맷으로 AJAX 에서 XML 을 대체하는데 사용되는 등, 다양한 종류의 응용에서 사용된다.

JSON은 언어 독립적 데이터 포맷이다. JSON은 JavaScript로부터 파생되었지만, 많은 현대 프로그래밍 언어는 JSON 포맷 데이터를 생성하고 파싱하는 코드를 포함한다. JSON의 공식 인터넷 매체 유형(media type)은 application/json 이다. JSON 파일명은 확장자가 .json 이다.

2000년대 초, 더글라스 크록포드가 JSON 포맷을 공식적으로 규정하였다. 2006년이래로 RFC 4627이 "정보" 사양으로사 사용가능해진 후, 2013년에 ECMA-404로 최초로 표준화되었다. 2017년 발행된 RFC 8259는 인터넷 표준 STD 90의 현재 버전이며, ECMA-404와 일관성을 유지하고 있다. 같은 해에 JSON은 ISO/IEC 21778:2017로서 표준화되었다. ECMA와 ISO 표준은 허용되는 문법만 기술하는 반면, RFC는 보안 및 상호운영성 고려사항도 다룬다.

명명

두문자 JSON는 2001년 3월 더글라스 크록포드가 공동설립한 회사인 State Software에서 유래되었다. 

2017년 국제표준(ECMA-404와 ISO/IEC 21778:2017)은 "Jason and Argonauts"와 같이 /ˈdʒeɪ·sən/ 으로 발음하기로 규정하였다. ECMA-404의 최초 버전(2013)에서는 발음을 지정하지 않았다. "UNIX and Linux System Administration Handbook"에서는 JSON 포맷의 이름을 짓고 홍보한 더글라스 크록포드가 Jason이라는 이름처럼 발음한다고 하였다. 하지만 어쩐일인지 기술 분야에서는 "JAY-sawn"이 훨씬 널리사용되는 것 같다. 2011년 크록포드는 "어떻게 발음하는지에 대해 많은 논의가 있지만, 솔직히 나는 아무 관심없다"고 하였다.

역사

JSON은 2000년대 초에 널리 사용되던 방법인 플래시나 Java 애플릿과 같은 브라우저 플러그인 없이, 상태가 없는(stateless) 실시간 서버-브라우저 통신 프로토콜을 위한 요구로 인하여 성장하였다.

JSON 라이브러리의 선구자가 Cartoon Network을 위한 Communities.com(State Software 공동설립자가 모두 여기에서 근무하였음)에서 Cartoon Orbit이라는 어린이 디지털 자원 교환 게임 프로젝트에서 사용되었다. Cartoon Orbit은 동적 HTML 요소를 처리하기 위한 독점적 메시징 포맷을 가진 브라우즈측 플러그인을 사용하였다(이 시스템도 3DO소유이었다). 초기 Ajax 기능의 발견후, digiGroups, Noosh,  기타 여러 곳에서 frame을 사용하여, 웹 응용의 시각적 문맥을 리프레시하지 않고 브라우저의 필드에 정보를 전달하였고, Netscape 4.0.5+ 및 IE 5+의 표준 HTTP, HTML 및 JavaScript 기능만을 이용해 실시간 리치 웹 응용을 실현하였다.

크록폴드는 JSON 포맷을 최초로 규정하고 보급하였다. State Software 공동 설립자는 표준 브라우저 기능을 사용하는 시스템을 만들기로합의하고, 두개의 HTTP 연결을 개방상태로 유지하고 추가 데이터 교환이 없으면 표준 브라우저 타임아웃 까지 재활용함으로써 함으로써, 웹서버에 영구적인 양방향 연결을 하는, 상태인지(stateful) 웹 응용을 생성하는 웹 개발자를 위한 추상레이어를 제공하였다. 공동설집자들은 원탁회의를 열고 데이터 포맷을 JSML 또는 JSON으로 부를지, 라이선스 유형을 어떻게 가져갈지에 대해 투표하였다. 칩 모닝스타는 State Software에서 상태있는 응용 프레임워크를 위한 아이디어를 개발하였다.

이 시스템은 선 마이크로시스템스, 아마존닷컴 및 EDS에 판매되었다. 2002년 JSON.org 웹사이트가 만들어졌다. 2005년 12월, 야후에서는 몇몇 웹서비스를 JSON으로 제공하기 시작하였다.

JSON은 JavaScript 스크립트 언어(특히 1999년 표준 ECMA-262 3rd 에디션)의 부분집합에 기반하였으며, JavaScript에서 널리 사용되었지만, 언어 독립적인 데이터 포맷이다. 많은 프로그래밍 언어에서 JSON 데이터를 파싱하고 생성하는 코드를 사용할 수 있다. JSON의 웹사이트에는 언어별 JSON 라이브러리 목록이 있다.

2013년 10월, Ecma International에서는 JSON 표준 1차 에디션 ECMA-404를 발행하였다. 같은 해, RFC 7148은 ECMA-404를 참조로 사용하였다. 2014년에 FRC 7159는 JSON의 인터넷 이용이 주요 참조가 되었으며 RFC 4627 및 RGC 7158을 초과하였다. (ECMA-262와 ECMA-404를 주요 참조로 보존하였음) 2017년 11월, ISO/IEC JTC 1/SC 22에서는 ISO/IEC 21778:2017을 국제표준으로 발행하였다. 2017년 12월 13일, 인터넷 공학 태스크포스(Internet Engineering Task Force)는 국제표준 STD 90의 현 버전인 RFC 8259를 발행하면서 RFC 7159를 퇴출하였다.

크록포드는  JSON 라이브를 오픈소스화 하기 위해 JSON 라이선스에 한 절을 추가하면서 "소프트웨어는 선을 위해 사용어야지, 악을 위해 사용되어서는 안된다"고 하여 회사 변호사들과 과도하게 현학적인 사람들을 비웃었다. 반면 이 절은 다른 오픈소스 라이브러리와 JSON 라이선스의 라이선스 호환성 문제를 야기하였다.

문법(Syntax)

다음 예는 인간을 기술하는 JSON 표현을 보인것이다.

{
   "firstName": "John",
   "lastName": "Smith",
   "isAlive": true,
   "age": 27,
   "address": {
      "streetAddress": "21 2nd Street",
      "city": "New York",
      "state": "NY",
      "postalCode": "10021-3100"
   },
   "phoneNumbers": [
      {
         "type": "home",
         "number": "212 555-1234"
      },
      {
         "type": "office",
         "number": "646 555-4567"
      }
   ],
   "children": [],
   "spouse": null
}

문자 인코딩(Character encoding)

크록포드는 원래 JSON은 JavaScript와 ECMAScript의 엄격한 하위집합이라고 주장하고 믿었으나, 그의 사양은 실제로는 유효하지 않은 JavaScript인 JSON 문서를 허용한다. 즉, JSON은 유니코드 라인 종결자 U+2028 LINE SEPARATER와 U+2029 PARAGRAPH SEPARATOR가 따옴표로 묶은 문자열내에 이스케이프 처리를 하지 않고 나타날 수 있다. (ECMAScript 2018 및 이전 버전에서는 불가능하다. 이는 JSON이 "제어문자"만을 불허한 결과이다. 최대 이식성을 위해서는 이들 문자를 백슬래시로 이스케이프 처리를 하는 것이 좋다. 이는 JSONP를 생성할 때 중요하다.

개방 생태계에서 JSON 교환은 UTF-8로 인코딩해야 한다. 이 인코딩은 기본 다국적언어 평면(U+10000 에서 U+10FFFF)를 벗어나는 문자를 포함한 유니코드 문자셋 전체를 지원한다. 그러나 이스케이프처리하면 이들 글자는 UTF-16 surrogate pair를 사용하여 써야 하며, 일부 JSON 파서는 이런 상세함을 놓친다. 예를 들어 JSON에서 이모지 문자 U+1F610 😐 NEUTRAL FACE를 포함하려면 다음과 같이 해야 한다.

{ "face": "😐" }
// 또는 
{ "face": "\uD83D\uDE10" }

JSON은 ESMAScript 2019 리비전 이후 부터 해당 언어의 엄격한 하위집합이 되었다.

데이터 유형

JSON의 기본 데이터 유형은 다음과 같다.

  • Number(수) : 분수 부분이나 지수표현 E를 포함할수 있는 부호있는 십진 수. 하지만, NaN과 같이 숫자가 아닌것은 포함하지 않는다. 정수와 소수를 구분하지 않는다. JavaScript는 모든 숫자값에 배밀도 부동소숫점 포맷을 사용한다. 나중에는 BigInt도 지원한다.) 하지만, JSON을 구현하는 다른 언어에서는 수를 다르게 인코딩할 수도 있다.
  • String(문자열) : 0개 이상의 유니코드 문자 시퀀스. 문자열은 겹따옴표로 분리되며, 백슬래시 이스케이프 문법을 지원한다.
  • Boolean(부울) : true 또는 false 값 중의 하나.
  • Array(배열) : 0개 이상 값의 순서있는 목록. 각각의 값은 어느 유형이든 관계없다. 배열은 대괄호 표현을 사용하며, 요소는 쉼표로 구분한다.
  • Object(객체) : 이름-값 쌍의 콜렉션으로서, 이때 이름(키)은 문자열이다. 객체는 사전(dictionary)를 표현하기 위한 의도로서, 각각의 키는 객체 내에서 유일하다. 객체는 중괄호로 구분되며, 각각의 쌍은 쉼표로 구분하고, 각각의 쌍내에서는 ':'을 사용하여 키와 값을 구분한다.
  • null(널) : 단어 null을 사용하는, 비어있는 값

구문 요소(값 및 구두점) 주변의 화이트스페이스는 허용되고 무시된다(단, 문자열 값 내의 화이트스페이스는 그대로 사용된다).  이러한 목적의 화이트 스페이스는 공백(space), 수평탭(horizontal tab), 라인피드(line feed), 캐리지리턴(carriage return) 등 4가지 특정 문자가 고려된다. 특히 byte order mask가 적합한 구현에 의하여 생성되지 않아야 한다(JSON을 파싱할 때는 허용될 수 있다). JSON은 코멘트를 위한 문법은 제공하지 않는다.

(RFC 4627과 같은) 초기버전의 JSON의 경우, 유효한 JSON 텍스트가 객체 또는 배열유형만을 포함해야 했다(객체나 배열 내에 다른 유형이 들어갈 수 있다). 이 제한은 JSON 텍스트를 직렬화 값으로 재정의한 RFC 7158에서 제거되었다.

JSON에서 Number는 프로그래밍 언어내에서의 표현에 대하여 불가지하다. 이때문에 숫자를 임의의 정밀도로 직렬화할 수 있지만, 이는 이식성 문제를 야기할 수 있다. 예를 들어, 정수와 부동소수 값간의 차이가 없으므로, 어떤 구현에서는 42, 42.0, 4.2E+1을 동일한 수로 취급하고, 다른 시스템에서는 달리 처리할 수 있다. JSON 표준에서는 오버플로, 언더플로, 정밀도 상실, 반올림, 부호있는 0 과 같은 구현 상세에 관해 아무런 요구사항이 없지만, "좋은 상호운영성"을 위하여 IEEE 754 binary54 이상은 기대하지 않는 것을 추천한다. (binary64와 같은) 부동소수의 기계수준의 이진 표현을 인간이 읽을 수 있는 (JSON의 Number와 같은) 10진 표현으로 직렬화하거나 그 반대방향에서 내재적인 정밀도 상실은 없다. 이를 정확하게, 최적으로 수행하는, 발행된 알고리듬이 존재하기 때문이다.

코멘트는 JSON에서 의도적으로 배제되었다. 2012년에 더글라스 크록보드는 설계 결정에서 "사람들이 코멘트를 사용하여 파싱 지침을 넣거나하여 상호운영성을 파괴하는 사례를 보아서 JSON에서 코멘트를 제거했다"고 하였다.

JSON은 "뒤에 있는 쉼표", 즉 데이터 구조 내에서 마지막 값 뒤에 있는 쉼표를 허용하지 않는다. 이는 JSON 탄생 시점부터 ECMA 표준과 일치하기 위해서이다. 이후의 ECMA 표준에서는 뒤에있는 쉼표를 허용하기도 했지만, JSON 사양은 호환성 이유로 이를 계속 불허하였다. 뒤에 있는 쉼표는 JSON 파생체에서는 사용 용이성을 향상시키기 위한 일반적인 기능이다.

의미론(Semantics)

JSON은 데이터 교환을 위한 구문적 프레임워크를 제공하지만, 모호하지 않은 데이터 교환을 위해서는 JSON 문법의 특정한 사용을 위한 의미론에 생산자와 소비자간 합의도 필요하다. 이러한 합의가 필요한 예중 하나가 JSON 표준이 아닌 JavaScript 문접에서 정의된 데이터 유형(Date, Function, Regular Expression, undefined 등)의 직렬화이다.

메타데이터와 스키마

JSON 텍스트의 공식 MIME type은 "application/json" 으로서, 대부분의 현대 구현은 이를 수용하고 있다. 많은 서비스 제공자, 브라우저, 서버, 웹 응용, 라이브러리, 프레임워크 및 API에서는 예전 시스템과의 호환성을 이유로 비공식적 MIME type "text/json" 또는 콘텐트 타입 "text/javascript"도 지원하고 있다. 중요한 사례로는 구글 검색 API, 야후, 플리커, 페이스북 API, Lift framework, Dojo Toolkit 0.4 등이 있다.

JSON 스키마는 유효성검증, 문서화, 상호작용 제어 등에 사용되는 JSON 데이터 구조를 정의하기 위한 JSON 기반의 포맷을 명시한다. JSON 스키마는 주어진 응용에서 요구하는 JSON 데이터를 위한 계약과 데이터를 어떻게 수정할 수 있는지를 제공한다. JSON 스키마는 XML 스키마(XSD) 개념에 기반하지만, JSON 기반이다. XSD에서와 마찬가지로, 스키마와 데이터 모두 동일한 직렬화/역직렬화 도구를 사용할 수 있다. 즉, 자기기술적(self-describing)이다. JSON 스키마는 Internet Draft(IETF에서 2019-09 초안)에서 규정되었고, 2019년 9월 19일 공개되었다. 여러 프로그램 언어를 위한 여러가지 유효성 검증기가 존재하며, 각각 부합성 수준이 다르다. 표준 파일명 확장자는 없지만, 일부는 .schema.json을 제안하였다.

JSON 표준은 객체 참조를 지원하지 않지만, JSON 기반 객체 참조를 위한 IETF 표준 초안은 존재한다. Dojo Toolkit은 표준 JSON을 사용하여 객체 참조를 지원한다. 특별히 dojox.json.ref 모듈을 사용하면 순환참조, 다중참조, inter message, lay referencing 등을 포함한 여러가지 형태의 참조를 사용할 수 있다. 내부적으로는 두가지 모두 이러한 참조에 "$ref" 키를 부여하고 파싱시 이를 해결한다. IETF 초안은 URL 문법만 명시하지만, Dojo에서는 더 많은 형태를 허용한다. 다른 방법으로는 모질라 JavaScript Sharp 변수를 사용하는 등의 비 표준 해결책도 존재한다. 하지만, 이러한 기능은 JavaScript 1.8.5 이후로 막혔고, Firefox 12 버전에서 제거되었다.

용도

JSON-RPC는 JSON을 기반으로 만들어진 원격 프로시저 호출 (RPC: remote procedure call)로서, XML-RPC 또는 SOAP 를 대체한다. JSON-RPC는 약간의 데이터 유형과 명령만을 정의하는 간단한 프로토콜이다. JSON-RPC는 시스템에서 전송 통지를 시키고(응답이 필요하지 않는 서버에 대한 정보), 응답할 수 있는 서버에 다중호출을 보낸다.

비동기 자바스크립트 및 JSON (AJAJ, Asynchronous JavaScript and JSON)은 Ajax와 동일한 동적 웹페이지 방법론이지만, XML 대신 JSON을 데이터포맷으로 사용한다. AJAJ 는 웹브라우저가 데이터를 불러들인 후, 새로운 데이터를 요청할 수 있는 능력을 제공하는 웹 개발 기술이다. 전형적으로 웹페이지에 대한 사용자 반응에 대응하여, 서버로부터 새로운 데이터를 표시한다. 예를 들어, 사용자가 검색상자 등에 문자를 치면 이를 서버에 보내어 즉시 해당되는 데이터베이스 항목의 드롭다운 목록을 표시한다.

JSON은 데이터 직렬화 포맷이지만, 임시로(ad-hoc) 설정언어로서 사용되어 왔다. 이러한 사용에서는 코멘트와 기타 유용하다고 생각되는 기능을 지원함으로써, 비표준 JSON 상위집합이 생성되었다. 이중에는 HJSON, HOCON, JSON5(JSON 버전 5가 아님) 등이 있다. YAML 버전 1.2의 주요 목적은 엄격한 JSON 상위집합 비표준 포맷을 만드는 것이었다.

2012년, 더글라스 크록포드는 설정 언어로서 사용될 때 JSON에서 코멘트를 사용하는 데에 대해 말한 적이 있다. "일부 사람들이 코멘트 기능이 없어서 슬퍼한다는 것을 알지만, 그럴 필요가 없다. 당신이 JSON을 사용하고 주석을 달고 싶은 설정 파일을 유지한다고 생각해보자. 그러면 원하는 대로 코멘트를 삽입하고 JSMin 파이프를 통과시킨 후 JSON 파서에 넘기면 된다."

JSON은 데이터 직렬화 포맷으로서 의도되었다. 그러나, JavaScript의 하위집합으로 설계되었다는 사실에서, JSON 텍스트를 JavaScript eval() 함수에 넘겨도 안전하다는 잘못된 생각이 만들어졌다. 어떤 유효환 JSON 텍스트, 특히 U+2028 LINE SEPARATOR 또는 U+2029 PARAGRAPH SEPARATOR 를 포함하는 JSON 텍스트의 경우, 2019년에 JavaScript 사양이 갱신되기전 까지는 유효한 JavaScript 코드가 아니었기 때문에 일부 예전 엔진은 지원하지 않기 때문이다. 인터넷 혹은 새로운 함수에서 유래된 임의의 코드를 수행하는 데 따른 많은 함정을 피하기 위하여, ECMAScript의 5 판에는 JSON.parse()가 처음 추가되었고, 2017년에는 모든 주요 브라우저에서 지원되었다. 지원하지 않는 브라우저의 경우, 더글러스 크록포드가 API-호환 자바스크립트 라이브러리를 제공하고 있다. 아울러 TC39 제안 "Subsume JSON"은 ECMAScript를 2019년 버전부터 엄격한 JSON 상위집합으로 만들었다.

다른 포맷과의 비교

JSON은 XML에 대한 오버헤드가 적은 대체품으로 홍보되었다. 이들 포맷은 실세계 상황에서 생성, 읽기, 디코딩을 지원하기위해 널리 사용되고 있다. XML을 제외하고라도 CSV, YAML(JSON의 상위집합)을 포함할 수 있다. 또한, 데이터 교환 언어는 아니지만, Google Protocol Buffers가 이러한 역할을 채워줄 수 있다.

YAML

YAML 버전 1.2는 JSON의 상위집합이다. 이전 버전은 엄격하게 호환되지 않았다. 예를 들어, JSON에서는 백슬래시(\)를 사용하여 슬래시(/)를 이스케이프처리가 가능하지만, YAML에서는 유효하지 않았다. 이러한 이스케이프 처리는 JSON을 HTML에 넣어 cross-site scripting 공격을 보호할 때 널리 사용되는 방법이다. 

YAML은 코멘트를 지원하지만, JSON은 지원하지 않는다.

XML

XML은 구조화된 데이터를 설명하고 객체를 직렬화하는데 사용되어 왔다. 동일한 종류의 데이터 교환을 목적으로, JSON과 동일한 데이터 구조를 표현하는 여러가지 XML 기반의 프로토콜이 지원된다. 데이터를 XML 로 인코딩하는 방법은 여러가지가 있다. 두개의 태그를 사용한 가장 값비싼 형태를 사용하면, JSON보다 훨씬 크게 만들어지지만, 데이터를 속성에 저장하고 짧은 태그와 닫는 태그를 />로 대체하면, 표현이 JSON과 거의 비슷해지거나 약간 커지는 정도가 된다. 그러나, XML 속성은 단일 값만 사용할 수 있고, 각 속성은 각각의 요소에 많아야 한번 나올 수 있다.

XML은 (요소와 속성을 사용하여) "데이터"를 "메타데이터"와 분리하지만, JSON에는 그러한 개념이 없다.

다른 중요 차이는 값에 대한 주소지정 방법이다. JSON은 단순한 "키"와 "값" 매핑만 있는 객체를 사용하지만, XML은 "노드"단에서 주소지정이 발생하여, 모든 노드가 XML 프로세서에서 고유 ID를 부여받는다. 추가적으로 XML 표준은 공통 속성 xml:id 를 정의하여, 사용자가 사용할 수 있고 ID를 명시적으로 지정할 수 있다.

XML 태그 명은 !"#$%&'()*+,/;<=>?@[\]^`{|}~ 및 화이트 스페이스를 포함할 수 없고, 마이너스(-), 마침표(.) 및 숫자로 시작할 수 있지만, JSON 키는 가능하다(단, 따옴표와 역슬래시는 반드시 이스케이프 처리해야 한다). 

XML 값은 문자(character)의 문자열이며, 내장 유형 에러방지가 없다. XML은 스키마의 개념이 있어서, 강력한 유형지정, 사용자 정의 유형, 선 정의한 태그, 형식적 구조, XML 스트림에 대한 정식 유효성 검증 등이 가능하다. JSON의 경우 강한 유형지정이 내장되어 있고, JSON 스키마에서 비슷한 스키마 개념이 있다.

XML은 코멘트를 지원하지만, JSON은 지원하지 않는다.

파생

JSON 사양을 기초로 여러가지 직렬화 포맷이 만들어졌다. GeoJSON, JSON-LD, Smile (데이터 교환 포맷), UBJSON, JSON-RPC, JsonML 등이 그러한 예이다.

함께 보기

  • 데이터 직렬화 포맷 비교
  • Jacson(API)
  • JSON 스트리밍
  • S-expression

==

원문 : JSON - Wikipedia

Posted by 푸른하늘 푸른하늘이

댓글을 달아 주세요

공간정보/표준2020. 9. 25. 17:45

ISO/TC 211 "자동 문서화(Automated Documentation" 특별그룹(AHG, Ad-hoc group)의 정식 멤버로 활동하게 되었습니다.

ISO 표준문서를 보면, UML 모델과 설명이 상이한 경우가 많습니다. 초안을 만든 뒤, UML을 수정하였으나 설명부분은 수정이 안되는 경우, 등등으로 인해 이러한 오류가 발생합니다. 이 특별그룹은 모든 설명을 UML 등의 모델에 작성하여 자동으로 ISO 표준 문서를 작성함으로써, 이러한 오류를 없애고자 하는 것이 목표입니다.

이 특별그룹 관련 저장소는 : https://github.com/ISO-TC211/AutomatedDocumentation 입니다.

AHG 5 "자동 문서화" 특별 그룹의 두 가지 주요 임무

규정적 선언(Normative statements)

규정적 선언, 적합성 클래스와 시험은 실행 코드가 아닌 순수한 문장으로 쓰여지는 경우가 많다. 이들이 기계가 읽을(machine-readable) 수 있어야 하는지, 가능하다면, 기계가 시험할(machine-testable) 수 있어야 하는지에 대해 의문이 있어왔다. 하지만, 모든 선언이 기계가 시험할 수 있는 것은 아니다. 기계가 읽을 수 있는 선언은 선언에 대해 구조화된 모델이 필요할 것이다. OGC는 자신의 표준을 위해 요구사항 모델을 정의하였다. 이 특별그룹은 <<statement>> 모델 초안을 개발해야 한다. 이 모델은 ISO 19105 모델과 연결되어야 하며, 향후 표준화를 위한 입력으로서 작용해야 한다.

더보기

Normative statements, conformance classes and test are often written in pure text, not as executable code. Questions have been raised whether they should be machine-readable and possibly also machine-testable. However, not all statements can be machine-testable. Machine readable statements would require a structured model for statements. OGC has defined a Requirements model for their standards. This ad hoc group shall develop a draft «statements» model. The model shall be linked to the ISO 19105 model and serve as input for future standardization.

 

모델-기반 문서화(Model-driven Documentation)

어떤 특별 그룹(ref ISO/TC 211 resolution 633)에서는 2013년, ISO TC/211 표준의 모델-파생 문서화에 대해 연구하였다. Enterprise Architect 및 ShapeChange를 위한 템플릿이 개발되었으며, github.com/ISO-TC211/UML-Best-Practices/wiki/DocumentationOfUmlModels 에서 볼 수 있다. 템플릿은 많이 사용되지 않았으며, 아마도 ISO 19135-1에서만 사용되었다. 하지만, ISO 19170-1은 EA로부터, EA => ShapeChange => Metanorma => ISO 문서 로 생성된 바 있다. 이 특별 그룹은 모델-파생 문서화에 대한 접근법 및 ISO/TC 211 표준화 프로젝트에서 활용하는 방법에 대해 연구할 것이다.

더보기

An ad hoc group (ref ISO/TC 211 resolution 633) studied model-driven documentation of ISO/TC 211 standards in 2013. Templates for Enterprise Architext and ShapeChange were developed and are available on github.com/ISO-TC211/UML-Best-Practices/wiki/DocumentationOfUmlModels The template has not been much used, probably only by ISO 19135-1. However, the ISO 19170-1 document was generated from EA using: EA => ShapeChange => Metanorma => ISO document. This ad hoc group will study approaches for MDD and how we to facilitate for use in ISO/TC 211 standardization projects.

 

아래는 Ribose에서 발표한 자료입니다. 확실한 내용은 모르겠지만, Metanorma라는 도구를 사용하면 EA(또는 .xmi)에서 구축한 모델을 docx 파일로 변환이 가능하다는 것 같습니다.

20200820-iso-tc211-model-based-authoring.pdf
2.95MB

여기에 들어가면 예전(2013)에 문서 자동화를 검토하며 만들어둔 템플릿을 볼 수 있습니다. 

아래는 이에 대한 자세한 문서입니다. 시간날 때 정리해보겠습니다. 

Automatic generation of documentation from UML models.docx
0.92MB

민, 푸른하늘

Posted by 푸른하늘 푸른하늘이

댓글을 달아 주세요

공간정보/표준2020. 1. 10. 16:02


지리정보를 UML로 모델링하기 위한 모범 사례에 대한 ISO/TC211 위키

이 위키의 목적은 지리정보를 UML로 모델링하기 위한 모범사례를 수집하고 표현하며, 기계와 인간이 모두 이해할 수 있는 모델을 제작하기 위함이다.

1. 개요

1.1 UML 기본

https://github.com/ISO-TC211/UML-Best-Practices/wiki/Basic-UML

1.1.1 UML 소개

https://github.com/ISO-TC211/UML-Best-Practices/wiki/Introduction-to-UML

UML은 무엇인가?

  • UML은 객체지향 모델링을 위한 그래픽 언어
  • Unified Modelling Language의 약어
  • Object Management Group(www.omg.org)에서 개발
  • UML 2.4.1 이 ISO 19505:2012 로 국제 표준화되어 있음

UML 다이어그램

그래픽 언어는 그래픽 모델 요소가 있는 다이어그램으로 구성된다. 아울러 모델링 도구는 모델 요소에 대한 문자 정의를 저장한다. 그래픽 언어가 충분하지 않을 경우, 자신만의 정확한 문자 언어로서 키워드 및 제약을 입력할 수도 있다.

UML에는 정보, 행태(behaviour), 유스케이스, 컴포넌트 등을 기술하는 여러가지 다이어그램이 있다. 지리정보는 주로 아래와 같은 3가지 정적 모델을 사용하여 기술한다.

  • 패키지 다이어그램 : 패키지와, 패키지 간의 관계를 표시한다.
  • 클래스 다이어그램 : 클래스와 클래스 간의 연관을 표시한다. 클래스 다이어그램은 클래스 명과 속성을 보인다.
        - 클래스에는 이름, 속성, 연산이 포함됨. 제한(constraints)와 tagged value가 표시될 수도 있음 
        - 속성은 속성명, 데이터유형, 다중도 로 표현됨
        - ApplicationSchema, FeatureType, dataType, enumeration, CodeList, interface, Union 등의
          스테레오타입이 있음
        - association role에서 탐색가능한 종점은 반드시 이름과 다중도가 있어야 함
  • 객체 다이어그램은 실세계를 설명하는 실제 인스턴스를 나타낸다.
패키지 다이어그램의 모델 요소
  • UML 패키지는 여러 요소 그룹을 위한 콘테이너이며, 패키지 다이어그램에서는 탭이 있는 폴더로서 표현된다.
  • 패키지 의존성(dependency)은 어떤 패키지의 클래스가 다른 패키지에 있는 클래스를 필요로 함을 나타낸다. 이는 점선으로 표시하며, 꼬리쪽 패키지를 위해서 화살표 쪽에 있는 패키지가 필요함을 나타낸다.
아래 다이어그램에서 "Linear information" 패키지에 있는 클래스가 "Citation and responsibel party information" 패키지에 속한 클래스가 필요함을 나타낸다. 점더 구체적으로, "Linear Information" 에 들어 있는 여러 클래스들이 데이터 유형이 CI_Citation인 속성을 가지는데, 이 CI_Citation은 "Citation and responsible party inforamtion"에서 정의된다.

클래스 다이어그램의 모델 요소

클래스

클래스는 다이어그램에서 클래스 명(name), 속성(attribute), 연산(operation) 영역으로 구성된 직사각형으로서 표현된다. 아울러 제약(constraints) 및 태그값(tagged values) 영역도 보일 수 있다.

  • 추상 클래스는 클래스명을 이탤릭체로 표기한다. 이러한 클래스는 인스턴스화 할 수 없다.
  • 속성은 속성명(attribute name), 데이터 유형(data type) 및 다중도(multiplicity : 반복 가능 횟수)로 표현한다. 다중도는 대괄호로 표현한다.
  • 다중도 [0..1]이란 0개 또는 1개, [0..*] 이란 0개 이상임을 의미한다. 다중도가 없으면 정확히 1개임을 뜻한다.
스테레오타입

클래스 명 및 패키지 명 위에는 스테레오타입을 표기할 수 있다. 스테레오타입은 기본 UML 요소를 확장하여 다른 의미를 부여하는데 사용한다. ISO 19103 - 개념 스키마 언어 및 ISO 19109 응용스키마 규칙에는 지리정보 모델에 사용할 수 있는 스테레오타입을 정의하고 있다. 스테레오타입은 대소문자를 무시하지만, ISO 19103, 19109에서 사용되는 스타일을 사용해야 한다.
  • 스테레오타입이 "ApplicationSchema"인 패키지에는 지형지물(feature) 유형을 포함한다. 이 스테레오타입은 GML 실현시 중요하다.
  • 스테레오타입이 "FeatureType"인 클래스는 지리 객체 유형을 표현한다. 이 스테레오타입은 GML 실현시 중요하다.
  • 스테레오타입이 "dataType"인 클래스는 식별성이 없는 특질의 집합이다. 이러한 클래스는 단독 인스턴스로서는 존재할 수 없고, 다른 클래스의 속성 혹은 컴포넌트로만 존재할 수 있다.
  • 스테레오타입이 "enumeration"인 클래스는 가능한 값이 정해진 고정 목록이다. 이러한 목록을 사용하는 속성의 값은 반드시 그 목록내에 존재해야 한다.
  • 스테레오타입이 "CodeList"인 클래스는 가능한 값이 확장될 수 있는 목록이다.
  • 스테레오타입이 "interface"인 클래스는 개념적 클래스이다. 이러한 클래스는 데이터 셋에서 직접 사용될 수 없으며, 다른 클래스에서 실현되어야 한다.
  • 스테레오타입이 "Union"인 클래스는 여러가지 유형 목록을 포함하며, 하나의 인스턴스에서 하나의 유형만 사용된다.

연관관계

클래스 간의 연관관계는 해당 클래스를 연결하는 선으로 표현된다.
  • 연관관계는 연관명을 가질 수 있다.
  • 연관관계는 방향이 있을 수 있다. 이는 연관관계가 탐색가능한(navigable) 방향을 보이는 화살표로 표시한다.
  • 탐색가능한 끝은 연관역할명(role name)과 다중도(연결 인스턴스의 가능한 수)를 가져야 한다.
  • 빈 다이아몬드가 있는 연관관계를 집합연관(aggregation)이라고 하며, 다이아몬드가 있는 쪽의 클래스가 반대쪽 개별 콤포넌트의 집합을 갖게 된다.
  • 채운 다이아몬드가 있는 연관관계를 합성연관(composition)이라고 하며, 다이아몬드가 있는 쪽의 클래스가 반대쪽 컴포넌트를 소유한다.
  • 클래스간의 상속성(Inheritance)는 빈 삼각형이 있는 선으로 표현되며, 삼각형이 있는 쪽의 클래스가 상위클래스이다.
노트(Note)

노트는 한쪽 귀퉁이가 접어진 직사각형으로 표시한다. 노트는 자유문으로 추가적인 정보를 기재하는데 사용되며, 해당 모델 요소와 점선으로 연결된다.

객체 다이어그램 모델 요소

  • 객체 다이어그램에서 객체는 사각형으로 표시되며, 위쪽에는 이름:클래스명(언더라인), 아래쪽에는 속성=값을 표시한다.
  • 객체간의 연결은 연관관계 인스턴스를 나타낸다.


1.1.2 추상화 수준(Level of Abstraction)


ISO 19103의 요구사항 4는 "모델은 해당 추상화수준에 대한 명확한 설명을 문서화해야 한다" 고 말한다.


"추상화수준"이란, 모델에서 묘사한 상세함의 정도 및 특정 구현에 대하여 그 상세함이 얼마나 구체적인지를 의미한다. 모델의 추상화수준은 기반 패턴의 정의로부터, 개념의 정의, 그리고 플랫폼 구현사양까지 여러 단계가 있다.

ISO 19103에서 설명한 4가지 추상화수준은 다음과 같다.

  1. 메타모델(가장 추상적임. ISO19109의 일반 지형지물 모델(General Feature Model)과 ISO19505의 UML 메타모델 등)
  2. 개념스키마 - 추상 스키마 (기본개념에 대한 핵심 모델. 예 : ISO19107의 기하 및 위상 등)
  3. 개념스키마 - 응용 스키마 (아직까지 개념 모델이나, 특정 응용에 위함. 예: 길, 건물 등)
  4. 구현스키마(특정 구현을 위한 스키마. 예 : GML 응용스키마(XSD))
아래는 여러가지 추상화 수준을 나타낸 그림이다.


1.2 Enterprise Architect 사용하기

1.2.1 유용한 도구(script, search, addin 등)

  • Enterprise Architect 스크립트 작성법 - 샘플 스크립트 - 문서제작 스크립트, .eap 파일 정보 보기, 모델 검증 등
  • Enterprise Architect에서 모델 검색용 스크립트 작성법
  • ShapeChange 플러그인

1.2.2 INSPIRE 투토리얼

 INSPIRE_UML_repository_tutorial.pdf

참고로 이 파일은 다음 세가지 부분으로 이루어짐.

- EA를 사용하여 UML 모델 생성하기
- EA와 Subversion 사용하기
- EA와 Subversion 저장소 사용하기

1.3 참고 문헌

1.3.1 요구사항 및 권고사항

https://github.com/ISO-TC211/UML-Best-Practices/wiki/Requirements-and-recomendations

여러가지 ISO/TC211 표준 및 기술사양에는 UML 모델링에 관한 규칙과 권고사항이 들어 있다. 이중 일부는 이 위키문서에도 들어 있지만, 지리정보 UML 모델을 작업하는 사람은 반드시 원 문서를 알아두어야 한다.

ISO 19103 - 개념 스키마 언어

ISO 19103:2015에는 ISO 지리정보 표준에서 개념스키마 언어를 사용하는 규칙 및 지침이 포함되어 있다. 선택된 개념 스키마 언어는 통합 모델링 언어(UML)이다.

이 표준에는 다음과 같은 요구사항 및 권고사항이 포함된 UML 프로파일이 있다.

- UML 일반 용법
- 클래스
- 속성
- 데이터 유형
- 연산
- 관계 및 연관관계
- 선택/조건부/필수 속성 및 연관관계
- 이름 명명법 및 네임스페이스
- 패키지
- 노트(Note)
- 제약(Constraints)
- 모델 문서화

ISO 19109 - 응용 스키마 규칙

ISO 19109:2015에서는 지형지물 정의 원칙을 포함하여, 응용스키마 생성 및 문서화에 대한 규칙 및 권고사항이 정의되어 있다. 그 초점은 논의의 영역에 속한 지형지물 및 속성에 대한개념 모델링이다.

- 응용스키마의 정의
- 응용스키마를 위한 개념 스키마 언어 사용법
- 개념 모델의 개념을 응용스키마의 데이터 유형으로 변환하는 방법
- 다른 ISO 지리정보표준에 있는 표준 스키마와 응용스키마를 통합하는 방법

19136 GML(부속서 E)

ISO 19136:2007은 지리마크업언어(GML)에 대한 XML 스키마 문법, 메커니즘 및 공통규약을 정의한다. ISO 19136:2007 부속서 E(규정)에는 ISO 19109/19103에 적합한 UML 응용스키마를 GML 응용스키마로 자동 매칭하는 것을 목표로 하는 규칙을 담고 있다. 이 부속서에는 다음 항목에 대한 인코딩 법칙을 서술한다.

- 응용스키마와 패키지
- 클래스
- 속성
- 연관관계 및 연관관계 끝

19139 XML 스키마 구현

ISO/TS 19139:2007 에서는 ISO 19115에서 유도된 XML 스키마 구현인 지리 메타데이터 XML (gmd : Geographic Metadata XML) 인코딩을 정의한다. 여기에는 UML로부터 XML로 매핑시키기 위한 일반 법칙이 담겨있는데, 다른 표준을 XML로 구현할 때에도 유용하다.

1.3.2 기타 유용한 문서

- ISO/TC211, OGC, INSPIRE의 지리정보 UML 모델링
    INSPIRE Repository tutorial : Enterprise Architect, 모델링, svn 저장소 사용법 등에 대한 소개
    OGC Domain modelling cookbook : 지리정보 도메인 모델을 구축및 유지관리 모범사례
    Domain Modelling using Hollow World 
    Presentation 2015(Data modelling and model driven implementation of data distribution)
- SVN 및 문서관리
   Enterprise Architect를 위한 버전 제어 모범 사례
   ISO/TC211 조화 모델 소개 - 조화모델 불러오기

- 프로파일
   ISO/DIS 19160-1 개념 모델 처리하기, 부속서 B : 프로파일 개발 지침
   ISO/DIS 19160-1 개념 모델 처리하기, 부속서 C : 샘플 프로파일
- 구현
   주소 : 뉴질랜드 개념 모델(프로파일), 부속서 I, 개념모델을 구현모델로 전환하는 방법
   주소 : 뉴질랜드 개념 모델(프로파일), 부속서 B/C, 데이터 유형을 실현하는 방법 예시 

- 스크립트 
    Querying EA's Database : [Inside Enterpise Architect : EA 데이터베이스 쿼리, Thomas Kilian]
    Scripting Enterprise Architect [Enterprise Architect 스크립트 작성법, Thomas Kilian]
    Fifty Enterprise Architect Tricks [Enterprise Architect를 위한 50가지 트릭, Peter Doomen]

- ISO/TC211 내의 논의
   UML에 대한 문제점 토론사항 

2. 모범 사례

2.1 관련 요구사항 및 권고사항

1.3.1 과 동일

2.2 모델링 모범사례

2.2.1 일반 - 추상화 수준

1.1.2와 동일

2.2.2 일반 - 패키지/클래스/속성의 명명법


접두사(GM_, TP_ 등)

예전 UML 편집기에는 다른 패키지에도 동일한 이름의 요소를 포함할 수 없는 "버그"가 있었다. 이러한 이유로, ISO TC 211에서는 기본적으로, 분류자(Classifier) 이름에 "네임스페이스" 접두사를 붙였다.(예: 기하의 경우 "GM_", 위상의 경우 "TP_") 현재 편집기에는 패키지 분리가 올바르게 이루어지므로, 따라서

예전 표준에서 사용된 접두어는 더이상 필요하지 않다. 다이어그램에서 혼동이 발생할 경우, 다이어그램의 의도를 명확히하기 위하여 네임스페이스 패키지를 쉽게 표시할 수 있다.


하지만 일부의 경우 사람의 가독성을 위하여 접두사가 가치가 있을 수 있다. 하지만, 경험적인 법칙으로는 접두사 대신 다이어그램에 네임스페이스를 표시하는 것이 좋다.

** 기존 표준에서 사용된 접두어는 Prefixes 페이지에서 볼 수 있다.

규칙과 권고사항

19103에는 패키지, 클래스, 속성, 역할의 명명에 대한 여러가지 규칙 및 권고사항이 있다., 그중 핵심은 다음과 같다.

Requirement 16 "UML 요소의 이름은 대소문자 구분하지 않으며, 네임스페이스 내에서 유일하고 공백없어야 한다."


GML을 구현하기 위하여, ISO 19136 GML에서는 이름을 W3C XML 네임스페이스에 정의된 "NCName" 이어야 한다고 요구한다. NCName은 위의 요구사항보다 좀더 제한적이며, 일반 문자/숫자/("-",".","_") 등만 사용할 수 있고, "!", "#", "?" 등과 같은 특수문자는 사용할 수 없다. 아울러 NCName은 숫자/"-","." 로 시작할 수 없다. (뒤쪽에는 나타날 수 있다.)

참고: 속성과 역할의 경우, 네임스페이스가 클래스이므로, 이 규칙에 따르면 다른 클래스에서 반복사용될 수 있다. 하지만, ISO 19109 (응용 스키마 규칙)의 권고사항에 따르면

/rec/uml/property-name : 속성, 연산, 연관 역할의 이름은 응용스키마 내에서 유일하거나, 또는 다른 클래스에서 사용될 경우에는 동일한 의도를 가져야 한다.(should have the same intention with respect to the CLASS owning the property as any other property with the same name in the Application Schema)


이 권고사항은 GFM 권고사항인 rec/general/property-name과 밀접한 관계가 있다. 

아울러 아래의 ISO 19103의 권고사항을 따른다.

Requirement 8 : classifier/속성/연산/매개변수에 대하여 UML 요소의 이름은 정확하고 이해가능한 기술적 이름을 사용해야 한다.

Requirement 9 : 매개변수의 콘테이너나 유형에 의미가 있는 경우, short parameter명을 써야 한다.


예: 클래스 명이 "Building"일 경우, 속성명은 "buildingName" 대신 "name" 을 쓴다.)

19103 Requirement 10: UML요소의 이름은 정확하고 이해가능한 이름이 되도록 여러 단어를 중첩하여 사용하되, "-"나 "_"을 사용하지 않아야 한다.

19103 Requirement 11: UML 속성, 연산명, 연관 역할, 매개변수의 경우, 이름에서 연결하는 첫번째 단어 뒤에 오는 각각의 단어의 첫문자를 대문자화 한다. 분류자, 패키지, 유형사양, 연관명에 대한 이름의 모든 첫번째 문자를 대문자화한다.


즉, 속성/연산/역할/매개변수는 lowerCamelCase, 패키지/클래스/연관은 UpperCamelCase 형태로 만든다.

예) 클래스 이름은 TransportLink 처럼 될 수 있으며, validFrom 과 validTo와 같은 속성을 가질 수 있다.

19103 Requrement 13: UML요소명은 실용적인 한 짧게 유지한다. 이해가능하면 약어를 사용하고, 특별한 의미를 추가하지 않는한, 전치사와 동사는 생략한다.


다중언어 이름

ISO19109 응용스키마에는 이름을 다중언어로 처리하는 방법에 관한 몇가지 요구사항이 존재한다.  응용 스키마가 있는 패키지의 경우, 주요 언어를 가진 태그값을 가져야 한다.

/req/multi-lingual/package : 응용스키마가 있는 PACKAGE에는 TAGGED VALUE "language"를 사용하여 응용스키마에 있는 이름 및 정의에 사용된 주요 언어를 지정해야 한다. TAGGED VALUE는 IETF REC 5646로부터 가져온 값을 사용해야 한다.

패키지는 TAGGED VALUE "designation"를 사용하여, 주요 언어에 대한 대응 언어로 패키지의 이름을 포함해야 한다.

 TAGGED VALUE는 여러가지 언어로 계속 반복가능하다. 그 값은 다음과 같은 패턴으로 포매팅해야 한다.

 "{Name}"@{language} 

 여기에서 {Name}는 원하는 언어에서의 이름, {language}는 IETF RFC 5646에서 가져온 언어코드이다.


예 : "Observation et Mesures"@fr

지형지물 유형, 속성, 역할, 연산도 TAGGED VALUE를 사용하여 다른 언어로 표현할 수 있다.

/req/multi-lingual/feature : FeatureType 또는 PropertyType은 TAGGED VALUE "designation"을 사용하여, 주 언어에 대한 대응 언어로 이름을 기록해야 한다.

FeatureType 또는 PropertyType은 TAGGED VALUE "definition"을 사용하여, 주요 언어에 대한 대응언어로 해당 문자열 정의를 기록해야 한다.

TAGGED VALUE "designation" "definition" "description"은 여러 언어로 반복 가능하다.

이들 TAGGED VALUE의 값은 다음과 같은 패턴으로 포매팅해야 한다.

"{Name}"@{language} 

 여기에서 {Name}은 원하는 언어에서의 이름, {language}는 IETF REC 5646에서 가져온 언어코드이다.


실세계 이름과 UML 이름

모델요소의 이름이 "분류자를 위한 정확하고 이해가능하며 기술적인 이름"이어야 하지만, 공백과 특수문자를 가질 수 없고 실 세계 이름과 다르게 될 수 있다. 예를 들어, transport link 클래스는 "TransportLink"가 되며, 기능적 도로등급은 "FuctionalRaodClass"가 된다. 사람의 가독성을 위하여,  alias로 실세계 이름 넣는 것이 좋다. 

19100 표준에 alias 사용에 대한 규칙 혹은 추천사항은 없다. Enterprise Architect에는 클래스, 속성, 연관에 있는 "alias"를 이 용도로 사용할 수 있다. 여러 alias를 사용해야 할 경우, TAGGED VALUE를 적용할 수 있다. (예를 들어 태그값 "alias")


2.2.3 일반 - 정의

모델요소 잘 정의하는 것은 사람들이 모델을 잘 이해하는데 중요하다. UML에서는 정의를 Notes필드에 적으며, tagged value에도 쓸 수 있다.  ISO 19103 및 ISO 19109에서는 패키지/클래스/속성의 정의에 대한 여러가지 규칙과 권고가 있다. 기본적으로 이 모든 권고의 내용은

"모든 모델 요소에 정의를 작성하라"


19103 규칙 및 권고사항

일반

Requirement 3 : 모든 규정 클래스 모델은 모든 클래스/속성/연관/연산 및  적절한 데이터유형 정의를 충분히 이해할 수 있도록 정의를 포함시켜야 한다.


Enumeration/codelist

Requirement 7 : 열거 유형의 값은 개념이므로, 각각의 값은 값에 대한 정의가 있어야 한다.


Naming 과 네임스페이스

Requirement 12 : UML 요소는 documentation 필드를 사용하여, 이름있는 요소의 의미(시멭틱)을더 설명해야 한다.


모델의 문서화 

Requirement 19 : 각 분류자는 의미를 설명하는 정의를 가져야 한다.

Requirement 20 : 패키지/분류자/연산/속성/역할/연관/제한은 개념 다이어그램 근처에 텍스트로 설명을 해야 한다.


10109 규칙 및 권고사항

응용스키마 문서화 

/req/uml/documentation: 응용스키마는 문서화되어야 한다. 클래스,속성, 역할, 연산, 제약의 텍스트 정의는 UML 도구에서 제공하는 주요 문서화 기능을 이용해 기록해야 한다. (export 가능할 경우)
패키지/클래스.../제약에 대한 2차설명 및 정보용 참고사항은 TAGGED VALUE "description"에 기록할 수 있다.
CLASS 혹은 기타 UML 구성요소가 지형지물 카탈로그에 정의된 모델 요소의 구현일 경우, 해당 카탈로그에 대한 참조를 TAGGED VALUE "catalogue-entry"에 문서화 해야 한다.


정의 작성 방법

Enterprise Architect에서 "UML 도구에서 제공하는 주요 문서화 기능"은 각각의 클래스/속성/역할/연산/제약에 대한 "Note" 필드이다. 정의는 이 필드에 기록해하며, 다음과 같이 작성해야 한다.

    • 가능한한 간결하고 예제나 설명은 포함하지 않아야 한다. (예나 설명은 "description"에 넣을 것)
    • "주소란..." "Address component is..." 처럼 시작하지 않아야 한다.
    • 마침표(".")로 끝내야 한다.

예 : 특정 지리적 구역, 위치 혹은 주소 범위를 정의하는 기타 공간 객체의 식별자 또는 지리적 명칭. (Identifier or geographic name of a specific geographic area, location, or other spatial object which defines the scope of an address.)

2차적 설명 - TAGGED VALUE "description"

2차적 설명은 태그 값 "description"에 기록할 수 있다.

자연언어 명칭

예:

address component

보완적 설명(complementary description)

    • 정의의 출처 참조는 키워드 SOURCE를 사용하여 포함시킬 수 있으며, 그 뒤에 Source의 약칭을 넣어야 한다.
    • 설명에서 추가적 해설은 키워드 NOTE를 사용하여 넣을 수 있다. 노트가 여러개 있을 경우, NOTE 1, NOTE 2 등 처럼 번호를 넣는다.
    • 예는 키워드 EXAMPLE을 사용하여 넣을 수 있다. 예가 여러개 있을 경우, EXAMPLE 1, EXAMPLE 2 와 같이 번호를 넣는다.
예:

SOURCE [UPU-S21]

NOTE 1 주소 구성요소의 4가지 다른 하위클래스가 정의된다.
    • 행정 단위명(Administrative unit name), 국가명, 도시명, 거리명 등을 포함할 수 있다.
    • 주소 지역명 예: 마을 혹은 단지명
    • 가로명(Thoroughfare name) 대부분 도로명 
    • 우편 설명자. 주소를 구성하기 위하여 

이들 하위클래스는 대부분 계층적으로 구성된다.

NOTE 2 주소 위치자(address locator)와 주소 구성자(address component)의 조합으로서, 이들 각각은 사람들이 읽을 수 있고 사람들에게 명확한 특정한 주소 공간 객체를 생성한다.

EXAMPLE 위치자 "13"과 주소 구성자 "Calle Mayer"(가로명), "Cortijo del Marques"(주소지역명), "41027"(우편 설명자), "Ecija", "Sevilla", "Espana" (행정단위명)은 이들 특정 주소를 생성한다.

참고 : INSPIRE에서의 정의

INSPIRE Repository tutorial 은 note 필드에 정보를 구성하는 방법에 대한 규약이 있다.(문서 8쪽 참조). 이 규약에 따르면, note 필드는 3개의 주요 요소를 포함할 수 있다. 자연적 명칭(natural name), 정의(definition), 설명(description)

이 규약은 ISO 19103 및 ISO 19109 규칙을 완전하게 따르지 않지만, natural name 및 description을 태그값 "description"으로 옮기면 19103/10109 규칙에 부합시킬 수 있다.


2.2.4 일반 - TAGGED VALUE

태그 값 tagged value란?

스테레오타입과 태그 값(Tagged Value)를 사용하면 기존의 UML 모델요소를 새로운 목적으로 확장시킬 수 있다. tagged value는 tag와 값의 쌍으로서, UML 모델요소에 특질을 추가한다. UML 2에서는 tag 정의가 있는 스테레오타입이 부여된 모델 요소에만 tagged value를 적용할 수 있다. 태그 값은 tag=value의 형태로 나타나며, 여기에서 tag는 태그명, value는 문자열값(literal value)이다. Tagged value는 특히 코드 생성 이나 설정 관리와 깊은 관계가 있다.

예 : 분류자에 추가된 태그값은 다음과 같이 정의될 수 있다.
{author="Joe Smith", deadline = 31 March 1997, status = analysis}

Tagged value는 스테레오타입에 대한 속성으로서 정의된다. 예를 들어 스테레오타입 CodeList에 대한 속성인 codeList는 어떤 기관에서 별도 관리하는 원래의 코드 목록에 대한 URI 참조값을 나타낸다.

19103의 tagged value

CodeList        codelist        실제 외부 코드 목록을 참조하는 영구 URI

19109의 tagged value

스테레오타입

Tagged value 

설명 

 ApplicationSchema version응용스키마의 버전
 ApplicationSchema description 2차 설명 및 정보
 ApplicationSchema catalogue-entry 이 응용스키마의 구현 원천인 지형지물카탈로그에 대한 참조
 ApplicationSchema language 응용스키마의 이름 및 설명에 사용되는 주 언어, IETF RFC 5646에서 가져온 값이어야 한다.
 ApplicationSchema designation 주 언어에 대한 대응언어로 표현한 패키지 명. "{Name}"@{language} 패턴에 따라 포매팅되어야 한다. 여러 언어로 반복할 수 있다.
 FeatureType designation 주언어에 대한 대응언어로 표현한 지형지물 유형 또는 특질 유형의 명칭. "{Name}"@{language} 패턴에 따라 포매팅 되어야 한다. 여러 언어로 반복할 수 있다.
 FeatureType description 2차 설명 및 정보
 FeatureType definition 주언어에 대한 대응 언어로 표현한 텍스트 정의. 여러 언어로 반복할 수 있다.

19136(부속서 E)의 tagged value

UML 모델 요소 

 태그값

 설명

 Package documentation   정의 (EA에서 "Notes"필드)
 Package xsdDocument   XML 스키마 파일명. 패키지가 자체적인 XML 스키마 문서로 매핑되어야 할 때 사용한다. 스테레오타입이 ApplicationSchema인 패키지에 필수이다.
 Package tagetNamespace
 (스테레오타입 ApplicationSchem에서만)
 응용스키마에 대한 대상 네임스페이스 URI
 Package xmlns   (스테레오타입 ApplicationSchem에서만) 
 xml 네임스페이스 약칭
 Package version   (스테레오타입 ApplicationSchem에서만)
 Package gmlProfileScheam   (스테레오타입 ApplicationSchem에서만)
 연관된 GML 프로파일
 Class documentation   정의 (EA에서 "Notes"필드)
 Class noPropertyType   이름있는 복합유형(named complex type)을 생성하지 않아야 할 경우 "true"로 설정
 Class byValuePropertyType  클래스의 태그 값 "byValuePropertyType"이 "true"일 경우, 이들 클래스를 위하여 이름 있는 복합유형을 생성해야 한다. (클래스 이름에 "PropertyByValueType" 접미사가 붙은 형태)
 Class isCollection  클래스에 대상 클래스에 대한 집합/합성 연관인 연관관계가 있을 경우, 연관관계 역할은 특질 요소로 변환되고, 해당 클래스의 태그값 "isCollection"은 "true"가 되며, 해당 지형지물의 복합 유형에 속성 그룹 gml:AggregationAttributeGroup이 추가된다.
 Class asDictionary  (스테레오타입이 CodeList인 경우에만)
클래스의 태그값 asDictionary이 "true"일 경우, 코드목록 표현에 외부 gml:Dictionary를 사용해야 한다.
 Class xmlSchemaType  (스테레오타입이 Type일 경우에만)
해당 데이터 유형에 대응되는 XML 스키마 유형명(typename)
 Attribute 및 Association End documentation  Definition (EA에서 "Notes" 필드) 
 Attribute 및 Association End sequenceNumber UML 모델에서 XML 스키마로 변환할 때, 특질의 순서를 일관성있게 유지
 Attribute 및 Association End inlineOrByReference 지형지물 및 객체 유형에 대하여, 태그값 "inlineOrByReference"를 "inline"인지 "byReference"인지에 따라 그 표현을 내장(inline)혹은 참조(by reference)로 제한한다. 태그값이 없거나 값이 "inlineOrByReference"인 경우에는 기본 인코딩을 사용해야 한다. 
 Attribute 및 Association End isMetadata 속성이나 연관역할이 메타데이터 특질인 경우 "true"로 설정한다.


2.2.5 일반 - 모델의 버전

UML 모델이 개정됨에 따라, 다른 버전별로 새로운 패키지가 생성되고, 전체 모델 저장소에는 동일한 클래스에 대하여 여러가지 버전이 존재하게 된다.

예를 들어, CI_Citation 클래스는 ISO/TC211 개념 모벨 저장소에 세가지 장소에서 정의되고 있다.

    • ISO 19115:2003 Metadata
    • ISO 19115:2006 Metadata(Corrigendum)
    • ISO 19115-1:2014 Metadata - Fundamentals
이들 클래스는 여러가지 다른 표준에서 사용되고 있으며, 다른 버전의 패키지에서 이름들이 재사용되고 있으므로, 어떤 버전의 클래스를 참조하는지 결정하는 것이 쉽지 않다. 다이어그램에 도시할경우 네임스페이스가 도움이 되지만, 아래 그림과 같이 검색에서는 네임스페이스가 표시되지 않는다.

이 검색 결과에서 CI_Citation 클래스가 어떤 버전에서 나온것인지 보기는 불가능하다. 날짜(특히 "Modified")에서 개략적으로 알수는 있지만, 이는 확실한 것이 아니다. Enterprise Architect에서 자동적으로 설정하고 갱신되기 때문이다.

상태, 페이즈, 버전(Statue, Phase and Version)

Enterprise Architect에는 Status, Phase, Version 등, 요소 및 패키지에 대한 유용한 메타데이터가 몇가지 존재한다. 이들 매개변수는 버전을 식별하는데 유용하며, 모든 패키지 및 요소에 대하여 한번의 작업으로 설정할 수 있다. Project Browser -> 패키지에 우클릭 -> Advanced->Update Package Status

상태 (Status)

상태는 Enterprise Architect에서 미리 정의된 코드 목록(Approved, Implemented, Mandatory, Proposed, Validated)에 기반하고 있다. (이들 코드 목록은 Project-Settings-Project Types-General Types에서 변경할 수 있다.)

ISO/TC211 표준의 개념 모델의 경우 가장 관련있는 값들은 다음과 같다.

    • Approved : 공식 표준 및 기술 사양을 위한 UML 모델
    • Proposed : 개발중인 표준 및 기술사양을 위한 UML 모델
    • Implemented : 구현 스키마를 위한 UML 모델
    • Superseded : 대체된 표준을 위한 UML 모델
국가 또는 지역 모델에 대해서는 다른 값을 적용할 수도 있다.

페이즈 (Phase)

Phase는 자유 기재이지만, ISO/TC 211 모델의 경우, 공식 페이즈를 사용하는 것이 자연스럽다.

    • WD : Working Draft
    • CD : Commitee Draft
    • DIS : Draft International Standard
    • FDIS : Final Draft International Standard
    • IS : International Standard
    • DTS : Draft Technical Specification
    • TS : Technical Specification

국가 또는 지역 모델에 대해서는 다른 값을 적용할 수도 있다.

버전(Version)

버전도 자유 기재이다. ISO/TC211 모델의 경우 모델이 발행된 년도이다. 국가 또는 지역 모델에 대해서는 다른 값을 적용할 수도 있다.

보기

아래 그림은 상태 값을 갱신하기 전, MI_BAND 클래스에 대한 검색 결과이다.

아래 그림은 상태 값이 갱신된 동일한 검색결과이다. 어떤 클래스를 사용해야 할 지 훨씬 쉽게 구분할 수 있다.


2.2.6 클래스 - 스테레오 타입

1.1.1 의 스테레오타입과 동일함 

2.2.7 클래스 - 일반화/특수화

https://github.com/ISO-TC211/UML-Best-Practices/wiki/Generalization

개요

상위클래스로의 일반화(Generalization) 및 하위클래스로의 특수화(Specialization)은 도메인 모델링의 중요하면서도 가치있는 부분이다. 상위클래스로부터 하위클래스로 상속성을 사용하면 모델에서 중복성을 줄이며, 공통 개념을 동일한 방식으로 취급할 수 있다.

아래 그림은 하위클래스와 상위클래스의 예를 보인 것이다. 차량(Vehicle)은 자동차(Car) 및 열차(Train)의 상위 클래스이다.

다른 예로서 ISO 19157 데이터 품질에는 추상 상위클래스 DQ_Result와 여러가지 다른 결과 유형을 위한 하위클래스를 볼 수 있다.

하위클래스로의 특수화

하위클래스로 특수화하는 주로 필요한 것은, 클래스의 식별된 부분에만 적용되는 속성/연관 또는 연산이 있을 경우이다.

예를 들어 DQ_Result의 각 하위클래스에 있는 속성은 해당 종류의 결과에만 적용된다. 하지만, 특별한 속성, 연관 혹은 연산이 없더라도 하위클래스가 개념적으로 다른 경우와 같은 상황도 있다. 위의 그림에서 Train이 이에 해당한다. 하위클래스 Train은 특별한 속성이나 연관관계가 없지만, 자동차와는 개념적으로 다르다. 이러한 하위클래스는 주의깊게 사용해야 하며, 모델을 복잡하게 만들 수 있다.

하위클래스는 속성, 연관, 연산의 중복을 줄일 수 있는 중요한 것이지만, 주의깊게 사용해야 한다. 불필요한 하위클래스는 모델을 복잡하게 만든다. 위와 같은 의도가 없는 이상 하위클래스를 생성하지 말라.

상위클래스로의 일반화

상위클래스로 일반화하는 주로 필요한 것은, 여러가지 클래스가 동일한 속성/연관 또는 연산을 가진 동일한 개념의 변종일 경우이다.

예를 들어 그림 위에서 Car 및 Train은 탑승차량의 일종이며, 승객수가 있을 수 있다. 또한 DQ_Result 아래에 있는 모든 하위클래스는 날짜와 범위가 있는 여러가지 결과이다. 이때 Vehicle 과 DQ_Result 상위클래스를 사용하면, 상당한 중복이 줄어들며, 동일한 개념을 모든 하위클래시를 위해 사용할 수 있게 된다.

상위클래스로 일반화할 수 있는지를 알아보기 위해서는 두가지 간단한 법칙을 고려해야 한다.

    • 100% 법칙 : 상위클래스에서 필요한 모든 속성 및 연관이 모든 하위클래스에도 적용할 수 있다.
    • Is a 법칙 : 자연어에서 "하위클래스가 상위클래스의 일종이다"라는 문장을 테스트해본다. (예: 열차는 차량이다.)

많은 경우, 상위클래스는 추상 클래스이며, 하위클래스는 구현되는 클래스이다.


2.2.8 클래스 - 추상클래스

1.1.1 클래스와 동일

2.2.9 클래스 - 클래스/데이터유형

UML 모델에서 개념 클래스는 물리적객체(강/도로/건물 등)를 표현할 수 있지만, 추상적객체(조직/거래/관측 등)도 표현할 수 있다. 도메인 모델링에서 처음 해야 하면서도 가장 중요한 작업이 개념 클래스를 식별하는 것이다.

데이터타입은 특별한 종류의 분류자이다. 클래스와는 유사하다. 데이터유형의 인스턴스는 값으로만 식별할 수 있다. 즉, 자체적으로 식별되는 인스턴스는 될 수 없고, 속성(및 연관) 값으로서만 존재할 수 있다. 각각의 값을 구분하는 것이 의미가 없을 때 주로 사용된다.

어떤 것이 클래스(ISO/TC211 응용스키마에서는 지형지물 유형)인가 데이터유형인 속성인가하는 의문이 자주 등장한다. 이에 대한 엄격한 답은 없다. 다만, UML 모델링에서 가장 기본되는 법칙은, 모델과 모델의 구현을 가능한한 간단하게 하라는 것이다. 또한 데이터 유형의 값은 자체적으로 존재할 수 없고, 관련된 클래스의 값으로서만 존재한다. 무차별적으로 복합데이터 유형을 사용하면, 객체내 데이터 양을 증가시킨다. GML에서의 예를 들어보자. 클래스에 대한 연관은 xlink:href로 사용할 수 있지만, 데이터 유형에 대한 연관은 항상 인라인이 된다. 데이터 유형 인스턴스는 객체 바깥에서는 존재할 수 없기 때문이다.

따라서, 데이터타입보다는 지형지물유형을 사용하는 것이 더 좋다. 기본 법칙은 아래와 같다.

"잘 모르면 데이터타입 대신 클래스를 사용하라"


2.2.10 속성 - 속성인가 연관인가


클래스에는 연관을 사용하고, 데이터타입에는 속성을 사용하라


이 글은 Geert Bleekeen의 블로그 글 속성인가 연관인가를 참고한 것이다. 클래스와 데이터 유형에 대해서는 윗 글을 참고할 것

ISO 19109에 있는 UML 및 일반지형지물모델(GFM)에는 객체에 특성을 제공하는 두가지 비슷한 방법 - 속성연관관계 - 을 보여준다. 객체의 특성을 위한 간단한 방법은 19103의 원시 데이터유형(Integer, CharacterString 등)의 속성을 사용하는 것이다. 하지만 자체적으로 여러개의 속성을 가지고 있는 복합 데이터 유형을 속성으로 가질 수 있다. 예를 들어 ISO 19115의 Citation의 여러가지 클래스 및 데이터 유형은 다른 표준에서 클래스의 특질로서 널리 사용된다. 이러한 경우 흔히 제기되는 의문이, 언제 복합 데이터유형을 속성으로 사용할지, 언제 연관으로 사용할 지 하는 것이다.

일반지형지물모델(GFM)에서 속성과 연관은 모두 PropertyType의 하위유형으로 많은 점에서 동등하다. GeertBeelkens의 블로그 글에서 기술한 것처럼, 이들은 UML 메타모델에서 동일한 메카니즘에 근거하고 있고, 구현에서도 거의 동일하다. (GML에서 연관은 속성과 비슷함)

게다가 UML 사양에 따르면, "데이터 유형은 클래스와 유사한 특별한 종류의 분류자이다. 데이터 유형은 값으로만 식별될 수 있다는 점만 클래스와 다르다"고 기술하고 있다. 달리 말해 데이터 유형의 인스턴스는 자체적으로 존재하는 객체가 아니며, 구현에서 관련된 객체의 일부이어야 한다.

가장 기본적인 법칙은 특성이 어떠한 분류자에 기반하는지 살피는 것이다. 즉 데이터 유형인가 지형지물 유형인가 하는 것이다. 그것이 지형지물 유형이라면 주 지형지물의 외부에 존재할 수 있고, 그 경우에는 연관으로서 참조만 가능하다.

반대로 분류자가 데이터 유형이면(이 글의 법칙을 따른 후에도) 데이터 유형의 값은 주 지형지물이 연관에 기반하는지 아니면 속성에 기반하는지에 따른다. 위에서 언급한 것처럼 연관은 GML에서 속성과 매우 유사한 형태이다. 따라서 데이터 유형에 기반한 특성이라면 속성으로 사용하는 것이 좋다.

아울러 동일한 원칙에 기반하여 데이터 유형에 대한 간단한 연관은 의미가 없으며 반드시 합성연관이어야 한다. 이는 ISO 19103의 요구사항 12에도 언급되어 있다.

2.2.11 속성 - 다중도(Multiplicity)

1.1.1 클래스 와 동일함.

2.2.12 속성 - 속성에 data type 연결하기

https://github.com/ISO-TC211/UML-Best-Practices/wiki/Attributes-and-data-types

지형지물유형, 객체유형, 데이터유형, 유니온유형의 속성은 이름과 데이터 유형이 있어야 한다. 이는 ISO 19109 응용 스키마 규칙 및 ISO 19136 GML에도 언급되어 있다. 이들 표준이 응용스키마와 관련되어 있기는 하지만, 개념 모델에도 동일한 규칙이 적용된다. 이는 모델의구현을 위해 중요하다.

데이터 유형은 ISO 19103에 미리 정의된 원시데이터 유형, 또는 다른 표준에서 정의된 유형, UML모델에서 자체적으로 정의한 유형 등 중의 하나이어야 한다.

UML 모델링에서 가장 흔한 오류중 하나는 속성 유형에, 기본 클래스에 연결하지 않은 이름을 지정하는 것이다.(예를 들어 data 유형에 그냥 "GM_Point"라고 입력하는 것은, ISO 19107 기본 모델에서 선택ㅎ하는 것과 동일하지 않다.) 다이어그램 상으로는 올바른 것처럼 보여도, 연결이 빠졌기 때문에, 구현이나 의존성 점검시 오류가 발생한다.

Enterprise Architect의 속성 테이블(t_attribute)에서, 속성은 데이터 유형에 연결되는 ClassifierID를 가져야 한다. 올바르게 이 링크를 올바르게 하려면, 절대 이름을 직접 입력하지말고, 항상 모델에서 선택해야 한다. 

불행하게도, EA에는 속성이 데이터 유형과 연결되었는지를 제어하는 기능이 존재하지 않는다. 하지만, 이는 검색 혹은 스크립트를 활용하면 된다. 아래 링크에는 데이터 유형 연결을 체크할 수 있는 스크립트 예제가 있다.

https://github.com/ISO-TC211/UML-Best-Practices/blob/master/Scripts/VBScript/VAL%20Data%20type%20references.vbs

2.2.13 연관 - 연관의 유형

https://github.com/ISO-TC211/UML-Best-Practices/wiki/Association-types

이 글은 Geert Bellkeen의 블로그 글 "합성연관, 집합연관, 연관관계"를 참조한 것이다.

연관관계는 모델에서 클래스 또는 데이터 유형을 연결할 때 사용된다. UML에서는 클래스 다이어그램에 단순 연관(association), 집합연관(aggregation), 합성연관(composition) 등세가지 연관관계를 지원한다. (일반화는 별도)  모든 연관은 단방향 혹은 양방향으로 탐색가능(navigable)할 수 있다. 화살표/다중도/역할 등으로 정의된다.

  • 단순연관은 두개의 클래스가 동등한 입장이다. 위의 그림에서 Person 클래스와 Car 클래스간에는 단순 연관이 있다. 사람은 차를 0개 이상 가질 수 있으며, 차는 1명 이상의 소유자가 있다. 이들은 모두 동등한 수준으로 서로 다른 것의 일부가 아니다.
  • 집합관계(aggregation, 빈 다이아몬드로 표시)에서는. 다이아몬드 쪽의 클래스가 전체이며, 다른 쪽에 있는 클래스가 일부이다. 예를 들어 위원회는 전체이며, 위원은 사람이다. 하지만, 사람(위원)은 위원회에 독립적으로 전해 할 수 있고, 다른 위원회에 소속될 수도 있고, 다른 클래스의 일부일 수도 있다. 위원회가 사라지더라도 사람은 존재한다.
  • 합성관계(composition, 채운 다이아몬드로 표시)에서는 다이아몬드 쪽의 클래스가 다른쪽 클래스를 소유한다. 예를 들어 차(Car)는 바퀴(Wheel)을 소유한다. 다이아몬드쪽의 다중도에 따라 반대쪽 클래스가 독립적으로 존재할 수 있는지가 결정된다. 그림에서 Car 쪽의 다중도가 0..1 이므로, Wheel은 Car가 없이도 존재할 수 있다. 합성관계일 경우, 현실적으로는 [0..1] 또는 [1] 다중도만 존재한다.
언제 어떤 연관관계를 사용해야 하는가? 이에 대한 간단한 해답은 존재하지 않지만, 다음 사항을 고려하면 좋다.

집합관계는 단순연관에 비해 모델에 새로 추가시키는 것은 없지만, 계층을 나타내는데만 도움된다.

합성관계는 모델에 강한 결합을 추가함으로써, 구현에 영향을 미친다. 합성관계는 정말 구현에 필요하다고 확신할때만 사용해야 한다.


2.2.14 연관 - 역할과 탐색가능성(navigability)

https://github.com/ISO-TC211/UML-Best-Practices/wiki/Association-roles-and-navigability

탐색가능성(navigability)

UML 클래스/데이터유형간의 연관은 탐색가능 방향을 가질 수 있다. 단방향(출처->대상 혹은 대상->출처)일수도 있고, 양방향일 수도 있다. 탐색가능 방향을 Unspecified로 지정할 수도 있으며, 이경우 대부분 양방향과 동일하지만, 사용해서는 안된다. 탐색가능 방향은 모델 구현이 탐색가능한지를 기술하며, 다이어그램에서는 화살표로 표시한다. 위의 그림에서는 모든 연관이 양방향으로 탐색가능하다.

탐색가능 방향은 구현에서 영향을 미친다.

GML 구현의 경우, ISO 19136 부속서 E에서 언급한 것처럼, 모든 탐색가능한 끝은 반드시 화살표로 표시해야 한다. 달리 말하여, 탐색가능 방향을 반드시 설정해야 한다.


또한 양방향 연관은 두 클래스 모두의 구현에서 서로에 대해 알아야 함을 의미한다. 이로 인하여 구현이 좀더 복잡해 질 수 있다. 양방향이 모두 필수일 경우, GML 구현에서 두 클래스는 서로 참조를 가져야 한다.

양방향은 서로 상대방을 알수 있는 구현으로 구현이 복잡하다. 즉, 서로 참조를 가져야 한다.

두 클래스의 구현이 서로 아는 것이 중요하지 않다면 단방향 연관을 사용하라.


역할명(role name)

구현에서는 연관은 속성과 비슷하다. 따라서 다음 사항이 중요하다.

탐색가능한 끝은 반드시 역할명(role name)을 가져야 한다. 이는 19136 부속서 E에 기술된 것처럼 "NCName" 이어야 한다. (속성명과 동일)

위의 그림에서 Person 클래스의 구현은 Car 클래스의 구현에 대한 참조를 가질 수 있으며, 이 참조의 이름은 자산(property)어야 한다. 또한 역으로 Car 클래스의 구현은 Person 클래스의 구현에 대한 참조가 있어야 하며, 이 참조의 이름은 owner이어야 한다. 하지만, Car와 Wheel간의 연관을 살펴보면, Car 쪽 끝에는 이름이 없다. 따라서 Wheel 클래스는 Car에 대한 참조를 알 수 없다.


다중도(Multiplicity)

연관 역할의 다중도는 한 클래스의 인스턴스가 다른 쪽 클래스를 몇개 참조할 수 있는지를 기술한다. Person 클래스는 0개이상의 Car 인스턴스를 참조할 수 있지만, Car는 한명 이상의 Person(owner)를 가져야 한다. 위원회(Committee)는 2명 이상의 위원(Person)이 있어야 하며, 위원은 0개 이상의 위원회에 속할 수 있다. 또한 Car는 3개 이상의 Wheel을 가져야 하지만, Wheel은 0개 또는 1개의 차에 속해야 한다.

다중도의 설정도 구현에서 중요하다.

ISO 19136 부속서 E 에 따르면, 모든 탐색가능한 끝의 다중도는 명확하게 설정해야 한다. 다중도 1과 1... 는 주의깊게 사용해야 한다. 


다중도를 1 또는 1... 로 설정할 경우, 해당 클래스의 구현은 항상 이 참조를 필수로 가져야 한다.(필수 속성과 비슷).  Car-Wheel 연관에서 Car 쪽의 다중도가 1로 설정되었다면, Wheel 클래스는 Car 클래스의 구현에 대한 참조가 반드시 존재해야 한다. 또한 Wheel 쪽의 다중도는 이미 (3..*)이다. 모델이 이런식일 경우, 구현에서 두 개의 클래스가 서로 반대쪽을 참조해야 하며, 이로 인해 데이터의 중복이 일어나게 된다.

2.2.15 연관 - INSPIRE Repository Tutorial

https://github.com/ISO-TC211/UML-Best-Practices/blob/master/Reference%20material/INSPIRE_UML_repository_tutorial.pdf 12-13쪽 참조

연관을 생성한 뒤에는 반드시 특성을 지정할 것. (특히 탐색가능 방향 및 역할 명)

역할명은 lowerCamelCase로 쓸 것. Notes 필드에 definition 과 description 적을 것. 

탐색이 불가능한 종점에서는 역할명/다중도/스테레오타입/tagged value 등이 관련 없다.

2.2.16 작업중

  • 네임스페이스 : UML 패키지와 XML 네임스페이스의 연결
  • 프로파일
    • 기존 모델의 확장 또는 프로파일링 :

2.3 클래스 다이어그램 모범사례

https://github.com/ISO-TC211/UML-Best-Practices/wiki/Best-practices-for-diagram-design

클래스 다이어그램은 모델의 일부에 대한 뷰이며, 모든 측면을 보여주지 않을 수 있다. 하지만, 모델에 대한 인간의 이해를 위해 중요한 그림이다. 이 페이지는 쉽게 이해할 수 있으며, 깔끔하고 일관성 있는 클래스 다이어그램을 생성하기 위한 모범사례를 담고 있다.

2.3.1 필요한 다이어그램

19103 개념 스키마 언어에는 문서화를 위해 포함시켜야 하는 다이어그램를 포함하여, 모델의 문서화를 위한 규칙/권고사항이 있다.  

필요한 다이어그램

19103 개념 스키마 언어에는 문서화를 위해 포함시켜야 하는 다이어그램를 포함하여, 모델의 문서화를 위한 규칙/권고사항이 있다.  아울러 포함하면 유용한 다이어그램도 있다.

패키지 다이어그램

[[패키지 의존성 다이어그램]]

ISO 19103 요구사항 17 및 21에 따르면, 하나이상의 패키지 다이어그램에 (외부 패키지 포함한) 패키지간 의존성을 표현해야 한다. 

클래스 다이어그램

ISO 19103 및 ISO 19109에 있는 규칙과 별도로, 클래스 다이어그램을 위한 주요 모범사례는 모든 분류자(클래스, 코드 목록, 열거형, 데이터 유형)가 가 적어도 하나의 클래스 다이어그램에 표현되어야 한다는 것이다. 이 스크립트를 사용하면 이 규칙을 확인할 수 있다. 아울러 모든 속성, 연관, 연산, 제약은 적어도 하나의 다이어그램에 표현되어야 한다.

[[High Level 개요 다이어그램]]

주요 클래스와 연관만  있는 고수준 개요 다이어그램을 사용하면 모델을 잘 소개할 수 있다. 이 다이어그램에서는 속성 및 역할 명은 숨겨야 한다.

[[상세 개요 다이어그램]]

ISO 19103 추천사항 16에 따르면, 모든 패키지는 모든 클래스가 표시되는 (속성/연산/역할등은 숨김) 개요 다이어그램이 필요하다. 맥락을 이해하는 데 중요할 경우 속성/연산/역할 등을 표시할 수도 있다.

[[Perspective specific diagram]]

모델의 특정 부분, 주요 분류자에 중점을 둔 다이어그램은 모델의 이해에 유용하다. 적을수록 좋다(less is more)는 원칙을 기억하라. 하나의 다이어그램에 등장하는 요소가 적을 수록 가독성이 높아진다. 관점에 관련 없는 속성은 표시하지 말라.

[[Codelist, enumeration, data types]]

하나의 패키지에 있는 모든 codelist/enumeration/data type을 하나의 다이어그램에 표현한 다이어그램도 유용하다. 이런 분류자들은 다른 패키지에서 재사용되는 경우가 많으므로, 이처럼 하나의 다이어그램에 모두 모아두면 많이 도움이 된다.

[[각 분류자에 대한 Context Diagram]]

ISO 19103 요구사항 18에 따르면, 모든 분류자는 Context diagram에 표현해야 한다. 여기에는 모든 속성/연산 및 해당 분류자에서 탐색가능한 모든 관계를 표시해야 한다. 관계가 깊은 분류자의 경우, Context 다이어그램을 공유할 수 있다. 하지만,적을수록 좋다(less is more)는 원칙을 다시 한번 기억하라. 한 다이어그램에 등장요소가 적을수록, 관점이 적을 수록가독성이 높아진다.

유스케이스 및 시퀀스 다이어그램

유스케이스 다이어그램과 시퀀스 다이어그램은 모델 개발 과정에서 중요한 역할을 한다.

---- 앞으로 설명 및 예제를 추가할 예정 ---


객체 다이어그램

클래스의 인스턴스가 들어 있는 객체 다이어그램은 모델의 이해와 테스트에 매우 중요하다. ISO/TC211에 있는 객체 다이어그램의 예는 ISO 19160-1에서 볼 수 있다. ISO 19160-1 프로파일을 개발할 때, 몇몇 샘플 주소를 위한 객체 다이어그램이 필수이다. 

아래 그림은 ISO 19160-1의 INSPIRE 프로파일을 위한 객체 다이어그램이다.

2.3.2 클래스 다이어그램 디자인

폰트/색

https://github.com/ISO-TC211/UML-Best-Practices/wiki/Colours-and-fonts

[[폰트]]

19103 개념스키마 언어에는 다이어그램의 폰트 크기에 관한 추천사항이 하나 있다.

추천사항 15 : 다이어그램 작성시 가독성을 고려해야 한다. 폰트 크기는 다이어그램 축철을 고려하여 8포인트 이상이 되어야 한다.(예: 12 pt font at 90% is 12*0.9 = 10.8 pt)


이 권고사항도 모범사례 적을수록 좋다(less is more)와 관련이 있다. 다이어그램은 추천된 폰트 크리로 프린트할 수 있는 정도의 크기어야 한다.

INSPIRE Repository tutorial 의 규약에 따르면

기본 폰트는 Ariel


모든 모델에서 이 규칙을 따를 것을 추천한다.

[[색]]

다른 지형지물 카탈로그에서 가져온 클래스를 다른 색으로 표현하면 이해하는 데 도움이 된다. 하지만, 다음 사항을 기억해야 한다.

색은 모델의 일부가 아니며, 그래픽 표현일 뿐이다. 색에는 어떠한 모델 의미론도 저장할 수 없다.


ISO 표준(문서)의 그림들엔 색이 없어야 한다. 하지만, ISO 모델 및 기타 모델에서 다이어그램에 색이 사용되고 있다. 하지만, ISO 표준 및 동일한 요구사항이 있는 문서에서 사용할 경우, 반드시 흑백으로 export 시켜야 한다. 예를 들어, INSPIRE와 관련된 국가 사양에서는 INSPIRE 클래스에 색깔을 사용할 수 있다. 하지만 다음 사항을 지켜야 한다.

다이어그램에 색을 사용할 경우, 색에 대한 범례를 제공하라.


ISO 19160-1 주소 - 개념모델에서는 표준 프로파일 문서화를 위한 요구사항 및 추천사항이 있다. 이들은 다른 모델에도 적용할 수 있다. (7.5.2장)

기본 클래스와 프로파일 전용 클래스를 구분하기 위하여, 주소 기본 클래스는 배경을 투명하게하고, 프로파일 전용 클래스의 경우엔 shaded fill color 배경을 사용하라.


[[속성]]  

현재 색이 다른 클래스에 대해 속성을 부여하는 것이 불가능하다. 여기여기를 참고할 것. (두개 모두 깨진 링크)


적을수록 좋다(Less is more)

https://github.com/ISO-TC211/UML-Best-Practices/wiki/Less-is-more

이 글은 Geert Bellkeen의 블로그 글 5 rules for better UML diagrams 를 참조한 것이다.

    • 복잡한 모델을 위한 대형,  압도적인 다이어그램 보다는, 여러개의 작은 다이어그램으로 분리
    • 각각의 UML 다이어그램은 소수의 요소에 집중하고 정의된 관점이 있을 것.
    • 다이어그램의 관점과 관련이 먼 속성/연관/제한은 숨길 것

ISO 19157에서 가져온 아래 그림에서, 목적은 데이터품질 단위가 DQ_DataQuality와 하나 이상의 DQ_Element로 구성됨을 보이는 것이다. DQ_Element의 속성은 이 관점에서는 관련이 없으므로, 보이지 않도록 하였다. 아울러 DQ_Element의 연관요소도 관련이 없으므로 숨김 처리했다.

요소가 많이 들어 있는 개요 다이어그램도 있을 수 있다. 이러한 다이어그램은 요소와 연관만 보이고 속성은 숨겨야 한다. 연관의 역할명도 숨기는 것이 좋을 수 있다.

[[속성 표시여부 선택하기]]

한 요소의 속성/연산/제약/노트 표시/숨기기 : 해당 요소 우클릭 - Features & Properties -> Feature and Compartment Visibility (Cntl-Sht-Y)
모든 요소의 속성/연산/제약/노트 표시/숨기기 : 해당 다이어그램 선택(F5) - Properties - Element

[[역할명 표시여부 선택]]

하나의 역할 명 : 레이블 우클릭 -> Hide label
연관의 모든 레이블 숨기기 : 연관 우클릭 - Visibility -> Hide all labels
연관 label 중 일부 숨기기 : 연관 우클릭 -> Visibility -> Set label visibility

[[연관 표시여부]]

하나의 연관 : 연관 우클릭 - Visibility - Hide Connector
여러개의 연관 : Diagram - Visible Relations?? (Cntl-Sht-I)
모든 연관 : Diagram 을 우클릭 - Properties - Connectors - Show relations

연관 관계 선을 직각 표시(Orthogonality)

https://github.com/ISO-TC211/UML-Best-Practices/wiki/Orthogonality

이 글을 Geert Bellkeen의 블로그 글 5 rules for better UML diagrams 를 참조한 것이다.

잘 정돈된 다이어그램은 어지러운 것보다. 이해하기 쉽다. 요소들을 수평/수직으로 정돈하고 직각 연결선을 사용하는 것은 가독성을 향상시키기 위한 첫번째 단계이다.

아래 첫 그림에서, 요소는 자동 정렬되어 있고, 연결선은 직선으로 되어 있다. 그 다음 그림은 수평/수직으로 정렬되어 있으며, 동일한 간격으로 조화된 크기로 맞췄으며, 연결선은 직간으로 처리했다. 이 그림은 좀더 정렬되어 이해하기 쉽다.

지저분함:

정렬된 그림:

요소를 정렬하고 높이를 맞추는 도구는 원하는 요소들을 선택하고 우클릭하면 접근할 수 있다. 라인 스타일은 선 선택 - 우클릭 - Line Style에서 설정할 수 있다. 위 예제의 라인 스타일은 Tree Style - Vertical 이다. 이 스타일은 세개의 하위 클래스가 모두 DQ_Result에 대하여 동일한 관계가 있기 때문에 사용할 수 있다. 만약 이들 중 하나가 다른 관계(예: 집합관계)가 있을 경우, 이는 별ㄷ의 선으로서 표시되어야 한다.

다른 표준에서 온 클래스 표시

https://github.com/ISO-TC211/UML-Best-Practices/wiki/Illustrate-classes-from-other-standards

대부분의 표준은 다른 표준으로부터 클래스나 코드목록을 포함한다. 다이어그램을 잘 이해하기 위해서는 이들 요소들이 어느 표준에서 유래했는지를 도시해야 한다. 이 페이지에서는 이를 위한 두가지 접근법을 제시한다.

[[첫번째 방법 : 경계선(Boundary)]]

외부 요소를 표시하는 간단하면서도 유용한 방법은 다이어그램에서 요소 둘레로 경계선을 추가한 뒤, 표준의 이름과 번호(및 연도)를 텍스트로 추가하는 것이다. 이렇게 하면 쉽고도 직관적인 표현이 가능하다.

아래 그림은 ISO19157:2013 지리정보-데이터 품질에서 사용한 방법이다.

Enterpise Architect에서는 Toolbox 중에서 Common 그룹에 들어 있다.

이 방법의 단점은 외부 표준의 이름이 변경되었을 경우, 텍스트가 자동적으로 변경되지 않는다는 점이다.

[[두번째 방법 : 네임스페이스를 모두 표시]]

또다른, 좀더 유용한 해법은 아래 그림과 같이 외부 클래스의 완전한 네임스페이스를 모두 표시하는 방법이다. 이렇게 하면, 표준명 뿐만 아니라, 어떤 패키지가 이 요소를 소유하는지를 보일 수 있다. 하지만, 문장이 길어지고 혼란스러워질 수 있다.

완전한 네임스페이스를 보이려면, 다이어그램을 선택한뒤, Properties - Diagram - Show Namespace 및 Fully Qualified Namespace 를 선택하면 된다. (단, 외부에서 가져온 것 뿐만 아니라, 모든 것의 네임스페이스가 표시됨)

선을 교차시키지 말것

https://github.com/ISO-TC211/UML-Best-Practices/wiki/No-crossings

이 글은 Geert Bellkeens 의 블로그 글 5 rules for better UML diagrams 중에서 2번째 규칙을 참조한 것이다.

선이 교차하는 다이어그램은 읽기 힘들다. 따라서, 다이어그램에 있는 어떤 선도 교차해서는 안된다. 교차가 불가피하면 별도의 다이어그램으로 분리할 것을 고려해 보거나, 모든 관계가 올바른지, 현재의 다이어그램에 반드시 포함시켜야 하는지 여부를 고민해 보라. 적을수록 좋다(less is more)는 원칙을 다시한번 강조한다.

아래 첫번째 그림은 선이 교차하고, 불필요한 DQ_Element가 포함되는 등 여러가지 실수가 존재한다. 이 그림의 목적은 평가 방법에 관한 것이므로, DQ_Element는 목적과 관계없다. DQ_Element를 제거하고, DQ_AggregationDerivation을 위쪽으로 이동시키면 정렬되고 이해하기 쉬운 다이어그램이 완성된다.

잘못된 그림:

올바른 그림:

상위 요소를 위쪽으로 배치

https://github.com/ISO-TC211/UML-Best-Practices/wiki/Parents-up

이 글은 Geert Bellkeens 의 블로그 글 5 rules for better UML diagrams 을 참조한 것이다.

게층에서 가장 높은 요소는 다이어그램에서도 제일 높은 곳에 위치해야 한다. 

    • 하위 클래스는 상위 클래스 아래에 위치시킨다.
    • 집합 관계의 경우, 소유하는 측의 요소가 부분 요소의 아래로 내려가서는 안된다.
    • 구현의 경우, 원 요소가 위에 있어야 한다.
아래 첫번째 그림에서 하위 클래스가 부모 클래스보다 위에 있다. 이렇게 하면 다이어그램에서 계층을 이해하기 어렵게 된다.

그대신 아래 그림과 같이 하위클래스를 부모클래스 아래에 배치한다.

아래는 집합관계를 보인 것으로 "전체" 쪽이 위에 있다. 이것도 DQ_EvaluationMethod 클래스가 DQ_Element의 일부이므로 계층화의 일종이다.

크기를 조화롭게

https://github.com/ISO-TC211/UML-Best-Practices/wiki/Harmonize-sizes

이 글은 Geert Bellkeens 의 블로그 글 5 rules for better UML diagrams 을 참조한 것이다.

모델 요소의 크기를 조율하면, 가독성을 향상시킬 수 있다. 중요도가 동일한 하위클래스와 연관클래스는 가능한 한 크기가 같아야 한다. 또한 직교성을 유지하기 위해서는 요소의 높이를 통일시킬 필요가 있다.

아래의 그림에서 DQ_Result의 하위 클래스 3개는 모두 중요도가 같지만, 속성의 수가 다르다. 원하는 요소들을 한꺼번에 선택한 후, 우클릭 - Same Height and Width를 선택하면 모두 동일한 크기로 설정할 수 있다.

아래 그림에서 DQ_Element에 대한 연관 클래스도 중요도가 동일하다는 것을 보이기 위해 동일한 크기로 설정하였다. 연관 클래스의 속성은 그림과 관련 없기 때문에 가독성 향상을 위하여 숨김처리하였다. (적을수록 좋다를 참고할 것)

제약(Constrains) 표시

https://github.com/ISO-TC211/UML-Best-Practices/wiki/Constraints

[[제약이란]]

제약이란, "요소의 의미론을 선언하기 위한 목적으로 자연언어 혹은 기계가독언어로 표시한 제한이나 조건"이다(ISO 19103).  제약은 예를 들어, 어떠한 조건하에 속성이 필수가 되는지 등의 조건을 설정함으로써, 모델에 정밀함을 추가하므로 중요하다. 개념 수준에서 제약을 표현하는 것은 검증, 관리 및 데이터 관리에 중요하다.

ISO 19109에는 여러가지 제약의 예가 있다.

    • 제약은 하나이상의 지형지물 인스턴스(다른 데이터 유형에 속한 것도 무방)에 있는 속성 값의 허용 조합을 지정할 수 있다.
    • 제약은 지형지물 인스턴스간의 연관관계 다중도를 제한할 수 있다.
    • 제약은 실세계 현상이 어떤 크기일 경우, 지형지물 인스턴스가 어떤 GM_Object의 하위유형으로 표현될 것을 요구할 수 있다.
    • 지형지물 연산에서 정의된 지형지물의 행태는, 제약으로서 제한할 수 있다.
[[제약 표현 방법]]

UML에서 제약은 자연언어 또는 기계가독언어, 일반적으로 객체 제약 언어(OCL, Object Constraint Language)로 표현할 수 있다. ISO 19103 권고사항14에 따르면, "제약은 OCL 2.0에 정의된 객체 제약 언어를 사용하여 표현한다. 또한 제약은 모델에 대한 문서에서 자연언어로 기술한다."고 되어 있다. OCL 표현은 구현에 중요하며(필수는 아님), 자연언어 표현은 인간의 이해에 중요하다.

[[자연어로서 먼저 작성하라]]

OCL로 제약을 작성하는 것은 직관적이지 않으므로, 먼저 자연어를 기술한 후, 이를 근거로 OCL을 추가한다.

[[OCL 작성방법]]

[[구현에서 제약 활용 방법]]

제약을 구현에서 사용함에 있어, ISO 19136 (GML) 부속서 E 의 내용을 참조한다. "모든 OCL 제약은 무시한다. 인스턴스 모델이 제약조건에 맞는지 평가하는 것은 GML인스턴스를 처리하는 응용에서 담당할 몫이다. 비고: Schematron 언어를 사용하여 OCL 제약을 GML 응용스키마를 표현하는 XML 스키마의일부로서 표현할 수 있다." 이는 GML 응용 스키마는 제약을 포함하지 않으며, 제약은 Schematron이나 데이터를 처리하는데 사용하는 응용에서 처리해야 한다는 의미이다.

ShapeChange를 사용하면 스키마에 정의된 OCL 제약을 파싱할 수 있다. ShapeChange는 OCL 제약으로부터 Schematron 규칙을 유도할 수 있다. OCL->Schematron 변환에 관한 자세한 내용은 여기를 참고하라.)

[[EA에서 제약 사용하기]]

== 클래스 수준에서 제약 기술하기

    • 제약은 반드시 클래스에 대한 특질으로서 서술되어야 한다. 다이어그램 및 다른용도, 모델 문서화에서 제약이 항상 클래스 를 따라다니도록 하기 위함이다.
    • 제약을 속성 수진에서도 쓸수 있지만, 추천하지 않는다. 다이어그램에서 속성에 추가된 제약을 표현할 방법이 없는 것처럼 보이기 때문이다.
    • 다이어그램 노트로서 제약을 쓸 수도 있지만, 이렇게 해서는 안된다. 이렇게 만들면 제약이 다이어그램의 일부가 되고, 클래스의 일부가 안되기 때문이다.

클래스/열거형/데이터 유형의 제약은 Properties 다이얼로그에서 Constraints 탭에서 접근할 수 있다.

    • OCL을 쓸경우, Type=OCL로 선택하라. 자연언어 표현은 다음방법으로 추가할 수 있다.
      • 해당 제약의 이름
      • 코멘트 /*... */로 처리하여 제약 내부
    • 자연언어로만 제약을 작성할 경우에는 Type=Invariant로 선택하라.

context 부분에 추가하지 말라. 이는 GUI를 통하여 암묵화되기 때문이다???

OCL 유형의 제약을 저장할 때, EA에서 (간단한) 문법 검증을 시행하며, EA의 관점에서 OCL 제약이 유효한지 아닌지에 대해 메시지를 출력한다.

== 제약을 다이어그램에 표시하는 방법

제약은 UML 다이어그램에서 2가지 방법으로 표시할 수 있다. 첫번째는 요소에 첨부된 노트, 두번째는 클래스를 나타내는 요소 내에 표현하는 방법이다. 일반적으로제약은 클래스 내부에 표현하는 것을 추천한다. 아래 그림은 제약을 클래스 내에 표시하는 방법과, 노트로서 표현하는 방법을 보인 것이다.

    • 다이어그램 전체의 제약을 표시하려면, 다이어그램 우클릭(F5) - Properties - Element 를 선택하고 Constrains 를 켠다.
    • 특정 한 요소의 제한을 표시하려면, 요소 우클릭 - Feature and Compartment Visibility(Cntrl-Sht-Y)를 선택하고 Constrains 를 켠다.

어떤 경우, 어떤 특정한 제약을 요소에 첨부된 노트로서 표시하는 것이 좋을 수 있다. 이 경우, 다이어그램에 노트를 추가하고, 요소에 이를 연결하면 된다. 링크 우클릭 - "Link this note to an element feature"를 선택한다. 이때 나타나는 다이얼로그에서 Feature Type = Constraint 를 선택하고, Feature 목록에서 원하는 제약을 선택한다.


2.3.3 모델 문서화


3. 모델 문서화

https://github.com/ISO-TC211/UML-Best-Practices/wiki/Documentation

3.1 모델의 자동 문서화

https://github.com/ISO-TC211/UML-Best-Practices/wiki/DocumentationOfUmlModels

ISO/TC 211 애드혹 그룹에서는 UML로부터 문서화하는 방법에 대해 조사하였다. 적용 범위는 어떤 모델인지 명확하지 않았지만, 작업과정에서 ISO/TC 211 조화모델에 있는 UML 모델에 집중하였다. 이는 UML모델 저장소로서 ISO/TC 211 표준의 일부이다.

하지만, 문서화 도구는 조화모델 포함 여부에 관계없이, ISO 19103에 따라 모델링된 어떠한 UML 모델에도 적용할 수 있다. 

UML 문서 자동생성은 전세계, 지역, 지역(국가) 수준의 UML 응용스키마에 대해서도 유용할 것이다.

문서화 도구는 아래 문서에서 사용할 수 있다. 링크는 여기

 Automatic generation of documentation from UML models.docx

EA 용 템플릿은 아래에 있다. 링크는 여기

 ISOTC11_EA_report_template.zip

ShapeChange 설정 방법 및 UML 모델 테스트는 여기를 볼 것

3.2 모델의 버전

https://github.com/ISO-TC211/UML-Best-Practices/wiki/Model-versions

2.2.5 일반 - 모델의 버전와 동일함

3.3 다이어그램을 이미지 파일로 내보내기

https://github.com/ISO-TC211/UML-Best-Practices/wiki/Diagram-export

Enterprise Architect에 있는 Diagram 메뉴에서 다이어그램을 이미지로 저장할 수 있다.(단축키 Ctrl-T) 다이어그램을 클립보드로 복사하려면 Ctrl-B를 누른다.

기본값으로서, 다이어그램은 shading 되고, 다이어그램 이름이 레이블로 달리는 프레임이 생성된다. 쉐이드, 프레임, 레이블을 없애는 방법은 다음과 같다.

쉐이드 삭제

Tools - Options - Diagram - Themes 에 들어가서 Monochrome for printing을 선택한다.

프레임 제거:

Tools - Options - Diagramsㅇ로부터 Diagram Frames를 제거한다. 아울러 scale을 200%로 저장하면 문서에서 최적의 해상도를 얻을 수 있다.


4. 도구, 스크립트 등

4.1 Enterprise Architect 스크립트

4.1.1 EA 샘플 스크립트

https://github.com/ISO-TC211/UML-Best-Practices/tree/master/Scripts

아래는 Visual Basic Script의 내용임

https://github.com/ISO-TC211/UML-Best-Practices/tree/master/Scripts/VBScript

모델을 바꿔주는 스크립트(CHG)

    • CHG Sort elements.vbs - 선택된 패키지에서 요소들 정렬
    • CHG Save Project As.vbs - 프로젝트 복사본 저장
문서화를 위한 스크립트(DOC)
    • DOC Count subpackages.vbs - 선택된 패키지에서 1단계 하위 패키지 수 
    • DOC Export diagrams as images.vbs - 다이어그램을 이미지 파일로 저장
    • DOC Export mapping files.vbs - 태그값에 기반한 매핑 파일 내보내기
    • DOC List prefixes.vbs - 클래스와 열거형을 위한 모든 접두사 목록
검증용 스크립트(VAL)
    • VAL Data type references.vbs - 데이터 유형 참조 목록을 만들고 빠진 참조 보고
    • VAL Duplicate element names.vbs - 중복 요소명 식별
    • VAL Elements in diagrams.vbs - 선택된 패키지 혹은 하위패키지에 있는 다이어그램에서 사용되지 않는 요소 식별
    • VAL Missing definitions.vbs - 정의가 없는 요소 및 속성 목록
    • VAL Model Validation.vbs - ISO 19103:2015 및 ISO 19109:2015에 정의된 규칙에 따른 모델 요소 검증
버전 관리 처리용 스크립트(VC)
    • VC Add Subpackages.vbs - 버전 관리를 위한 패키지 추가
    • VC Get All Lates.vbs - 선택된 패키지 및 하위패키지를 위한 모든 최신 것을 가져옴
    • VC Resync Status.vbs - 버전 관리 청소 - 선택된 패키지 및 하위패키지를 루핑하면서 VC Provider에 상태를 다시 싱크함
    • VC Remove Version Control.vbs - 버전 관리 제거. 선택된 패키지 및 하위패키지를 루핑하면서 버전 관리 제거
##위의 목록 스크립트, MDG Technology 그룹에 속해져있는 것
    • HMMG Script
    • Version Control Script
MDG Techonologies를 EA 모델로 가져오는 방법

기타 스크립트

4.2 EA에서 모델 찾기

https://github.com/ISO-TC211/UML-Best-Practices/wiki/Model-searches-in-Enterprise-Architect

4.2.1 EA 모델에서 검색

EA에서, 원하는 요소를 빨리 찾기 위해서는 model searches를 시행하면 된다. (Project Browser Toolbar에서 접근가능한, Find in Project Browser 버튼을 사용한 검색과 혼동하지 말라). Search는 Edit - Find in Project or Edit - Search in Model(Ctrl-F 또는 Ctrl+Alt+A)에서 접근할 수 있다. Search 드롭다운에서 검색을 한 뒤 Run 버튼을 누른다.

"Find in Project(Ctl-F)"의 여러가지 기능 (Start - Explore - Search - Search in Model)

[[미리 정해진 찾기 기능(Built-in Search)]]

EA의 Search 드롭다운에는 "Built-in"이라는 미리 정의된 검색 이 있다.

[[XML 파일로부터 가져온 검색]]

검색을 XML 로부터 import할 수 있다.(최상위 태그가 <RootSearch>) Search Builder Toolbar에서 Import Search를 누르면된다. XML파일로부터 가져온 검색은 검색 드롭다운에서 "My Searches" 범주에 나타난다.

[[MDG Technology의 일부인 검색]]

MDG Techonology(최상위 태그가 <MDG.Technology>)는 Tools - MDG Technology Import에서 가져올 수 있다. MDG Techonology의 일부로 가져온 검색은 검색 드롭다운에서 MDG Techonology라는 이름의 범주로 나타난다.

4.2.2 새로운 검색 정의 생성

EA에서, 자신만의 검색을 정의할 수 있다. (EA 사용자지침서 Create Search Definitions 참조) 가장 강력한 검색은 EA 마크로를 사용하여 강화한 SQL 검색이다. (EA의 데이터베이스 엔진은 기본 Jet 3.5 이며, 이는 마이크로소프트 Access와 동일하다.)
    1. Edit - Find in Project (Ctrl-F 또는 Ctrl+Alt+A)
    2. Builder 버튼을 클릭한다.
    3. 새로운 검색 정의를 생성한다. 이름을 주고 Editor Type이 SQL Editor인지 확인한다.

    1. 검색을 SQL로 정의한다. 필요시 마크로도 포함

    1. Project Browser에서 검색하고자하는 요소를 선택한다.
    2. Run 버튼을 누른다.

4.2.3 검증시 검색을 사용하기

검색을 사용하여 클래스, 속성, 기타 UML 요소가 특정 요구사항이나 권고사항에 부합하지 않는 요소를 알아낼 수 있다.

---- 향후 작업

4.2.4 검색 공유

검색 불러오기 및 내보내기

Search Builder 툴바에 있는 Export Search 버튼을 사용하면 다이얼로그 박스가 나타나고, 여기에서 XML 파일로 내보내고자하는 검색을 선택할 수 있다. 이 XML 파일을 Import Search 버튼을 사용하면 다른 사람이 불러올 수 있다.

참고로, 불러들이는 검색 정의가 이미 있는 검색정의와 이름이 중복될 경우, 동일한 이름을 가진 두개의 검색 정의가 생긴다. 

이러한 XML 파일은 UML 모델과 동일한 저장소에 저장할 수도 있다.

MDG Technology에서 Bundle Search

--- 향후 작업

4.2.5 검색 팁

CLASSGUID 와 CLASSTYPE

결과 셋(result set)의 일부로 CLASSGUID 와 CLASSTYPE을 지정할 경우, EA는 각 결과줄 앞에 해당 아이콘을 그려준다. 결과 셋에서 더블클릭하면 요소, 연산 및 속성이 직접 열린다. 다이어그램과 패키지는 직접 열리지 않는다. 이들은 Alt-G를 통해 프로젝트 브라우저에서 찾은 후 열어야 한다. Inside Enterprise Architect, EA User Guide 참고

4.3 ShapeChange plugin

https://kartverket.no/geodataarbeid/standarder/sosi/programmer-og-verktoy/

이 페이지에서는 SOSI 정의 파일의 품질관리 및 제품사양 생성에 도움이 되는 프로그램과 도구를 다운로드 받을 수 있다.

EA용 설정 프로젝트 파일

이 프로젝트 파일에는 SOSI 전체 모델 등록물을 포함하며, 문서화 템플릿, SOSI 모델 검증기, SOSI UML 프로파일 5.0 등이 있다. EA에서 여는 방법은 설치 가이드를 참고하라.

Download SOSI Model Register (eap, 350 MB)

SOSI 문서화 템플릿 (EA)

최종 SOSI 제품사양의 정보모델(5장)에 해당하는 UML 모델의 그림 및 텍스트 설명을 내보내기 위하여 EA에 설치해야 할 RTF 템플릿

Download SOSI documentation template in EA (xml) - updated 28.09.2017

SOSI 문서 RTF로부터 DOCS

EA 보고서를 향상시키는 마크로가 담겨있는 Word 템플릿. 정보모델을 제품사양서에 입력하기 전.

Download SOSI documentation from RTF to DOCX (dotm) - updated 28.09.2017

Shape Change

ShapeChange는 UML 모델로부터 GML을 생성하는데 사용된다. 자세한 매뉴얼은 www.shapechange.net에서 확인할 것

EA의 SOSI 플러그인

이 플러그인은 UML 모델로부터 SOSI 관리 및 SOSI 실현을 위한 정의 파일을 생성하기 위한 것이다. 이 플러그인의 일부로서 SOSI UML 프로파일이 설치된다.

이 EA 플러그인은 Arkitektum AS에서 개발하였다.

Download SOSI plugin in EA version 2.0.0.28 (exe)

SOSI UML 프로파일 5.0

이 프로파일은 표준 스테레오타입을 정의한다.

Download SOSI UML profile (xml)

SOSI 모델 검증 Add-on 1.0

이 도구는 EA 애드온으로서, 당신의 모델이 UML Modelling 5.0 규칙의 요구사항 및 권고사항을 충족시키는지를 점검하기 위한 목적이다.

Download SOSI Model Validation from the Mapping Authority's Github account .

UML 모델링 스크립트

노르웨이 매핑기관의 Github 계정에는 UML 모델을 작업할 때 도움이 되는 (예를 들어, 제품사양을 위한 모델 준비시 사용하는)스크립트를 몇개 올려두었다. 이들 스크립트는 EA용이다. 

SOSI_ps

제품 사양 문서를 위한 출발점을 생성하는 프로그램

Download SOSI_ps version 28.10.2013 (zip)

4.4 ShapeChange를 이용하여 조화 모델로부터 XML 스키마 생성

ISO TC211 UML 모델을 실제 응용에서 활용하기 위해서는, 정보처리 에이전트간에 직렬화되고 전달할 수 있는 표현으로 구현되어야 한다. 대부분의 현재 구현은 XML을 직렬화 스킴으로 사용하는데, 이때 XML 스키마 문서를 사용하여 교환 문서의 구조를 정의한다. 개념 모델을 구현하는 스키마를 자동으로 생성하기 위해서는, UML 모델로부터 XML 스키마를 자동적으로 생성하는 소프트웨어 절차가 필요하다. 여기에서 설명하는 절차는 여러가지 최신 표준에서 사용될 수 있다.

4.4.1 소프트웨어 요구사항

이 절은 아주 개략적인 내용이다. 자세한 내용은 조화모델 관리그룹 위키를 보라

Enterprise Architect(EA) : ISO/TC 211 조화 UML 모델을 개발/갱신관리하는데 사용되는 상용 소프트웨어 패키지. 여기에서 설명하는 내용은 12.1.1230을 기반으로 한다. 2017-07 현재 EA의 버전은 13.5이나, 여기에 있는 절차는 새로운 버전으로 테스트하지 못했다.

ISO/TC 211 조화 모델 : ISO/TC 211 조화모델은 웹에서 접근가능한 디렉토리에 저장되어 있으며, 여기에는 TC 211 작업과정에서 만들어진 모든 UML 모델을 담고 있는 파일이 들어있다. 모델은 EA로 부터 XMI(XML interchange format for UML)을 사용하여 export하였으며, 이들 XMI 파일은 온라인 디렉토리에서 버전관리를 하고 있다.(,아래의 Subversion 참고) Enterprise Architect외의 UML 모델링 소프트웨어 패키지도 XMI 파일을 사용할 수 있지만, 실질적으로 모델의 모든 측면(노트, 태그, 색깔 등)을 번역할 수 있을 만큼 충분히 신뢰할 정도로 포맷이 표준화되어 있지 않다. TC 211 조화모델에 있는 XML 문서는 다음과 같은 네임스페이스를 사용하고 있으며(xmi.version="1'1", xmlns:UML="omg.org/UML1.3", EA exporter 버전은 2.5이고, windows-1252 캐릭터 인코딩을 사용하고 있다.

Subversion : TC 211 조화모델 저장소는 Subversion 소프트웨어를 사용하여 관리되고 있다. Subversion은 Apache Software Foundation의 오픈소스 패키지이다. 모델 컴포넌트를 체크아웃하고 변화를 체크하기 위해서는 자신의 컴퓨터에 subversion client가 있어야 한다.

ShapeChange : Interactive Instruments GmbH 소프트웨어의 오픈소스 패키지로서, UML 에서 XML 변환을 구현하여 모델 구현을 위한 XML 스키마를 생성해준다.

SolidGround : CSIRO에서 원래 제작한 EA를 위한 소프트웨어 확장으로서, ShapeChange를 수행하기 전, UML 모델을 테스트할 때 매우 유용하다. 이 소프트웨어는 더이상 CSIRO에서 관리하지 않는다. Windows 설치자(Solid_Ground_Setup.msi)는 XML Maintenance Group 저장소에 있다. 이 저장소에는 약간의 문서도 준비되어 있다. 

4.4.2 모델 설정

TC 211용 XML 스키마를 생성하기 위해서는 UML 모델을 구성할 때 특정한 UML 프로파일을 따라야 한다. 문제가 있으면 온라인 ShapeChange 문서를 참고하라. 핵심적인 스테레오타입 몇개를 소개하면 다음과 같다.

스테레오 타입 

적용 범위 

해석 

 Application Schema

 UML 패키지

 해당 패키지에 담긴 클래스는 하나의 XML 네임스페이스로서 구현된다.

 Abstract

 클래스

 해당 클래스는 XML에서 추상요소로서 구현된다. 이 클래스는 UML모델에서 하나이상의 구체(concrete) 클래스의 대상(target)이어야 한다.

 Union

 클래스

 이 스테레오타입은 클래스의 인스턴스에서 해당 UML클래스 내의 속성이 단 하나만 허용함을 나타낸다. XML 스키마에서는 xsd:choide로서 구현된다.

 CodeList

 클래스

 이 스테레오타입은 해당 UML 클래스가 gco네임스페이스에서 정의된 코드목록으로서 구현되며, 클래스내의 속성은 허용된 값만 적용됨을 나타낸다.

별도의 XML 네임스페이스로서 구현되는 각각의 모델 모듈은 별도의 UML 패키지로서 존재해야 하며, 이들 패키지의 스테레오타입은 <<Application Schema>>이어야 한다. Application Schema 패키지는 표 및 그림에 있는 태그가 존재해야 한다.

 태그

값의 예 

참고 

 targetNamespace

 http://standards.iso.org/ iso/19115/-3/cit/2.0

 XML 스키마 파일에서 선언되어야 하는 네임스페이스 URI

 version

1.0 


 xmlns

cit 

 XML 스키마에서 접두어(prefix)요소로서 사용되는 3자리 문자. TC211 범위내에서 고유해야 함 

 xsdDocument

ISO19115-3/cit/1.0/cit.xsd 

 XML스키마를 생성하기 위한 Path fragment 및 파일명. 이 파일 경로는 스키마 생성과정이 실행되는 장소에 추가된다. 아래를 보라.

 xsdEncodingRule

iso19139_2007 

UML-XML 변환 법칙을 위한 식별자. 현재 반드시 iso19139_2007 이어야 한다.

응용스키마 패키지는 반드시 하나이상의 하위 패키지를 가져야 하며, 이들 각각은 별도의 xml 스키마 파일에서 구현된다. 명확성을 위하여, 이들에게 스테레오타입 <<Leaf>>를 부여할 수 있으나. 이는 요구사항이 아니다.

응용스키마 수준에서 하나의 XML 스키마 파일이 생성된다. (이름은 해당 패키지의 xsdDocument 태그로 지정함(위의 예에서는 cit.xsd) 이 스키마파일은 <xsd:include>요소를 사용하여, 응용스키마 패키지 내에 있는 하위 패키지에서 생성된 스키마 파일을 include시킨다. 별도 분리된 스키마 파일을 원하는 경우(추천됨), 응용스키마 패키지내의 패키지에 xsdDocument 및 xsdEncodingRule 태그가 있어야 한다. 참고로 xsdDocument 경로는 <xsd:include> 경로가 간단해지도록, 최상위 xsd의 문서 경로와 일치하는 것이 좋다. (자세한 내용은 아래의 후처리를 참고)

UML 클래스 속성을 위한 태그

UML 클래스의 속성 및 탐색가능한 연관역할은 sequenceNumber 태그를 가지는 것이 좋으며, 이때 일련번호는 개별 UML 클래스 범위내에서 고유해야 한다. 일련번호는 필수가 아니며, 없을 경우 ShapeChange에서 자동생성한다. 존재하지 않을 경우, 특질을 위한 XML 요소는 클래스에 나타난 순서를 따르지만, 클래스에 다른 클래스로의 연관이 존재할 경우, 생성된 XML 스키마내에서의 이러한 요소의 순서는 예측불가능하다. 일련번호 사이에 공백이 있어도 무방하며, 속성이나 연관이 많고 나중에 새로운 속성이 추가되거나 순서나 변경될 가능성이 있는 경우 이런 공백이 도움이 될 수 있다.

패키지 간의 연결

EA 모델에서 다른 TC 211 응용스키마의 클래스는 반드시 EA 인터페이스를 사용하여, 해당 클래스에 대한 링크로서 포함해야 한다. 클래스명을 직접입력하면 필요한 내부 링크가 만들어지지 않는다. 이들 링크가 있으면 EA에서 의존성(dependency) 다이어그램을 자동 생성하고, UML-XL 프로세서로 생성할 때, 필요한 네임스페이스를 xml 스키마로 가져온다.

4.4.3 스키마 파일의 구조

결과 스키마는 여러 ISO 스키마를 위한 디렉토리구조로서 불러진다.(아래그림) 다른 모델에서 import 또는 하나의 모델의 여러 부분을 구현하는 스키마를 include하는 경로는 이 디렉토리 구조를 따른다. 최상위 폴더에는 각각의 TC211 표준을 위한 폴더가 있다.(ISO19115, ISO19110등) 이들 폴더에는 모델에서 정의된 각각의 xml 네임스페이스를 위한 하위폴더가 있는데, 네임스페이스 약어가 폴더명으로 사용된다. 다음 수준의 하위폴더는 각 네임스페이스 구현을 위한 버전 번호로 이름이 부여되며, 실제 스키마 파일은 해당 스키마를 위한 버전번호 폴더 내에 존재한다.

스키마는 'xsdLocation' 태그값에서 지정한 구조로 불러들여지게 된다. 이 태그값은 생성된 스키마가 저장될 위치에 대한 경로를 제공한다. 경로 위치는 ShapeChange가 수행된 최상위 디렉토리에 대한 상대경로가 된다.

4.4.4 작업 순서


==

원문 : https://github.com/ISO-TC211/UML-Best-Practices/wiki

Posted by 푸른하늘 푸른하늘이

댓글을 달아 주세요

공간정보/표준2020. 1. 10. 13:19

개요

https://github.com/ISO-TC211/HMMG/wiki

이 위키의 목적은 ISO/TC211 조화 UML 모델(Harmonized UML Model)의 사용자 및 편집자에게, 이 모델에 연결하고 작업하는 방법을 알려주기 위한 것이다.

ISO/TC 211 조화 UML 모델에 접근하는 방법

ISO/TC 211 조화 UML 모델은 Sparx ProCloud Service에 있는 Sparx Enterprise Architect 에서 관리된다. 이 모델은 웹 브라우저를 통해서도 접근할 수 있으며, Enterprise Architect에서 재사용가능 자원(Reusable Asset)을 통하여, 혹은 Enterprise Architect에서 Sparx ProCloud 로 직접 접근할 수도 있다.

WebEA 접근

조화 UML 모델은 http://iso.sparxcloud.com에서 제공된다. 등록된 사용자는 로그인 후 모델을 편집할 수 있으며, 모든 사용자는 읽기 전용 모드로 접근할 수 있다. WebEA 모델은 클라우드 저장소에 있는 현재의 모델을 보여주며, 항상 최신 상태로 유지된다.

EA 프로젝트 다운로드

조화모델에 대한 복사본이 들어 있는 Enterprise Architect 프로젝트는 HMMG GitHub에서 다운로드 받을 수 있다. 이 복사본은 주기적으로 갱신된다.

재사용가능 자원

HMMG 모델중 일부는 다른 모델에서 불러들여서 재사용가능 자원(Reusable Asset)으로서 사용할 수 있다. 모델 요소에 대한 GUID는 예전의 Subversion 기반의 저장소로부터 관리되므로, 지역 모델로부터 조화모델로의 기존 링크는 모두 변경되지 않는다. asset 서비스에 연결하려면, Reusable Assets 사용자 지침서를 참고하라. 연결시 다음의 매개변수를 적용한다. Name: iso_in_the_cloud   Protocol: http Server: 104.130.217.178   Port: 804 Model Name: iso

저장장치를 선택하고 모델을 불러들인다(import). 각각의 표준번호별로 모든 부 및 판본을 포함한 저장소가 생성된다. 표준 개발시 중요한 사항으로서, 개발중인 표준만 있는 추가적인 패키지가 추가로 존재할 수 있다.(Additional packages with only the standard in development may exist in addition.) 이들은 새로운 버전으로 주기적으로 갱신된다.

Enterprise Architect에서 직접 접근 (편집자 전용)

Enterprise Architect에서 직접 접근하려면, 클라우드 연결 열기(open a cloud connection)을 선택하고 다음의 매개변수를 적용한다. Name: iso_in_the_cloud   Protocol: http Server: 104.130.217.178   Port: 804 Model Name: iso

사용자 이름과 비번을 입력한다.

조화 모델의 구조

아래 글 참조

조화모델의 패키지 구조에 관한 설명

태그 값(Tagged Values)

각각의 패키지에는 해당 표준, 부, 버전을 구분하기위한 태그값이 추가되어 있다. 아래 글 참고

 

모델에 사용되는 접두어

https://github.com/ISO-TC211/HMMG/wiki/Prefixes


지리정보를 UML로 모델링하기 위한 모범 사례에 관한 ISO/TC211 위키

https://www.internetmap.kr/entry/UML-Best-Practices
지리정보를 UML로 모델링하기 위한 최적 사례를 설명하는 글

====

조화 모델의 패키지 구조

https://github.com/ISO-TC211/HMMG/wiki/Structure-of-the-Harmonized-Model

이 페이지는 조화 모델의 구조에 대해 설명한다. 설명된 구조는 새로운 표준 프로젝트에서도 사용해야 한다.

아울러 지리정보를 UML로 모델링하기 위한 모범 사례에 대한 ISO/TC 211 위키 를 참조하라.

 

주요 패키지 구조

조화 모델은 아래와 같이 "ISO TC211", "OGC", "Other ISO Standards" 등 세가지 패키지로 구성된다. 

ISO/TC 211 조화모델(HM)의 구조

표준 패키지 구조

메인 패키지 "ISO TC211" 속에는 각각의 표준이 서브 패키지로 들어 있다. 이들 서브 패키지에는 부(part)별, 버전(edition)별로 패키지가 구성되어 있다.

메인패키지의 표준 명은 다음과 같은 형태로 구성된다.

 

ISO [표준번호][주 표준 명]   예) ISO 19110 "Methodology for featre cataloguing"

 

부/버전별 패키지 명은 다음과 같은 형태로 구성된다.

 

ISO [표준번호]-[부 번호] Edition [판번호]    예) "ISO 19110 Edition 2" 또는 ISO 19115-1 Edition 1"

ISO 조화모델의 구조

태그 값(Tagged Values)

각각의 패키지는 표준/부/버전을 식별할 수 있는 추가적인 태그값을 가지고 있다. 상세한 내용은 패키지 태그 값을 참조

 

모델링

ISO/TC211 모델은 "지리정보를 UML로 모델링하기 위한 ISO/TC211 모범사례"에 따라 모델링되어야 한다.

====

조화 모델의 패키지 태그

https://github.com/ISO-TC211/HMMG/wiki/Package-tags-in-the-Harmonized-Model

이 글은 조화 모델에서 패키지에 사용되는 태그 값(tagged values)를 설명한다. 이 태그 값들은 새로운 표준 프로젝트에서도 사용되어야 한다.

지리정보를 UML로 모델링하기 위한 방법은 "지리정보를 UML로 모델링하기 위한 ISO/TC211 모범사례"를 참고하라.

 

주 표준 패키지 태그

각각의 주 표준 패키지에는 표준을 식별하는 2개의 태그가 존재한다.

  • number : 주 표준의 번호. 예) "19110", "19115" 등
  • name : 주 표준 명 예) "Methodology for feature cataloguing", "Metadata" 등

ISO 표준 조화 모델 주 패키지 태그 값

표준 버전 패키지 태그

각각의 표준 버전 패키지에는 특정한 부(part) 및 버전을 식별하는 5개의 태그가 존재한다.

 

  • number : 주 표준의 번호. 예) "19110", "19115" 등
  • name : 주 표준 명 예) "Methodology for feature cataloguing", "Metadata -- Part 1:Fundamentals" 등
  • edition - 공식 ISO 표준 버전 번호
  • publicationDate - 발행월 (yyyy-mm)
  • yearVersion - 발행년(yyyy)

ISO 표준 조화 모델 하위 패키지 태그 값

 

Posted by 푸른하늘 푸른하늘이

댓글을 달아 주세요

공간정보/표준2019. 10. 11. 15:30

국가공간정보포털 지식공간의 KSDI 표준체계 문서에는 총 23개의 기술기준이 등록되어 있다. 이중 공간정보 작성 및 제작관련 기술기준은 18개, 측량관련 기술기준은 13개, 기타 업무지침이 6개로 분류되어 있다. 측량의 결과도 실질적으로 공간정보라고 할 수 있으므로, 사실상 여기에 등록되어 있는 기술기준은 대부분 공간정보 제작에 관한 기술기준이라고 할 수 있을 것이다.

하지만, 이들 기술기준은 "공간정보표준에 적합한 기술기준"은 아니다.  국가공간정보 기본법 제23조(표준 등의 준수의무)에는 "공간정보체계의 구축ㆍ관리ㆍ활용 및 공간정보의 유통에 있어 이 법에서 정하는 기술기준과 다른 법률에서 정하는 표준을 따라야 한다."고 규정이 되어 있다. 이 규정만 보면 기술기준을 따라 작업을 하면 표준에 적합한 데이터가 생산될 것처럼 보이지만, 현재의 기술기준은 표준과 거리가 멀고, 현재 생산되고 있는 데이터도 대부분 표준에 적합하지 않다.

정부 및 지방자치 단체는 규정에 따라 일한다. 좀 극단적으로 이야기해서 규정에 어긋나면 아무것도 할 수 없는 것이 규정이다. 따라서 국가공간정보 기본법에서 표준을 지키라고 되어 있지만, 규정에 명시되어 있지 않으면 아무 것도 할 수 있는 것이 없다. 반대로 이야기하면, 일상 업무에서 표준에 적합한 데이터가 생산되기 위해서는, 기술기준을 따라 작업을 하면 자연스럽게 표준에 부합하도록 규정을 개정해야 한다는 것이다.

기술기준을 개정할 때 유의할 점이 있다. 제품 규격과 제작 방법을 구분해야 한다는 것이다. 우리나라 공간정보 관련 기술기준, 즉 각종 작업규정에는 대부분 데이터 제품에 대한 규격(중의 일부)과 제작 방법이 함께 규정되어 있다. 하지만, KS X ISO로 대표되는 공간정보 표준에는 제품의 규격에 관한 표준만 존재한다.

제품 규격이란 해당 제품 그 자체에 대한 규격을 말한다. 즉, 제품에 어떠한 지형지물이, 어떠한 구조로 만들어지며, 각각의 지형지물의 품질은 어떠하고 어떻게 평가해야 하는지, 생산되는 결과물과 함께 제공되어야 하는 메타데이터에는 어떤 것이 담기는지, 어떤 포맷으로 배포되는지 등, 제품을 생산하고 배포할 때까지 전 과정에 대한 기준이다. 

제품 규격은 KS X ISO 19131 "데이터제품 사양서"에 정의되어 있다. 제작하는 데이터 제품의 종류별로 이 표준에 따라 데이터 규격을 만들고, 이를 기술기준으로 등록해야 한다.  예를 들면, "항공사진측량 작업규정"이 아닌 "1/5,000 수치지형도 제품규격서",  "토지피복지도 작성지침"이 아닌 "토지피복지도 제품규격서", "수치지도 수정용 건설공사 준공도면 작성에 관한 지침"이 아닌 "건설공사 준공도면 제품규격서"가 기술기준으로 등록되어야 한다.

제품 규격이 정해지면 제작 방법은 다양할 수 있다. 예를 들어 1/5,000 수치지형도를 제작할 때, 현재는 대부분 항공사진 측량으로 제작되고 있으나, 적절한 고해상도 위성영상이 있다면 이를 활용할 수도 있고, 드론을 날려서 1/1,000 급의 대축척 지도를 제작한 후 이를 축소편집하여 제작할 수도 있다. 항공 LIDAR 스캐너를 이용해서 제작할 수도, 지상에서 GPS나 토털스테이션을 사용하여 제작할 수도 있다. 제품의 규격을 만족시킬 수 있다면 어떤 방법도 사용할 수 있도록 열어두는 것이 국제적인 추세이다. 이렇게 되어야만 새로운 기술이나 장비가 개발되더라도 유연하게 대처할 수 있다.

제작 방법은 "표준 작업 매뉴얼" 형태로 제작해야 한다. 예를 들어, 항공사진 측량 표준 작업 매뉴얼, 드론 사진측량 표준 작업 매뉴얼, LIDAR 측량 표준 작업 매뉴얼, GPS 측량 작업 매뉴얼 등을 만든다. 각각의 매뉴얼에서는 필요한 최소한의 방법론만을 제시하고, 작업기관에서는 작업의 성격에 따라 어떤 작업방법을 사용할지 알아서 결정할 수 있어야 한다. 대규모 건설공사의 경우, 시공하는 업체는 국가에서 정한 표준시방서와, 전문기관이 정한 전문시방서를 참고로 하여, 대상 공구에 적합한 공종을 선택하는 방식으로 자체적으로 시공 시방서를 작성한다. 공간정보 제작방법도 이러한 방식으로 표준 작업 매뉴얼을 참고하는 방식이 보편화되어야 한다.

작업자가 제작방법을 마음대로 선택한다고 하면 품질을 어떻게 보장할 수 있을지 우려를 할 수 있다. 하지만, 제품 규격서에는 데이터 제품에 포함된 각각의 지형지물에 대한 품질요소, 그리고 샘플링 방법을 포함한 품질 평가방법 등이 모두 기술되어 있으므로, 그 방법에 따라 품질을 평가할 수 있다. 작업기관에서도 자체적으로 품질을 평가해 볼 수도 있고, 품질평가원 등의 제3의 독립기관이나 발주기관에서도 동일한 방법으로 품질을 평가할 수 있다. 

제4차 산업혁명은 데이터를 기반으로 한다고 이야기한다. 이 데이터는 표준에 의해 제작된, 컴퓨터가 이해할 수 있고 자동처리될 수 있는 일관성 있는 데이터를 말한다. 이를 위해서는 모든 제품 제작이 데이터 제품 규격서를 기반으로 작성되고, 누구나 동일하게 이해하고 참조할 수 있는 구조가 되어야 한다. 공간정보가 실질적으로 제4차 산업혁명의 기반이 될 수 있기를 희망한다. 

====

이 글은 원래 공간정보표준 전담기관인 국토정보공사의 의뢰를 받아, 공간정보표준 뉴스레터 2019년 9월호에 실린 글입니다. 아래는 뉴스레터를 캡처한 것입니다.

민, 푸른하늘

공간정보표준 뉴스레터 2019년 9월호
공간정보표준과 기술기준

Posted by 푸른하늘 푸른하늘이

댓글을 달아 주세요

공간정보/표준2019. 3. 5. 14:25

INSPIRE 데이터 사양은 INSPIRE에 사용되는 다양한 주제의 공간데이터를 동일한 방법으로 정의하고 서술하기 위한 기준입니다. 데이터 사양에 따라 제작된 데이터는 어떠한 목적으로든 쉽게 교환할 수 있으며, 다른 데이터와도 쉽게 결합하여 사용할 수 있습니다. INSPIRE 의 가장 큰 목표는 "다양한 응용에서 끊김없이 사용할 수 있는 일관성 있는 데이터를 생산하는 것, 즉 데이터 상호 운영성"입니다. 이 목표를 달성하기 위한 가장 핵심이 데이터 사양이라고 할 수 있습니다.

참고로 INSPIRE 의 데이터 사양(data Specification)은 ISO 19131(데이터 제품 사양: Data product specification)에 기초하고 있습니다. 약간은 차이가 있을 수 있지만, 거의 대부분 비슷하다고 생각해도 됩니다. 다만, 제가 이제까지 본 데이터 제품 사양서는 대부분 꼭 필요한 내용만 담고 있어서 내용이 함축적이고 양이 많지 않음에 비해서, INSPIRE의 제품 사양은 해당 데이터에 관련된 내용을 모두 담고 있어, 다른 문서를 참조할 필요가 없습니다. 대신 양은 아주 방대합니다.

데이터 상호 운영성은 기술적 상호 운영성과 의미론적 상호 운영성으로 나누어 생각해 볼 수 있습니다. 기술적 상호 운영성이란, 다양한 시스템 구성 요소간에 투명하게 잘 돌아가는 것을 의미합니다. 중간에 사람(코디네이터)가 없이도 컴퓨터만으로 자동 처리되는 것을 의미합니다. 이를 위해 가강 기본적으로 필요한 것이 기계-중립적인 포맷입니다. DXF 나 Shape 포맷운 지원되는 모델이 너무 약해서 곤란합니다. 기계 중립적인 포맷은 XML의 일종인 GML이 널리 사용되고 있으며, 특히 ISO 19100 표준에서는 GML이 유일한 표준 포맷입니다. 대부분의 경우, 이러한 기술적 상호 운영상은 소프트웨어에서 지원되기 때문에 이런 부분은 거의 문제가 없다고 생각할 수 있습니다. 

기술적 상호 운영성보다 더 중요한 것이 의미론적 상호운영성입니다. 의미론적 상호운영성에서는 데이터의 내용을 동일한 방식으로 이해될 수 있어야 한다는 의미입니다. 이를 위해서는 먼저 사용하는 용어, 개념 등의 통일이 중요합니다. 예를 들어 동일한 도로라고 해도 바라보는 입장, 즉 교통의 관점인가 유지관리의 관점인가에 따라 다르게 볼 수 있다는 것입니다. 특히 유럽의 경우엔 수많은 나라와 기관들이 얽혀 있기 때문에 이러한 개념-개념이 가리키는 실제 대상- 이를 가리키는 용어의 삼박자가 일치하는 것이 매우 중요합니다.

의미론적 상호 운영성의 핵심은 구조적/스키마 일관성입니다. 예를 들어 도로를 정의한다고 했을 때 한쪽에서는 도로를 면형 데이터로 구성하고 다른 쪽에서는 노드-링크로 구성하였다면 이 두 데이터를 서로 교환해서 사용하는 것은 거의 불가능할 것입니다. 어느쪽에서는 객체로 구성한 것을 다른 쪽에서는 속성으로 정의한다든지, 어느 쪽에서는 집합 연관관계를 구성하였는데, 다른 쪽에서는 이런 연관관계를 구성하지 않았다면, 데이터를 투명하게 상호 교환하기는 거의 불가능해집니다. 그때마다 사람이 개입해서 정확하게 구성되었는지 확인해야 하니까요. 이러한 중간 확인 과정없이 모두 자동으로 처리하고자 하는 것이 결국 데이터 상호 운영성 그 자체라고 할 수 있습니다.

아래 그림은 제가 "공간정보 유통과 표준에 대하여" 라는 글에서 동일한 도로에 대해 각기 다른 스키마를 채택한 예를 든 그림입니다. 이 상태 그대로는 데이터의 호환은 거의 불가능합니다. 이처럼 각기 다른 스키마를 가지고 있는 현실에서 어떻게 일관성을 확보할 것인가하는 것이 의미론적 상호 운영성의 핵심이라고 볼 수 있습니다.

이러한 방식으로 데이터를 모두 투명하게 가져다 쓰는 가장 쉬운 방법은 모두 동일한 구조, 동일한 시스템을 사용하는 방법일 것입니다. 물론 한개의 부서라면 가능하고 실제로도 그렇게 운영됩니다. 하지만, 조금만 범위를 넓혀도, 예를 들어 옆 부서간에도 사용하는 시스템이 다를 수 있고, 데이터를 바라보는 관점과 구조가 다를 수 있습니다. 지자체 전체로 보았을 때, 국가 전체로 보았을 때는 그 경우의 수가 끝도 없겠죠.

이를 해소하는 방법은 "공통 상호 도메인 모델"을 채택하는 것입니다. 기존의 시스템은 각각 고유의 내부 모델과 데이터를 그대로 유지하되, 이 공통 도메인 모델과 교환할 수 있는 방법만 고려하면 됩니다. 

아래는 제가  예전에 올린 "공간정보 유통과 표준에 대하여"라는 글에 올렸던 그림(원 소스는 ISO 19109 응용스키마)입니다.  이 그림에서 공통 응용스키마라고  표현한 것이 바로 INSPIRE에서 말하는 "공통 상호 도메인 모델"입니다. 이 그림에서는 시스템이 두개만 표현되어 있는데, 이러한 방식을 적용하면 아무리 많은 시스템이 있어도 동일한 방식으로, 모두 똑같은 의미로 데이터의 상호 운영성이 확보 될 수 있습니다.

아래는 INSPIRE에서 구축중인 34가지 공통 데이터 레이어입니다.

INSPIRE 에서는 데이터의 상호 운영성을 위하여, 이들 각각에 대하여 데이터 사양을 구축했습니다.  아래는 그중 몇개만 정리한 것입니다.

Annex I - 

Annex II

Annex III

예를 들어 아래의 PDF 파일은 건물(III.2)에 관한 데이터 사양입니다. 

inspire_dataspecification_bu_v3.0.pdf

아래는 이 데이터 사양에 들어 있는 3 가지 응용스키마중 한가지인 "Buildings 2D" 응용스키마 입니다. 보시는 것처럼 스테레오타입이 <<featureType>> 인 클래스가 총 6가지 뿐이 없습니다. 

다른 응용스키마도 이와 비슷하기 때문에 공통 데이터 모델(응용스키마) 자체만 봤을 때는 그다지 복잡할 게 없어 보입니다. 그럼에도 이 데이터 사양은 311쪽이나 됩니다. 읽어보면 정말 내용도 방대합니다. 여기에는 배경 정보, 유스케이스, 상위 실행규칙에 관한 내용 등등... 모든 것이 포함되어 있기 때문입니다. 한마디로, 건물에 관한 공통 데이터 모델에 부합하는 데이터를 만들고자 할 경우, 이 문서만 보면(다른 문서를 참고하지 않아도. 심지어는 INSPIRE 실행 규칙(IR)을 읽어 볼 필요 없이) 모든 필요한 내용이 들어 있습니다. 

===

INSPIRE의 34개 레이어 별로. 위와 같은 데이터 사양이 각각 정의되어 있습니다. 그냥 모든 문서가 300쪽이라고 가정하면 모든 문서는 거의 10,000 쪽에 달합니다.

문제는 이렇게 방대한 문서를 어떻게 하면 모든 분야에서 일관성 있게 작성할까 하는 것입니다. 각 분야의 전문가별로 그냥 각자 데이터 사양을 만들면, 각기의 관점에 따라 형식도 다르고 내용도 문서가 만들어질 것입니다. 어떤 사람은 자세하게 작성하고 어떤 사람은 압축하여 기술할 수도 있습니다. 심지어는 동일한 내용에 대해 다르게 기술할 수도 있을 것입니다.

INSPIRE 에서는 그래서 각 Working group 별로 데이터 사양을 제작하기 전에, 먼저 데이터 사양을 위한 모델링 프레임워크를 만들었습니다. 아래 그림에서 빨간 사각형으로 쳐둔 부분이 바로 이 모델링 프레임워크입니다. 이를 작성한 다음 해에는 가장 핵심 주제인 annex I의 9 개 레이어에 대해 데이터 사양을 작성하고, 2012년 부터 나머지 25가지 레이어의 데이터 사양을 제작했음을 알 수 있습니다.

여기에서 모델링 프레임워크라고 부르는 것은 아래와 같은 기술지침(technical guideline)을 말합니다. 이중에서 2.5 ~2.7이 가장 중요한 문서입니다.

아래 그림은 범용개념 모델(generic conceptual model)이 어떤 것을 의미하는지를 나타낸 것입니다. 가운데에 빨간 네모 박스를 해둔 부분이 범용 개념 모델로, 이 모델을 기반으로 각각의 데이터 사양(맨위)이 만들어 졌음을 볼 수 있습니다. 그리고 범용 개념 모델은 기존의 ISO/OGC 등의 기반 표준을 기준으로 만들어 졌다는 것을 볼 수 있습니다. 

즉, INSPIRE에서는 국제 표준을 그대로 채택한 것이 아니라, 그중에서 자신들이 사용할 것만 뽑고, 정리를 해서 "범용 개념 모델(Generic Conceptual Model)"이라는 것을 만들고, 이것을 기초해서 각각의 레이어별로 데이터 사양을 제작했으며, 이 데이터 사양을 기준으로 데이터를 제작하고 교환한다는 것입니다. 

일본의 경우에는 ISO 19100 시리즈 표준에서 자신들이 필요한 것들만 뽑아서 일본지리정보표준 프로파일(JPGIS : Japan Profile for Geographic Information Standards)를 만들고, 이를 모든 데이터 제작, 유통의 기준으로 삼고 있습니다. 당연히 일본에서도 JPGIS를 기준으로 데이터 제품 사양서를 만들고, 제품 사양서를 기준으로 데이터를 제작 유통하도록 규정되어 있습니다. INSPIRE 의 범용 개념 모델과 JPGIS가 일대일로 대응할 수는 없겠지만, 개념적으로는 동등한 수준이라고 볼 수 있을 것 같습니다.

INSPIRE 범용 개념 모델(GCM:Generic Conceptual Model)

GCM은 ISO 19100 시리즈를 기반으로 한 데이터 모델링 원칙입니다. ISO 19109에는 일반 지형지물 모델(GFM: General Feature Model)이 정의되어 있습니다. 지형지물(클래스)와 속성, 연관관계 등이 서로 어떻게 연결되는지 등을 정의한 메타 모델입니다. 이름상으로는 GCM과 GFM이 유사한 부분이 있을 것 같지만, GCM은 다음과 같은 내용을 담고 있어서, GFM 과는 완전히 다릅니다. (GFM도 포괄하고 있습니다.)

- 공통 용어 및 기반
- 데이터 사양 생산을 위한 요구사항과 권고사항
- 응용스키마에서 사용되는 기본 유형
- ID, 범용 네트워크 모델(GNM: Generic Network Model), 지명사전(gazetteer)를 포함한 공통 개념

아래는 GCM에 포함된 내용들입니다. 한마디로 GCM은 모든 데이터 사양을 위한 최적의 모델링 원칙으로서, 이를 따르면 일관성있는 데이터 사양을 만들 수 있습니다.

(A) INSPIRE 원칙(INSPIRE principles)
    - 공간데이터는 가장 적절한 수준에 보관하고 접근 가능하게 하고, 관리해야 한다.
    - 여러 관련자의 다양한 자료로 부터 공간데이터를 일관성있게 결합하고, 여러 사용자및 응용에서 공유할 수 있어야 한다.
   - 어떤 한 수준의 공공기관이 수집한 공간 데이터는, 다른 공공기간 관에도 공유할 수 있어야 한다.

(B) 용어(Termiology)
   - 용어를 참조할 때, 용어집을 통해 일관성 있는 언어를 사용해야 한다.
   - ESDI에서는 공통 용어를 만들어야 한다.

(C) 참조 모델(reference model)
   - 기술적 파트(정보 모델링 등)에 대한 프레임워크

(D) 응용스키마와 지형지물 목록에 대한 규칙(Rules for application schemas and feature catalugues)
   - 지형지물 목록에서는 공간 객체의 유형과 특성을 정의한다.
   - 공간 데이터셋의 완전한 내용 및 구조는 공식 개념스키마언어(UML)로 표현한 응용스키마로 정의

(E) 공간적 측면 및 시간적 측면(Spatial and temporal aspects)
   - 공간 객체의 공간/시간적 특성을 기술하는 개념 스키마
     - 공간 기하 및 위상/시간 기하 및 위상/커버리지 함수

(F) 다중언어 및 문화적 적응(Multi-lingual text and cultural adaptability)
   - 지형지물 목록, 지형지물 개념 사잔, 정의 및 지리적 명칭, 속성/연관 및 열거형/코드리스트 등은 다중언어로 기술한다.
   - 응용스키마는 다중 언어를 사용하지 않는다.

(G) 좌표 참조(coordiante referencing)
    - 공간/시간 참조체계, 측정 단위, 좌표 변환 매개변수, 유럽 지리 그리드(European geographical grids)

(H) 객체 참조 모델링(Object Reference Modelling)
   - 정보를 어떻게 기존의 공간 객체에 참조할 것인가. (좌표로 참조하는 게 아니라, 기본 지형지물 공간 객체를 통해 참조함)

(I) 데이터 변환 모델(Data translation Model)
   - 국가/지역 응용스키마를 INSPIRE 응용 스키마로 변환 및 그 반대 변환. 변환에는 데이터 변환과 질의 변환이 있음

(J) 묘화 모델(Portrayal Model)
   - 데이터 사양에 부합하는 데이터에 대한 묘화 규칙 모델. 표준화된 묘화 목록의 사용

(K) 식별자 관리(Identification Management)
   - Annex I/II에 있는 공간 객체는 객체 식별자를 가져야 함. 모호함이 없이 객체를 식별할 수 있는 유일 객체 식별자의 역할 및 성격을 정의함
   - 필요시 Annex III의 레이더도 유일 객체 식별자를 지원할 수 있음

(L) 등록물 및 등록소(Registers and registries)
   - 좌표계, 측정 단위, 코드 목록, 지형지물 개념 사전, 식별자 네임스페이스, 지형지물 목록, 응용 스키마 등을 등록할 수 있는 등록소(register) 필요
   - 등록소는 등록물 서비스(registry service)를 통해 접근할 수 있음
   - 데이터에 대한 메타 데이터는 별도의 카탈로그 서비스(catalogue service)를 통해 제공됨

(M) 메타데이터(Metadata)
   - 발견/평가/사용을 위한 메타데이터의 정의

(N) 유지관리(maintenance)
   - 변화된 것만 갱신함, 객체의 버저닝 지원, 공간객체 라이프 사이클 규칙

(O) 품질(Quality)
   - 각각의 공간 데이터 셋의 품질 수준 공개에 필요한 조언
   - 각각의 공간 데이터셋에 대한 수용가능한 품질 수준, 각각의 데이터셋에서 이 수준을 만족하는 방법 등의 모범 사례를 제공함

(P) 데이터 전달(Data Transfer)
   - 공간객체의 인코딩은 모델에 따라야 함. 즉 UML 응용스키마로 완전히 결정됨
   - 웹 서비스를 구현하는 네트웍 서비스를 지원하기 위해 공간객체는 GML로 인코딩되어야 함
   - 커버리지 데이터는 기존의 인코딩을 사용해야 함(예 정사영상)

(Q)  데이터간의 일관성(Consistency between data)
   - 국경, 주제, 분야, 해상도를 뛰어넘어 일관성이 있어야 함

(R) 다중 표현(Multiple representation)
   - 시간과 공간을 통한 합성,
   - 해상도간의 합성

(S) 데이터 획득(Data Capturing)
   - 주어진 공간 객체에 대한 데이터 사양 고유의 입력 기준)예, 호수는 2ha를 넘을 것, 도로는 European Road Network의 일부일 것 등

(T) 부합성(Conformance)
   - 어떤 데이터가 데이터 사양에 부합하는지를 시험하는 방법. 각각의 데이터 사양에 지정된 부합성 테스트를 적용해야 함

INSPIRE 데이터 사양 개발 방법

INSPIRE 기술 지침 2.6에서는 데이터 사양 개발 방법론(Methodology for the development fo data specification) 을 다루고 있습니다. 여기에서는 데이터 사양 문서에는 이런 이런 내용을 넣어야 한다는 것보다 훨씬 포괄적인 내용, 즉, 어떻게 사용자의 요구를 조사, 분석하여 데이터 사양에 담아야 할지를 담고 있습니다.

간단히 정리하자면, 먼저 기존의 정책자료, 보고서 설문조사 등을 통해 유스케이스를 개발하고, 현재 존재하는 데이터 등의 상황을 분석한뒤 이를 비교하여 차이를 분석하여 데이터 사양을 개발한 뒤 비용 편익 분석 등을 통해 반복한다는 내용입니다. 일반 시스템 개발에서 사용하는 방법론과 그다지 다른 것 같지는 않네요.

어쨌든... 이런 과정을 통해 작성되는 데이터 모델은, 너무 간단해서도 사용자 요구사항을 만족시킬 수 없고, 너무 복잡해지면 구현하기 힘들고 비용이 과다해 지므로, 적절히 균형을 유지해야 한다는 점을 강조하고 있습니다.

===

이상입니다. 이 글은 INSPIRE 데이터 사양에 관한 교육자료를 보고 마음대로 편집한 것입니다.




Posted by 푸른하늘 푸른하늘이

댓글을 달아 주세요

공간정보/표준2018. 12. 21. 17:49

INSPIRE 지침(Directive)은 유럽연합 의회(Paliament) 및 각료 이사회(Council)에서, 유럽의 환경관련 정책에 사용되는 공간데이터를 효율적으로 공유하고자 하는 목적으로 만들어졌습니다. 이 지침은 2007년 5월 15일부터 효력을 발생하였으며, 2021년 목표로  실행중에 있습니다.

INSPIRE 지침의 핵심은 데이터/서비스의 상호운영성입니다. 이를 위하여 다음과 같은 5가지 비전을 제시하고 있습니다. 한마디로 줄이자면, 모든 관련 데이터를 일관성있게 작성하고, 관리하고, 공유하며, 평가할 수 있어야 한다고 할 수 있습니다.

  • 데이터는 한번만 수집하고, 가장 효율적으로 관리할 수 있는 곳에서 유지관리해야 한다.
  • 여러가지 자료들을 seamless하게 결합하고 공유할 수 있어야 한다.
  • 정부 한 레벨에서 수집한 정보도, 모든 레벨에서 공유되어야 한다.
  • 좋은 정책에 필요한 공간 데이터는 널리 활용될 수 있어야 한다.
  • 쉽게 찾고, 목적에 맞는지 평가하는 것이 가능해야 한다.

INSPIRE 지침은 일종의 법률이라고 생각할 수 있습니다. 법률에는 시행령/시행규칙 등이 따르는 것처럼, INSPIRE 지침을 효율적으로 시행하기 위한 실행규칙(Implementing Rules)가 규정되어 있습니다. 이 실행규칙은 집행위원회(Commission)에서 제정하는 것으로, INSPIRE 지침과 실행규칙은 유럽연합 회원국들은 의무적으로 지켜야 합니다. 각각의 회원국이 지침과 실행규칙을 자국의 법률에 반영하는 것은 의무사항은 아니지만, 그래도 의무적으로 지켜야 하는 것입니다. 

INSPIRE 실행규칙은 아래와 같이 총 5개 분야에 대해 정의되어 있습니다. 이중 일부는 내용이 수정되거나 보완되어, 규칙 수는 전체 12개가 존재합니다. 

  • 메타데이터(Metadata)
  • 데이터셋/서비스 조율 및 상호운영성(Harmonization and Interoperability of Spatial data sets and services)
  • 네트워크 서비스 (검색, 뷰, 다운로드, 전송, 미들웨어) (Network services(discovery, view, download, transform, middleware)
  • 데이터 서비스 공유 (정책부분) (Data and Service sharing (policy)
  • 모니터링 및 보고를 위한 협조 및 수단 (Coordination and measures for Monitoring & Reporting)

실행규칙까지는 어디까지나 "무엇을 해야한다"를 규정하는 것입니다. 구체적으로 "어떻게"해야 실행규칙에서 요구하고 있는 사항들을 달성하는지에 대해서는 기술 가이드라인(Technical Guidleine)이 만들어져 있습니다. 당연히 위의 5개 분야별로 구체적인 가이드라인이 만들어져 있습니다. (일부 분야는 아직도 작업중이라고 합니다.)

이러한 INSPIRE의 데이터/서비스 상호운영성을 확보하려면, 당연히 지오포털(GeoPortal)과 같은 컴퓨팅/네트워크 자원이 필요합니다. 유럽 연합 INSPIRE 지오포털은 http://inspire-geoportal.ec.europa.eu/입니다. 이곳에서 INSPIRE 데이터셋 검색/뷰/다운로드/변환 등의 서비스를 사용할 수 있습니다. 각 회원국에도 각자의 환경에 따라 지오포털을 설치할 수 있지만, 의무사항은 아닙니다. 하지만, 각회원국의 INSPIRE자원을 유럽 포털에 연결해야 하는 것은 의무사항입니다. 

INSPIRE 데이터는 총 34개의 레이어로 구성되어 있습니다. 이 내용은 Annex Theme의 정의와 범위(Definition of Annex Themes and Scope)" 정의되어 있는데 아래와 같습니다. 레이어만을 봤을 때는 우리나라의 기본공간정보에 환경관련 자료가 더 추가되어 있는 정도로 보입니다. 물론 축척(정보의 상세도)에 따라 다르겠지만, 이 정도 데이터면 거의 모든 공간 정보 분석에는 충분할 것 같습니다.

  • Annex I (9)- 좌표계, 그리드, 지명, 행정단위, 주소, 지적, 교통네트워크, 수질, 보호구역
  • Annex II (4) - 고도, 토지피복, 정사사진, 지질
  • Annex III (21) - 통계구역, 건물, 토질, 토지이용, 건강/안전, 유틸리티 및 정부서비스, 환경 모니터링 시설, 생산 및 공업 시설, 농수산 시설 , 인구 분포, 지역관리/제한, 자연재해 위험구역, 대기 조건, 기상적 지리적 특징, 해양 지리적 특징, 바다 구역, 생물 지리 구역, 생태구역/바이오톱, 종의 분포, 에너지 자원, 광물 자원

모니터링 및 보고 (COMMISSION DECISION of 5 June 2009)

INSPIRE 실행규칙 5종 중에서, 비 기술적인 실행규칙이 두가지 종류가 있는데, 이 실행 규칙은 그 중 하나입니다. (다른 하나는 데이터 서비스 공유) 이 실행규칙을 위해서 다음과 같은 보조 문서들이 있습니다.

  • 모니터링 및 보고를 위한 가이드 라인
  • 모니터링 지표를 위한 템플릿, 보고를 위한 템플릿
  • 모니터링과 보고를 위한 접근방법의 부합성 문서?

정책 시행에 있어 가장 중요한 것은 모니터링 및 보고입니다. 어떤 정책이 제대로 시행되는지 검사를 하지 않고 그냥 알아서 하도록 둔다면, 시행하는 사람도 그것을 취합하는 사람도 정확한 현 상황을 파악하기 힘들 것입니다. INSPIRE에서는 지속적으로 모니터링하고, 최소한 3년마다 한번씩 보고를 하며, 그 결과를 공개하도록 명시하고 있습니다. INSPIRE에 관계된 모든 사람들은 정보수집에 참여하여 정보를 제공해야 하며, 그 모니터링/보고 대상은 기본적으로 데이터셋 및 서비스입니다. 

검사하는 내용은 다음과 같습니다.

  • DSi1 - 해당 데이셋이 존재하는가?
  • DSi2 - 그 데이터셋은 INSPIRE에 부합하는가?
  • MDi1 - 그 데이터셋에 대해 메타데이터가 존재하는가?
  • MDi2 - 그 메타데이터는 INSPIRE에 부합하는가?
  • NSi1 - 서비스에서 이 메타데이터에 접근할 수 있는가?
  • MSi2 - 서비스에서 데이터셋에 접근할 수 있는가?
  • MSi3 - 서비스를 사용할 수 있는가?
  • MSi4 - 서비스가 INSPIRE에 부합하는가?

즉, 회원국은 자신이 제작하여 유럽 지오포털에 올리는 데이터 34종에 대해 각각 이러한 기준을 만족하는지 지속적으로 모니터링하여 보고한다는 뜻입니다. 

보고 양식은 아래와 같습니다. 어떤 나라인지는 표시되어 있지 않지만, 이 나라에서 Annex I에 속하는 데이터셋 9종(좌표계, 그리드, 지명...)은 메타데이터 항목의 첫번째 지표(MDi1)에 대해서 98개의 평가항목중 72개를 만족했으며, 두번째 지표(MDi2)에 대해서는 98개 항목중 26개만 만족했다는 뜻입니다. 

Annex I은 총 9개의 레이어로 구성되어 있는데, 실제 데이터셋은 98개이라고 되어 있어서 좀 이상해 보입니다만, 어쨋든 98개중 72개만 메타데이터가 존재하고, 그중에서 INSPIRE 지침에 부합하는 것은 27%에 불과하다는 뜻입니다. 

모니터링 및 보고는 2010년부터 시작하여, 매년 2개씩 보고서를 제출하고 있으며, 2013년 현재 18,138건의 데이터셋 및 7,088건의 서비스에 대해서 이러한 모니터링이 이루어지고 있다고 합니다.

데이터/서비스 공유(Commison Reglation No 268/2010)

데이터 서비스 공유에 관한 실행규칙도 비 기술적 실행규칙입니다. 이 실행규칙은 2010년 발효되었으며, 다음과 같은 보조 문서들이 있습니다.

  • 가이드라인  : "각국의 데이터/서비스 공유 모범사례"에 관한 문서

이 실행규칙은 "관계기관 및 일반 사용자들에게 공간 데이터셋 및 서비스를 조화된 조건에 따라 제공"함을 목적으로 하고 있습니다. 다음은 이 실행규칙에서 정의된 사항중 일부입니다.

  • 용역 등에 참여하는 계약자에게는 공간 데이터셋 및 서비스를 접근할 수 있도록 해야 한다.
  • 데이터/서비스에 대해서 접근을 제한 할 수도 있지만, 반드시 공유를 제한하는 이유를 제시해야 하며, 접근하려면 어떤 조건이 만족되어 하는지를 알려야 한다.
  • 합의나 계약을 할 경우, INSPIRE 지침 제3항에 있는 용어를 사용해야 한다.
  • 반면 승인하지 않은 사용에 대해서는 엄격히 제한하여, 제3자는 INSPIRE 데이터셋/서비스를 다른 사람들에게 제공해서는 안된다.
  • 이러한 데이터/서비스의 접근 가능성에 관한 정보는 반드시 메타데이터에 반영되어 있어야 한다.
  • 평가 및 사용에 관한 정보는 필요시 제공해야 한다. 여기에는 사용시 비용도 포함될 수 있다.
  • 문서 요청으로부터 20일 이내에 데이터 셋 및 서비스를 접근할 수 있도록 해야 한다.

이 실행규칙의 가이드라인 문서인 "각국의 데이터/서비스 공유 모범사례"에는 협조체계, 계약 방법, 투명성, 라이센스, 비용 부과 방법, 공개적인 접근, 비상시 사용, 제3자 데이터 등에 대해 여러가지 사례가 들어 있다고 합니다.

메타데이터 (COMMISSION REGULATION (EC) No 1205/2008)

메타데이터는 기술적 INSPIRE 실행규칙 중 하나입니다. (나머지는 네트워크 서비스, 데이터 사양 입니다.) 메터데이터에 관한 실행규칙은 2008년 발효되어, 다른 어떤 실행규칙보다 빨리 제정되었습니다. 그만큼 중요하다는 반증이라고 생각합니다. 이 실행규칙의 보조문서는 다음과 같습니다. 

  • 정오표
  • ISO 19115 및 ISO 19119에 기반한 가이드라인
  • 실행규칙 개발 절차에 관한 보고서

메타데이터는 공간 데이터 또는 서비스에 담겨 있는 내용을 요약한 것으로, 어떤 데이터가 들어 있는지, 어떻게 사용할 수 있는지 등등에 관한 내용이 들어 있습니다. 사용자는 메타데이터를 통해 자신이 원하는 목적에 맞는 데이터를 찾을 수 있습니다.

메타데이터 실행규칙에는 다음과 같은 내용이 정의되어 있습니다.

  • ISO 표준에 정의된 필수 요소 및 추가 요소
  • 가이드 라인 변경에 따른 동적인 측면
  • 메타데이터 요소의 조건 및 다중성
  • 각각의 메타데이터에 대한 값 정의역

아래는 데이터 셋에 대한 메타데이터 중 일부를 추린 것입니다.

아래는 서비스에 관한 메타데이터입니다. 일부는 데이터셋에 대한 메타데이터와 동일한 것들도 있지만, 서비스에만 적용되는 항목들도 존재합니다.

2014년 초까지 28만 5천개 정도의 메타데이터가 등록되어 있고, 유럽 지오포털을 통해 검색할 수 있다고 합니다. http://inspire-geoportal.ec.europa.eu/proxybrowser/ 에 들어가보시면 제가 글을 쓰는 현재, 총 51만건이 등록되어 있다고 나오네요.

네트워크 서비스 (COMMISSION REGULATION (EC) No 976/2009
                       Commission Regulation (EU) No 1088/2010 )

네트워크 서비스에 관한 실행규칙은 기술적 실행규칙중 하나로서, INSPIRE에 규정된 여러가지 서비스 (검색, 뷰 서비스가 중점)에 대한 내용입니다. 이 실행규칙에 대한 보조문서는 다음과 같습니다.

  • INSPIRE Viewing 서비스 기술 가이드라인(2.0)
  • Dicovery 서비스 가이드라인(2.0) - 
  • SOAP Primary for View/Discovery 서비스
  • Web Service Description Language를 사용한 view/discovery 서비스의 문서화에 대한 제안
  • 기타 기술적 보고서

이 실행규칙은 서비스에 관한 기술적 규격이나 성능 기준 등을 정의함으로써, 상호운영성을 확보하는 것이 목적입니다. 최초 운영 능력(IOC, initial operating capability), 성능, 용량, 가용성, 반응시간, 서비스 요청, 발행, 수집, 레이어 등 다양한 부분에 대해 정의하는데, 특히 검색(Discovery)및 뷰(View)서비스에 관한 특정한 요구사항을 정의하고 있습니다.

예를 들어 Annex 1에는 서비스 품질에 대해 정의하는데, 검색서비스의 반응 시간은 3초 이내, GetMap 요청에 대한 반응시간(470kb)은 5초 이내이어야 하며, 동시접속은 각각 30, 20이상이라고 정의하고 있습니다.

Annex II는 검색서비스에 대한 내용으로서, 어떤 검색을 제공해야 하는지, 어떤 연산을 제공해야 하는지 등을 정의하고 있습니다. 제공해야 하는 연산은 다음과 같습니다.

  • Get Discovery Metadata
  • Discovery Metadata
  • Publish Metadata
  • Link Discovery Service

Annex III는 뷰서비스에 대한 내용으로서, 아래와 같은 연산이 제공되어야 한다고 정의하고 있습니다. 또한, 좌표계를 지원해야 하며, 영상 포맷은 적어도 PNG와 GIF를 지원해야 한다고 명시하고 있습니다.

  • Get View Metadata
  • Get Map
  • Link View Servcie

==

네트워크 서비스에 관한 실행규칙은 이 외에도 한가지 종류가 더 있습니다. 바로 Commission Regulation (EU) No 1088/2010 로서, 여기에서는 다운로드 및 변환 서비스가 정의되어 있습니다. 이 실행규칙에 대한 보조문서는 다음과 같습니다.

  • INSPIRE 스키마 변환 서비스에 관한 기술 가이드(초안)
  • 스키마 변환 네트워크 서비스 - 최신 기술 분석
  • INSPIRE 좌표변환 서비스 기술 가이드(초안)

마찬가지로 이들 서비스에 대해서도 성능, 반응시간, 용량, 가용성 등에 대한 최소 기준이 정의되어 있습니다. 예를 들어 성능 부분에서 Get Spatial Dataset 및 Get Spatial Object 연산의 경우, 30초 이내에 반응 해야 한다고 구체적으로 정의되어 있습니다. 

Annex II에는 다운로드 서비스에서 제공되어야 할 연산을 정의하고 있습니다.

  • 연산
    • Get Download Service Metadata
    • Get Spatial Dataset
    • Describe Spatial Data set
    • Link Download Service
  • 직접 접근 다운로드 연산
    • Get Spatial Object
    • Describe Spatial Object Type
  • Get Spatial Object 연산을 위한 검색 기준
    • URI, 핵심 속성 (예: 갱신 일), 지역, 주제 등

데이터 사양 개발(Commission Regulation (EU) No 1089/2010
                      Commission Regulation (EU) No 1312/2014)

제가 제일 관심있는 부분은 데이터 사양입니다. INSPIRE 데이터셋 또는 데이터셋 시리즈를 어떻게 만들지를 구체적으로 정의한 부분이기 때문입니다. 데이터 사양은 한마디로 설계도라고 할 수 있습니다. 제작 및 평가의 기준이 된다고 할 수 있죠. 다만 이 실행 규칙은 "공간 데이터셋 및 서비스의 상호운영성"을 위한 실행 규칙이라고 되어 있습니다. 서비스에 관한 내용이 어떤 것인지 감은 안잡힙니다만... 아래는 이 실행규칙에 대한 보조 문서들입니다. 이중에서 2.3부터 2.7까지는 데이터사양을 만드는 방법에 대한 기준이며, 2.8 이하에서는 각각의 주제에 대한 구체적인 사양이 있습니다.

  • D 2.3 Definition of Annex Themes and Scope(기본) 
  • D 2.5 Generic Conceptual Model 
  • D 2.6 사양 개발 방법론 
  • D 2.7 인코딩 가이드라인 
  • D 2.8.1.1 -... Annex I 주제에 대한 데이터 사양... 그 다음에 Annex II 등

2013년 현재까지 18000여건의 데이터셋이 공개되어 있는데, 아주 일부만이 데이터 사양에 부합된다고 말하고 있습니다. 기존의 데이터셋은 당연히 INSPIRE 제품사양 기준에 따라 변환되어야 합니다. 이러한 변환은 시간도 많이 걸리고 매우 복잡한 절차가 필요한데, (일부는 아얘 너무 사양과 거리가 멀어서 변환자체도 불가능하기도 하답니다.) "Data harmonization", "Precedures for data and metadata harmonisation", "Examples of data transformation" 등의 모듈을 사용하여 변환해야 하는 것 같습니다.

두번째 실행 규칙 1312/2014는 주로 서비스에 관한 규칙이라고 하는데, 자세한 내용은 없습니다.

INSPIRE에 대한 부합성

데이터 또는 서비스를 공개할 때 가장 중요한 것은 표준에 맞느냐 하는 것입니다. 하지만, 표준은 범위가 너무 넓다보니, 그냥 표준을 지켰느냐라고 하는 것은 별로 의미가 없습니다. 정말 표준을 지켰다고 하면 ISO 19100 시리즈의 모든 문서의 추상 시험 스위트를 하나씩 검사해서 모두 통과했다는 뜻이기 때문에, 사실상 불가능하기도 하고, 일부는 의미가 없을 수도 있습니다.

표준에 대한 부합성을 논의하려면, 구체적으로 지키고자 하는 내용을 프로파일(Profile)로 정하고, 이에 대한 부합성을 따지는 방향으로 이루어져야 합니다. INSPIRE에서도 당연히 이러한 방향으로 진행되고 있으며, 따라서 이 부분에서는 어떤 규정을 지켜야 하고, 어떻게 테스트를 해야 INSPIRE에 부합하다고 할 수 있는지 (표준을 지켰다고 할 수 있는지)를 규정하고 있습니다.

INSPIRE 부합성을 따지는 대상은 메타데이터, 네트워크 서비스 및 데이터셋입니다. 당연히 위에서 논의했던 내용에 대해서만 부합성을 따질 수 있는 것입니다.

부합성을 따지는 기준은 당연히 실행규칙(IR : Implementing Regulation)입니다. 이는 법적 기준으로서 반드시 지켜야 합니다. 그 구체적인 요구사항 및 시험 방법에 대해서는 기술 가이드라인(TG)에 추상시험 스위트(ATS : Abstract Test Suites)로 규정되어 있습니다. 실제 구현하는 사람들은 이 ATS를 실행가능 시험 스위트 (ETS : Executable Test Suites)로 구현하여 메타데이터/서비스/데이터셋에 대해서 시험해야 하는 것입니다. (일부는 수작업으로만 검사할 수 있는 것도 존재합니다) 이러한 부합성 테스트를 통과한 데이터에 대해서는 인증을 하게 되고요.

이러한 과정을 통해 INSPIRE에 대해 부합한 데이터가 있어야만 모든 INSPIRE 시스템이 원할하게 돌아갈 수 있게 됩니다. 예를 들어 데이터셋의 내용이 변경되었을 때, INSPIRE에 부합한 데이터셋이라면 사람의 개입없이도 자동으로 지오포털까지 변경될 수 있는 것입니다.

예를 들어 INSPIRE 메타데이터에 대한 검증기는 아래에 있습니다. 누구든 자신이 작성한 메타데이터가 INSPIRE에 부합하는지를 확인하려면 이 데이터 검증기에 돌려보면 됩니다.

===

이 글은 이 자료를 제 나름대로 정리한 내용입니다.


민, 푸른하늘

Posted by 푸른하늘 푸른하늘이

댓글을 달아 주세요

공간정보/표준2018. 12. 4. 11:01

INSPIRE 개요

INSPIRE 지침(Directive)의 목적은 유럽연합 환경 정책 및 환경에 영향을 미칠 수 있는 정책이나 활동을 위하여, 유럽연합 공간 데이터 인프라를 생성하기 위함이다. 이 유럽 공간 데이터 인프라를 사용하면, 공공 기관간의 환경 공간 정보의 공유를 촉진하고, 유럽내 공간 정보에 대한 공공 접근을 활성화하며, 여러 국가에 걸친 정책의 결정에 도움을 줄 수 있다. 

INSPIRE는 유럽 연합 회원국이 각자 제작, 운영하고 있는 공간 정보 인프라에 기초한다. INSPIRE 지침은 환경 응용에 필요한 34개의 공간 데이터 주제를 다루고 있다.

INSPIRE는 2007년 5월 15일에 시행되었으며, 여러가지 단계로 시행되어 2021년까지 완료될 예정이다.

아래의 동영상은 INSPIRE가 왜 필요하며, INSPIRED에서 다루는 공간 데이터의 유형에 대해 다루고 있다.

INSPIRE 정책의 배경

공공기관에서 사용되고 교환되고 있는 모든 정보는 상당한 부분이 특정한 위치를 참조하고 있다. 이러한 정보의 품질은 '공간 데이터'의 이용가능성에 따라 달라지며, 공간 데이터는 수집된후 (지리 참조되어) 위치에 연결된 후, 처리하여 정보를 생성한다. 대부분의 환경정보, 즉, 배출 측정, 생태 다양성 관측 또는 환경 품질 데이터 등은 공간적 성격을 가지고 있다. 

정책 관련 평가와 분석은 여러가지 환경 및 공간 데이터를 조합하여 이루어진다. 토지이용, 행정 경계, 표고, 수자원, 교통망, 생산시설, 보호 시설 등이 그러한 예이다. 기상, 지질, 토양 등의 지리 물리적 데이터는 또한, 인구 밀도나 건강과 안전에 관한 데이터 등과 같은 사회 경제적 데이터 뿐만 아니라, 환경 정책적 관점에서도 관련이 있다.

환경에 영향을 미치는 여러가지 주제적 환경적 법령 및 정책(농업, 교통, 에너지, 공간 개발 등)에 깔려 있는 프로그램과 조치는, 일반적으로 환경에 미치는 사회적 압력으로부터 발생하는 위험성 혹은 재난이 될 수 있는 자연 또는 인공적 위험의 완화가 필요하다. 

예를 들어, 대기의 질과 기상 조건에 관한 데이터를 교통, 공장 위치, 도시/농업의 공해 배출원, 역학 등과 연계하면, 대기 오염에 의해 건강에 미치는 영향을 평가할 수 있다. 이러한 데이터는 공해원인을 식별하고, 대기의 질에 영향을 미치는 정책에서 배출 경감 목표를 조정하는 등에 사용할 수 있다.

INSPIRE 지침의 준비과정(2001-2004)에서 수행된 수많은 사실 확인 및 공개 컨설팅을 통해, 환경에 영향을 미치는 환경 정책에 필요한 공간 데이터가 널리 사용되지 못하게 가로막는 중요한 장애 요인을 식별하였다. 예를 들어 지역에서 유럽을 대표하는 모든 분야의 공개 컨설팅 참여자중 97%는 다음과 같은 내용에 동의하였다.

  1. 공간데이터가 빠지거나 불완전한 경우가 많다.
  2. 사용 가능한 공간 데이터에 대한 설명(문서)가 불완전한 경우가 많다.
  3. 공간 데이터셋을 다른 공간 데이터셋과 결합하기 힘든 경우가 많다.
  4. 공간 데이터를 찾고 접근하고 사용하는 시스템이 별개로 작동되며, 호환되지 않는 경우가 많다.
  5. 문화적, 제도적, 재정적, 법적 장애로 인해 기존 공간정보의 공유 및 재사용이 방해 혹은 지연된다.

INSPIRE 원칙

INSPIRE는 아래와 같은 여러가지 공통 원칙에 기초하고 있다.

  1. 데이터는 단 한번만 수집되고, 가장 효율적으로 관리되는 곳에 저장되어야 한다.
  2. 유럽 전역 여러 자료원의 공간 정보를 원할하게 결합하고, 많은 사용자 및 응용에 공유할 수 있어야 한다.
  3. 한 레벨/축척에서 수집된 정보를 다른 모든 레벨/축척과 공유할 수 있어야 한다. 자세한 정보는 조사를 위해, 일반적 정보는 전략적 목적으로 활용할 수 있다.
  4. 모든 레벨에서 원할한 가버넌스를 위해 필요한 공간 정보는 언제든지, 투명하게 제공되어야 한다.
  5. 어떠한 공간 정보를 사용할 수 있는지, 어떻게 특정한 요구에 따라 사용할 수 있는지, 어떠한 조건으로 취득하고 사용할 수 있는지 등에 대해 쉽게 파악할 수 있어야 한다.

INSPIRE 규약

INSPIRE 지침은 2007년 4월 25일 공식 간행물에 발행되었고, 2007년 5월 15일 발효되었다.

Directive 2007/2/EC of the European Parliament and of the Council of 14 March 2007 establishing an Infrastructure for Spatial Information in the European Community (INSPIRE)

(2007 3월 14일 유럽 의회 및 위원회 발의, EC내 공간정보를 위한 하부구조(INSPIRE) 설립을 위한 지침 2007/2/EC)

INSPIRE

 제목  발행일
2007 3월 14일 유럽 의회 및 위원회 발의, EC내 공간정보를 위한 하부구조(INSPIRE) 설립을 위한 지침 2007/2/EC  2007/4/26

실행 규칙

회원국의 공간데이터 인프라가 각각의 커뮤니티 및 경계를 넘어 상호 호환되고, 사용될 수 있도록 보증하기 위해서는 여러가지 특정 분야에서 공통 실행규칙(IR, Implementing Rules)의 채택이 필요하다. 이러한 실행 규칙은 위원회 명령(Commission Decision) 혹은 규칙(Regulation)으로 채택되었으며, 모든 구성원의 의무이다. 위원회는 이러한 규약을 채택하는 과정에서 규제 위원회(regulatory committee)의 도움을 받았다. 이 위원회는 회원국의 대표로 구성되며, 위원의 대표가 회장이다.(Comitology procedure)

메타데이터

제목  발행일
2014년 11월 10일 위원회 규약(EU) No 1311/2014. INSPIRE 메타데이터 요소의 정의에 따른 규약 No 976/2009에 대한 개정  2014/12/11
INSPIRE 메타데이터 규약에 대한 정오표  2010/1/15
INSPIRE 메타데이터 규약  2008/12/4

데이터 사양

제목 발행일
2014년 12월 10일 위원회 규약 (EU) No 1312/2014. EU 의회 공간 데이터 서비스의 상호운영성에 대한, 2007/2 실행명령 규약 No 1089/2010에 대한 개정  2014/12/11
2013년 10월 21일 위원회 규약(EU) No 1253/2013. 공간 데이터셋 및 서비스의 상호운영성에 관한 실행 명령 규약 No 1089/2010 에 대한 개정  2013/12/10
2010년 11월 23일 위원회 규약 (EU) No 1089/2010. 공간 데이터셋 및 서비스의 상호운영성에 관한 EU 의회 실행 명령  2011/2/6
2011년 2월 4일 위원회 규약 (EU) No 102/2011. 공간 데이터셋과 서비스의 상호운영성에 관한 EU 의회 실행명령 No 1089/2010에 대한 개정  2011/2/5
2010년 11월 23일 위원회 규약 (EU) No 1089/2010. 공간 데이터셋과 서비스의 상호운영성에 관한 EU 의회 실행명령  2010/12/8

네트워크 서비스

제목 발행일 
위원회 규약. 다운로드 서비스 및 전송 서비스에 관한 규약 (EC) No 976/2009에 대한 개정  2010/12/8
2009년 10월 19일 위원회 규약  (EC) No 976/2009. 네트워크 서비스에 관한 EU 의회의 실행 명령  2009/10/19

데이터 및 서비스 공유

제목 발행일
INSPIRE 데이터 및 서비스 공유에 관한 규약  2010/3/29

모니터링과 보고

제목 발행일
INSPIRE 모니터링과 보고에 관한 위원회 결정  2009/5/6

INSPIRE 실행 규칙

회원국의 공간데이터 인프라가 각각의 커뮤니티 및 경계를 넘어 상호 호환되고, 사용될 수 있도록 보증하기 위해서는 여러가지 특정 분야에서 공통 실행규칙(IR, Implementing Rules)의 채택이 필요하다 

  • 메타데이터
  • 데이터 사양
  • 네트워크 서비스
  • 데이터 및 서비스 공유
  • 공간 데이터 서비스
  • 모니터링 및 보고

이들 실행 규칙은 위원회 결정 및 규약으로 채택되었으며, 모든 구성원의 의무이다. 

위원회는 이러한 규약을 채택하는 과정에서 규제 위원회(regulatory committee)의 도움을 받았다. 이 위원회는 회원국의 대표로 구성되며, 위원의 대표가 회장이다.(Comitology procedure)

INSPIRE 기술 지침

실행 규칙 외에도, 의무가 아닌 기술 지침 문서에는 상세한 실행 측면 및 기존 표준, 기술, 사례 등과의 관계를 기술하고 있다. 아래의 그림은 실행 규칙을 INSPIRE 규약과 이에 대응되는 기술 지침 문서간의 관계를 나타낸 것이다.

기술 지침 문서는 회원국이 위원회 규정(Commision Regulation)으로 기술된 실행규약(Implementing Rules)를 실행할 것인지를 정의한다. 기술 지침 문서는 의무가 아닌 기술적 요구사항을 포함할 수 있다. 회원국이 이 기술 지침에 부합하고자 선택할 경우, 이 기술적 요구사항을 반드시 만족시켜야 한다. 이 기술적 지침을 실행하면 INSPIRE 서비스의 상호운영성을 극대화시킬 수 있다.

기술 지침 문서의 유지관리는 INSPIRE 유지관리 및 실행 프레임 워크의 중요한 임무이다.

모든 기술 지침 문서는 여기에서 볼 수 있다.

INSPIRE 관계자

INSPIRE 코디네이션 팀(CT)

INSPIRE 코디네이션 팀은 DG Environement와 JRC(Joi8nt Research Center)의 유럽 위원회 직원 및 유럽 환경 위원회(EEA)의 직원으로 구성되어 있다. 이들의 임무는 INSPIRE의 실행 및 향후 발전을 조율하고, 다른 EU 정책과 협조하는 것이다.

DG Environement는 INSPIRE를 위한 전반적인 법적, 정책적 코디네이터로서 역할을 한다. 환경 정책에 관한 INSPIRE의 주요 목적하에, EEA에 대한 협력을 기반으로, DG Environment는 실행 프로그램을 위한 프레임 워크로서, INPIRE를 위한 환경적 주제적 정책 요구사항을 규정한다. DG Environement는 INSPIRE 유지관리 및 실행 그룹의 의장을 맡고 있다.

JRC(Joint Research Center)는 INSPIRE의 전반적인 기술적 코디네이터 역할을 한다. JRC는 INSPIRE를 위한 기술적 인프라의 실행가능성 및 혁신을 보장하며, 유럽 및 국제 연구그룹 간의 협력을 보증한다. JRC는 또한 INSPIRE의 목적을 위한 국제 표준화단체와의 공동작업을 주도 및 모니터링 하며, 기타 관련 국제 활동과의 기술적 조율에도 책임이 있다. JRC는 INSPIRE 유지관리 및 실행 그룹(MIG-T)의 기술 하부 그룹의 의장을 맡고 있다.

2013년 유럽 환경 위원회 (EEA, European Environmental Agency)는 모니터링과 보고와 관련된 업무를 수행하고 SEIS 및 INSPIRE 활동의 일부로 INSPIRE 하의 데이터/서비스 공유함으로써, EU 수준의 협조에 대한 참여를 늘렸다. EEA는 또한 잘 설치된 유럽 환경 정보 및 관측 네트워크(Eionet)을 통한 네트워킹 경험을 살려, INSPIRE를 다른 EU 수준의 활동과 통합을 강화하였다. 여기에는 환경적 경험하에 보고 및 정보 배포도 도함된다.

INSPIRE 위원회(IC)

INSPIRE 지침 22조에 따르면, 회원국 대표로 구성되는 INSPIRE 위원회(Committee)는 위원회(Commission)를 지원하고, 위원회(Commission)에서 제안되는 실행 규칙 도안에 대한 각자의 의견을 전달하는 데 도움을 주는 일반적인 임무를 부여받고 있다. 이러한 의견은 투표의 형태를 띈다.

국가 접촉선(NCP: National Contact Points)

INSPIRE 지침 19(1) 항에 따르면, 각 회원국은 반드시 접촉선을 지정해야 한다. 접촉선은 대부분 공공기관으로, INSPIRE에 관련하여, 위원회에 대한 접촉에 책임이 있다. 예를 들어 접촉선은 INSPRE 실행에 관한 정보를 각 국가에 제공해야 할 책임이 있으며, 회원국을 대표하여 위원회에 보고해야 한다.

국가 접촉선 목록

INSPIRE 유지관리 및 실행 그룹(MIG)

2013년, INSPIRE 국가 접촉선 대표로 구성되는 INSPIRE 유지관리 및 실행 그룹이라는 위원회 전문가 그룹을 설치하였다. MIG는 유럽 위원회(DG Environment와 JRC), EEA, EU 회원국 간의 공동활동을 조율하고, INSPIRE 지침의 유지관리 및 실행을 지원한다.

MIG는 기술적인면을 다루는 영구적인 하부그룹(MIG-T)가 있으며, 유리관리 및 실행 작업 프로그램(MIWP)에서 정의한 특정 활동에 초점을 맞춘 한시적 하부그룹을 설치할 수 있다.

MIG는 이해관계자 그룹으로부터 선정된 전문가 플에 의해 보환된다. 이 전문가 풀은 MIG 하부그룹이 특정 실행 및 유지관리 문제를 해결하기 위해 설치될 때 소환할 때 이용되지만, INSPIRE 실행 또는 유지관리 특정 측면에 관련하거나 관심있는 전문가에 접근할 수 있는 기회도 제공한다.

MIG 대표

MIG-T 대표

전문가 풀

INSPIRE 이해 관계자

INSPIRE 실행 계획 및 기술 지침 문서 및 유지관리 및 실행 프레임워크를 개발하기 위해서는 회원국의 이해 관련 기관으로부터의 전문가에 대한 참여 프로세스가 필요하다.

이해 관련 기관은 MIG 작업을 위한 전문가 추천을 의뢰받으며, MIG 및 하부그룹의 작업에 대한 입력 및 피드백을 제공한다. 이해 관련 기관의 전문가는 주제 클러스터 토론 플랫폼에서 실행 문제에 관한 토론도 할 수 있다.

참고 : 법적 프레임워크를 개발하는 동안, 이해 관련 기관은 법적 의무 기관(LMO)와 공간데이터 관심 커뮤니티로 구분되었다. 이러한 구분은 실행 단계에서는 구분하기 힘들기 때문에 그다지 고려하지 않고 있다.

공간데이터 관심 커뮤니티(SDIC: Spatial Data Interest Communities)

법적 의무기관(LMO: Legally Mandated Organisation)

교육 라이브러리

교육 교재

위원회 및 EEA 및 연구 프로젝트나 이해관계 기관에 생산된 다양한 교육 자원이 존재한다.

이러한 교육 코스의 선택은 공간지식베이스(GKB : Geospatial Knowledge Base) 교육 플랫폼에 만들어져 있다. GKB는 EC INSPIRE 팀과 ELISE 프로젝트에서 공동으로 위탁하고 있다. 이들 INSPIRE 교육 라이브러리는 무료이나, 등록이 필요하다.

INSPIRE 교육 교재를 위한 등록

이 라이브러리에 추가하고 싶은 교육 모듈이 있다면 제안을 제출하거나, 아래의 링크를 이용해 주세요.

교육 모듈 제안

새로운 교육 모듈 요청

INSPIRE를 위한 의미론적 지식

내용  링크  관리자  공무원  기술자
 INSPIRE 개요  여기  ◎  ◎  ○
 INSPIRE 데이터/서비스 공유  여기  ◎  ◎  ◎
 XML/GML 기본 개념  여기    ○  ○
 INSPIRE 데이터 사양  여기  ○  ◎  ◎
 데이터 품질  여기    ○  ○
 INSPIRE 네트워크 서비스  여기  ○  ◎  ◎
 Data 조화  여기    ◎  ○

◎: 필수 ○: 선택

고급 기술 모듈

내용  링크  관리자  공무원   기술자
 데이터/메타데이터 조화를 위한 절차  여기    ○  ◎
 데이터 변환 예  여기    ○  ◎
 INSPIRE를 위한 메타데이터와 데이터 검증  여기    ○  ◎
 메타데이터와 목록 서비스  여기    ◎  ○
 INSPIRE 네트워크 서비스 -고급  여기    ○  ◎

◎: 필수 ○: 선택

기술 트렌드 및 혁신 솔루션
내용 링크  관리자  공무원   기술자
 INSPIRE 고급  여기  ◎  ○  
 Linked 데이터 개요  여기  ○  ○  ○
 Linked 데이터 고급  여기      ○

◎: 필수 ○: 선택

INSPIRE 용어집에는 INSPIRE 지침 및 INSPIRE 실행 규칙 문서 그리고 이 교육 모듈에서 사용되는 공통 용어에 대한 일반적인 용어 및 정의를 담고 있다.

===

https://inspire.ec.europa.eu/about-inspire/563

Posted by 푸른하늘 푸른하늘이

댓글을 달아 주세요

공간정보/표준2018. 8. 9. 22:43

일본 국토지리원에서 공간정보 표준과 관련하여, 공공측량 시행시 공간정보 표준을 지키는 방법에 대해 설명한 글입니다.

간단히 요약하면, 측량계획기관(발주자)가 측량사업을 시행하고자할 때, 먼저 제작하고자하는 측량성과의 종류, 내용, 구조, 품질 등을 담은 제품사양서를 작성해야 합니다. 이를 공공측량시행계획서와 함께 국토지리원에 제출하여 승인을 받습니다. 

이때 제품사양서에는 여러가지 내용이 포함되므로, 이 사이트에는 여러가지 샘플을 제공함과 동시에, 제품사양서 편집툴도 제공합니다. 전형적인 측량작업인 경우에는 샘플을 편집하는 방법이 편하고(기준점 측량부터 응용측량까지 측량 종류별로 따로 샘플이 있습니다.), 독특한 측량작업이라면 처음부터 제품사양서를 만들어야 하는데, 이때 제품사양서 편집 툴을 사용합니다.

제품사양서는 측량사업을 발주시 필요한 여러가지 사업관련 서류중의 하나로 포함됩니다. 측량작업기관은 이 제품사양서를 기준으로 측량을 실시하고 그 품질을 평가하여 메타데이터와 함께 측량 계획기관에 제출합니다. 이때 측량성과는 GML 로 제출합니다. 공간정보 표준에서 데이터 교환에는 GML 포맷을 사용하는 것이 표준으로 되었기 때문입니다.

품질 평가의 경우, 각각의 측량작업 별로 [품질요구 및 평가]에 관한 샘플이 있으므로, 이를 기준으로 평가를 하게 됩니다. 평가 결과는 품질평가표에 정리하게 됩니다. 메타데이터 작성의 경우 여러가지 항목을 입력해야 하기 때문에 국토지리원에서는 메타데이터 편집기를 제공하고 있습니다. 

이렇게 작성된 공공측량결과는 국토지리정보원에 사본을 제출하도록 규정되어 있는데, 이때 품질평가표와 메타데이터를 함께 제출해야 합니다. 

이처럼, 일본에서 작업규정준칙(우리나라의 공공측량작업규정에 해당)에 따라 제품사양서로부터 메타데이터에 이르기 까지의 규정만 지키면 자동으로 공간정보 표준을 지키게 됩니다. 아니, 공공측량인 이상 공간정보 표준을 지키지 않을 수 없습니다. 규정에 정해져 있으니까요.

우리나라에서 여러가지 이유로 공간정보표준을 지키지 않거나 혹은 무시되고 있는데, 일본의 사례를 잘 참고했으면 좋겠습니다.

민, 푸른하늘

원문 : https://psgsv2.gsi.go.jp/koukyou/public/seihinsiyou/seihinsiyou_index.html

====

작업 규정 준칙 제 5 조에는 측량 계획 기관이 공공 측량을 실시하고자 할 때, 측량 성과의 종류, 내용, 구조, 품질 등을 나타내는 제품 사양서를 정하도록 규정하고 있습니다. 본 사이트에서는 공공측량 제품 사양서 등에 대한 정보를 제공합니다.


** 측량 계획기관의 GML 포맷 데이터 서비스 지원에 대하여(2014년 4월 9일)

국토 지리원이 "지리정보표준 프로파일 (JPGIS)"을 기반으로 정비.제공하는 데이터는, 2012년부터 GML 형식으로 제공하도록 하겠습니다.

1.GML 단일화 배경과 국토 지리원의 대응  

"지리 정보 표준 프로파일 (JPGIS)"은 ISO 국제 표준을 기반으로 공간 데이터의 사양을 정하고 있습니다. 2011 년 ISO 표준이 개정되어, 공간 데이터는 원칙적으로 GML 형식으로 인코딩하는 것이 국제표준이 되었기 때문에, 국토 지리원의 데이터도 앞으로 원칙적으로 GML 형식으로 제공하기로 하였습니다. 그러나 이용자 요구가 높은 지리 공간 데이터는 다른 포맷으로도 제공할 예정입니다. 

2. 측량 계획 기관의 공간 데이터 정비에 대하여

국토 지리원에서는 측량 계획 기관의 GML 포맷 데이터 서비스를 지원하기 위하여,  XML 포맷에서 GML 포맷으로 변환하는 도구를 공개하고 있습니다. 자세한 내용은 공공 측량 뷰어 컨버터 사이트를 참고하십시오. 

「지리 정보 표준 프로파일 (JPGIS)」에 대한 상세한 내용은 여기를 참조하십시오.




이 사이트 자료를 "지리정보표준 프로파일 (JPGIS) 2014"에 맞춰 갱신하였습니다.(2014년 4월1일)




메타데이터 편집기를 개선했습니다. (2013년 6월 25일)

제품사양서 및 메타데이터의 "좌표참조계"에는 "JGD2011"로 기술하여주십시오(2013년 6월25일)
-> "지리 정보 표준 프로파일 (JPGIS) 2014 '에 맞춘 본 사이트의 자료(최신 제품사양서 및 메타데이터의 "좌표참조계")를 이용할 경우, 이미 "JGD2011"로 기술되어 있으므로, 별도 처리가 필요없습니다. (2013 년 6 월 13 일)


제품사양서 작성

제품 사양서란

  • 어떤 측량 성과를 작성하는가
  • 작성하는 데이터의 내용과 구조는 어떠한가?
  • 품질은 어느 정도인가 

등을 정한 측량 업무의 발주서류 중 하나입니다. 

  • 발주자(측량계획기관)는 제품사양서 등을 사용하여 사업을 발주합니다. 
  • 수주자는 제품사양서를 기준으로 데이터를 작성합니다. 

 측량계획기관은 공공측량 실시계획서와 함께, 제품사양서를 국토지리원에 제출해 주십시오.

제품사양서 작성방법

제품사양서 작성방법은 다음의 세가지가 있습니다. 1-3. 중 하나의 방법으로 만듭니다] 

  1. "작업규정준칙"을 준용한 "공공 측량 작업 규정"에 따라 업무를 수행할 경우, 제품 사양서 샘플 (① 제품사양서, ② 응용 스키마, ③ 품질 요구 및 평가)을 사용할 수 있습니다. [가장 추천하는 방법]
    1. "① 제품사양서" 워드 파일을 다운로드받아, 필요한 내용을 작성해주세요.
    2. "② 응용스키마" PDF 파일의 내용을 확인해 주세요.
    3. "③ 품질요구 및 평가" PDF 파일의 내용을 확인해 주세요.
    4. "① 제품사양서"를 사용하여 작성한 제품사양서를 공공측량 실시계획서와 함께 국토 지리원에 제출하십시오.

      【주의】 "② 응용스키마", "③ 품질요구 및 평가"의 내용이 업무에 적합하지 않은 경우, 방법 2 또는 방법 3을 사용하여 제품사양서를 작성하십시오.

  2. 제품사양서에서 "응용 스키마", "품질요구 및 평가" 등을 직접 만들 경우, "④ 원본 작성용 제품사양서" 파일을 다운로드받아 수정하여 작성하십시오. 

  3. 제품사양서 편집기를 활용하면, 모든 제품사양서 항목을 직접 만들 수 있습니다. 단, 제품사양서  편집기는 자세한 응용스키마 UML 클래스다이어그램을 작성할 수 없으므로, 주의하시기 바랍니다.

제품사양서 등 샘플

기준점측량

① 제품
사양서
② 응용
스키마
③ 품질요구 및 평가④ 원본 작성용
제품 사양서
(참고)
기준점 측량 (GNSS)

[워드:62KB]
2018.4.1

[PDF:231KB] 
2014.4.1

[PDF:176KB]
2014.4.1

[워드:1.1MB]
2018.4.1

응용 스키마 XML 문서
(JPGIS 부속서 12 형식)
 
[XSD:8KB] 
2015.11.24 

(JPGIS 부속서 8 형식) 
[XSD:6KB] 

코드 목록
 
[XML:1KB] 
2015.11.24
기준점 측량 (TS)

[PDF:207KB]
2014.4.1

기준점 측량
(좌표 보정)

[워드:64KB]
2018.4.1

[PDF:161KB] 
2014.4.1
[워드:157KB] 
2018.4.1

  • 제품사양서는 PDF 형식으로 작성하는 것이 원칙입니다. 워드로 작성한 파일은 PDF 형식으로 변환하십시오. 
  • 예전 공개한 "제품 사양서 (간략 버전)" 파일은 "① 제품 명세서" 파일로 대체되었습니다.
  • 예전 공개한 "제품 사양서 (상세 버전)" 파일은 "④ 원본 작성용 제품사양서" 파일로 대체되었습니다.

수준측량

①제품
사양서
②응용
스키마
③품질요구 및
평가
④원본 작성용
제품사양서
(참고))
수준측량
(신설・재설)

[워드:63KB]
2018.4.1

[PDF:259KB]
2014.4.1

[PDF:190KB]
2014.4.1
※재측, 지반변동
조사와 동일

[워드:1.0MB]
2018.4.1

응용스키마 XML문서
(JPGIS 부속서 12 형식)
[XSD:4KB]
2014.4.1

(JPGIS 부속서 8 형식)
[XSD:3KB]

코드 목록
[XML:1KB]
2014.4.1

수준측량
(이전)

[워드:63KB]
2018.4.1

[PDF:167KB]
2014.4.1

[워드:336KB]
2018.4.1

수준측량
(재측,
지반변동조사)

[워드:64KB]
2018.4.1

[PDF:271KB]
2014.4.1

[PDF:190KB]
2014.4.1
※신설・재설과
동일

[워드:1.0MB]
2018.4.1

  • 제품사양서는 PDF 형식으로 작성하는 것이 원칙입니다. 워드로 작성한 파일은 PDF 형식으로 변환하십시오. 
  • 예전 "제품 사양서 (간략 버전)" 파일은 "① 제품 명세서" 파일로 대체되었습니다.
  • 예전 "제품 사양서 (상세 버전)" 파일은 "④ 원본 작성용 제품사양서" 파일로 대체되었습니다.

수치지형도

① 제품
사양서
② 응용
스키마
③ 품질요구 및 평가④ 원본 작성용
제품 사양서
(참고)
수치 지형도
(지도 정보 수준 500)
[워드:75KB]
2016.4.1
표준 제품사양서
[PDF:3.9MB] 
2014.4.1 
(응용스키마:제 4·5 장) 
(품질요구 및 평가:7 장) 

구현 가이드 
[PDF:1.7MB] 
2014.4.1
[워드:175KB] 
2016.4.1
응용스키마 XML 문서
(JPGIS 부속서 12 형식)
 
[XSD:88KB] 
2014.4.1 

(JPGIS 부속서 8 형식) 
[XSD:89KB] 
2014.4.1
수치 지형도
(지도 정보 레벨 1000)
[워드:74KB]
2016.4.1
수치 지형도
(지도 정보 수준
 
500/1000 혼합)
[워드:75KB]
2016.4.1
수치 지형도
(지도 정보 레벨 2500)

[워드:75KB]
2016.4.1

표준 제품사양서
[PDF:3.7MB] 
2014.4.1 
(응용 스키마:제 4·5 장) 
(품질 구 및 평가:7 장)

[워드:164KB] 
2016.4.1

촬영(사진기준점 설치, 촬영, 항공삼각측량

①제품사양서②응용스키마③품질요구 및 평가④원본 작성용
제품사양서

디지털 항공카메라

[워드:67KB]
2018.4.1
[PDF:199KB]
2014.4.1
[PDF:233KB]
2014.4.1
[워드:202KB]
2018.4.1
아날로그 항공카메라[워드:67KB]
2018.4.1
[PDF:270KB]
2014.4.1
[PDF:214KB]
2014.4.1
[워드:226KB]
2018.4.1

  • 본 명세서 샘플은 "작업규정 준칙" 제3편 제3장 제1절 ~ 7절 업무 (사진기준점 설치, 촬영, 항공삼각측량)을 고려하며, 성과품은 "수치 사진"과 "외부 표정 요소 성과표"입니다.
  • 제품사양서는 PDF 형식으로 작성하는 것이 원칙입니다. 워드로 작성한 파일은 PDF 형식으로 변환하십시오.

정사사진 작성

①제품사양서②응용스키마③품질요구 및 평가④원본 작성용
제품사양서

정사사진

[워드:65KB]
2016.4.1
[PDF:242KB]
2014.4.1
[PDF:178KB]
2016.4.1
[워드:222KB]
2016.4.1

  • 제품사양서는 PDF 형식으로 작성하는 것이 원칙입니다. 워드로 작성한 파일은 PDF 형식으로 변환하십시오.

항공 레이저 측량

①제품사양서②응용스키마③품질요구 및 평가④원본 작성용
제품사양서

수치 표고 모델

[워드:65KB]
2018.4.1
[PDF:200KB]
2014.4.1
[PDF:155KB]
2014.4.1
[워드:444KB]
2018.4.1

  • 본 제품사양서샘플의 성과품 (수치 표고 모델)은 그리드 데이터 (x, y, z 값을 갖는 점군 데이터) 입니다. DEM 데이터 (벡터로 격자크기 및 자료범위를 지정하여 z 값만 기술한 데이터)가 아니므로 주의하시기 바랍니다.
  • 제품사양서는 PDF 형식으로 작성하는 것이 원칙입니다. 워드로 작성한 파일은 PDF 형식으로 변환하십시오.

응용 측량

①제품사양서②응용스키마③품질요구 및 평가④원본 작성용
제품사양서

노선 측량

[워드:189KB]
2018.4.1
[PDF:249KB]
2015.11.24
[PDF:168KB]
2014.4.1
[워드:314KB]
2018.4.1

하천 측량

[워드:172KB]
2018.4.1
[PDF:230KB]
2014.4.1
[PDF:190KB]
2014.4.1
[워드:247KB]
2018.4.1

용지 측량

[워드:169KB]
2018.4.1
[PDF:230KB]
2014.4.1
[PDF:170KB]
2014.4.1
[워드:244KB]
2018.4.1

삼차원 점군 데이터 제작

원본 작성용
제품사양서(안)

삼차원 점군 데이터

[워드:45KB]
2018.4.1

  • 이 원본 작성용 제품사양서 샘플(안)은 실시하는 측량 업무나, 필요한 제품 사양에 따라 수정하여 사용하십시오. 
  • 제품사양서는 PDF 형식으로 작성하는 것이 원칙입니다. 워드로 작성한 파일은 PDF 형식으로 변환하십시오.

=======

참고자료 : 지리 공간 데이터 제품 명세서 작성 가이드 JPGIS 2014 판 [PDF : 2.1MB]

제품사양서 편집기

아래는 국토지리원에서 공개한 제품사양서 편집기 (지리공간 데이터 제품사양서 작성 지원 툴)입니다. 단, 이 편집기에서는 자세한 응용스키마 UML 클래스 다이어그램을 작성할 수 없습니다. 별도로 작성한 UML 클래스 다이어그램 등을 추가 · 편집해야 하므로 주의하시기 바랍니다. 

[제품 명세서의 작성은 제품 사양서 등 샘플을 사용하는 방법을 권장합니다] 

지리공간 데이터 제품 명세서 작성 지원 도구
지리 공간 데이터 제품 명세서 작성 가이드 JPGIS 2014 판 [PDF : 2.1MB]

품질평가

품질 평가는 "작성한 데이터가 제품사양서에서 규정한 품질을 만족하는지" 확인하는 작업입니다. (수주자가 평가합니다.) 

  • 발주자 (측량계획기관)은 제품사양서에 품질에 관한 사항을 규정합니다. 
  • 수주자는 제품사양서를 기준으로 데이터를 제작하고 측량성과에 대한 품질을 평가합니다. 
  • 품질평가표를 보면 데이터 품질(합격 여부)을 알 수 있습니다. 

측량 계획 기관은 국토 지리원에 측량 성과를 제출 할 때, 품질 평가표 사본도 제출하십시오. 

품질 평가표는 개별 표에 각 품질 요소의 평가 결과를 기재하고, 총괄표에 합격 여부를 기재합니다. 아래에 있는 품질평가표 샘플을 제품사양서 품질 요구에 따라 변경 한 후 사용하십시오. (수치 지형도 데이터 등, 여러가지 지형지물이 포함된 측량 성과의 경우, 각각의 지형지물별로 별도의 표를 작성하십시오)

기준점 측량

품질평가표 샘플

GNSS 관측

[엑셀:43KB]
2014.4.1

토털스테이션 관측

(1급)
[엑셀:42KB]

2014.4.1

(2급)
[엑셀:42KB]

2014.4.1

(3급)
[엑셀:42KB]

2014.4.1

(4급)
[엑셀:42KB]

2014.4.1

※등급(1~4급)・관측방법(GNSS・TS)가
여러가지인 경우

[엑셀:78KB]
2014.4.1
기준점 성과좌표 보정
(보정 파라미터에 의한 재계산)
[엑셀:40KB]
2014.4.1

수준 측량

품질평가표 샘플

수준측량(신설・재설치・재관측・
지반변동 조사)

(1급)
[엑셀:40KB]

2014.4.1

(2급)
[엑셀:40KB]

2014.4.1

(3급)
[엑셀:40KB]

2014.4.1
(4급)
[엑셀:40KB]

2014.4.1
(簡易)
[엑셀:40KB]

2014.4.1
(등급 여러개)
[엑셀:67KB]

2014.4.1
수준측량 (이전)(1급)
[엑셀:40KB]

2014.4.1
(2급)
[엑셀:40KB]

2014.4.1
(3,4급)
[엑셀:40KB]

2014.4.1
(등급 여러개)
[엑셀:58KB]

2014.4.1

수치지형도

※ 데이터 품질 적용 범위는 임의로 10 가지 예를 넣었습니다. 실제 사양에 따라 재작성하십시오.

품질평가표 샘플

수치지형도 

(지도정보레벨 500)
[엑셀:83KB]

2014.4.1

(지도정보레벨 1000)
[엑셀:83KB]

2014.4.1

(지도정보레벨 500/1000 혼합)
[엑셀:83KB]

2014.4.1

(지도정보레벨 2500)
[엑셀:83KB]

2014.4.1

촬영

품질평가표 샘플

촬영(사진기준점 설치, 촬영, 항공삼각측량)

디지털 항측 카메라
[엑셀:39KB]

2014.4.1

아날로그 항측 카메라
[엑셀:41KB]

2014.4.1

정사사진 제작

품질평가표 샘플

정사사진

[엑셀:38KB]
2014.4.1

항공 레이저 측량

품질평가표 샘플

수치표고 모델

[엑셀:37KB]
2014.4.1

응용측량

품질평가표 샘플

노선측량

[엑셀:38KB]
2015.11.24
하천측량[엑셀:39KB]
2015.11.24
용지측량[엑셀:38KB]
2014.4.1

3차원 점군 데이터 제작

품질평가표 샘플(안)
三次元点群データ[엑셀:22KB]
H29.10.20

메타데이터


메타 데이터 편집기 를 개선했습니다 (2013년 6 월 25 일)
    · "위도 경도" 입력 기능을 개선했습니다.
    · "JGD2011의 전거" 입력 기능을 삭제했습니다.
     (이전 버전을 제거한 후 새 버전을 설치하십시오)

메타 데이터란 "데이터(측량 성과)에 대한 요약 데이터"로서, 검색 등에 사용됩니다. 

  • 발주자(측량계획기관)는 제품사양서에 메타데이터 작성 규정을 기재합니다.
  • 수주자는 제품사양서에 따라 메타 데이터를 작성합니다. 
  • 메타데이터는 검색 시스템 등에서 이용되어, 측량 효율화에 도움이 됩니다. 

측량계획기관은 국토지리원에 측량 성과를 제출할 때, 메타데이터 사본도 제출하십시오. 

메타 데이터 편집기를 사용하면 메타 데이터를 쉽게 작성할 수 있습니다. 자세한 내용은 다음을 참조하십시오. 


문의처

본 사이트에 관한 질문 등은 다음 문의 양식으로 접수하고 있습니다. 

문의 양식


====

원문 : https://psgsv2.gsi.go.jp/koukyou/public/seihinsiyou/seihinsiyou_index.html




Posted by 푸른하늘 푸른하늘이

댓글을 달아 주세요

공간정보/표준2018. 6. 20. 16:20

현재 우리나라의 공간데이터 교환은 많은 문제가 있습니다. 생산자가 데이터 공개를 기피하는 것은 논외로 치더라도, 기껏 공개한 데이터도 공개 주체마다 제 각각이라서 사용하기 힘듧니다. 그것은 단순히 교환 포맷의 문제가 아닙니다. 데이터 교환용 공통 스키마가 있어야만 해결될 수 있습니다.

데이터 생산자는 자신의 데이터를 이 공통 스키마에 따라 변환한 임시 데이터셋을 만들고, 이를 지정한 공통 포맷으로 변환한 후, 이렇게 만들어진 파일을 공유해야 합니다. 이렇게 해야 각각의 생산자별로 다른 형태의 데이터가 만들어지는 상황을 피할 수 있습니다.

공간데이터 교환을 위해 가장 좋은 포맷은 GML(지리 마크업 언어 : Geography Markup Language)입니다. ISO TC211 표준에서도 교환표준으로 GML을 추천하고 있습니다. GML은 XML의 일종입니다. XML은 IT 분야에서 정보 전달의 수단으로 널리 사용되고 있습니다. 특히 해당 XML의 구조를 xsd(xml schema definition)이라는 구조로 저장하여 이를 함께 배포함으로써 데이터의 일관성을 유지하고 사용성을 높이고 있습니다. 마찬가지로 GML도 그 구조를 xsd로 만들어 함께 배포하면 데이터 교환에 관한 문제가 해결될 수 있습니다.

이상이 제가 공간정보 유통과 표준에 대하여라는 글에서 주장한 내용입니다. 

공간정보를 GML로 변환하는 것은 어렵지 않습니다. 대부분의 공간정보 처리 소프트웨어가 모두 GML을 지원하고 있기 때문입니다. 그런데 그 GML의 구조를 나타내는 XML Schema는 어떻게 만들어야 할까요? 이 글이 바로 공통스키마를 만들고, 이 공통스키마를 xsd로 변환하는 방법에 관한 글입니다.

공통 응용스키마 작성

공통 응용스키마는 다른 응용스키마와 마찬가지로, ISO 19103에서 정의한 개념스키마 언어인 UML(통합 모델링 언어 : Unified Modelling Language)를 사용하여, ISO 19109에서 정의한 응용 스키마 규칙에 따라 만듧니다. UML은 그래픽 언어이기 때문에 파워포인트나 포토샵 아니면 그냥 워드프로세서로 만들 수도 있지만, 대부분은 UML 도구를 사용하여 만들게 됩니다. 오픈소스인 Modellio도 정말 좋은 대안입니다. 하지만, ISO TC211에서는 상용 프로그램인 Enterprise Architect를 사용하여 작업하므로, 저도 이 도구를 사용하고 있습니다.

또한 응용스키마는 클래스 다이어그램 뿐만 아니라, 각각의 패키지/클래스/속성/연관 등에 대한 상세한 설명을 담은 문서가 필요한데, 이것도 UML 도구의 문서화도구를 사용해야만 편리합니다. 클래스 다이어그램과 문서가 일관성을 유지할 수 있기 때문입니다. 이와 같은 장점때문에 ISO 19109 응용스키마 법칙에서는 UML도구의 문서화 기능을 사용하여 문서화하라고 권고하고 있습니다. 따라서 UML 도구는 공간정보 응용스키마를 작업하려면 필수사항이라고 할 수 있습니다.

그런데 Enterprise Architect 를 사용하여 만든 응용스키마는 xsd로 직접 변환이 되지 않습니다. 기본적으로 UML 은 프로그래밍 언어가 아니기 때문이기도 하고, UML과 XML이 만들어진 개념이 많이 차이가 있기 때문입니다. 그렇다고하여 UML로 만들어진 응용스키마를 보면서 xsd를 따로 만드는 것은 에너지 낭비일 뿐만 아니라 불일치가 발생할 가능성이 높으므로 반드시 피해야 합니다.

ShapeChange를 이용한 UML ->XML Schema 변환

ISO TC211에서는 이 문제를 ShapeChange 등의 공개 소프트웨어를 사용하여 해결하였습니다. 상세한 내용은 ShapeChange를 이용하여 UML 모델에서 XML 스키마 생성하기를 읽어보시면 됩니다. 이 절차의 핵심은 ShapeChange입니다. 이 소프트웨어가 UML의 교환포맷인 XMI를 읽어들여서 모델의 적합성을 체크한 후, xsd를 만들어주는 소프트웨어 입니다. 

ShapeChange를 설치하고 테스트하는 방법은 ShapeChange 소개글에 나와 있습니다. 간단히 정리하면 Java Runtime Enviroment 32비트버전을 설치하고, ShapeChange 압축파일을 적당한 위치에 압축해제 해주고 약간의 설정을 해주면 됩니다.

ShapeChange 소개글에서 사용한 테스트용 응용스키마는 아래와 같이 생겼습니다. 복잡한 연관 관계는 없이 기본적인 데이터 유형 몇개와, 이들을 사용하는 지형지물 유형 2개가 정의되어 있습니다.

이 응용스키마에 대한 xmi 파일은 아래와 같습니다. 참고로 xmi 는 OMG에서 개발한 XML 교환용 포맷입니다.

test.xml

아래는 이 파일의 시작부분입니다. 매우 복잡합니다. ㅎㅎ

아래는 ShapeChange를 실행시켰을 때 나오는 XML Schema 파일 (.xsd)입니다. 

test.xsd

아래는 이 파일의 시작부분만 일부 캡처한 것입니다. 물론 많이 복잡합니다만, xml 스키마를 일부 알아볼 수 있겠네요.

예를 들어, 위에 있는 클래스 다이어그램에서는 DataType2를 아래와 같이 정의했습니다.

xsd에서는 아래와 같이 정의되어 있습니다. 제가 아직 XML/GML을 공부하는 중이라 잘은 모르지만, 예쁘게 정리된 것 같습니다. ㅎㅎㅎ

  <element name="DataType2" substitutionGroup="gml:AbstractObject" type="test:DataType2Type"/>
  <complexType name="DataType2Type">
    <sequence>
      <element maxOccurs="unbounded" name="string" type="string"/>
      <element minOccurs="0" name="integer" type="integer"/>
    </sequence>
  </complexType>
  <complexType name="DataType2PropertyType">
    <sequence>
      <element ref="test:DataType2"/>
    </sequence>
  </complexType>

보너스 - 지형지물 카탈로그 제작

게다가... ShapeChange를 사용하면 xml 스키마 뿐만 아니라, ISO 19110에서 규정한 지형지물 카탈로그(Feature Catalogue)도 만들 수 있습니다.  아래가 그 html 파일입니다.

test.html

그리고 아래는 이 지형지물 카탈로그의 첫부분만 캡쳐한 것입니다.

지형지물 카탈로그는 ISO 19110 표준에 정의되어 있습니다만, 우리나라에서 아직까지 지형지물 카탈로그를 제작해서 공개한 경우는 못본 것 같습니다. 그런데 이렇게 쉽게 제작할 수 있다면 지형지물 카탈로그도 더 많이 공개될 수 있지 않을까 기대해볼 수 있을 것 같네요.

====

아직까지 자세히 들여다보지는 못해서 사용법이나 자세한 설정방법 등은 잘 알지 못하지만, 응용스키마 작업을 하려면 ShapeChange를 반드시 활용해야 한다는 것은 알게되었네요. 오래전부터 고민해왔었는데, 이걸 발견하니 속이 후련해지는 느낌입니다. ㅎㅎㅎ

민, 푸른하늘


Posted by 푸른하늘 푸른하늘이

댓글을 달아 주세요

공간정보/표준2018. 6. 18. 23:28

ISO TC211 UML 모델을 실제 응용프로그램에서 활용하기 위해서는, 이 모델들을 직렬화하고 정보처리단위간에 전송할 수 있는 표현으로 구현되어야 한다. 대부분 현재의 구현은 XML을 사용하여 직렬화하며, 이때 XML Schema를 사용하여 교환 문서의 구조를 정의한다. 개념 모델을 구현하는 스키마를 자동적으로 생성하려면, UML 모델로부터 XML 스키마를 생성하는 소프트웨어 처리가 필요하다. 여기에서 설명하는 처리는 여러가지 최신 표준을 위하여 사용된다.

필요 소프트웨어

여기에 서술된 내용은 매우 간략한 정보이다. 자세한 내용은 Harmonized Model Management Group 위키를 참조하라

Enterprise Architect(EA) : ISO TC211 조화 UML모델을 생성, 갱신, 관리하는데 사용되는 상용 소프트웨어 패키지. 여기에 설명된 내용은 버전 12.1.1230을 기초로 한다. 2017년 07월 현재 EA 버전은 13.5이지만, 새로운 버전에 이 절차를 테스트하지 않았다.

ISO TC211 조화 모델(Harmonized Model) : ISO TC211 조화 모델은 웹에서 접근가능한 디렉토리에 저장되어 있다. 이 디렉토리에는 TC211가 책임을 맡고있는 모든 UML 모델을 담고 있는 파일들이 있다. 이 모델들은 EA로부터 XMI XML 교환포맷을 사용하여 내보낸(export) 것으로, 이들 XMI 파일들은 이 온라인 디렉토리에서 버전 관리(아래 Subversion을 볼 것)되고 있다. EA를 제외한 다른 UML 모델링 패키지도 이들 XMI 파일을 사용할 수 있으나, 실용적으로는 모델의 측면(노트, 태그, 색 코딩 등)을 모두 신뢰성있게 변환할 수 있을 정도로 표준화된 상태가 아니다. TC211 조화모델 저장소에 있는 XMI 문서는 다음의 네임스페이스를 사용한다. 

xmi.version="1.1" xmlns:UML="omg.org/UML1.3"

아울러 Enterprise Architect exporter 버전 2.5를 사용했고, windows-1252 캐릭터 인코딩을 사용하였다.

Subversion : TC211 조화모델 저장소는 Subversion 소프트웨어와 아파치 소프트웨어 재단의 오픈소스 패키지를 사용하여 관리되고 있다. 모델 요소를 체크아웃하고 변화를 체크하려면, 반드시 Subversion 클라이언트를 설치해야 하며, 모델 저장소와 연결해야 한다.

ShapeChange : Interactive Instruments GmbH software에서 제작한 오픈소스 소프트웨어 패키지로서, UML을 XML로 변환하여 모델 구현을 위한 XML Schema를 생성한다.

Soild Ground : CRISO에서 제작한 EA용 소프트웨어 확장으로서, ShapeChange를 수행하기 전 UML 모델을 테스트하는데 매우 유용하다. 현재는 CRISO에서 관리하지 않는다. 윈도우용 설치프로그램은 XML Maintenance Group 저장소에 있다. 해당 저장소에서 관련 문서도 구할 수 있다.

모델 설정

TC211을 위한 XML Schema를 생성하려면, UML 모델을 구성할 때 특정한 UML 프로파일을 따라야 한다. 자세한 내용은 온라인 ShapeChange 문서를 참고하라. 아래는 몇가지 핵심적인 스테레오타입과 태그를 설명한 것이다.

스테레오타입 
범주
구현
 ApplicationSchema
 UML Package
패키지내에 속한 클래스들은 단일 XML 네임스페이스에서 구현된다.
 Abstract
 Class
UML 클래스가 XML의 추상요소로 구현된다. UML 모델에서 하나 이상의 구체 클래스가 존재해야 한다.
 Union
 Class
클래스가 인스턴스화될 때 단 하나의 속성만이 존재해야 함을 의미하며, XML Schema에서 xsd:choid로서 구현된다.
 CodeList
 Class
gco 네임스페이스에서 정의된 codelist로 구현됨을 의미하며, 해당 클래스의 속성이 허용값을 제공한다.

별도의 XML 네임스페이스로 구현되는 각각의 모델 모듈은 별개의 UML 패키지에 들어 있어야 한다. (스테레오타입은....???) 응용스키마 패키지는 다음 표1과 그림1에 표시된 tag를 가져야 한다.

Tag
값 예시
참고
 targetNamespace
 http://standards.iso.org/iso/
19115/-3/cit/2.0
 XML 스키마에서 선언될 네임스페이스 URI
 version
 1.0
 
 xmlns
 cit
 TC211 내에서 고유한 3글자 약어. xml 스키마에서 접두어 이름으로 사용됨
 xsdDocument
 ISO19115-3/cit/1.0/cit.xsd
 생성된 XML스키마를 위한 경로(부분)과 파일명. 이 파일 경로가 스키마 생성 절차가 수행된 위치 뒤에 추가된다. 아래를 볼 것
 xsdEncodingRule
 iso19139_2007
 UML에서 XML 변환 규칙 세트를 위한 식별자. 현재 이것은 반드시 iso_19139_2007 이어야 함.

<그림 1> 태그값을 부여하는 EA 대화창 화면

응용스키마 패키지는 하나 이상의 하위 패키지를 포함해야 한다. 이때 하위 패키지들은 각각 별도의 XML 스키마 파일로 구현된다. 분명하게 하기 위하여 스테레오타입 <<Leaf>>를 부여할 수도 있지만 요구사항은 아니다.

해당 패키지에서 xsdDocument 태그로 지정된 이름(그림1에서 cit.xsd)을 가진, 하나의 XML 스키마 파일이 응용스키마 수준에서 생성된다. 이 스키마는 응용스키마 패키지에 포함된 하위 패키지에서 생성된 스키마 파일들을 포함<xsd:include>하게 된다. 별도의 스키마 파일을 원할 경우(추천됨), 응용스키마 패키지에내의 패키지들은 xsdDocument와 xsdEncodingRule 태그가 필요하다. 이때 xsdDocument의 경로는 <xsd:include>경로를 간단하게 하기위해 최상위 xsd의 문서 경로와 일치해야 한다. (아래의 후처리(Post Processing) 절 참고)

UML 클래스에서 속성에 대한 태그

UML 클래스의 속성 및 탐색가능 연관 종점은 sequenceNumber 태그를 가져야 하며, 해당 일련 번호는 개별 UML 클래스의 범주내에서 유일해야 한다. 일련변호는 필수가 아니다 - ShapeChange는 일련번호 없이도 XML 스키마를 생성한다. 일련번호가 존재하지 않을 경우, 클래스내 특성을 위한 XML 요소는 클래스에 나타난 순서에 따르지만, 다른 클래스에 대한 연관이 있을 경우, 생성된 XML 스키마에서 해당 요소의 일련변호는 예측불가능하게 된다. 일련번호 사이에 공백이 있어도 무방하다. 속성과 연관이 많은 클래스의 경우, 일련번호가 바뀌거나 나중에 새로운 속성이 추가되면 편리하다.

패키지 간의 링크(Linkage)

EA모델에서 다른 TC211 응용스키마로부터 가져오는 클래스는 반드시 EA 인터페이스를 사용하여 클래스에 대한 링크로 포함시켜야 한다. 클래스의 이름을 입력하면 필요한 내부 링크가 생성되지 않는다. 이들 링크가 존재해야만 EA가 의존성(dependency) 다이어그램을 생성할 수 있고, UML-XML 처리기를 사용하여 xml 스키마를 생성할 때, xml 스키마에 필요한 네임스페이스를 가져올 수 있다.

스키마 파일의 구조(Organization)

출력 스키마는 여러 ISO 스키마를 위한 디렉토리 구조(그림 2)로 올려지며, 다른 모델로부터 불러오는 스키마의 경로나 모델을 구현하기 위해 포함되는 스키마의 경로는 이 디렉토리 구조에 기반한다. 최상위 폴더내에 각각의 TC211 표준을 위한 폴더(즉, ISO19115, ISO19110 등)가 존재한다. 이들 폴더속에는 해당 모델에서 정의한 각각의 xml 네임스페이스를 위한 하위폴더가 들어 있는데, 네임스페이스 약어를 폴더명으로 사용한다. 그 하위 폴더의 이름은 해당 네임스페이스의 구현을 위한 버전번호이며, 실제 스키마 파일은 해당 스키마의 버전 번호 폴더 내에 존재한다. 

<그림 2> ISO TC211 XML 스키마 디렉토리를 위한 폴더 명명구조

스키마는 'xsdLocation' 'xsdDocument' tagged value에 의해 이 구조로 올라간다. 이때 xsdDocument는 생성된 스키마가 저장될 위치에 대한 경로(그림 1 참고)를 제공한다. 경로 위치는 ShapeChange가 실행되는 root 디렉토리에 대한 상대경로이다.

작업 흐름

주 TC211 조화 모델 저장소에 있는 UML 모델들은 ShapeChange로 직접 편집하거나 작업할 수 없다. 이 저장소의 'implementation-XML' 하위폴더는 별도의 저장소로서 접근되어야 한다. 이 폴더는 주 조화모델의 UML 모델 복사본을 담고 있는데, xml 스키마를 생성하기 위하여 편집된 것이다. 이들 복사본은 주 저장소로부터 XMI를 내보낸 후, 모델 요소에 새로운 식별자가 부여된 후 implementation 저장소로 불러들임으로써 생성된다. 따라서, 주 조화모델과는 별도로 implementation 모델 내부에서 모델간 연결이 설정될 수 있다.

처리절차는 다음과 같다. 좀 더 자세한 정보는 HMMG 위치 페이지의 조화모델 저장소 접속 방법을 참고하라.

  1. implementation-xml subversion 디렉토리를 자신의 로컬 환경으로 체크아웃한다.[accessed 2018-03-10, rev 3333] (아이디/비밀번호가 필요함)
  2. EA의 version control 설정에서 'implementation-XML'을 이 디렉토리로 연결한다.
  3. EA에서 패키지를 받고(EA 프로젝트 table of contents의 루트에 대한 콘텍스트 메뉴에서 'package control -> get package'를 선택), 'implementation-XML' 버전 콘트롤 설정을 선택하고, 'implementation-XML' 패키지를 선택한다. 이렇게 하면 EA 프로젝트의 workspace를 위한 디렉토리 구조를 불러온다.
  4. 모델 최상위의 콘텍스트 메뉴에서 'Package Control/Get All Latest'를 선택하면 모델이 올라온다. 준비완료.

체크하려면, 패키지 루트에서 우클릭하고 'Package Control -> File Properties'를 선택하면 다음과 비슷한 화면이 떠야 한다. (*** 이런 메뉴 없음)

<그림 3> Enterprise Architect 의 파일 정보

EA에서 패키지 체크아웃이 실패할 경우, subversion command line 기능으로 조치를 취할 필요가 있다. Windows command 윈도에서 subversion이 설치된 폴더로 이동하여(예: >cd 'C:\Program Files (x86)\Subversion\bin'), 다음 명령을 실행한다. 

> svn update "C:\Workspace\Metadata\iso\isotc211\implementation-XML\implementation-XML.xml"

최초의 체크아웃일 경우에는 TC211 저장소를 접근하기 위한 아이디/비밀번호를 입력해야 한다. 다음부터는 소프트웨어가 기억하게 된다. 저장소가 잠겼거나, 발생해서는 않되지만 svn 작동오류 또는 Windows 충돌이 발생했을 경우, unlock 이 필요할 수 있다. 예를 들어 다음 명령을 수행한다.

> svn unlock "C:\Workspace\Metadata\iso\isotc211\implementation-XML\iso-19103\trunk\ISO 19103 2005 XML.xml"

'Package Control/Check out' 등이 이제 이상없이 작동할 것이다.

SolidGround Operations

EA에 모델이 올려지면 SolidGround extention이 작동된다. 이제 모델을 점검하여 XML 생성에 간섭을 일으킬 수 있는 문제를 찾아볼 수 있다. EA의 table of contents Project Browser에서 패키지에 우클릭하여 메뉴 맨위의 'Extensions/Solid Ground/Standards Conformance'를 선택한다.

<그림 4> SolidGround 기능을 접근하기 위한 메뉴 접근

점검하고자 하는 패키지를 선택하고, 'Run Conformance Tests'를 선택한다. XML 스키마에 사용하고자 하는 모든 패키지에 대해 conformance 테스트를 수행한다. 결과 보고서에서 대부분 경고는 걱정할 필요가 없지만, 변경시켜야 하는 것들을 표시하는 경우가 많다. 오류는 수정해야 한다. ShapeChange는 오류를 만나면 이를 알리게 된다. 

Standards Conformance 콘텍스트 메뉴는 여러가지 유용한 옵션이 있다.

<그림 5> conformance test 콘텍스트 메뉴

'Generate Package Dependency Diagram' - 패키지에 의존성 다이어크램이 추가된다.

'Run Conformance Test' - 태그, 링크 등을 찾는다.

'Verify Package Dependencies' - 사용하는 모델에 모든 참조패키지가 있는지 확인한다.

'Assign Sequence Numbers' - 속성 및 연관에 일련번호를 부여한다. 일련번호는 생성된 XML 스키마에서 속성 및 연관의 순서를 결정한다. 이들은 ShapeChange에서 필요하지만, 순서가 정확한지 확인해야 한다. 클래스 속성은 UML에 나타난 순서에 따르지만, 연관의 순서는 다이어그램에서 명확하지 않다. 일련번호는 클래스 내 속성의 태그로서 나타나거나, 연관의 경우 EA property 대화상자를 통해서 접근할 수 있다.

ShapeChange 수행

ShapeChange 문서에 따르면, EA 호환성은 버전 7.0/7.1에 개발되었으며, 이후 버전에서도 변경없이 수행된다. ShapeChange는 EA 버전 12.0까지 사용되었다. 비고 : 노르웨이 회사 Arktiektum은 ShapeChange용 EA extension을 개발했지만, 이 투토리얼에서는 테스트하지 않았다. 유용할 것으로 본다. 자세한 내용은 여기를 보라.

ShapeChange 설치 폴더에서 test.bat을 수행하여 소프트웨어가 이상없이 작동하는 지 확인한다.

한가지 흔한 문제가 ‘Exception in thread "main" java.lang.UnsatisfiedLinkError: no SSJavaCOM in java.library.path’ 이다. 이것은 32비트 소프트웨어를 64비트 기계에서 돌릴때 발행하는 호환성문제이다. http://shapechange.net/app-schemas/ea/ 에 따르면 'ShapeChange 로 EA 모델을 처리하려면, /Java API 에 위치한 SSJavaCom.dll dmf /System32(32비트) 혹은 /SysWOW64(64비트)로 복사한다. 64비트 기계에서는 /SysWOW64 폴더에 있는 java.exe를 사용한다. EA 는 32비트 응용이기 때문이다.' 이라고 한다. 마지노선은 ShapeChange는 32 비티 버전의 java.exe에서 돌려야 하며, SSJavaCom.dll 이 class 경로에 있어야 한다. 그래서 Windows/System32 와 Windows/SysWOW64 모두에 둔다. ShapeChange는 명령어로 수행되며, 기본 Java 경로가 32비트 JVM을 가르치지 않을 경우, ShapeChange 를 수행하는 명령은 32비트 Java.exe에 대한 전체경로를 포함시켜야 한다.

[full path to 32 bit java.exe] –jar [shape change jar location] -Dfile.encoding=UTF-8 –c [configuration file location] 

대괄호 속 단어들은 자신의 구성에 따라 결정해야 한다. 나는 일반적으로 모든 파일을 완전한 경로로 실행시키므로, 현재의 작업 폴더 위치에 대해 걱정할 필요가 없다. 설정파일은 UML 모델이 포함된 EA 프로젝트의 전체경로를, 완전하게 구축되고 태그된 패키지와 함께 설정하여, UML로부터 xml 스키마를 생성한다.

ShapeChange 설정파일 준비하기

ShapeChange 설정파일을 사용하면, UML에서 XSD로 변환할 때 필요한 매우 다양한 제어가 가능하다. 가장 중요한 설정은 <input> 부분으로 다음과 같이 지정한다.

<parameter name="inputFile" value="[[TC211모델이 포함된 EA 프로젝트 파일명]]"

ShapeChange는 정규표현식(regular expression)을 사용하여 처리하고자하는 응용스키마를 식별한다. 스테레오타입이 <<ApplicationSchema>>인 패키지와 regEX와 일치하는 네임스페이스 tag 만 처리하게 된다. 설정파일에서 regex는 appSchemaNamespaceRegex 파라미터로 지정된다. 아래의 정규표현식은 3글자의 약어를 가진 ISO 네임스페이스에 대해서 작동된다.

<parameter name="appSchemaNamespaceRegex" value=
    "^http://standards.ios.org/iso/19115/-3/[a-z,0-9]{3}/\d.\d"/>

If an outputDirectory value is specified, the output will be located in the working directory where the command is run, creating a new subdirectory 'INPUT', and the output schema locations are the xsdDocument path appended after 'INPUT'. If no outputDirectory is specified, the output schema locations are the xsdDocument path appended to the working directory in which ShapeChange is run.

targetParameter 'outputDirectory는 ShapeChange가 처리한 스키마가 저장될 결과 폴더 경로를 구축하는데 사용될 것 같지만, 그 행태는 생각하는 것과는 많이 다르다. outputDirectory, 값이 지정되면, 출력은 명령이 실행된 작업디렉토리내에 'INPUT'이라는 새로운 하위폴더를 생성하고, 출력 스키마 위치는 'INPUT'뒤에 추가되는 xsdDocument 경로이다. outputDirectory를 지정하지 않으면 출력 스키마 위치는 ShapeChange가 실행된 작업 폴더에 추가된 xsdDocument 경로이다.???

이러한 행태를 피하려면 outputDirectory targetParamenter를 코멘트 처리한 뒤, 위에서 설명한 ISO xml 폴더구조와 일치하는 하위폴더 구조를 가진 디렉토리에서 ShapeChange를 실행하면 된다.

출력 스키마를 위한 폴더 설정

ShapeChange가 생성한 스키마들은 위의 스키마파일의 구조에서 설명한 디렉토리 구조로 배분될 필요가 있다. ShapeChange는 자동으로 이러한 디렉토리를 만들지 않으므로, standards.iso.org/iso/191nn 디렉토리 구조 전체를 목표 출력 디렉토리에 준비해 두어야 한다. 준비하는 방법은 GitHub\ISOTC211\XML\standards.iso.org\iso의 내용을 복사하고, xsd파일을 모두 지우면 된다. 기존의 스키마 파일들은 덮어씌워지지만, 기존의 것을 지우면 새로운 스키마 파일이 생성된 것을 쉽게 확인할 수 있다. 스키마 파일에  import 문을 올바르게 생성하려면 ShapeChange 설정에서 'standardNamespaces.xml'파일을 포함시켜야 한다. 완전한 경로를 포함시켜야 한다. 실제 내용은 아래와 비슷하게 된다.

<xmlNamespaces xmlns="http://www.interactive-instruments.de/ShapeChange/Configuration/1.1">
<xmlNamespace nsabr="cat" ns="http://www.isotc211.org/2014/cat/1.0" location="../../../ISO19115-3/cat/1.0/cat.xsd"/>
<xmlNamespace nsabr="cit" ns="http://www.isotc211.org/2014/cit/1.0" location="../../../ISO19115-3/cit/1.0/cit.xsd"/>

이들 상대 경로는 표준화된 폴더 구조로 인해 작동한다. '../../../' 패턴은 동일한 ISO 모델로부터 import 할 경우에는 필요 없지만, 다른 모델로 부터 import할 때도 작동된다. 상태 경로를 동일한 패턴으로 사용하면 유지관리가 쉬워진다.

후처리(Post Processing)

ShapeChange에서 만들어진 출력은 몇가지 문제가 있다. (새로운 버전에서는 해결되었을 수 있음)

첫번째 문제

생성된 XML의 Abstract 클래스에 ':' 가 붙는다.

이 문제는 문서 편집기에서 'name=":Abstract' 를 'name="Abstract'로 찾기-바꾸기를 하면 쉽게 처리할 수 있다.

두번째 문제

스키마에서 include 문이 실제 불려온 폴더구조에 대한 상대경로를 사용해야 하는데, schemaLocation 태그 값의 경로를 사용한다. import 경로는 schemaLocations.xml 파일로부터 올바르게 구성되지만, include 경로는 그렇지 않다. 이들 오류는 수작업으로 모든 스키마를 조사하여 해당 경로부분을 제거해야 한다.

위의 예에서 include 문은 다음과 같이 수정해야 한다.

<include schemaLocation="catalogues.xsd">

===

원문 : https://github.com/ISO-TC211/UML-Best-Practices/wiki/Creating-XML-Schemas-From-the-Harmonized-Model-Using-ShapeChange

Posted by 푸른하늘 푸른하늘이

댓글을 달아 주세요

공간정보/표준2018. 6. 17. 23:12

며칠 전 Enterprise Architect를 사용하여 공간정보 표준 클래스다이어그램을 그리는 방법에 대한 글을 작성했습니다. Enterprise Architect(EA)는 ISO TC211에 참여하는 분들이 사용하는 도구이기 때문에 공간정보 표준과 관련된 일을 하는 분들에겐 무척 편리한 도구라고 말씀드렸습니다. 사용법 자체도 다른 도구와 별반 다르지 않게 직관적으로 사용할 수 있어 좋은 것 같았고요.

제가 그 글을 쓸 때 참고한 글은 Inspire Repository Tutorial 이라는 글로서, INSPIRE 표준에 참여한 분들을 위한 입문서입니다. 그런데, 사실 그 글을 작성하면서 몇가지 어려운 점을 겪었습니다. 먼저 제가 사용한 버전은 13.0 버전인데, 이 입문서에서 사용한 버전은 이전 버전으로서 UI가 너무 많이 바뀌는 바람에 명령을 일일이 찾아야 했다는 겁니다. 그래도 최신판이 낫겠거니 하고 계속 사용하려고 했는데, 다른 글을 참고해보니, 12버전을 사용해서 테스트했고 이후 버전엔 테스트하지 않았다는 내용이 있어.. 결국 다시 12버전을 설치했고, 앞으로도 계속 이 버전을 사용하기로 했습니다.

또 한가지... 더 중요한 사항은 제가 Subversion(SVN) 아이디/비밀번호가 없어서 ISO TC211 표준에 대한 저장소(https://inspire-twg.jrc.it/svn/iso/)를 SVN으로 다운드로 받을 수 없었고, 그래서 그중 implementation-XML 부분만 일일이 수작업으로 복사해서 넣었다고 말씀드렸는데, 이게 완전히 잘못되었다는 것입니다. 아이디/비밀번호가 없어도 다운로드 받는 방법이 있었고, 특히 implementation-XML 부분은 현재 작업중인(체크아웃-체크인하기 위한 임시) 디렉토리여서 이걸 사용하면 안된다는 것이었습니다. 

아무튼... 그래서 ISO TC211의 표준 저장소에서 자신의 PC로 ISO 표준에서 사용중인 모든 클래스다이어그램 등을 불러오는 작업을 수행해 보겠습니다. 

참고로 이 글은 조화 모델 저장소 접근방법이라는 글을 그대로 따라한 것입니다. 여기에서 조화 모델(Harmonized Model)이라는 뜻을 정확히는 잘 모르겠지만요.

ISO 표준 패키지 가져오기

소프트웨어 설치

먼저 두가지 소프트웨어를 설치해야 합니다.

첫번째는 Enterprise Architect. 최신버전보다는 12.1 버전을 사용하세요.

두번째는 SVN 클리언트 프로그램. 여기 들어가면 여러가지가 있는데, 원문에서 Tortoise SVN을 사용해서 저도 여기에서 다운로드 받아 설치했습니다. http://tortoisesvn.net/downloads.html

SVN 으로 파일 받기

그 다음, 자신의 컴퓨터에 작업 공간을 만들어야 합니다. 아무곳이나 만들어도 되지만 한글 디렉토리는 피하는 게 좋습니다. 저는 시키는대로 "C:\Standards/ISOTC211"에 설치를 했습니다. 설치할 위치를 정하면 그곳에 iso라는 이름의 폴더를 추가합니다. 이 폴더가 root 폴더가 되어 저장소에 있는 파일들과 폴더들이 여기로 복사됩니다. 

다음 저장소에 있는 파일을 체크아웃합니다. 아래 그림과 같이 "iso"  폴더를 우클릭하고 "SVN Checkout..."을 선택합니다.

대화상자에서 UML에 아래와 같이 https://inspire-twg.jrc.it/svn/iso/을 입력하고 OK를 누릅니다.

이렇게 실행하면 아래와 같이 경고메시지가 발생합니다. 인증서가 잘못되었다는 뜻이라는데, 원래 이렇게 발생한다고 하더군요. Accept를 누르면 실행됩니다.

이제 Tortoise SVN이 isotc211 모델의 저장소에 대한 복사본을 현재 폴더에 설치합니다. 설치가 완료되면 다음과 같은 대화창이 뜹니다.

폴더 구조는 다음과 같습니다.

Enterprise Architect 환경설정

먼저 EA를 실행하고 기존의 프로젝트를 열거나 새로운 프로젝트를 생성합니다. 

다음으로 아래 화면과 같이 버전 콘트롤 설정을 합니다. 

Project -> Version Control -> Version Control Setting

대화창에는 다음과 같이 입력합니다.

- Unique ID : ISOTC211
- Type : Subversion
- Working Copy Path : 위에서 만든 iso 폴더의 경로 (예: C:\Standards\ISOTC211\iso)
- Subversion Exe : Tortoise SVN이 설치된 위치. (예: C:\Program files\TortoiseSVN\bin\svn.exe)

이제 Save를 누르고 잠시 기다리면 아래 화살표처럼 정의되었다는 내용이 뜹니다. 이제 Close를 누릅니다.

 패키지 가져오기

Project Browser 에서 Model을 우클릭한 후, Package Control -> Get Package를 선택합니다. 그러면 아래와 같은 대화상자가 뜨는데, 아래와 같이 Select a Version... 에서 "ISOTC211"을 선택하면 자동으로 목록을 가져옵니다. 이제 "isotc211\ISO_TC211.xml 을 선택하고 OK를 눌러줍니다.

최신버전 가져오기

잠시 기다리면 Project Browser에 아래와 같이 목록이 나타납니다. 현재는 모두 빈 목록뿐입니다.

여기에서 또다시 Model을 우클릭하고 Package Control -> Get All Latest를 눌러줍니다. 다음 대화창에서는 "Import changed file only" 옵션을 선택합니다. 그러면 모든 패키지가 새로 갱신됩니다. (이 경우엔 모두 새로 채워줍니다. 언제든지 최신 버전이 필요하면 이 명령을 수행하면 됩니다.) 모든 패키지가 들어오기까지는 상당한 시간이 소요됩니다.

이제 완료되었습니다. 모든 패키지가 Locked 되어 있어 편집은 안되지만, 살펴볼 수는 있습니다. 이 상태는 EA <-> Client (나의 PC) <-> Server <-> 저장소(Repository) 간의 연결이 끝난 상태입니다. 즉 필요할 때마다 Get All Latest를 눌러주면 상태를 체크하여 최신 패키지로 모두 갱신됩니다.

저는 ISO 패키지를 사용만 하는 입장이라, 이걸로 충분합니다만, 이들을 편집하고 싶다면 여기를 읽어보세요.

참고로 원래 EA에서 사용하는 파일 포맷은 MS Access 라고 합니다. 당연히 이진파일입니다. 그런데 SVN(을 비롯한 모든 종류의 버전관리 도구)은 이진파일의 버전관리는 불가능합니다. 그래서 EA에서는 자신의 파일을 XMI(UML 교환용 포맷으로 XML 형식)으로 내보내고, 이것을 내 로컬 저장소에 저장을 합니다. 그리고 이 로컬 저장소를 서버와 통신해서 버전관리를 하는 방식입니다. 상당히 영리한 방식이라고 할 수 있습니다. 

그런데, EA에서 사용하는 XMI 파일은 클래스등의 객체 구조 뿐만아니라, 색깔, 다이어그램 상의 위치 등 다양한 정보를 보관한다고 합니다. 따라서 EA가 아닌 UML 도구는 EA의 XMI 파일을 정상적으로 다룰 수 없고, 따라서 다른 UML 도구는 소스 버전관리가 불가능합니다. 이런 점에서도 공간정보 표준과 관련된 작업을 하려면 어쩔 수 없이 Enterprise Architect를 사용할 수 밖에 없을 것 같네요.

No-SVN 환경의 ISO TC211 패키지 가져오기

사실 표준 제정/개정 등의 작업에 참여하지 않는 저같은 사람들은 위와 같이 모든 저장소의 내용을 다운로드 받고, 또 최신판으로 유지할 필요는 없습니다. 그냥 안정된 버전을 다운로드 받아 사용하는 것이 가장 편합니다. 여기에 들어가서 ISOTC211_HM_NoSVN.eap를 받아서 사용하면 됩니다.

아래는 이 파일을 받아서 그냥 EA에서 불러들인 후, GFM(일반 지형지물모델 : General Feature Model) 클래스 다이어그램을 표시한 화면입니다. 좌측위 "Project Browser"를 보시면 ISO TC/211 표준 뿐만 아니라, OGC 표준 그리고 ISO TC211 표준에서 참조하는 기존 표준(예: ISO 3166 국가코드)들도 포함되어 있음을 알수 있습니다. 아주 편리할 것 같습니다. ㅎㅎㅎ

ISO 19000 시리즈 클래스 관계 확인하기

제가 제일 많이 사용하는 기능은 ISO 19000 표준시리즈에 포함된 여러가지 클래스간의 관계를 확인하는 것입니다. 제가 요즘 여기저기 표준관련 문서를 뒤적거릴 일이 많다보니, 어떤 클래스가 어떤 속성이 있고, 다른 클래스와 어떤 관계가 있는지 등을 알아봐야 할 때가 많기 때문입니다.

일단 위와 같은 방법으로 ISOTC211_HM_NoSVN.eap를 불러왔다고 가정하고 시작하겠습니다.

제일먼저 어떤 클래스가 있는지 확인하고 싶을 때에는 Cntl_F (Find in Project) 창을 불러서 아래의 위치에 원하는 클래스명을 입력하면 됩니다. 아래는 DateTime 클래스를 검색한 예인데, 아래와 같이 나타난 여러개의 클래스 중에서 적당한 것을 선택하시면 됩니다. 클래스 중에서 Status가 Supersede라고 되어 있는 경우가 있는데, 이 녀석은 과거 버전이므로 사용해서는 안됩니다. Implemented도... 정확히 무슨 내용인지 아직 모르지만, 어쨌든 Status가 Approved 인 것을 선택하면 됩니다.

선택한 상태로 오른쪽 마우스 클릭을 하면 위와 같이 여러가지 옵션이 나타납니다. 여기에서 Properties... 를 누르면 아래와 같이 이 클래스의 특성을 볼 수 있습니다. 왼쪽 화살표를 누르면 연관관계를 확인할 수 있고요, 오른쪽 아래의 "Details"를 누르고 다시 "Attribute"를 누르면 속성을 확인할 수 있습니다.

또 위의 그림에서 "Find in Diagrams..."를 누르면 아래와 같은 창이 나오고  아무 다이어그램이던 더블클릭하면 이 클래스가 포함된 다이어그램을 확인할 수 있습니다. 원래 이 저장소(ISOTC211_HM_NoSVN.eap)는 ISO TC/211 위원들이 실제 표준 문서 작업을 할 때 사용하던 것과 동일한 복사본이기 때문에, 표준문서에 포함되어 있는 그림들을 포함해 다양한 다이어그램을 확인할 수 있습니다.

그런데 이런 식으로 확인하는 것만으로는 한계가 있을 수 있습니다. 예를 들어 필요에 따라 연관관계에 있는 다른 클래스들을 확인하고 싶지만, 다이어그램에는 숨겨두었을 수 있기 때문입니다. 

이 때에는 다이어그램에서 해당 클래스를 우 클릭한 뒤, 콘텍스트 메뉴에서 "Insert Related Elements"를 선택하면, 아래와 같이 연관관계나 상속관계에 있는 클래스들을 볼 수 있고, 이들을 클릭하면 해당 클래스들이 다이어그램에 추가됩니다. 이때 화살표 쪽을 선택하면 Relation depth를 조절할 수 있습니다.

이상입니다.

민, 푸른하늘

===

원문 : https://github.com/ISO-TC211/HMMG/wiki/Connecting-to-the-Harmonized-Model-Repository

Posted by 푸른하늘 푸른하늘이

댓글을 달아 주세요

공간정보/표준2018. 6. 12. 13:45

얼마전 Modelio 3.7 을 사용해서 공간정보표준 클래스 다이어그램을 작성하는 방법을 올렸습니다. 이번에는 Enterprise Architect를 사용해서 작성하는 방법을 말씀드리려고 합니다.

Enterprise Architect은 상용 UML Tool입니다. 제일 저렴한 개인용 버전도 $229입니다. 그럼에도 이 도구를 사용하려고 생각한 것은 이 도구가 ISO/TC 211에서 추천하는 (그리고 사용중인?) 도구라는 걸 알게 되었기 때문입니다. 유럽연합의 공간정보기반인 INSPIRE에서도 이 도구를 사용하고 있고요.

게다가 조금 뒤져보니 GML을 지원해주고 있다고 하니, (제가 아직 GML을 잘 모르지만) 아주 유용할 것 같다는 생각이 들었습니다. 우리나라에는 ArcGIS 를 사용하는 기관이 많은데, ArcGIS 모델도 지원한다고 합니다. 

또 한가지 이유는 Modelio 3.7에서는 문서화 도구가 없는데 비하여(제가 못찾은 걸 수도 있습니다.), Enterprise Architect(앞으로는 EA로 쓰겠습니다.)는 문서화 도구가 아주 좋은 듯합니다. 원래 ISO 표준에서는 응용스키마에 대한 문서를 UML 도구에서 지원하는 문서화 도구를 쓸 것을 강력하게 권고하고 있어서, 문서화도구의 편리성은 매우 중요합니다.

어쨌든... 어찌어찌... Enterprise Architect 13 버전을 구해서 테스트해 보기로 했습니다. 이 글은 Modelio와 비교하기 쉽도록 가능한 한 체계를 동일하게 유지하도록 노력했으니 참고하세요.

*******
참고 : 이 글은 Enterprise Architect 13.0 버전을 사용하여 작성했습니다. 하지만, ISO TC 211에서는 12.1 버전을 사용하고 있습니다. 따라서 12.1 버전을 설치하여 테스트하실 것을 적극 추천합니다. 또한 이 글의 "ISO 19100 기본패키지 Import" 부분은 제가 잘못 이해한 내용이 담겨 있으니 이 글을 참고하시기 바랍니다.
*******

1. Project 생성

EA를 처음 사용하려면 먼저 프로젝트를 생성해야 합니다. 아래와 같이 EA 화면 맨 오른쪽 위를 누르고 New Project를 클릭한 뒤, 폴더와 프로젝트명을 입력하면 됩니다.

그 다음엔 "Model Wizard"라는 게 나오는데, (저도 잘 모르니까) 아무것도 선택하지 않고 [확인] 버튼만 눌러줍니다.

다음으로 View를 만들어 줍니다. 아직까지 View의 역할은 잘 모르겠지만... 아래와 같이 Project  Browser 창에서 'Model -> Add -> Add View"를 선택하면 됩니다.

2. 패키지 만들기

패키지는 서로 관련이 깊은 클래스들의 모임입니다. 하나의 프로젝트에는 여러개의 패키지가 들어 있고, 서로 관계가 있을 수 있습니다. 아래는 JPGIS2014의 Geometry/Topology 패키지에 포함된 하위패키지들의 상호관계를 나타낸 것입니다. 이처럼 패키지로 구성된 프로젝트라면 패키지를 만들고 시작하는 것이 좋습니다. (물론 클래스부터 만들고 나중에 패키지로 만들어 정리해도 됩니다.)

참고로, 아래 그림은 EA의 기능을 이용해서 만든 그림입니다. Publish -> Save Image -> Save to File로 저장한 건데, 좀 흐릿해서 배율좀 올리려했더니 잘 안되네요. 

아래는 Start->View-Preference->Diagram->Gradient and Background에서 배경을 완전히 없앤 뒤 화면을 캡쳐한 것입니다. 저는 이게 더 깔끔하니 좋네요.

패키지를 만들 때는 만들어둔 View를 우클릭한 뒤, Add Package... 를 클릭하면 됩니다.  (여기서도 Model Wizard에서는 아무것도 선택하지 않았습니다.

2-1. ISO 19100 기본패키지 Import

제가 Modelio를 사용할 때 답답했던 점 중의 하나는, ISO 19100 표준 시리즈에 원래 포함되어 있던 많은 클래스나 패키지 정의를 새로 만들어야 했던 것입니다. 분명 누군가는 19100 표준에 포함된 정의를 이미 만들어 두었을 텐데, 어디에서 그걸 찾을 수 있을지 막막하여 결국 제가 필요한대로 새로 만들어 사용했었습니다.

그런데, EA로 작업하다보니 그럴 필요가 없었습니다. 이미 만들어진 19100 시리즈의 클래스 다이어그램 등을 모두 구할 수 있었기 때문입니다. 

여기에 들어가 보시면 아래의 화면과 같이 나타납니다. 원래 이곳은 유럽연합의 공간정보기반인 INSPIRE에서 관리하는 사이트로서, 원래는 SVN (subversion)이라는 소스관리 도구로 관리되고 있는 ISO 19100 시리즈 표준의 기본 패키지입니다. 

기본 패키지라고 써둔 이유는, 응용스키마를 작성할 때 참조해야 하는 패키지가 모두 포함되어 있기 때문입니다. 다른 표준들에서도 이 표준을 참조하고 있으며, 사용자들이 공간정보 응용스키마를 작성할 때에도 여기에 포함된 ISO TC-211 패키지만 참조해서 사용하면 됩니다.

참고로, 이 상위 폴더를 찾아보면, 다른 표준에 들어 있는 클래스 다이어그램들도 모두 볼 수 있습니다. 계속해서 작업이 이루어지고 있어 예전 버전과 최신 버전을 모두 찾아볼 수 있습니다. (이 저장소는 ISO 표준 관계자들의 공식 저장소 중 하나라고 어디에선가 읽었습니다.)

원래는 SVN으로 관리되므로, 이들 내용을 받을 때도 SVN을 사용해야 하지만, 저는 id/pw를 받지 못해서 그냥 이곳에서 모두 일일히 다운로드 받았습니다. 아래는 그중 일부입니다. 이중 파일 크기가 큰 것 두개부터 import한 뒤, 파일 크기가 작은 것을 import하면 구조가 자동으로 정리가 됩니다. 패키지 또는 뷰에서 우클릭하고 import/export->import package from XMI files... 명령을 사용하면 읽어들일 수 있습니다. 

아래가 제가 모두 읽어들인 결과입니다.

아래는 이렇게 정리한 파일을 모두 한꺼번에 Export 한 것입니다. ISO 공간정보 표준과 관련하여 클래스다이어그램이 필요하시면, 이 파일만 읽어들여서 사용하시면 됩니다.

invalid-file

3. 클래스 다이어그램 만들기

이제 본격적으로 클래스 다이어그램을 만들어볼 차례입니다. 아래 그림과 같이 원하는 패키지에서 우클릭한 뒤, Add diagram을 선택하면 됩니다. 만들어진 다이어그램은 나중에 편한대로 다른 위치로 옮길 수 있지만, 설명하고자 하는 패키지 내부에 만드는 게 가장 좋습니다.

그 다음 나오는 대회상자에서 UML Structural -> Class 를 선택하고 적당한 이름을 준 뒤 확인버튼을 누르면 해당 패키지 속에 클래스 다이어그램이 추가됩니다. 참고로 아래 대화상자에서 보시는 것처럼, 아주 다양한 종류의 다이어그램을 생성할 수 있습니다. ArcGIS도 보이고... 아래쪽으로 더 내려가면 GML도 보이더군요. (그런데 아직까진 GML 다이어그램이 뭘까... 싶네요)

4. 클래스 생성하기

다이어그램 상태에서 클래스를 만들 때에는 아래 그림과 같이 Toolbox에서 Class->Class를 선택한 뒤, 다이어그램내 적당한 위치에서 클릭해주면 됩니다.(드래그&드롭은 안됩니다.) 이때 클래스 명은 "Class1, Class2" 등으로 만들어지는데, 여길 선택해서 적절한 이름을 넣어주면 됩니다.

이렇게 그래픽으로 추가하지 않고(그림은 만들지 않고), 정의만 생성할 수도 있습니다. 적당한 대상(Package 등)에서 Add element를 선택하면, 아래와 같은 대화상자가 나타나는데, 여기에서 클래스를 직접 추가할 수 있습니다. 

이렇게 클래스 정의만 있는 상태에서 클래스다이어그램에 추가하려면 그냥 Drag&Drop을 하시면 됩니다. 그러면 아래와 같은 대화상자가 나타나는데, Link를 선택하면 됩니다.

참고로 클래스 다이어그램에서 클래스나 link를 선택한 상태에서 Del 키를 누르면, Diagram에서 삭제가 되지만 정의 자체는 패키지에 삭제되지 않은 채 남아 있습니다.

5. 속성(Attribute) 추가하기

EA에서 속성을 추가하려면, 아래 그림과 같이 Project Brower에서 원하는 클래스에 우클릭하고 Attribute... 를 클릭하면 됩니다.

그러면 아래와 같은 대화상자가 나타납니다. 여기에서 속성의 name, 유형, 초기값, 다중도(Multiplicity) 등 원하는 값들을 선택하면됩니다. 그런데, 공간정보 응용스키마를 생성하려면 속성의 유형은 UML의 기본 속성유형(int, boolean, byte 등)이 아니라, ISO 19103 개념스키마의 기본 유형(Integer, Boolean, CharacterString 등) 이나, 다른 표준 패키지에서 정의된 유형을 지정해야 합니다.

이를 위해서는 아래 그림과 같이 유형에서 맨 아래에 있는 "Select Type..."을 선택하고

아래와 같은 대화상자에서 해당 유형을 직접 선택하거나, 빨간 화살표를 쳐둔 "Search"를 눌러 검색해서 입력하면 됩니다.

아래는 이렇게 속성을 추가한 뒤의 클래스의 모습입니다. 아주 깔끔하게 (Modelio 와는 달리 초기값도) 잘 나오네요.

6. 연관관계 생성하기

연관관계는 주로 다이어그램에서 생성합니다. 아래 그림과 같이 좌측 Toolbox에서 원하는 관계를 선택한 후, Source 클래스를 먼저 클릭하고 Target 클래스를 선택해 주면 됩니다. Source 클래스를 클릭하면 우측 빨간화살표와 같이 화살표가 나타나는데, 이것을 클릭하고 Target 클래스를 지정해줘도 됩니다.

연관관계에는 적절한 role을 부여해야 합니다. 연관관계 선을 더블클릭하면 다음과 같은 대화상자가 나오는데, 여기에서 Role(s)를 선택하고 적절한 role 이름, 다중도, 탐색가능(Navigability) 등을 지정해줍니다.

그러면 아래와 같이 associationrole 이 예쁘게 나타납니다.

7. 스테레오타입 추가하기

공간정보표준중 KS X ISO 19103 개념 스키마 언어 6.10.2에는 여러가지 스테레오타입이 나옵니다. 패키지에 대한 스테레오타입으로는 <ApplicationSchema><leaf>이 정의되어 있고, 클래스에 대한 스테레오타입으로는 <CodeList> <DataType> <FeatureType> <Union> <Type>등의 스테레오타입이 정의되어 있습니다. 물론 이 외에도 새로운 것을 정의하여 사용할 수 있다고 규정되어 있습니다.

스테레오타입은 여러가지로 사용될 수 있는데, 공간정보표준에서 사용되고 있는 스테레오타입은 의미의 확장, 혹은 의미의 명확화라고 생각할 수 있습니다. 즉, 모두다 클래스이지만, <FeatureType>라는 스테레오타입을 사용한다면, 이 클래스는 지형지물임을 명확히 알 수 있게 됩니다.

Modelio의 경우, 모든 스테레오타입을 새로 정의해서 사용해야 했지만, EA에서는 기존 정의되어 있는 것을 그대로 사용할 수 있습니다. EA에 GML 을 지원해주고 있다고 했는데, 여기에서 조금 도움이 되네요.

클래스에 대하여 스테레오타입을 지정하는 예를 살펴보겠습니다. 먼저 다이어그램이나 Project Browser에서 원하는 클래스를 더블클릭하면 아래와 같은 대화상자가 나타납니다. 여기에서 맨오른 쪽위에 있는 Strerotype을 클릭하고 새로나오는 대화상자에서 Profile을 열고 GML을 선택합니다.

그러면 아래와 같이 GML에서 사용할 수 있는 스테레오타입이 모두 나타납니다. 여기에 있는 스테레오타입은 ISO TC-211 표준의 스테레오타입과 일치하니까 이걸 사용하면 됩니다. 

참고로 패키지에 대해 스테레오 타입을 지정하면 아래와 같이 나타납니다.

아래는 이상과 같은 과정을 통해 작성한 테스트용 클래스 다이어그램입니다. 깔끔하니 잘 만들어지네요.

8. 문서화(Documentation)

일단 여기까지 순조롭게 진행되니, 문서화 기능도 테스트해보고 싶어졌습니다. Publish->Document->Generate Documentation을 누르면 아래와 같은 화면이 뜹니다. 여기에서 파일명과 출력포맷(.rft와 .pdf 등)을 지정하고, 오른쪽에 있는 Generate를 누르면 문서가 생성됩니다.

아래가 이렇게 만들어진 문서입니다. 오른쪽 위에 날짜가 약간 깨진 것 빼놓고는 괜찮네요. rtf 포맷을 만들면 Word 같은 도구로 편집할 수 있고, 템플릿을 지정하는 기능도 있으니, 적당하게 편집하면 예쁜 문서를 만들 수 있을 것 같네요.

===

이상입니다. EA를 처음 써보는 중이라 아직도 모르는 것 투성이지만, 아주 편하게 잘 사용할 수 있을 것 같네요. 

민, 푸른하늘


Posted by 푸른하늘 푸른하늘이

댓글을 달아 주세요

공간정보/표준2018. 6. 5. 01:02

이 글은 KS X ISO 19109 응용스키마 규칙을 정리한 글입니다. 이 표준에 따라 응용스키마를 제작하려면 무엇을 해야 하는지, 뭘 유의해야 하는지 등에 대하여 썼지만, 완전한 해설서라기 보다는 제가 아는 만큼만 정리하고, 제 생각에 따라 적은 글이라는 것을 밝힙니다. 개인적인 주장도 담겨 있으니, 참고만 하시길 바랍니다. 

혹시 다른 의견이 있으시다면 이글에 댓글이나 이메일이나 페이스북을 통해 알려주시면 감사하겠습니다.

원문 : ISO Standard 19109:2015 Geographic information — Rules for application schema
        KS X ISO 19109 지리정보 - 응용스키마 규칙

응용스키마 예제

일단 먼저 원문(부속서 C.1)에 포함되어 있는 응용스키마를 살펴보겠습니다. 거꾸로 시작하는 것도 재미있거든요.

이 그림은 가상의 고압송전망입니다. 여기에서 A와 B는 중앙변전소, C는 송전타워입니다. 실선은 고압송전선, 점선은 중앙변전소 경계를 나타냅니다.

응용스키마

이들에 대한 응용스키마는 응용의 목적/제작자/주변환경 등에 따라 달라집니다. 사실은 백인 백색이라고 할 수 있습니다. 비슷해 보여도 디테일은 모두 다를 수 있으니까요. 어쨌든... 이 표준에서는 아래와 같이 응용스키마를 구성했습니다.

먼저, 변전소는 두가지(중앙변전소, 송전타워)가 성격이 비슷하므로, 먼저 Substation을 정의하고, MainSubstation과 TowerSubstation이 이를 상속받도록 정의했습니다. 

MainSubstation(중앙변전소)의 속성은 (상속받은 속성을 포함해서) 이름, 주소, 공간 속성 두 가지 등 총 4가지 속성이 있습니다. 공간속성중 하나는 topology의 일부가 되는 topologyRelatedBy(TP_Node 유형), 그리고 중앙변전소의 경계를 나타내는 geometricallyDescribedBy(GM_Surface 유형) 입니다.

TowerSubstration(송전타워)도 4개의 속성이 있는데, 공간속성은 GM_Point 유형 과 TP_Node 유형의 두가지입니다.

TransmissionLine(송전선)은 공간 속성(geometricallyDescribedBy)이 GM_Curve 유형이고, 위상속성은 TP_Edge 유형입니다. 

마지막으로 UtilityNetwork은 전력망 전체를 나타내는 위상체계입니다. 속성은 topology 하나가 있습니다. topology는 데이터유형이 TP_Complex입니다. 위상복합체라고 하는데, 이 데이터를 뒤져보면 이 송전망의 모든 위상구조가 담겨있습니다. 그 속엔 변전소(TP_Node)와 송전선(TP_Edge)가 서로 연결되어 있을 것입니다.

이러한 그림을 UML 클래스다이어그램이라고 합니다. 응용스키마는 UML 클래스 다이어그램으로 생성해야 합니다. 

참고로... 저라면 다르게 구성할 겁니다. 제 생각은 이 글 맨 아래를 확인하시면 됩니다.

패키지 다이어그램

이와 같이 응용스키마를 만들 때, 패키지 다이어그램도 함께 작성해야 합니다. 아래가 이 응용스키마의 패키지 다이어그램입니다. 작성한 응용스키마(스테레오타입 «ApplicationSchema»라고 붙어있음)가  ISO 19107 공간 스키마 패키지를 사용하고 있다는 뜻입니다. 그리고 중간에 메모로 표시한 것은 공간스키마 중에서 사용하는 유형이 어떤 것인지를 나타내는 것입니다. (이것은 반드시 적어야 할 필요는 없습니다.)

이러한 의존관계는 UML 도구를 사용하여 작성하고, ISO 표준에 포함되어 있는 표준 스키마 패키지들을 적절히 가져올 경우 자동적으로 생성됩니다.

지형지물의 문서화

응용스키마는 클래스다이어그램 뿐만 아니라, 이 다이어그램에 표현된 지형지물 및 속성에 대한 자세한 내용이 필요합니다. 그림에는 안보이지만 UML을 작성할 때 기록해 둔 자세한 내용 및 추가적인 정보를 문서화해야 하기 때문입니다.

다음은 송전선에 대한 상세한 내용입니다. 지형지물 유형 그 자체와, 세가지 속성에 대해 자세한 내용을 볼 수 있습니다. 물론, 다른 지형지물에 대해서도 이러한 문서를 작성해야 합니다. 

이와 같은 UML 클래스다이어그램은 원래 UML 툴을 사용하여 작성하게 되어 있습니다. 시스템을 개발하는 분들은 UML 툴을 많이 활용하고 잘 알겠지만, UML 툴에는 클래스 다이어그램에 대한 상세한 내용을 문서로 뽑아내는 기능이 있습니다. 19109에서는 이러한 기능을 이용해 문서화해야 한다고 규정하고 있습니다. 

물론 UML을 일반 그림도구나 PowerPoint 등으로 그릴 수도 있습니다. 그 경우엔 문서화를 따로 할 수 없어 수작업으로 만들어야죠. 하지만, 이렇게 되면 UML과 지형지물 요소의 문서가 일치하지 않을 가능성이 높습니다. 따라서 반드시 UML 도구를 사용해야 한다고 생각하면 맞습니다.

제가 얼마전 올린 Modellio 3.7 도 이런 도구중 하나입니다. 그리고 ISO TC/211에서는 "Enterpise Architect"라는 도구를 추천한다고 하더군요. 하여튼 어떤 것도 좋지만, 응용스키마는 반드시 UML 도구를 사용해서 작성해야 합니다. 

저는 이번 글은 UML 도구를 사용하지 않고 그림을 복사해서 붙여뒀습니다만, 다음에는 도구를 사용해서 문서화하는 기능을 테스트해볼 계획입니다.

응용스키마 작성목적

이 표준의 6.1에는 응용스키마의 목적을 두가지로 밝히고 있습니다.

- 컴퓨터가 읽을 수 있는 표현으로 데이터 구조를 정의함으로써, 자동으로 데이터를 관리할 수 있게함.
- 특정 응용의 데이터 내용을 문서화함으로써, 관계자들이 모두 데이터를 정확하게 이해할 수 있음.

그런데, 제 생각으로는 위에서 작성한 응용스키마 및 문서 만으로는 첫번째 목적을 달성하기는 힘들 것 같습니다. UML 도구를 사용하여 응용스키마를 작성할 경우, 산출물은 클래스다이어그램//데이터 문서(데이터 사전 등)으로 사람들이 데이터를 이해하는 데는 반드시 필요합니다. 하지만, 자동으로 데이터를 관리하기 위해서는 이 응용스키마와 데이터를 직접 비교하고 검증해야 하는데, 이러한 몇가지 문서만으로는 불가능하다고 보이기 때문입니다. (참고로 제가 공간정보 표준과 유통에 대하여 쓴 것처럼, 응용스키마를 XSD로 인코딩하고, 데이터를 XML로 인코딩하면 이러한 검증은 가능합니다)

6.2에는 응용스키마는 제공자와 사용자간의 데이터 전송 및 교환에 매우 중요함을 밝히고 있습니다. 

즉, 이 표준을 사용하면 데이터 교환을 위한 (공통) 전송 응용 스키마 구축할 수 있는데, 구축된 응용스키마를 사용하면 전송된 데이터세트의 의미를 해석할 수 있고, 데이터간 어떠한 변환이 필요한지를 결정할 수 있다고 말하고 있습니다. 한편, 이 표준에 있는 규직을 사용하여, 시스템 내부용 응용 스키마 구축을 위해서도 적용할 수 있기는 하지만, 이러한 응용 스키마는 이 표준의 범위에 속하지 않는다고 밝히고 있습니다.

결국, 응용스키마를 제작하는 가장 중요한 목적은 데이터의 교환이고, 데이터 교환시 데이터의 내용 및 구조를 정확하게 정의하고, 서로 이해하기 위한 목적이라고 요약할 수 있습니다.

응용스키마 작성시 주의사항

응용스키마는 위의 예제와 같이 만들면 됩니다. 복잡하면 크기가 커질 뿐, 이와 같은 형식만으로만 만들 수 있다면 크게 문제는 없습니다. 하지만, 응용스키마를 이렇게 만들기 위해서는 몇가지 지켜야 할 것들이 있습니다.

사실 이 KS X ISO 19109 응용스키마 규칙은, 이와 같은 응용스키마를 작성하기 위한 규칙을 세세하게 정한 것입니다.

공간정보 UML 프로파일

위에 있는 클래스 다이어그램에는 다섯가지 지형지물 클래스가 있습니다. 이 다섯가지 클래스는 모두 스테레오타입이 «FeatureType»으로 되어 있습니다. 이 클래스들이 지형지물(피처) 유형이라는 뜻입니다. 스테레오타입은 19103 개념스키마에 정의되어 있습니다. 그리고 CharacterString, Integer와 같은 기본유형도 개념스키마에 정의되어 있구요. 

사실 공간정보표준은 개념스키마언어로서 UML을 권장(필수가 아니래요!!!)하고 있는데, UML을 그대로 사용해서는 안됩니다. 미리 스테레오타입과 기본유형을 정의해 둔 외에도 여러가지 제한들을 모두 지켜야 합니다. 이것을 (공간정보 표준용) UML 프로파일이라고 합니다. 즉, 공간정보 표준에 따라 응용스키마를 구성할 때에는 UML 프로파일을 사용해야 하는 것입니다.

공간정보표준에서 사용하는 UML 프로파일의 대략적인 내용은 다음과 같습니다. (자세한 내용은 19109 에 포함되어 있습니다.)

- 텍스트, 이름, 숫자, 날짜시간 등에 대한 원시유형(primitive type)/공통구현 유형/파생유형은
  ISO19103에 정의된 것만 사용한다.

- UML 연관의 경우, 반드시 다중도를 명시할것/탐색가능한 연관 끝에는 명시적인 이름이 있을 것

- 역할 이름이 주어진 연관은 클래스의 속성으로 처리할 것

- (권장) 속성, 연산, 연관 역할 이름이 패키지 내에서 유일할 것

- 사용할 수 있는 스테레오타입: Application Schema, CodeList, dataType, enumeration, FeatureType, Leaf, Union, use 등.

- 스테레오타입 이름은 UpperCamelCase로, 표준 UML 키워드는 lowerCamelCase를 사용할 것

이렇게 (공간정보용) UML 프로파일을 정의해 둔 이유는, 응용스키마를 누가 작성하던 동일한 결과가 나오도록 하기 위함입니다. 그냥 UML로 작성한다는 규정만 있다면, 동일한 내용을 작성한다고 해도 사용자마다 차이가 생길 수 있기 때문에, 이를 방지하는 목적이죠.

GFM(일반 지형지물 모델)

공간정보 응용스키마에서 가장 중요한 것은 지형지물(Feature)입니다. 지형지물은 공간상의 위치가 있는 것 뿐 아니라, 없는 것들도 모델링 할 수 있고, 해야 합니다. 지형지물은 기본적으로 UML 클래스입니다. 그냥 일반 클래스가 아니라, 형식이 엄격히 정해져 있는 클래스죠. 이러한 지형지물을 정의하기 위한 개념을 일반지형지물 모델이라고 합니다. (이를 응용 스키마의 메타모델(MetaModel)이라고 합니다.)

아래가 ISO I9109:2015에 정의되어 있는 일반 지형지물 모델입니다.

여기에서 FeatureType이라는 메타클래스에 대해서 좀 더 살펴보겠습니다. 일단 FeatureType은 IdentifiedType에서 상속을 받았고, 그래서 FeatureType의 속성에는 isAbstract(추상 지형지물인가 아닌가) 외에도, name(지형지물 유형 이름), definition(정의), description(설명), designation(지정... ), 그리고 constraintedBy 등이 들어있습니다. 여기에서 name과 definition은 필수입니다. 

아래쪽 다이아몬드는 Feature가 여러 Property(Attribute, Operation, FeatureAssociationRole)를 가질 수 있다는 의미입니다. PropertyType쪽에 carrierOfCharacteristecs라고 연관역할이 있는데, 이는 이 Property들의 집합에 대한 링크입니다.

오른쪽에 있는 자기 자신을 향한 화살표는 상속(일반화/특수화) 관계를 가질 수 있다는 의미고요.

일반 지형지물 모델(GFM)은 일반적인 사용자, 즉 응용스키마를 작성하는 사람은 구지 잘 몰라도 관계는 없습니다. 머... 대부분 비슷한 응용스키마를 참고해서 수정해서 쓰는 저같은 사람은 특히나 필요없죠. 하지만, 여기에 있는 내용은 반드시 지켜야 합니다. 예를 들어, 지형지물에 대한 설명을 할 때에는 반드시 description이라는 속성을 사용해야 하고, desc 같은 걸로 임의로 바꾸면 안된다는 뜻입니다.

지형지물 정의

지형지물(Feature)를 정의할 때 지켜야할 사항은 /req/general/feature (7.4.5 FeatureType)에 정의되어 있습니다.

첫번째, 지형지물은 메타클래스 FeatureType의 인스턴스로 모델링되어야 한다.
두번째, 지형지물은 GM_Object 또는 TM_Object의 하위 유형으로  모델링되어서는 안 된다.
세번째, 지형지물 이름은 응용 스키마 내에서 유일해야 한다.

첫번째와 세번째는 위에서도 언급했으니 생략하고, 두번째에 대해서만 생각해보겠습니다. 대부분 GIS를 처음 배울 때 "도형데이터는 점, 선, 면이 있다"로 부터 시작합니다. 그러다보니, 도형=지형지물로 생각하는 경향이 있는데, 이렇게 사용하면 안된다는 뜻입니다. 예를 들어, 공간스키마(19107)에서 기하원시객체(geometric primitive)는 GM_Point, GM_Curve, GM_Surface 등이 있는데, 이것을 직접 지형지물로 사용하지 말고, «FeatureType»으로 정의한 지형지물의 속성으로 사용하라는 것입니다.

그냥 일반적인 UML 문법으로 봤을 때는 «FeatureType»을 사용하여 정의하든, GM_Point 등을 사용하여 정의하던 아무런 문제가 발생하지 않습니다. 하지만, (공간정보 표준) 응용스키마는 모든 지형지물을 스테레오타입이 «FeatureType»인 클래스로만 정의하라는 것입니다.

지형지물에 대한 UML 생성시 지켜야 할 사항은 /req/uml/feature (8.2.6)에 정의되어 있습니다. FeatureType은 CLASS로서 구현하되 스테레오타입을 «FeatureType»로 해야 한다는 것, CLASS이름은 ApplicationSchema 내에서 유일해야 한다는 것. 그리고 해당 CLASS에 대한 텍스트 정의는 UML 도구의 문서화 도구를 이용하여 기록할 것 등의 내용입니다. UML 프로파일에서 대략적으로 이야기했던 내용을 구체적으로 지정한 것입니다.

기타 정의

이 표준에는 이 외에도 응용스키마를 작성할 때 지켜야 할 규칙이 많습니다. 적합성 클래스 기준으로 12가지가 있고, 강제규정과 권고사항을 합치면 약 70가지 정도됩니다. 

여기를 보시면 제가 이 규칙들을 정리해 놓은 구글 스프레드시트를 보실 수 있습니다. 완벽한 건 아니고, 제가 참고삼아 보려고 만든 것이라, 빠진 내용들도 많습니다. 잘못된 점이 있거나 의견이 있으시면 댓글을 달아주세요. (스프레드시트에 댓글을 달린다고 하는데, 한번도 테스트를 안해봐서 모르지만, 어쨌든요~

응용스키마 규칙에 대한 생각

제가 공간정보표준을 보면서 정말 까다롭다고 생각한 부분이 있습니다. 공간스키마와 시간스키마, 그중에서도 위상에 관한 부분입니다. 제가 생각하기에 "유용한" 위상구조는 2차원 도형에 대한 구조인데, 1차원 3차원까지도 위상구조를 정의한다는 건 너무 복잡하기만 할 뿐이라고 생각했었습니다. 위상구조는 대부분의 경우, 공간 원시 객체(geometric primitive)에 일정한 알고리듬을 적용하면 자동으로 만들어 낼 수 있는데, 이걸 데이터 구조에 억지로 끼워넣는다는 느낌도 들었고요.

그런데 이번에 표준에 대해서 살펴보면서 이런 생각을 좀더 굳히게 되었습니다. 응용스키마가 내부 시스템 구조용이 아니라, 주로 다른 시스템간의 데이터 전송을 위한 목적이라는 것입니다. 원래 위상구조를 만드는 목적은 실시간으로 연결성을 계산하려면 많은 계산이 필요하므로 미리 처리해서 데이터 구조로 만들어 둔 것입니다. 따라서, 운영 시스템에서는 위상 데이터가 매우 중요합니다.

하지만 데이터 전송을 위한 공통 응용스키마 제작이 목적이라면,  되도록이면 간단한 구조로 데이터를 전송하는 게 좋다고 봅니다. 수신측에서는 이 데이터를 각자의 시스템 목적에 따라 재가공해야 하므로,  위상구조와 같은 "알고리듬"에 의존하는 항목들은 그때 복원하는 것이 맞다고 결론을 내렸습니다.

커버리지도 이와 비슷합니다. 커버리지는 어떤 특정위치에 대한 특성값을 반환하는 함수로서 기능합니다. 커버리지는 여러가지 지형지물를 기반으로 구성되므로, 커버리지 구조가 없더라도 데이터를 전송하는데는 크게 문제가 없다고 판단됩니다.

클래스의 정의에서 연산(Operation)은 데이터 교환용 응용스키마에서는 사용하지 않는 건 당연하고요.

이런 관점에서 제가 판단했을 때 구지 데이터 교환용 공통 응용스키마에는 별로 필요없겠다고 생각한 것들이 위의 그림에서 노란색으로 표시한 것들입니다.

제가 데이터 교환에 관련된 표준만 관심을 두고 공부하는 중이지만, 아직도 모두 이해하고 있는 건 아니기 때문에 나중에 바뀔 수도 있지만, 당분간은 응용스키마에 관한 한 "되도록 가장 간단한 구조"로 작성할 생각입니다.

따라서!!!

제일 위의 예제도 아래와 같이 바꾸는 게 맞다고 생각합니다. 그림을 보시면 모두 이해할 수 있으리라 생각하고 설명은 생략합니다.

참고 : 데이터 교환은 전송에 의한 방법과 트랜젝션(transaction)에 의한 방법이 있습니다. 트랜젝션의 경우, 사용자가 데이터를 요청하면 이를 처리하여 되돌려주는 방식입니다. 이 방식에서도 응용스키마가 사용되는데, 이 경우, 연산(Operation) 정의를 비롯해 실시간 데이터 처리가 관계되므로 위상구조도 데이터로 보내는 것이 맞다고 봅니다. 

===

이상입니다.

민, 푸른하늘



Posted by 푸른하늘 푸른하늘이

댓글을 달아 주세요

공간정보/표준2018. 5. 27. 00:39

장면 1

우리나라 정부가 생산 관리하는 데이터를 공개하는 곳인 공공데이터 포털

- 동일한 제목의 자료를, 올린 지자체도 있고, 안올린 곳도 있다.
- CSV, Excel, XML 등 포맷이 제각기.
- 동일한 자료에 대해서도 데이터 제작 주체에 따라 구조가 달라지기도 한다.
    - 예를 들어 열의 갯수가 모두 다른 경우
    - 열로 분리, 콤마로 분리, 분리 안한 것 등등

*참고 : 영국의 경우 www(월드와이드웹)의 창시자 팀버너스리 경(Sir Tim berners-Lee)이 주도하는 ODI(Open Data Institute)와 공동으로, XML 기반으로 데이터 공유 

장면 2

국가 공간정보를 공개하는 국가공간정보포털. (사례 : 버스노선)

- 지도데이터는 존재하지 않고, "공간정보목록정보"에만 존재
    - 목록에 존재하는 지자체는 21개. (군산시는 버스노선마다 따로따로 올려서 51개)
    - 데이터의 내용 및 구조에 관한 정보가 없는 경우 많음(예: 버스노선)
    - 고유주소 없음(예 : 동두천시를 검색한 주소를 복사한후 새창에 붙이면 동작하지 않음
- "국가공간정보포털개방목록"에 BRM 분류가 있으나, 막상 클릭하면 아무것도 없는 항목 다수
- 지방자치단체에서 작성한 데이터는 거의 없는 듯

장면 3

지방자치단체간 데이터 교환

- A 지자체에서 인접한 B 지자체에 도로데이터 요청한다.
- B 지자체는 A 지자체에서 요청하는 포맷으로 변환하여 전송한다.
- A 지자체는 B 지자체의 데이터를 받은 후 그냥 사용할 수 없다. 왜그럴까?

도입

우리나라에서 데이터 교환 또는 유통체계에서 벌어지는 사례를 몇 가지 들었습니다. 공공데이터 포털에서 제공되는 데이터는, 공간정보보다 훨씬 간단한 text 정보임에도 제대로 공개/유통되지 못하고 있다고 많은 사람들이 지적하고 있습니다. 이걸 생각해보면 이보다 훨씬 구조가 복잡한 공간정보에 대한 유통 체계가 문제가 있는 것은 어쩌면 당연할 수도 있습니다.

정보공개/데이터 유통과 관련된 모든 문제는 데이터 유통체계가 미비하기 때문에 발생하는 것입니다. 유통체계가 뭐가 잘못된 것인지를 말하는 대신, 데이터 유통체계가 완벽하게 이루어지면 어떻게 데이터공개/교환/유통이 이루어질 수 있는지를 생각해 보겠습니다.

1. 개인정보보호, 보안 등 현행법에 저촉되지 않는 모든 데이터가 공개된다.
2. 모든 공개된 데이터의 상세한 내용및 구조가 별도의 데이터로서 공개된다.
3. 동일한 이름의 데이터에는 내용과 구조가 완전히 동일하다.
4. Machine Readable 한 포맷으로 공개된다.
5. 공개된 데이터의 구조도 함께 공개되며, 이 구조를 사용하여 자동 검증이 가능하다.
6. 이미 공개된 데이터가 일부 수정된 경우, 수정된 부분에 대해서 즉시 공개된다.
7. 공개된 데이터는 관련자에게 즉시 통지(notification)된다.
8. 해당 데이터의 사용자/기관은 (사람이 개입하지 않고) 자동으로 갱신된 데이터를 읽어오고,
   이 데이터를 사용하여 자신의 데이터를 자동으로 수정한다.

대략 이렇게 정리할 수 있을 것 같습니다. 즉, 데이터를 어느 사이트에 올려 놓는다고 하여 유통이 되는 것이 아니라, 이런 식으로 기계간 통신(Machine to Machine)으로, 사람이 개입하지 않고 자동으로 처리될 수 있어야만 "궁극적"으로 데이터 유통이 된다고 할 수 있습니다. 이렇게만 되면, 어느 생산자든 데이터를 수정하면 그 데이터를 사용하는 사람의 데이터도 자동 수정되어, 결국 "실시간 갱신" 시스템이 완성될 수 있을 것입니다.

이러한 체계를 갖추기는 물론 매우 어렵습니다. 하지만, 불가능한 것은 아닙니다. 데이터 공급자의 의지와 노력 (+ 제도적 뒷받침), 그리고 공간정보 표준을 준수하면 이러한 체계를 갖출 수 있습니다. 그중에서 오늘 제가 할 이야기는 공간정보 표준, 그중에서도 유통과 밀접한 관련이 있는 "데이터의 내용과 구조"에 대한 내용입니다.

데이터의 내용과 구조(응용스키마)

"데이터의 내용 및 구조"를 이야기하면 보통 데이터 교환 포맷을 떠올립니다. 텍스트 위주의 DB라면 CSV나 XML 등이 교환포맷으로 많이 사용됩니다. Excel 파일로 올리는 곳도 많지만요. 공간정보 DB는 Shape 파일이나 GML 등의 포맷이 많이 이용됩니다. 물론 아직 DXF를 선호하는 분들도 있고요. 사실 데이터 포맷 자체는 큰 문제가 아닙니다. 한글파일이나 스캐닝한 영상을 올리지만 않고, 적절한 구조를 지원만 한다면 어떤 포맷을 사용해도 데이터 교환에는 그다지 큰 문제는 없습니다. 즉, (정확한 내용 및 구조를 가지고 있다면) 데이터 교환에 어떤 포맷을 사용해도 문제는 없다는 뜻입니다. 널리 알려지지 않은 포맷이라면 불편함이 더 많아질 뿐입니다.

하지만, 현재 국가공간정보포털에 올려진 파일은, 공각정보분야에서 일하는 사람이라면 누구나 잘 알고 있는 Shape 포맷으로 올려져 있는데, 왜 바로 가져다 쓸 수 없을까요? 그것이 바로 "데이터의 내용 및 구조"에 관한 문제입니다. 

이종 시스템 간의 상호 작용을 성취하기 위해서는 두 가지 근본 문제가 결정되어야 한다. 첫 번째 문제는 공간 데이터의 내용의 의미와 논리적 구조를 정의하는 것이다. 이것은 응용 스키마에서 이루어져야 한다. 두 번째 문제는 응용 스키마와 관련된 데이터를 표현할 수 있으며, 시스템과 플랫폼 독립적인 데이터 구조를 정의하는 것이다."

이 글은 "KSXISO 19118 지리정보 - 인코딩" 표준의 6절에 있는 내용입니다. 이종 시스템간의 데이터 교환을 위해서는 첫번째 "공간데이터의 내용 및 구조" 정의, 두번째 "데이터 포맷" 정의가 필요하다는 뜻입니다.

데이터 포맷은 위에서 언급한 것처럼, 사실 데이터 교환에 참여하는 자들끼리 동일한 포맷을 사용한다면 큰 문제가 아니라고 말씀드렸습니다. 하지만, "데이터의 내용 및 구조"는 완전히 다른 문제입니다. 예를 들어 두개의 기관에서 도로데이터를 각각 다음과 같이 정의하였다고 해보겠습니다. 

A 지자체(좌측)은 모든 도로를 하나의 "Road" 클래스로 분류하고, 5가지 속성을 갖는 것으로 정의했습니다.(이중 두개의 속성은 도형정보입니다.) B 지자체는 추상클래스인 Road 를 MainRoad 클래스와 AuxRoad 클래스가 상속받도록 정의했습니다. 물론 MainRoad와 AuxRoad는 구조가 다릅니다. 도로중심선(CenterLine)은 A 지자체에서만 정의하였고, 속성들이 서로 조금씩 다른 것도 있고 아얘 빠진 것들도 있습니다. (가상이니 심각하게 받아들이지 마시길...)

A 지자체에서 B 지자체에게 도로 데이터를 Shape 포맷으로 요청하면 어떻게 될까요. 당연히 B 지자체는 자신의 현재 구조 그대로 Shape 포맷으로 변환해서 넘겨줄 것입니다. 이 데이터를 받은 A 지자체는 다음과 같은 처리가 필요할 것입니다. 

- B 지자체에서는 MainRoad와 AuxRoad로 분리되어 있는 클래스를 Road 클래스로 합쳐야 합니다.
- RoadCover 는 RoadSurface와 동일하므로 클래스명만 수정합니다.
- CenterLine은 존재하지 않으므로 RoadSurface를 사용하여 자동 생성합니다.
- DateOpen는 MainRoad에만 있으므로, AuxRoad 클래스는 임의의 날짜를 부여합니다.
- Name은 동일하므로 그대로 가져옵니다.
- Admin 도 DateOpen 과 동일한 방식으로 처리합니다.

결국 데이터는 넘겨받았지만, 모든 클래스들을 일일이 검사하고, 수정을 거쳐야만 사용할 수 있게 됩니다. 새로 처음부터 만드는 것보다야 훨씬 편하지만, 엄청 많은 수고가 필요합니다. 넘겨받을 클래스의 수가 많을 수록 더 많은 노력이 필요하겠죠.

U 라는 사업체가 있어서 이들 도로데이터를 가져와서 사용하는 경우엔 어떨까요? 먼저 A 지자체에서 데이터를 받아와 데이터를 불러들이는 프로그램을 짰습니다. 이제 B 지자체에서 데이터를 받아오면 새로 프로그램을 짜야 합니다. 또다른 데이터를 받아오면? 또다시 새로운 프로그램을 짜야죠. 이처럼 모든 기관별로 응용스키마가 조금씩 다르기 때문에 매번 조금씩 달리 편집해서 사용해야 합니다. 물론 데이터를 제공해준다는 가정하에요. 예전에 내비게이션용 도로지도를 제작하던 어떤 업체 관계자는, 매 지자체별로 별도로 접촉해서 자료를 얻어야 했는데 공개하지 않는다는 곳도 많았지만, 기껏 공개를 해도 이처럼 많은 편집/가공이 필요하다고 푸념했던 기억이 납니다.

이처럼 현재 공개된 자료들은 모두 사용하려는 사람들이 구조를 일일이 검사하고, 변환하는 프로시져를 만들고, 테스트하는 과정을 걸쳐야만 사용할 수 있습니다. 심지어는 텍스트 정보만 제공되는 공공데이터 포털도 마찬가지입니다. 어떤 한 기관에서 제공하는 자료라면 그나마 다행이지만, 여러 기관의 데이터를 취합해야 하는 경우 정말 많은 자원이 소요됩니다. 게다가 담당자가 바뀌거나, 시스템이 변경되면 모든 과정을 새로 밟아야 합니다.

관리기관별로 데이터 내용 및 구조(응용스키마)가 다른 이유는 자신의 목적에 따라 시스템을 구축하기 때문입니다. 처음 측량을 통해 생산한 원시데이터는 동일하더라도, 시스템을 구축할 때는 내부의 목적, 사용하는 하드웨어/소프트웨어의 종류 등에 따라 달라질 수 밖에 없습니다. 응용스키마가 원래 그런 성격이니까요.

공통 응용스키마

그럼 이처럼 데이터 생산/관리 기관별로 구조가 다른 상태에서 어떻게 데이터를 교환해야 할까요? 이것이 "KSXISO 19118 지리정보 - 인코딩" 표준에서 다루는 문제입니다. 아래는 이 표준의 그림 1 "두 시스템간의 데이터 교환의 개요"입니다.

이 그림을 간단하게 설명하면, 다음과 같습니다.

1. 다수의 시스템에 대하여 공통 응용스키마 I 를 정의해야 한다.
2. 내부 DB는 이 공통 응용스키마를 적용한 임시 내부 데이터베이스 M_AI 를 생성한다.
3. 이 표준에 따른 인코딩 서비스 R을 사용하여 자료를 공통포맷으로 변환한다.
4. 이렇게 만들어진 파일/스트림을 상대측에 전송한다.

즉, 자산의 내부 DB를 그냥 변환하는 것이 아니라, 공통 응용스키마를 적용하고, 공통 포맷을 적용하여 변환해야 한다는 것입니다. 물론 읽어들일 때는 이 반대의 수순을 밟으면 되고요.

여기에서 볼 수 있는 것처럼, 데이터 공유에 있어 가장 중요한 것은 데이터 공개/유통에 참여하는 모든 참여자가 공유하는 "공통 응용스키마"입니다. 공통 응용스키마를 사용하고 그것이 정확하게 지켜지기만 한다면, 어떤 포맷을 사용해도 문제없이 데이터를 공유할 수 있습니다.

XML 인코딩

그런데, KSXISO 19000 표준군에서는 모든 종류의 공간정보 교환에 XML 포맷으로 인코딩 할 것을 권장하고 있습니다. KSXISO 19118 인코딩에서는 데이터를 XML로 변환하는 규칙을 제시하고 있고, KSXISO 19136 지리마크업언어(GML)에서는 이 XML 변환규칙을 보다 정확하게 규정하고 있으며, KSX1SO 19139 메타데이터 XML 구현에서는 메타데이터를 XML 로 변환하고 공유하는 규칙을 다루고 있습니다. 즉, 데이터 교환은 가능한한 XML 을 이용하라는 것입니다.

그런데 XML(또는 GML)은 데이터 그 자체일 뿐입니다. XML을 사용한다고 하여 데이터 교환이 순조롭게 이루어질 수 없습니다. 데이터의 내용 및 구조(응용스키마)의 공유, 준수가 필수적으로 뒤따라야 합니다.

XML 스키마는 XSD(XML Schema definition)로 정의됩니다. XSD는 말그대로 XML 파일의 스키마를 정의하는 문법입니다. 일반 XML 파일은 <tag1> </tag1> 등과 같은 형태로 태그만 맞춰주면 어떠한 데이터도 추가할 수 있으습니다. 그러나, XSD를 정의하면 XSD에 정의되어 있는 항목외에는 들어갈 수 없고, XML에 XSD 정의항목이 빠졌다면 오류가 발생하게 됩니다. 즉, XML 과 XSD는 쌍으로 움직이고, 일정한 내용과 구조를 갖출 수 있게 됩니다.

이와 같이 XML 은 XSD가 존재하기 때문에 데이터와 응용스키마를 함께 공개/교환 할 수 있습니다. Shape 등 다른 포맷은 응용스키마를 일치시킨다고 해도, 해당 데이터가 응용스키마에 일치하는지 여부는 별도의 어플리케이션을 작성해야만 검증할 수 있습니다. 하지만, XSD+XML은 이 자체만으로 데이터 구조의 일관성을 유지할 수 있습니다.

19118 인코딩 표준에서는 UML로 작성된 응용스키마를 XSD로 변환하는 규칙도 제공합니다. 다음 그림은 이 표준의 "그림 C.1 - XML 기반의 변환규칙" 입니다.(일부 수정) 이 그림에서 말하는 것은, 공간정보 응용스키마는 XSD로 인코딩하고, 공간데이터(응용데이터)는 이 XSD를 기준으로 XML(GML) 로 변환한 후, 이 두개의 파일을 모두 제공하라는 것입니다. 이것이 ISO 표준에 따르는 것이죠.

따라서, 국가공간정보포털과 같은 데이터 교환장소에는 데이터를 GML(XML) 포맷으로 제공하는 외에도 다음과 같은 응용스키마 관련 정보를 함께 제공해야 합니다. 이중 위의 두가지는 사람들이 편하게 이해하기 위한 용도이고, 마지막 XSD는 컴퓨터가 직접 해석하기 위한 용도입니다. (이 이외에도 메타데이터에 관한 내용도 XML로 제공해야 하지만, 이는 생략합니다.)

- 응용스키마 (UML)
- 데이터딕셔너리 - 응용스키마 객체의 상세 해설
- XSD - XML 용 스키마

기존 공간정보를 다루는 입장에서 볼 때, Shape 파일 등이 널리 사용되고 있으므로, 이런 포맷을 사용하는 것이 더 낫다는 의견도 있을 수 있습니다. 하지만, XML 포맷을 사용하면 다음과 같은 장점이 있어서, 단순한 Shape 파일보다 월등한 편의성을 누릴 수 있습니다.

- XML 포맷은 사람들도 어렵지 않게 읽을 수 있지만, 무엇보다 컴퓨터 처리에 좋다.

- XML을 처리하기 위한 다양한 라이브러리가 존재하기 때문에(오픈 소스도 다수 존재함)
  GIS 소프트웨어를 사용하지 않아도 일관성 검증이나 통계 등 간단한 데이터 처리가 가능하다.
    - XML Validator
    - XML DOM Parser

- XML 은 W3C에서 정의한 정보 교환/처리를 위한 표준으로 Web/IT 분야에 널리 사용되고 있으며,
  특히 공간정보를 모르는 사람들도 장벽없이 처리할 수 있다.

- XML 파일의 스키마(구조)를 정확하게 정의하는 XSD (XML Schema Defintion)를 함께 제공하면,   
  데이터 구조의 검증이 아주 쉬워진다. 즉, 일관된 구조가 100% 유지할 수 있다. 

이러한 장점이 있기 때문에, 데이터 공개/교환은 XML(GML)을 사용해야 한다는 것이 제 생각입니다. 아니 다른 포맷으로는 이러한 장점을 대체할 수 없으므로, 반드시 XML(GML)을 사용해야 합니다.

결론

이제 마무리를 지어야 할 때가 왔습니다. 제가 처음에 언급했던 "완벽한 데이터 유통체계"에 대해 다시 생각해보겠습니다. 

1. 개인정보보호, 보안 등 현행법에 저촉되지 않는 모든 데이터가 공개된다.
2. 모든 공개된 데이터의 상세한 내용및 구조가 별도의 데이터로서 공개된다.
3. 동일한 이름의 데이터에는 내용과 구조가 완전히 동일하다.
4. Machine Readable 한 포맷으로 공개된다.
5. 공개된 데이터의 구조도 함께 공개되며, 이 구조를 사용하여 자동 검증이 가능하다.
6. 이미 공개된 데이터가 일부 수정된 경우, 수정된 부분에 대해서 즉시 공개된다.
7. 공개된 데이터는 관련자에게 즉시 통지(notification)된다.
8. 해당 데이터의 사용자/기관은 (사람이 개입하지 않고) 자동으로 갱신된 데이터를 읽어오고, 
   이 데이터를 사용하여 자신의 데이터를 자동으로 수정한다.

동일한 데이터에 대해 공통 응용스키마를 갖도록 하고 이를 XSD, GML 로 공개하는 체계가 갖추어진다는 것은, 이 여덟가지 중에서 2,3,4,5 항목에 해당합니다. 1번 항목은 제도적으로 해결해야 할 부분이며, 6,7,8 항목은 공개된 데이터를 실시간으로 전달할 수 있는 시스템의 구축이 필요합니다. 물론 이러한 내용도 일부(개념적 수준에서는) 표준에 정의되어 있습니다. 

현재 국토지리정보원에서는 일부 지형지물에 대해 완공이 되는 즉시 측량을 실시하는 실시간 갱신작업을 실시하고 있는 것으로 압니다. 그런데, 이러한 측량이 완료되는 시점에서 국민에게 전달될 때까지의 시간 - 즉, 네이버/다음 등의 포털지도에 나타나기 까지의 시간은 최소 6개월 이상 걸릴 것으로 생각됩니다. 제가 지금까지 말씀드린 "데이터의 내용 및 구조"라고 통칭한 이러한 기술을 적용하여, 정말 실시간으로 데이터를 공유할 수 있는 날이 빨리 오기를 소망합니다.

민, 푸른하늘


Posted by 푸른하늘 푸른하늘이

댓글을 달아 주세요

공간정보/표준2018. 5. 15. 19:07

ISO/TC 211에서 발간한 공간정보 표준 가이드(ISO_TC_211_Standards_Guide)를 번역했습니다.

사실 번역을 시작한지는 꽤 된 것 같습니다. 적어도 3년 이상된 것 같은데, 생각날 때마다 찔끔찔끔 하다가, 이번에는 꼭 마치겠다는 각오로 끝냈습니다.

아직 모자라는 부분이 많습니다. 표준에 대해 모르는 부분도 많다보니, 제대로 번역이 안된 부분도 있고, 아직 제대로 검토를 하지 않아서 오자나 탈자도 많을 겁니다. 그렇다고 퇴고를 언제 할지도 모르는데 무작정 둘 수 없어서 공개합니다. 

이 글의 원본이 2009년에 나왔습니다. 벌써 9년이나 흘렀네요. 그러다보니 개요부분에 현실과 약간 멀어진 내용도 있고, 소개된 표준도 현실을 반영하지 못한 부분도 있습니다. 

원본은 아래와 같습니다. 영어 원문과, 일본 국토지리원에서 번역한 일본판 원문입니다. 내용은 거의 비슷하기 때문에 두가지 버전을 참고하면서 번역했습니다. 구글 번역기의 도움을 많이 받았습니다.

ISO_TC_211_Standards_Guide.pdf

ISO_TC_211_Standards_Guide_Japanese.pdf

아래는 제가 번역한 한글판입니다. 

ISO_TC_211_표준_가이드.pdf

아무튼 조금이라도 도움이 되길.

민, 푸른하늘


Posted by 푸른하늘 푸른하늘이

댓글을 달아 주세요

사진/360 파노라마2018. 4. 20. 19:25

며칠전 집사람과 함께 결혼 30주년 기념으로 프라하에 다녀왔습니다. 원래 제가 360*180도 파노라마 사진을 좋아하기 때문에, 얼마전 구입한 기어360을 사용해서 파노라마 사진을 많이 촬영했습니다. 이 글은 그 과정에서 느낀 점입니다.

기어360을 사용하면 파노라마 사진을 쉽게 촬영할 수 있습니다. 스위치만 한번 눌러주면 되니까요. SNS로 공유하는 것도 쉽습니다. 제는 Theta360 사이트에 올리고 공유하는데, 이 글을 참고하시면 됩니다. 

제 기어360의 현재 상태

제가 촬영-공유가 쉽다고 말한 것은 기존의 360도 파노라마를 촬영하는 방법에 비해 쉽다는 것입니다. 즉 어안렌즈를 장착한 DSLR로 촬영하고, 컴퓨터에 다운로드 받아, PTGui 등으로 스티칭하고, 공유사이트에 올린 후, 링크를 받아서 공유하는 과정에 비하면 1/10 아니 1/100의 노력만으도 가능하기 때문입니다. 사실 혁명적 수준으로 간단해진 건 사실입니다.

하지만, 대부분의 사진은 그냥 핸드폰으로 촬영하고 공유하고 있는 현재, 기어360으로 파노라마를 촬영하고 공유하는 것은 여전히 많은 과정이 필요하고 번거롭습니다. 핸드폰으로 사진 촬영해서 공유하는 것과 비교하면? 한 20-30배 정도는 시간이 더 많이 걸리는 것 같네요. 

첫번째 촬영준비 과정. 카메라를 켜면 정상작동할 때까지 시간이 걸립니다. 모든 카메라가 시동시간이 필요하겠지만,  요즘 디카는 대부분 이런 과정이 극히 짧습니다. 스마트폰은 말할 것도 없구요. 기어360의 촬영과정은 1. 보호캡을 벗긴다. 2. 리모콘 스위치를 켠다. 3. 기어360 스위치를 켠다. 4. 기어360이 준비 완료되기까지 기다린다. 5. 셀카봉을 뽑니다. 6. 리모콘을 누른다. 

제가 스톱워치로 시간을 재보니, 여기까지 27초가 걸렸습니다. 상당히 걸리는 편이죠. 물론 리모콘이나 셀카봉 없이 촬영하는 방법도 있겠지만, 리모콘이 없으면 타이머를 이용하는 게 귀찮고, 셀카봉이 없으면 손이 크게 나와서 자세가 안나옵니다. 그래서 사실상 저에게는 필수입니다. 

또한, 리모콘이나 셀카봉을 생략한다고 하여 시간이 많이 줄어드는 것도 아닙니다. 리모콘에 전원을 넣어둔 상태에서 기어360이 완전히 준비되기까지는 18초 가량이 걸렸습니다. 겨우 5-10초 정도 단축된겁니다. 20초 걸리나 30초 걸리나, 사진을 찍는 입장에서는 별 차이를 느낄 것 같지 않습니다.

어쨌든, 사진 한장을 촬영하기 위해서 20초 이상 걸린다면 아무 곳에서나 촬영하기는 힘들게 됩니다. 제가 이번에 여행하면서 느낀 것도 기어360으로 촬영하려면 마눌님한테 잠시 기다려줘~~ 라고 하고선 한참 이리저리 조작한 후 촬영해야 해서, 마음껏 촬영하지 못했습니다. (익숙하지 않았던 이유도 있습니다. 이젠 꽤 익숙해졌으니 다시 여행을 가고싶네요. ㅎㅎㅎ)

그러다보니, 하루 종일 돌아다니면서 촬영해도 100컷 이상 촬영하기는 힘들었습니다. 물론 모든 곳에서 360 사진을 촬영하는 건 아니고 대부분 핸펀이나 일반 카메라로 촬영하다가 정말 마음에 드는 공간이 나타나면 기어 360을 꺼내는 거니까, 대부분의 경우 100장 이상 촬영할 필요는 없을 것 같지만 말이죠.

두번째 촬영 단계. 사실 촬영단계는 일반 카메라와 동일합니다. 스위치만 누르면 되니까요. 만약 SNS로 공유하지 않고 그냥 집에서 처리하겠다고 하면 여기서 끝내면 됩니다. 다른 곳으로 이동하여 좀 더 촬영할 수도 있고요.

그런데, 여기에서 지적할 것 하나. 배터리 용량이 너무 모자란다는 겁니다. 대충 느낌으로 제가 하루에 50장 ~ 100장 정도 촬영한 것 같은데, 배터리 한개로 부족했었습니다. 마침 제가 아래와 같은 배터리를 이베이에서 구입해서(사실은 제건 도착하지 않아서 빌려서. ㅠㅠ) 갔기에 망정이지 아니라면 중간중간 충전하느라 더욱 번거러웠을 뻔 했습니다. 게다가 저는 사진만 촬영해서 그렇지, 비디오까지 촬영했더라면 배터리 소모가 훨씬 더 컸을 겁니다.

세번째 핸펀으로 다운로드(스티칭)하는 단계. 사진을 공유하려면 일단 스마트폰으로 다운로드 받아야 합니다. 1. 스위치를 켠다. 2. 준비완료 연결음을 기다린다.(스마트폰에 자동연결됨) 3. 앱에서 Gear360 갤러리에 들어간다. 4. 원하는 사진을 선택한다. 5. 저장을 누른다. (스티칭이 되면서 저장됨) 7. 기기 갤러리에 들어간다. 8. 해당사진을 클릭하여 확인해본다.

여기까지 제가 스톱워치로 시간을 재보니 대략 1분 20초 정도 걸렸습니다. 여기에서 핵심 사항은 스티칭-저장하는 시간인데, 이외로 이 시간은 별로 걸리지 않습니다. 10초 정도에 불과합니다. 그런데, Gear360갤러리에 들어가면 기기에 있는 사진의 목록을 만드는 시간이 10초 정도, 또다시 스마트폰 갤러리에서 목록을 만드는 시간이 10초 정도씩 걸립니다. 

매번 스위치를 넣을 때마다 똑같이 반복되는 것으로 보아 갤러리에서 목록을 별도로 관리하지 않는 듯 합니다. 아무튼 이 단계는 조금 앱을 최적화시키기만 하면 속도가 빨라지지 않을까... 싶은데 좀 아쉽습니다.

네번째 SNS에 공유하는 단계. 가장 편한건 페이스북에 공유하는 것입니다. 페이스북에는 올리기만 하면 360도 파노라마를 인식하여 적당한 형태로 공유할 수 있습니다. Google 포토의 경우도 360*180 파노라마로 인식을 하기는 하지만, 공유시켜보면 여러번 클릭을 해야만 볼 수 있어서, 360파노라마 공유용으로 썩 적합하지 않습니다. 기타 다른 사이트에 올리면 거의 일반 사진으로 먹힙니다. 카카오톡등의 메신저로 보내도 그냥 사진 그대로만 전달되므로, 360도 파노라마의 느낌을 전달할 수 없습니다.

사실 이건 삼성이 해결해주어야 할 일입니다. 삼성 클라우드에 올릴 수 있도록 하고, 아주 공유하기 쉽도록 해줘야 하는 거죠. 하지만, 아주 더럽습니다. 아래는 Gear360앱에서 공유를 눌렀을 때 나타나는 화면인데, 보시는 것처럼 하루에 2GB까지만 공유할 수 있다고 나옵니다. 하루에 2GB면 쓸만하죠. 문제는 이게 딱 이틀뒤에는 사라진다는 겁니다. 임시공유가 목적이면 모르겠지만, 되도록이면 사용하지 마라... 넘들이 하니까 나도 하는 척은 하겠다... 하는 뜻으로만 보입니다. 또한 공유링크를 받아서 360파노라마를 보려면 여러번 클릭하는 것도 못마땅한데다가 드래그 하는 것만으로는 360*180 모두를 확인할 수 없습니다. 머리위쪽과 바닥쪽을 보려면 핸드폰을 기울여야만 보입니다. 한마디로 그냥 쓸만하지 못합니다.

그래서 저는 이 글에서 쓴 것처럼 Theta360 사이트를 이용하고 있습니다. 간단히 말하면 1. Theta360앱을 실행한다. 2. 원하는 사진을 고른다. 3. 적절한 제목/내용/태그를 입력한다. 4. Theta360 사이트에 업로드 한다. 5. Brouser로 확인을 누른다. 6. 주소를 복사한다. 7. 원하는 사이트들에 주소를 복사한다. 8. 원하는 SNS 사이트나 메신저에 주소를 붙인다. 이런 순서로 진행하면 됩니다.

제가 스톱워치로 체크한 시간은 대략 1분 30초 정도 걸립니다. 사실 이건 인터넷 연결속도에 따라 다르기 때문에 빠르다 늦다고 이야기할 것은 아니고, 만약 삼성에서 직접 지원을 하였다면 거의 이 과정들이 필요하지 않을 것이기 때문에 10-20초 이내로 해결될 수 있지 않을까 싶습니다. 아무튼 문제의 삼성입니다.

===

흠... 그러니까 기어 360이 꺼져 있는 상태에서 촬영하고 공유한다면 3분30초 정도 걸리는 셈이네요. 이건 최적화되었을 때의 이야기이고, 실제 사용하려다보면 실수도 하고 그러니까 더 늘어납니다. 제가 방금 테스트 해보니 4분 50초 걸렸습니다. 게다가... 단계를 세어보니 거의 25단계가 됩니다. 물론 제가 자세하게 쓰려다보니 늘어난 것도 사실입니다만, 사진 공유에 비하면 엄청 많은거죠.

그러니까 다른 사람들과 여행을 하던 중이라면, 기어360으로 360파노라마를 촬영하고 실시간으로 공유하는 것은 불가능하다고 봐야 합니다. 제가 여행중 약 150장의 사진을 촬영했고, 이중에서 5장 정도만 공유했는데, 이것들은 모두 레스토랑이나 카페에 가서 주문을 기다리면서 올렸던 겁니다. 박물관에서 멋진 그림을 봤다고 그 자리에서 촬영하고 올리려면 동행자가 짜증낼게 분명하니까요.

===

지금 삼성은 기어360 을 중심으로한 VR 사업을 거의 접은 걸로 압니다. LG는 일치감치 접었고, 고프로도 휘청거리고 있고... 아마도 다른 업체들도 그리 좋은 상태는 아닐거라고 봅니다. VR 자체가 제 생각엔 VR 헤드셋에서 볼 수 있는 것처럼 아직도 거추장스럽게 크고 불편하며, 360 카메라도 아직까지 품질과 편의성이 부족하기 때문입니다. 

360 VR 카메라가 대중적이 되려면... 

1. 카메라 시동시간이 대폭 단축되어야 한다. - 사실 이건 요즘 카메라기술로 보면 어렵지 않을 것 같습니다. 360카메라의 경우 전원을 켰다껏다 반복하게 되므로, 이를 줄이면 배터리 효율도 올라가게 되지 않을까 싶습니다.

2. 360VR 카메라에서 자동으로 스티칭을 해주면 좋다. - Richo Theta의 경우 사진을 촬영하면 바로 기기 내부에서 스티칭이 진행됩니다. 따라서 그냥 다운로드만 하면 사용할 수 있습니다. 그런데 기어 360의 경우 5초를 약간 넘는 수준이니 크게 문제되는 건 아닐 것 같습니다.

3. 360카메라에서 스마트폰으로의 다운로드가 투명하게 이루어져야 한다. - 옵션을 제공해야겠지만, 찍으면 바로 스마트폰으로 자동 다운로드 받도록 하는 것도 어렵지 않을 것 같습니다.

4. 클라우드 업로드가 쉽고 편하게 - 구글 Photo처럼 무한정의 공간을 제공하고, 어디든 쉽게 공유할 수 있도록. 그리고 360Photo 공유사이트처럼 다양한 기능을 추가제공....

머 이 정도가 생각납니다.  간단히 말하면 아주 쉽고 편하게 만들어야 한다는 겁니다. 특히 핵심은 클라우드 서비스와의 연동이 되어야 한다는 것. 스마트폰으로 사진촬영하는 만큼은 불가능하겠지만, 그래도 그 수준까지 좁힐 수 있도록 추구한다면 어느 정도는 만족스런 결과가 나오지 않을까 싶습니다.

사실 더 중요한 건 해상도 등 사진 품질입니다. 기어360 2016의 해상도는 7776x3888 로서 어느 정도 충족되긴 했지만, 사실 품질이 많이 떨어집니다. 사진을 확대해보면 잡음이 많거든요. 아마도 해상도를 강조하다보니 강제로 Edge Enhancement를 적용한 듯 합니다. 어쨌든 일반 사진정도에 해상도는 8000x4000 정도 이상이 되어야 왠만큼 감상하는 데 지장이 없을 겁니다. 하지만, 사진의 해상도는 지금 나와있는 기기들이 모두 1/2.3" CMOS 센서를 사용하는 것으로 보아, 쉽지는 않을 것 같아 일단 주요 리스트에서는 뺐습니다.

아무튼... 현재의 상황을 보았을 때 가까운 시간 이내에 이런 모든 것을 만족하는 360VR 카메라/사이트/서비스가 나올것 같지는 않을 것 같네요. 멍청한 삼성.... ㅠㅠ

민, 푸른하늘


Posted by 푸른하늘 푸른하늘이

댓글을 달아 주세요

사진/360 파노라마2018. 4. 6. 11:50

파노라마 사진을 촬영할 때 반드시 고려해야 하는 것이 시차(Parallax) 문제입니다. 360*180 파노라마를 촬영하는 분들이 사용하는 Cubicpan과 같은 파노라마 헤드(Panorama head)는 이 시차를 없애기 위한 목적의 장비입니다.

Cubicpan 파노라마 헤드

이 글에는 시차를 없앨 수 있는 무시차점(NPP : Non Parallax Point)를 찾기위한 방법이 기술되어 있는데, 어렵지는 않아도 꽤나 귀찮은 작업입니다. 그럼에도 불구하고, 이와 같은 방법이 필요한 것은 파노라마 사진을 정확히 촬영하려면 아래 사진들과 같이 무시차점을 중심으로 사진을 촬영해야 하기 때문입니다. (참고 : 파노라마사진의 원리와 촬영방법

파노라마사진기파노라마 사진기의 원리

하지만, 요즘 나오는 Gear360과 같은 일체형 360 카메라의 경우, 이것이 불가능합니다. 어안렌즈가 달린 두개의 카메라로 동시에 촬영하기 때문에 무시차점을 일치시킬 수 없기 때문입니다. 로드뷰나 구글 스트릿뷰에서 가끔 머리와 몸통이 따로 놀거나 아래와 같이 겹쳐져 보이는 것도, 모두 동일한 문제 때문에 발생하는 것입니다. 

이러한 시차 오류는 거리에 따라 달라집니다. 거리가 멀다면 거의 눈에 띄지 않지만, 거리가 가까울수록 오류가 크게 나타납니다. 

그런데... 이런 시차 오류가 얼마나 크게 발생할까요? 사실 예전부터 궁금했는데, 이번에 기어360을 사용해서 Cupix.com의 자동360VR을 만드는 서비스를 테스트해보다 보니 좀더 정확히 파악하고 싶어졌습니다.

기어360 등의 360 액션캠은 모두 화각이 180도 이상되는 어안렌즈(fish-eye)를 사용하고 있습니다. 이 어안렌즈의 기하학적인 원리는 영문 위키백과 Fish-eye 문서중 Mapping Function을 보시면 되는데, 저는 그냥 이해하기 쉽도록 equidistant 모델을 사용하는 걸로 가정하겠습니다. equidistant 모델은 카메라 렌즈에서 물체를 바라볼 때의 각도 차이와 사진상에 촬영되는 이미지의 거리와 비례하는 것을 말합니다.

즉, 카메라 정면에서 1도 차이가 사진상에 10pixel 차이가 난다고 가정하면, 45도 위치에 있는 물체든, 90도 위치에 있는 물체든 모두 1도 차이는 사진상에 10pixel 차이가 난다고 가정한다는 것입니다. (물론 이런 Mapping Function을 사용하는 어안렌즈가 오히려 드물고, 대부분 equisolidangle 방식을 사용한다고 합니다만...)  

그리고, 어안렌즈의 화각은 정확히 180도 이고, 위의 오른쪽과 같이 CMOS에 꽉차도록 촬영한다고 가정하겠습니다. 물론 어안렌즈의 화각은 모두 180도보다 크고, 꽉 차게 촬영할 지 좀 벗어나게 촬영할지는 카메라 메이커에 따라 달라지지만, 그냥 계산이 편하도록 이렇게 가정합니다. 

CMOS는 SONY IMX 377의 스펙을 참조하여, 4000x3000 픽셀짜리를 사용한다고 가정하겠습니다. 따라서 180도가 3000픽셀이므로 1도 차이가 약 16.7 pixel을 차지하는 셈이네요. 센서의 크기는 1/2.3" 입니다. 6.16x4.62mm 라니, 4.62mm에 3000 픽셀이 들어 있습니다.

다음으로 어안렌즈가 아래와 같이 배치되어 있다고 가정하겠습니다. 아래쪽에 있는 위치는 무시차점의 위치입니다. 원래 여기에 배치해야 하지만, 카메라의 구조상 d 만큼 벗어나게(앞으로 튀어나오게) 배치했다고 생각하겠습니다. 여기에서 계산하고자 하는 것은 이 거리 d와 중심에서 벗어난 각도 θ에 따라, 촬영된 각도의 차이 δ가 얼마나 발생하느냐 하는 것입니다. (두 카메라에서 벗어난 각도는 약간씩 다르고, 카메라 중심에서 물체까지의 거리도 조금 다르지만, d 가 S에 비해 상당히 작다고 가정하고 무시합니다.)

여기에서 d 는 대략 2cm 에서 4cm 정도로 두면 될 것 같습니다. 제가 이번에 여러 기기들을 가져와서 대충 재어본 결과입니다. (정확하지는 않습니다.)

이제 계산을 해보겠습니다. 다음은 d=20mm  일때, 즉 렌즈간 간격이 20mm 일 때의 각도오류입니다. 예를 들어, 아래 주황색 0.88 이란, 정면에서 50도 벗어난 곳에 1미터 지점에 있는 물체는 원래 촬영되어야 할 위치에서 0.88 도 벗어난 곳에 촬영된다는 의미입니다.

d20
theta1002005001000200050001000050000
00.000.000.000.000.000.000.000.00
101.990.990.400.200.100.040.020.00
203.921.960.780.390.200.080.040.01
305.732.861.150.570.290.110.060.01
407.373.681.470.740.370.150.070.01
508.784.391.760.880.440.180.090.02
609.924.961.980.990.500.200.100.02
7010.775.382.151.080.540.220.110.02
8011.295.642.261.130.560.230.110.02
9011.465.732.291.150.570.230.110.02


이것을 pixel 수로 환산하면 아래와 같습니다. 예를 들어, 정면에서 90도 방향으로 1 미터 떨어져 있는 물체는 양쪽 센서에 약 20 픽셀정도 차이난 위치에 촬영된다는 뜻입니다. 더 가까운 곳에 있는 물체들은 당연히 볼 필요도 없고, 적어도 5미터는 떨어져 있어야만 스티칭하는데 별 문제가 발생하지 않는다고 보아야겠네요.

픽셀수3000각도180
1도당픽셀
16.67
theta1002005001000200050001000050000
00.000.000.000.000.000.000.000.00
1033.1616.586.633.321.660.660.330.07
2065.3232.6613.066.533.271.310.650.13
3095.4947.7519.109.554.771.910.950.19
40122.7661.3824.5512.286.142.461.230.25
50146.3073.1529.2614.637.322.931.460.29
60165.4082.7033.0816.548.273.311.650.33
70179.4789.7335.8917.958.973.591.790.36
80188.0894.0437.6218.819.403.761.880.38
90190.9995.4938.2019.109.553.821.910.38


d=40일 경우는 아래와 같습니다. 그냥 위의 표에 2배이니 구지 필요하지는 않겠지만요. ㅎㅎ

픽셀수3000각도180
1도당픽셀
16.67
theta1002005001000200050001000050000
00.000.000.000.000.000.000.000.00
1066.3333.1613.276.633.321.330.660.13
20130.6465.3226.1313.066.532.611.310.26
30190.9995.4938.2019.109.553.821.910.38
40245.53122.7649.1124.5512.284.912.460.49
50292.61146.3058.5229.2614.635.852.930.59
60330.80165.4066.1633.0816.546.623.310.66
70358.94179.4771.7935.8917.957.183.590.72
80376.17188.0875.2337.6218.817.523.760.75
90381.97190.9976.3938.2019.107.643.820.76

===

이상입니다. 흠... 계산은 계산이니까... 하긴 했습니다만, 이것말고도 고려할 요소가 많을 것 같은데... 싶네요~~ ㅠㅠ

민, 푸른하늘




Posted by 푸른하늘 푸른하늘이

댓글을 달아 주세요

사진/360 파노라마2018. 4. 2. 17:03


요즘은 좀 잠잠해졌습니다만, 2-3년전 VR(Virtual Reality)에 관한 관심이 높아지면서 많은 회사들이 360 VR 카메라를 제작했습니다. 일부는 이미 사업을 정리했다는 소식도 들리지만, 몇몇 회사들은 계속 신제품을 내고 있습니다.

저는 오래전부터 360 파노라마 제작에 관심이 많았지만, 사실 최근의 360 카메라에는 별로 관심이 없었습니다. 일체형이면서 소형 카메라이기 때문이지만, 화질이 제 기준에는 너무 못미치는데다, 가격도 만만치 않았기 때문입니다.

그런데 우연치 않게 삼성 기어360 2016버전이 단종되면서 10만원 이하에 구할 수 있다는 걸 알고 하나 장만하고선 조금씩 만지다보니 꽤나 재미있는 물건이라는 걸 알게되었습니다. 어차피 화질이야 어쩔 수 없다고는 해도 그냥 리모콘 단추만 누르면 360 파노라마가 촬영되고, 스마트폰으로 몇번 조작만 하면 쉽게 친구들과 공유할 수 있다는 편리성 때문입니다. 요즘도 어디 나갈 때는 꼭 이녀석을 챙겨다닙니다. 기념할 만한 순간이 있으면 그냥 똑딱이 사진기 꺼내들 듯 기어360으로 한장 남기고 있습니다.

그러던 중 우연히 자동 360VR 서비스를 구현한 Cupix 의 기능을 테스트하던 중, 이 회사에서 보유한 여러가지 360 VR 카메라를 빌려줄 수 있다고 하여, 잘됐다 싶어 테스트해보기로 했습니다. 기어360보다 나은 기기도 있다고 알고 있으니 한번 비교해 보자고요.

일단 이번에 제가 만져본 VR 카메라들의 목록입니다. 여기에 나온 내용은 여기를 비롯해 여러군데에서 찾아서 비교해 본 것입니다. 이 표의 원본은 여기에 있으니 참고하세요.

원래 이 글의 목적은 이들 카메라의 사진 품질을 비교하는 것이었습니다. "camera lens resolution chart" 으로 검색해서 나온 여러가지 도안중 적당한 것을 붙여두고, 일정한 거리에서 촬영해서 비교하는 방식으로요. (물론 엄격하게 비교를 한다면 촬영환경도 동일하도록 유지해야 하고, 비교도 좀더 과학적으로 해야겠지만...ㅠㅠ_

그런데 사진의 품질은 그다지 차이가 많이 나지 않았습니다. 물론 해상도 차이가 있기는 해도, 원래 센서 사이즈가 동일하기 때문에 (고프로는 확인이 안되지만, 거의 1/2.3" 정도입니다.) 차이가 없는 게 아닌가 생각해봤습니다. 어쨌던 그러다보니 비교가 무의미해졌고, 그래서 동영상도 비교를 해보기로 했습니다.

위 표에서 보시면 동일한 센서를 사용하는데도 불구하고 사진해상도와 동영상 해상도가 다릅니다. 동영상의 경우, 많은 양의 자료를 처리하다보니 프로세서를 비롯한 하드웨어 구성에 따라 달라지는 게 아닌가 합니다. 그리고 사진품질의 경우에서도 보시는 것처럼, 단순 해상도로 비교할 수 없는 매우 다양한 비교인자가 필요합니다. 그러나, 저는 능력이 부족하여 그냥 동일한 지점에서 영상을 서로 비교해 보는 정도로민 진행했습니다.

그렇지만, 360VR의 경우 단순히 영상의 품질만으로는 비교할 수 없습니다. 사진이나 동영상은 워낙 오랫동안 사용되어 왔기때문에 누구나 쉽게 촬영하고 쉽게 감상하고 공유할 수 있지만, 360VR의 경우엔 사용법도 익숙하지 않고, 처리도 여러단계를 거쳐야 하며, 공유할 수 있는 플랫폼도 매우 제한적이기 때문에, 이 모든 것을 얼마나 쉽게 부드럽게, 투명하게 만들 수 있느냐 하는 것까지도 함께 평가되어야 할 요소입니다.

머... 그래도 저는 계속말하지만, 전문적인 평가를 할 수 있는 상태가 아닌만큼 사진촬영하고, 비디오 촬영해서 스티칭을 한 뒤 유튜브로 올리는 과정에서 느낀 점들만 썼습니다. 물론 이것도 겨우 몇시간 써본 정도라서 객관적이라고 보기는 힘들다는 것을 고려해서 읽어주시기 바랍니다.

GoPro Fusion

- GoPro 앱을 설치하려고 하였으나, 내가 가진 폰(A8)에서는 제어가 안된다고 나왔음. 보급형 모델이기 때문일 수도 있겠다 싶었으나, 최신 스마트폰에서도 동일한 문제 발생. 결국 앱이 잘못된 것일 가능성 높음.

- GoPro Fusion Studio를 PC에 깔아서 사용. 자동으로 연결하여 360 사진/비디오로 스티칭 해주는데, 사용방식이 직관적이어서 어렵지 않았음. 

- 하지만, PC에 USB로 연결하면 연결이 될때보다 안될 때가 많았음. GoPro Fusion쪽에 문제가 있는듯.

- 처리방법

- GoPro Fusion을 연결한뒤 Fusion Studio 실행. 아래와 같이... 여기서 왼쪽을 클릭하면 됨


- 이제 왼쪽에 리스트가 나타남. 여기에서 선택을 하고 [Add to Render Queue]를 눌러줌

- 선택끝나면 윗쪽에서 [RENDER(?)]를 누르고 아래쪽 [RENDER ALL]을 누르면 스티칭 완료.

- 사진 촬영 결과. 

- 다른 기종에 비해 아주 좋다고는 할 수 없으나, 깔끔한 편임. 

- 음성으로 촬영 가능. 하지만, 리모콘이 없다보니(앱이 설치되었다면...앱으로 제어가능 했을 듯.) 소리를 지를 수도 없고... 사진 타이머 촬영이 불가능해서 멀리 떨어져서 촬영하려면 애로가 있을 듯.

- 좌측우측 사진이 따로 따로 저장됨(별도의 SD 카드에 저장됨. 각각 Fusion Back, Fusion Front로 나타남). 별도의 스티칭 프로그램 사용한다면 맞는 걸 찾아서 넣어주어야 하기때문에 어려울 수 있음. 하지만, 고프로를 PC에 연결하면 Fusion Studio가 자동 작동되고, 고프로에서 촬영된 사진을 선택하면 직접 처리할 수 있어서 일반적으로는 어려울 이유가 없음.

- 처리된 비디오의 크기가 엄청나게 커짐. 원래 촬영한 원본은 각각 200MB 정도였는데, 처리 완료후 생성된 비디오는 2GB가 넘음. 5배 정도 커진 것. 이유를 모르겠음.

- 비디오의 품질은 타의 추종을 불허하는 정도. 해상도도 뛰어나고 색감도 좋음.

- 특히 Stabilizer의 위력이 대단함. 거의 자이로를 사용한 것 같은 느낌. (Stabilizer 적용모드에 2가지가 있는데, Full Stabilization으로 적용하면 카메라 방향이 항상 동일한 방향으로 유지되고,  Anti-shake를 적용하면 카메라를 기울였을 때 화면이 수평을 보지 못하는 문제가 있었음) 

Gear 360 2017

- 사용방법은 이전 글 참조 : 2016/2017버전은 거의 동일함

- 앱을 사용하여 제어 가능. 별도의 리모콘으로도 제어 가능.

- 사진 품질은 별로 좋지 않은 편임.

- 비디오 품질도 그냥 그런 정도. Stabilizer가 있다고는 되어 있으나, 별로 잘 적용된다는 느낌은 없었음.

- 최대해상도(4096x2048)일 때 24fps뿐이 안되는 것이 영향을 미쳤을 수도 있음.

- 라이브 스트리밍이 가능하다는 점 외에는 별로 2016버전보다 좋다는 느낌은 없었음.

- 다른 기기들보다, 핸드폰용 앱은 아주 좋은 편임. 특히 기기를 켜기만하면 핸폰에서 인식을 하여 자동으로 연결시켜주므로, 매우 편리함. (그래서 다른 기기들에는 앱이 안돌아가는 걸까?) 다만 갤러리 상태에서 기존 사진 리스트를 불러오는 시간이 너무 길어서 짜증스러움.

- 데스크탑용 프로그램은 ActionDirector라고 CyberLink라는 회사에서 제작한 프로그램을 사용하는데, 원래 비디오 편집용 프로그램이라서 360VR을 위한 최적화된 프로그램이 아니며 산만해 보임.

- 공유 플랫폼이라고 제작한 samsungvr.com은 거의 버려진 자식느낌.

Gear 360 2016

- 사용방법은 이전 글 참조 : 2016/2017버전은 거의 동일함

- 화질은 과하게 Sharpening을 한 느낌. 잡음이 무척 많음

- 화질이 그렇게 떨어진다는 느낌은 아님. 

- 그러나 Stabilization 기능이 전혀 없어서 비디오 보기는 불편함.

리코 쎄타 S

- Ricoh Theta S 앱을 사용하여 연결. Wifi로 연결하는데, 매번 기계를 켤 때마다 Wifi 설정을 바꿔주어야 해서 매우 불편함.

- 촬영하자마자 스티칭되어(기계에서) 스마트폰으로 전송됨. 전송되는 시간이 조금 걸리는 편(10초 정도) 성능이 떨어지는 기기에서 스티칭하기 때문에 발생하는 문제로 보임.

- 기기를 PC에 직접 연결해보면 촬영 원본은 없고 스티칭이 되어 있는 사진만 있음. (단, 비디오는 스티칭 되어 있지 않음)

- 따라서 앱을 연결하지 않고 기계만으로 촬영하려면, 셀프타이머 촬영이나 리모콘이 필요함. 

- 사진품질은 거기서 거기 정도.

- 앱에서 비디오를 다운로드 받고 스티칭하는 속도는 평균적인 정도임. 

- PC용 스티칭 프로그램은 가장 사용하기 편함. 그냥 사진/비디오를 끌어다 놓으면 됨.

- 비디오 품질은 예상처럼 가장 안좋음. 해상도가 너무 낮으며, Stabilization 기능이 없음.

- 데스크탑용 프로그램은 가장 편하다는데 직접해보지는 않았음. 특히, 방향 편집이 편하다고.

- 사진/비디오 공유사이트는 가장 편함. 현재도 잘 유지되고 있음. 

LG 360캠

- LG 360 캠 매니저 을 설치하여 사용. 기기에 전원을 넣고 앱을 실행하면 Wifi 를 자동으로 잡아주어 사용하기 어렵지 않음.

- 앱에서 다운로드/스티치. 속도는 평균정도.

- 사진품질은 비슷비슷

- 비디오 품질은 그냥 별로... Stabilzation 기능 없어서 불편.

샤오미 Mi Sphere

- 매뉴얼은 여기

- Mi Sphere Camera 앱을 설치하여 사용

- 사진 품질은 그냥 그런 정도.

- 비디오 다운로드가 아주 불편함. 폰으로 다운로드 받으면 완료되는 게 아니라, 설정을 바꾼 후 (Gyro Stabiliztion 등) Export 를 눌러주어야 함. More(...)를 눌러야 하기 때문에 어디에 위치하는지 알기 힘듦

- 한번 다운로드 받으면 이미 다운로드 받았다고 나옴. Export도 마찬가지.

- Full 해상도로 다운로드 되지 않음. 저장된 당시에는 210MB였으나, Export를 시키면 10MB(1440x720)로 줄어들고, 해상도가 으로 줄어듦. 

- 그래서 결국 PC용 스티칭 프로그램을 설치하여 작업함.

- 처리 속도가 매우 느림. (고프로 퓨전 스튜디오 작업에 비해 3-5배 정도 걸림)

- 비디오 품질은 별로 좋지 않은 편. 

- Stabilizer 가 적용되었으나, 흔들림이 많이 남아 있음.

샤오이 Yi 360 VR

- Yi 360을 설치하여 사용. 사용하기 편리. Wifi에 자동 접속해줌.

- 사진은 별도의 작업없이 기기에서 직접 스티칭됨

- 사진품질은 비슷비슷

- 비디오 촬영시에도 실시간 스티칭이 지원됨. (단, 3840x1920까지 지원) 최대해상도로 촬영을 위해서는 실시간 스티칭을 꺼야 함.

- 데스크탑용 앱은 직관적. 바로 Drag/Drop 한 뒤 Stitch를 눌러주면 됨. 

- 화질은 좋은 편. 

- PC용 스티칭 소프트웨어의 속도가 아주 느림. Stabilize 모드 적용여부를 선택할 수 있음.

- 아래는 Stabilize(EIS) 모드 적용한 버전. 맨 마지막에 한바퀴 돌았는데도 동일한 방향을 유지하고 있음. (이건 Gopro Fusion에서 Full Stabilization 을 적용한 것과 동일)

- 그런데... 데스크탑 버전에서 스티칭을 해보면 속도가 너무 느림. 테스트해본 기기중 가장 느린 듯. (샤오미 Mi Sphere 도 만만치 않게 느림) 스티칭을 할 때 영상매칭까지 고려한다면 이해가 안되는 건 아니지만, 그런지 아닌지는 아무런 근거가 없음)

===

아래는 4개의 비디오를 비교해 본 것입니다. 좌측아래 GoPro Fusion 이 제일 품질이 좋고... 시계방향으로 Yi 360VR, Gear360 2016, Gear360 1017 순서로 품질이 좋은 것 같습니다. (LG 360CAM과 Ricoh Theta S는 의미가 없어서 생략했습니다.)

이 그림 한장으로 비교하기는 힘들겠지만, 전체적으로 비디오의 품질은 고프로가 확실히 뛰어납니다. 색감도 괜찮고요. (색감은 촬영조건에 따라 달라질 수 있습니다.) 

Ricoh Theta S나 LG 360CAM 의 경우엔 해상도가 너무 낮아서 비교하기도 민망할 정도이지만, 다른 종류들은 거의 비슷비슷한 것 같습니다. 

이에 비해, 사진의 품질은 정말로 비슷합니다. 해상도만으로는 Ricoh Theta S 가 제일 낮고(15M(5376 x 2688), Gear 360 2016이 가장 좋은데(30M(7776x3888)) Resolution Chart상으로는 별로 차이가 많지 않은 것 같습니다. (다만 Gear360 2016은 해상도가 높고 구분도 잘되긴 하지만, 과하게 Sharpening을 적용한 것 같은 느낌이라서... 아마도 다른 사진들도 Sharpening을 더 적용하면 나아질 것 같아서 비슷하다고 말씀드렸습니다.)

전반적으로 볼때... 제가 테스트해본 느낌으로는 아직 360VR이 보편화되기는 힘들겠다는 생각입니다. 일단 기기 자체도 만만치 않게 비싼데다가(GoPro Fusion은 80만원대이고, 왠만한 제품들은 다 40만원대) 앱과 데스크탑처리 소프트웨어, 그리고 공유플랫폼 등이 (제품에 따라 다르기는 하지만,) 아직 정말 누구나 편하게 사용할 수 있는 정도는 아닙니다. 아니 아직도 너무 복잡한 것 같다는 게 결론입니다.

그리고 만약 360VR에 관심이 있다면, 현재 10만원대 이하로 구입할 수 있는 Gear360 2016버전이 꽤 괜찮은 선택이라는 생각도 드네요. 데스크탑용 처리소프트웨어와 공유플랫폼은 엉망이지만요.

좀 더 쉽게 접근할 수 있을 때가 오겠죠. 다음번 물결에는. ㅎㅎ

민, 푸른하늘

Posted by 푸른하늘 푸른하늘이

댓글을 달아 주세요

공간정보/표준2018. 3. 30. 23:07

Aaron Skonnard

DevelopMentor

May 2003

Summary : XML Schema 정의 언어(XSD)는 include와 import와 같은 포함 메커니즘을 통해 코어 라이브러리의 재사용 및 장기 관리를 가능하게 한다. 아울러 스키마 정의를 여러개의 파일 및 네임스페이스로 분할하여 관리할 수 있다. 오늘날 사용되는 프로그래밍 언어 방식의 유형 계층을 모델링할 수 있는 스키마 라이브러리의 설계방법에 대해 배워보자.

개요

XML Schema 정의 언어(XSD)는 XML 문서를 설명하는 언어중 대세가 되고 있다. XML Schema는 simple 및 complex 유형을 정의할 수 있다. Simple 유형은 문자만의 요소/속성에 맞춤식 값공간을 정의할 수 있으며, Complex 유형은 이러한 값 공간을 배열하여 구조체를 만들수 있다. XML 스키마는 매우 표현이 뛰어나고 XML 기반 응용에 강력한 서비스를 제공할 수 있다. 특히 웹 서비스 도메인에 유용하다. 이러한 서비스로는 검증, reflection, 자동 직렬화(type mapping) 원격 메소드 발동 등이 지원되며, XML을 위한 IntelliSense와 같은 기능을 잘 지원해줄 수 있다.

나의 첫번째 글 XML Schema의 이해에서는 핵심적인 XSD 언어 구성과 사용법에 대해 다루었다. XSD는 사실 이 글에서 다루었던 것 보다 훨씬 더 강력한 기능을 제공한다. Complex 유형 정의에서는 확장이나 제한을 사용한 유도 유형을 지원함으로써, complex 유형 계층을 정의할 수 있다. complex 유형 계층이 있으면, 인스턴스 문서에서 대체 기법을 사용할 수 있게 된다. XSD는 또한 schema 정의를 여러개의 파일과 네임스페이스로 분할 한 뒤, include 혹은 import 하는 방법을 사용함으로써, 재사용과 간편한 유지보수를 가능하게 한다. 이러한 좀더 고급 설계중심의 주제가 이 글의 주제이다.

유형 계층 (Type Hierarchies)

XML Schema의 이해에서 XSD에 내장된 simple 데이터 유형의 종류를 보였다. (그림 1) 이들 데이터유형은 유형 계층으로 정의된다. 그림 1에서 화살표는 제한에 의한 유도(derivation by restriction)를 나타낸다. 즉, byte는 short을 제한함으로서 유도되는데, 이는 byte의 값공간이 short의 값공간의 부분집합이라는 의미이다. 이러한 계층성을 유형간의 관계로 생각할 수 있다. 예를 들어, 제한에 의한 유도를 사용할 때, 유도된 유형의 인스턴스는 기반 유형의 인스턴스이기도 하다는 뜻이다. (즉, byte는 short의 일종이며, short은 int의, int는 long의 일종 등등이다.)


<그림 1> XSD 내장 데이터유형

XSD를 사용하면 이 계층을 확장하여 맞춤형 simple 유형을 정의할 수 있다. 새로운 simple 유형을 정의할 때, 기본적으로 내장 데이터유형으로부터 유도된 새로운 유형을 정의하고, 하나 이상의 facet을 제한하게 된다. 다음의 예에서 tns:PersonAge 는 xsd:byte로부터 유도하여, 값공간을 0에서 100까지로 제한한다.

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
   xmlns:tns="http://example.org/person"
   targetNamespace="http://example.org/person">
   ...
   <xsd:simpleType name="PersonAge">
      <xsd:restriction base="xsd:byte">
         <xsd:minInclusive value="0"/>
         <xsd:maxInclusive value="100"/>
      </xsd:restriction>
   </xsd:simpleType>
   ...
</xsd:schema>

이제 tns:PersonAge 와 xsd:byte 사이에는 유형 관계가 있다. tns-PersonAge는 xsd:byte의 유효한 인스턴스이기도 하며, xsd:byte는 xsd:short 의 유효한 인스턴스이고, xsd:short는 xsd:int의 유효한 인스턴스인다. 이러한 관계는 제한을 통한 유도 유형에서는 항상 성립한다. Simple 유형의 제한에 관한 자세한 내용은 XML Schema의 이해를 참고하라.

Complex 유형의 경우, 위의 예에서 보인 것처럼 유형 계층을 정의할 때 제한 혹은 확장에 의하여 유형을 유도할 수 있다. 하지만, 제한과 확장을 동시에 적용할 수 없다. 하나의 유형정의에서는 제한과 확장 두가지 중 하나만 사용하여 유도할 수 있다. 따라서 기본 유형을 제한하고 확장하고 싶다면, 두번을 별도로 유형 정의해야 한다.

제한에 의한 Complex 유형 유도

Simple 유형과 마찬가지로, 제한에 의하여 Complex 유형을 유도할 수 있다. 이는 기존의 Complex 유형으로부터 그 구조체를 형성하는 요소나 속성을 제한함으로써 새로운 Complex 유형을 유도할 수 있다는 것이다. 예를 들어, 사람을 표현하는 아래의 Complex 유형을 살펴보자.

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
   xmlns:tns="http://example.org/person"
   targetNamespace="http://example.org/person">
   ...
   <xsd:complexType name="Person">
      <xsd:sequence>
         <xsd:element name="name" type="xsd:string"/>
         <xsd:element name="age" type="xsd:byte " minOccurs="0"/>
         <xsd:element name="phone" type="xsd:string" minOccurs="1" maxOccurs="5"/>
      </xsd:sequence>
      <xsd:attribute name="id" type="xsd:string "/>
   </xsd:complexType>
   <xsd:element name="person" type="tns:Person"/>
   ...
</xsd:schema>

다음의 XML 문서는 tns:Person 유형의 유효한 인스턴스를 담고 있다. 참고로 로컬 요소 및 속성은 정규화되어 있지 않다. (로컬 요소와 속성은 기본이 비정규화(unqualified)임) 또한 age 요소는 생략되어 있으며, phone 요소는 세번 들어가 있다. 이는 모두 유형 정의에서 허용된 것이다.

<tns:person xmlns:tns="http://example.org/person"
   id="333-22-4444">
   <name>Bob Smith</name>
   <phone>801-444-5555</phone>
   <phone>801-555-6666</phone>
   <phone>801-666-7777</phone>   
</tns:person>

만약 tns:PersonType을 구성하는 일부 요소 및 속성을 제한하려고 한다면, xsd:complexContent와 xsd:restriction 요소를 사용하여, 제한(restriction)에 의한 새로운 complex 유형을 유도할 수 있다.

...
<xsd:complexType name="RestrictedPerson">
   <xsd:complexContent>
      <xsd:restriction base="tns:Person">
        <!-- redefine base type's particles here -->
        ...
      </xsd:restriction>
   </xsd:complexContent>
</xsd:complexType>
...

xsd:complexContent 요소는 해당 complex 유형이 다른 complex 유형으로 유도된 것을 나타낸다. xsd:restriction 요소는 원래 제한하기 전의 기본 유형과, 모든 기본 유형(base type)의 particle(compositor, 요소 정의, wildcard 등)에 대한 새로운 정의를 포함한다. 이렇게 할 때에는 반드시 기본유형의 모든 particle을 나열해야 하며, 기본유형의 부모가 있을 경우, 해당 내용도 포함시켜야 한다.

기본유형은 두가지 방법으로 제한할 수 있다. 한가지는 값공간을 더 좁게 제한하는 것. 또다른 하나는 particle의 출현빈도(occurrence constraint)를 강하게하는 것이다. "값공간을 좁계"하는 것은 기본 유형에서 사용된 simple 유형으로부터 유도된 다른 유형으로 유형을 변경하면 된다. 예를 들어, tns:PersonType에서 age 요소는 xsd:byte 유형이다. age 요소의 유형을 tns:PersonAge으로 변경하면 age의 값 공간을 더 제한할 수 있다.

base 유형의 출현빈도 제한을 더 강하게 지정하는 방식으로 제한할 수도 있다. "강한 출현빈도 제한"이란, 새로운 출현빈도 제한이 기본유형의 출현빈도 제한 범위이내에 한다는 것을 의미한다. 예를 들어, 위의 phone 요소는 최소 1번에서 최대 5번 등장할 수 있다고 정의되어 있다. 유도 유형에서 이 요소를 제한 할 때, phone 요소의 minOccurs를 1보다 작게하거나, maxOccurs를 5보다 크게 바꿀 수는 없다. 하지만, 아래처럼 두면 해당요소가 반드시 2번 나타나도록 횟수제한을 강하게 하고 있다. (여전히 기본 유형의 횟수제한에 유효하다)

...
   <xsd:element name="phone" type="xsd:string"
                minOccurs="2" maxOccurs="2"/>
...

이러한 방식으로 작동되므로, 어떤 요소가 기본 유형에서 필수로 정의되어 있다면(name, phone 등), 유도 유형에서는 이를 삭제시킬 수 없다. (참고 : minOccus 와 maxOccurs의 기본값은 1이다) 하지만, 기본 유형에서 선택적 요소인 경우(age), maxOccurs=0으로 두어 출현하지 못하도록 막거나, minOccurs=1로 두어 필수 요소로 만들 수 있다. 여기에서도, 유도 유형의 횟수제한은 기본유형에서 정의된 범위 내에 있을 때만 적법하다.

속성에서도 이와 동일하다. 속성이 기본유형에서 선택적일 경우(기본값임), 필수로 만들거나, 금지시킬 수 있다.('prohibited'는 제한에서만 적용되며, 그렇지 않은 경우 무시됨) 예를 들어 다음의 속성 정의는 유도 유형에서 id 속성을 금지시키는 방법을 나타낸다.

...
<xsd:attribute name="id" type="xsd:string" use="prohibited" />
...

이제 제한된 complex 유형의 완전한 예를 살펴보자, 아래의 예제는 xsd:string을 pattern facet으로 제한한 새로운 simple 유형을 정의하고 있다. 이들 유형은 base 유형에 사용되는 일부 요소및 속성 정의를 제한하는데 사용된다. 아울러 여러 요소 및 속성 선언의 횟수제한을 제한하고 있다.

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
   xmlns:tns="http://example.org/person"
   targetNamespace="http://example.org/person">
   <xsd:simpleType name="PersonAge">
      <xsd:restriction base="xsd:byte">
         <xsd:minInclusive value="0"/>
         <xsd:maxInclusive value="100"/>
      </xsd:restriction>
   </xsd:simpleType>

   <xsd:simpleType name="Phone">
      <xsd:restriction base="xsd:string">
         <xsd:pattern value="\d{3}-\d{3}-\d{4}"/>
      </xsd:restriction>
   </xsd:simpleType>

   <xsd:complexType name="Person">
      <xsd:sequence>
         <xsd:element name="name" type="xsd:string"/>
         <xsd:element name="age" type="xsd:byte " minOccurs="0"/>
         <xsd:element name="phone" type="xsd:string"
                      minOccurs="1" maxOccurs="5"/>
      </xsd:sequence>
      <xsd:attribute name="id" type="xsd:string "/>
   </xsd:complexType>

  <xsd:complexType name="RestrictedPerson">
      <xsd:complexContent>
         <xsd:restriction base="tns:Person">
            <!-- redefine base particles here -->
            <xsd:sequence>
               <xsd:element name="name" type="xsd:string"/>
               <xsd:element name="age" type="tns:PersonAge" 
                            minOccurs="1"/>
               <xsd:element name="phone" type="tns:Phone"
                            minOccurs="1" maxOccurs="1"/>
            </xsd:sequence>
           <xsd:attribute name="id" use="prohibited" />
         </xsd:restriction>
      </xsd:complexContent>
   </xsd:complexType>

   <xsd:element name="person" type="tns:Person"/>
   <xsd:element name="resPerson" type="tns:RestrictedPerson"/>
...
</xsd:schema>

이 예에서 우리는 새롭게 정의한 simple 유형(tns:PersonAge와 tns:Phone)을 사용하여 age와 phone 요소의 값공간을 제한하였다. 아울러 age 요소에 대해 횟수제한을 강화하였다. (이제 필수요소가 됨) phone 요소는 이제 정확하게 한번만 출현해야 하고, id 속성의 경우 선택적이 아니라 금지되었다. 아래의 문서는 tns:RestrictedPerson의 유효한 인스턴스를 담고 있다.

<tns:resPerson xmlns:tns="http://example.org/person">
   <name>Bob Smith</name>
   <age>33</age>
   <phone>333-333-4444</phone>
</tns:resPerson>

이 새로운 유형의 모든 측면은 기본 유형을 제한한 것이므로, tns:RestrictedPerson의 유효한 인스턴스는 tns:Person의 유효한 인스턴스이기도 하다. 그러나 그 반대는 참이 아니다. tns:Person의 유효한 인스턴스라고 하여 반드시 tns:RestrictedPerson의 유효한 인스턴스는 아니다.

확장에 의한 Complex 유형 정의

제한에 의한 유도가 중요하고, XML 스키마의 핵심요소이기는 하지만, 대부분의 프로그래밍 언어에서는 지원되지 않는다. 따라서, 스키마 정의를 프로그램 유형으로 매핑할 때, 마지막 예제에 있는 대부분은 프로그램의 클래스로 자연스럽게 변환되지 않는다. 하지만 확장에 의한 유도는 대부분의 객체지형 프로그래밍 언어에서 상당히 널리 사용되며, XSD에서도 지원된다.

Complex 유형만이 확장에 의한 유도가 지원된다. (즉, 기존의 simple 유형을 확장하여 새로운 simple 유형을 만드는 것은 불가능하다.) 하지만, 기존의 simple 유형 또는 complex 유형을 확장하여 새로운 complex 유형을 유도할 수 있다. 어느 유형으로부터 유도하는지는 xsd:simpleContent 또는 xsd:complexContent 요소를 사용하여 지정하며, xsd:extension을 중첩사용하여, 확장에 의한 유도를 표시한다.

simple 유형으로부터 확장에 의한 유도를 할 때에는, 새로운 유형에 속성 만 추가할 수 있다. (요소를 추가하면 더이상 simple 유형이 아니다.) 다음의 예는 기존의 simple 유형인 tns:Phone 으로부터 속성을 추가하여 새로운 complex 유형인 tns:PhoneWithLabel을 정의하는 방법을 나타낸다.

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
   xmlns:tns="http://example.org/person"
   targetNamespace="http://example.org/person">
...
   <xsd:simpleType name="Phone">
      <xsd:restriction base="xsd:string">
         <xsd:pattern value="\d{3}-\d{3}-\d{4}"/>
      </xsd:restriction>
   </xsd:simpleType>
   <xsd:complexType name="PhoneWithLabel">
      <xsd:simpleContent>
         <xsd:extension base="tns:Phone">
           <!-- add attributes here -->
           <xsd:attribute name="label" type="xsd:string" use="required" />
         </xsd:extension>
      </xsd:simpleContent>
   </xsd:complexType>
   <xsd:element name="phone" type="tns:PhoneWithLabel"/>
...
</xsd:schema>

xsd:simpleContent는 xsd:complexType의 자식으로서 나타난다. 이는 새로운 유형의 내용이 character 데이터만 있고 다른 child 요소가 없음을 표시한다. 이 경우, 유형에 속성을 추가만 했으며, 이로 인해 새로운 유형은 complex 유형이 되었다. (simple 유형은 어떠한 구조도 가질 수 없다. 속성조차). 아래는 tns:PhoneWithLabel 의 유효한 인스턴스이다.

<tns:phone xmlns:tns="http://example.org/person"
   label="mobile">333-333-4444</tns:phone>

이미 존재하는 complex 유형으로부터 확장하는 것도 동일한 방법으로 가능하다. 다만, xsd:complexContent를 사용하여, 새로운 유형의 내용에 character 데이터 외에도 다른 내용(예를 들어 추가적인 child 요소)이 존재함을 표시한다. 아래의 예는 tns:Person으로부터 새로운 complex 유형을 유도하는 방법을 나타낸다.

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
   xmlns:tns="http://example.org/person"
   targetNamespace="http://example.org/person">
...
   <xsd:complexType name="Person">
      <xsd:sequence>
         <xsd:element name="name" type="xsd:string"/>
         <xsd:element name="age" type="xsd:byte "  minOccurs="0"/>
         <xsd:element name="phone" type="xsd:string"  minOccurs="1" maxOccurs="5"/>
      </xsd:sequence>
      <xsd:attribute name="id" type="xsd:string "/>
   </xsd:complexType>

   <xsd:element name="person" type="tns:Person"/>

   <xsd:complexType name="ExtendedPerson">
      <xsd:complexContent>
         <xsd:extension base="tns:Person">
            <xsd:sequence>
               <xsd:element name="sex" type="xsd:string"/>
               <xsd:element name="weight" type="xsd:double"/>
               <xsd:element name="height" type="xsd:double"/>
            </xsd:sequence>
         </xsd:extension>
      </xsd:complexContent>
   </xsd:complexType>
...
</xsd:schema>

확장에 의하여 유도할 때에는 base 유형에 어떠한 변화도 만들 수 없다. base 유형에 새로운 particle을 추가하는 것만 가능하다. base 유형을 변경시킬 수 없으므로, 제한에 의한 유도에서처럼 particle을 재정의 할 필요가 없다. 그 대신, 그냥 새로운 내용을 정의하면 base 유형의 내용의 뒤에 추가된다. 새로운 내용은 논리적으로 base 유형 내용의 뒤에 추가되어, 아래와 같이 마치 두개의 내용 모델이 하나의 xsd:sequence 요소 내에 둘러싸여진 것처럼 작동된다. 

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
   xmlns:tns="http://example.org/person"
   targetNamespace="http://example.org/person">
...
   <!-- the logical content model of the derived type -->
   <xsd:complexType name="ExtendedPerson">
      <xsd:sequence>
         <!-- base type's content model -->
         <xsd:sequence>
            <xsd:element name="name" type="xsd:string"/>
            <xsd:element name="age" type="xsd:byte " minOccurs="0"/>
            <xsd:element name="phone" type="xsd:string" minOccurs="1" maxOccurs="5"/>
         </xsd:sequence>
         <!-- derived type's content model -->
         <xsd:sequence>
            <xsd:element name="sex" type="xsd:string"/>
            <xsd:element name="weight" type="xsd:double"/>
            <xsd:element name="height" type="xsd:double"/>
         </xsd:sequence>
         <xsd:attribute name="id" type="xsd:string "/>
      </xsd:sequence>
   </xsd:complexType>
...
</xsd:schema>

다음은 tns:ExtentedPerson의 유효한 인스턴스의 예이다.

<tns:extPerson xmlns:tns="http://example.org/person"  id="333-22-4444">
   <name>Bob Smith</name>
   <phone>801-444-5555</phone>
   <phone>801-555-6666</phone>
   <phone>801-666-7777</phone>   
   <sex>M</sex>
   <weight>175</weight>
   <height>72</height>
</tns:extPerson>

제한에 의한 유도와는 달리, 확장된 유형의 인스턴스는 base 유형의 유효한 인스턴스가 아닌 경우가 많다. 여기에서 보는 것처럼 tns:extPerson은 절대 tns:Person의 유효한 인스턴스가 아니다.

 There are a few restrictions to derivation by extension when it comes to xsd:all compositors. If a complex type uses xsd:all as its top-level compositor, you can't extend it by adding new particles—you can only add attributes in this case. Also, you can't extend another complex type with an xsd:all unless it has an empty content model. 확장에 의한 유도에서 xsd:all compositor를 사용할 때에는 몇가지 제한이 있다. complex 유형이 최상위 compositor로서 xsd:all을 사용하면, 새로운 particle을 추가하는 방식으로 확장할 수 없다. - 이 경우에는 속성 추가만 가능하다. 또한, xsd:all이 있는 complex 유형은 내용모델이 비어있지(empty) 않는한 확장할 수 없다.

유도 방지(Blocking Derivation)

'봉인(sealed)' 클래스 정의와 비슷하게, 특정한 유형으로부터 새로운 유도를 방지하고자 할 경우가 있다. XSD에서는 xsd:complexType에 final 속성을 통하여 가능하다. (참고로, substitution 구릅을 사용할 때 요소선언에서 final 속성을 사용할 수도 있다.) final을 사용하면, 특정유형으로부터 유도 메커니즘이 금지된다. final 속성의 값은, extension, restriction, #all 등 세가지이다. 예를 들어, 다음의 complex 유형 정의는 tns:Person 기본유형으로부터 제한에 의한 유도 및 확장에 의한 유도 모두를 금지한다.

...
   <xsd:complexType name="Person" final="#all">
      ... <!-- omitted for brevity -->
   </xsd:complexType>
...

아래의 예와 같이 xsd:schema에 finalDefault 속성을 사용하면, 스키마 전체에서 final 속성을 기본값으로 지정할 수 있다.

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
   xmlns:tns="http://example.org/person"
   targetNamespace="http://example.org/person"
   finalDefault="restriction">
...


이렇게 하면 기본값으로, complex 유형간에서 제한에 의한 유도가 허용되지 않는다. 위에서 보인 final 속성을 사용하여 이 설정을 덮어씌워야만 변경이 가능하다.

추상 유형(Abstract Types)

대부분의 객체지향 언어에서는 추상 유형을 정의할 수 있다. 이 문맥에서 추상유형이란 인스턴스화 할 수 없는 것을 말한다. 추상 base 클래스와 추상 base 인터페이스가 이러한 유형의 예이다. One purpose of abstract types is to define a contract that other derived types will implement. 추상유형의 목적은 다른 유도 유형이 수행된다는 계약을 정의하는 것이다. This makes it possible to build applications around abstract interfaces, supporting numerous possible implementations. The assumption is that some derived type will be substituted for the abstract type at runtime. 

아울러 XSD는 추상 complex 유형을 정의할 수 있다. 아래와 같이 xsd:complexType 요소에 abstract 속성(boolean)을 사용하면 된다.

...
   <xsd:complexType name="Person" abstract="true">
      ... <!-- omitted for brevity -->
   </xsd:complexType>
...

이 속성의 기본값은 false로서, complex 유형은 구체적이라는 것이다. 추상 스키마 유형은 XML 인스턴스 문서에서 유형으로 나타날 수 없다는 것을 의미한다. 그대신 추상유형이 있어야 할 곳에 반드시 유도된 유형이 대체되어 나타나야 한다.

xsi:type을 사용한 대체(substitution)

유형계층을 정의하면 좋은 장점은 유도된 유형의 인스턴스를 대체할 수 있는 능력이다. 객체지향 기술에서 폴리모피즘과 같이, base 유형이 와야할 곳에 유도 유형을 대체할 수 있다. XML 문서에서 이를 실행할 수 있는 방법중 하나가 xsi:type을 사용하는 방법이다.

xsi:type을 사용하면 요소의 유형을 명시적으로 지정할 수 있다. 이렇게 함으로써 스키마에서 요소선언이 없을 경우에 조차, 어떤 요소가 특정 유형이라고 주장하는 것이 가능해진다. 이 속성은 유도된 유형의 인스턴스를 기반유형이 와야 할 곳에 사용할 때 가장 널리 사용된다. 이 경우, 스키마 프로세스는 xsi:type 속성에서 지정한 유형이 기대된 기반유형으로부터 유도되는 것을 보증한다. 예를 들어, 아래의 tns:Family라는 complex 유형 정의를 고려해 보자. 이 유형은 tns:Person 유형의 여러개의 person 요소 목록을 포함하고 있다. 

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
   xmlns:tns="http://example.org/person"
   targetNamespace="http://example.org/person">
...
   <xsd:complexType name="Family">
      <xsd:sequence>
         <xsd:element name="person" type="tns:Person"
                      maxOccurs="unbounded"/>
      </xsd:sequence>
   </xsd:complexType>
   <xsd:element name="family" type="tns:Family"/>
...
</xsd:schema>

아래의 문서는 tns:Family의 유효한 인스턴스를 담고 있다. 주목할 점은 tns:RestrictedPerson 과 tns:ExtendedPerson 의 인스턴스가 tns:Person의 인스턴스가 와야할 곳에 대체되었다는 점이다.

<tns:family xmlns:tns="http://example.org/person"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema">
   <person id="333-22-4444">
      <name>Bob Smith</name>
      <phone>801-444-5555</phone>
      <phone>801-444-6666</pho