이 글은 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) 정의를 비롯해 실시간 데이터 처리가 관계되므로 위상구조도 데이터로 보내는 것이 맞다고 봅니다.
===
이상입니다.
민, 푸른하늘