지리정보를 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)은 어떤 패키지의 클래스가 다른 패키지에 있는 클래스를 필요로 함을 나타낸다. 이는 점선으로 표시하며, 꼬리쪽 패키지를 위해서 화살표 쪽에 있는 패키지가 필요함을 나타낸다.

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

연관관계

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

1.1.2 추상화 수준(Level of Abstraction)

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

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

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

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

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

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

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

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

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

다중언어 이름

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

예 : "Observation et Mesures"@fr

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

실세계 이름과 UML 이름

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

2.2.3 일반 - 정의

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

19103 규칙 및 권고사항

일반

Enumeration/codelist

Naming 과 네임스페이스

모델의 문서화 

10109 규칙 및 권고사항

응용스키마 문서화 

정의 작성 방법

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 와 같이 번호를 넣는다.

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

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

19136(부속서 E)의 tagged value

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 구현에서 두 클래스는 서로 참조를 가져야 한다.

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

역할명(role name)

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

위의 그림에서 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개의 차에 속해야 한다.

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

다중도를 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 네임스페이스의 연결

• 제약 https://github.com/ISO-TC211/UML-Best-Practices/wiki/Constraints
• OCL : INSPIRE Repository tutorial 10-11
• 표시방법 : INSPIRE Repository tutorial 14쪽

• 프로파일
• 기존 모델의 확장 또는 프로파일링 :

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 개념스키마 언어에는 다이어그램의 폰트 크기에 관한 추천사항이 하나 있다.

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

INSPIRE Repository tutorial 의 규약에 따르면

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

[[색]]

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

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

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

[[속성]]  

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

적을수록 좋다(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번째 규칙을 참조한 것이다.

상위 요소를 위쪽으로 배치

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

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

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

• 하위 클래스는 상위 클래스 아래에 위치시킨다.
• 집합 관계의 경우, 소유하는 측의 요소가 부분 요소의 아래로 내려가서는 안된다.
• 구현의 경우, 원 요소가 위에 있어야 한다.

크기를 조화롭게

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 작성방법]]

• INSPIRE Repository tuturial 10-11에는 OCL을 작성하는 방법에 관한 힌트가 있다.
• 과거 및 현재의 OCL 사양은 http://www.omg.org/spec/OCL/에서 볼 수 있다.
• OCL 작성을 위한 지침. CABOT, Jordi and GOGOLLA, Martin. Object Constraint Language (OCL): A Definitive Guide. In : Formal Methods for Model-Driven Engineering. Springer Berlin Heidelberg, 2012. p. 58–90. Lecture Notes in Computer Science.

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

제약을 구현에서 사용함에 있어, 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로 선택하라.

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

제약은 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. 모델문서화 링크)

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 Count subpackages.vbs - 선택된 패키지에서 1단계 하위 패키지 수 
• DOC Export diagrams as images.vbs - 다이어그램을 이미지 파일로 저장
• DOC Export mapping files.vbs - 태그값에 기반한 매핑 파일 내보내기
• DOC List prefixes.vbs - 클래스와 열거형을 위한 모든 접두사 목록

• 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 Add Subpackages.vbs - 버전 관리를 위한 패키지 추가
• VC Get All Lates.vbs - 선택된 패키지 및 하위패키지를 위한 모든 최신 것을 가져옴
• VC Resync Status.vbs - 버전 관리 청소 - 선택된 패키지 및 하위패키지를 루핑하면서 VC Provider에 상태를 다시 싱크함
• VC Remove Version Control.vbs - 버전 관리 제거. 선택된 패키지 및 하위패키지를 루핑하면서 버전 관리 제거

• HMMG Script
• Version Control Script

• 노르웨이 매핑기관의 스크립트 : https://github.com/kartverket/UML-modelleringsskript

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 새로운 검색 정의 생성

1. Edit - Find in Project (Ctrl-F 또는 Ctrl+Alt+A)
2. Builder 버튼을 클릭한다.
3. 새로운 검색 정의를 생성한다. 이름을 주고 Editor Type이 SQL Editor인지 확인한다.

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 문서를 참고하라. 핵심적인 스테레오타입 몇개를 소개하면 다음과 같다.

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

응용스키마 패키지는 반드시 하나이상의 하위 패키지를 가져야 하며, 이들 각각은 별도의 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

국가공간정보포털 지식공간의 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월호에 실린 글입니다. 아래는 뉴스레터를 캡처한 것입니다.

민, 푸른하늘

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

실행 규칙

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

메타데이터

데이터 사양

네트워크 서비스

데이터 및 서비스 공유

모니터링과 보고

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 지침 및 INSPIRE 실행 규칙 문서 그리고 이 교육 모듈에서 사용되는 공통 용어에 대한 일반적인 용어 및 정의를 담고 있다.

===

https://inspire.ec.europa.eu/about-inspire/563

며칠 전 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

장면 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개월 이상 걸릴 것으로 생각됩니다. 제가 지금까지 말씀드린 "데이터의 내용 및 구조"라고 통칭한 이러한 기술을 적용하여, 정말 실시간으로 데이터를 공유할 수 있는 날이 빨리 오기를 소망합니다.

민, 푸른하늘