8.유틸리티 패키지

📌 GeoAPI 유틸리티 패키지 개요
GeoAPI는 org.opengis.util 네임스페이스를 사용하여 ISO 19103:2005 (지리 정보 – 개념 스키마 언어) 에서
정의된 타입을 구현합니다.

기본 Java 언어 및 표준 Java 라이브러리에 존재하지 않는 타입을 제공
ISO 19100 시리즈의 UML 타입을 Java 타입으로 매핑하는 역할 수행

ISO 19103은 19100 시리즈의 기반이 되는 핵심 요소들을 정의
GeoAPI는 해당 요소를 Java의 기존 타입으로 매핑하거나, 필요 시 유틸리티 패키지에서 제공

📌 ISO 19103에서 정의한 주요 타입 카테고리
Primitive types (기본 타입) - §8.1.1
Collection 또는 Dictionary types (컬렉션 및 딕셔너리 타입) - §8.1.2
Enumerated types (열거형 타입) - §8.1.3
Representational types (표현 타입) - §8.1.4
Name types (이름 타입) - §8.1.5
Derived types (파생 타입) - §8.1.6

이러한 매핑은 완전히 1:1 대응이 아니며, 특정 필요성이 발생할 때 추가 구현됨


8.1 패키지 매핑 (Package Mapping)

📌 ISO 19103 타입을 Java 타입 및 GeoAPI 유틸리티 패키지로 매핑
➡ 아직 필요한 사례가 없는 타입들은 “unimplemented” 로 표시됨


8.1.1 기본 타입 (Primitive Types Mapping)

📌 ISO/OGC 명세에서 정의한 Primitive 타입을 GeoAPI에서 매핑하는 방식

Java 기본 타입이 존재하는 경우 (예: int, double) → Java 기본 타입을 선호
NULL 값이 필요한 경우 → 해당 기본 타입의 객체 래퍼(wrapper) 사용

📌 ISO 19103 타입과 GeoAPI 매핑 표

📷 첨부 이미지: Primitive Types Mapping 표

Table 1: Primitive Types Mapping

Type GroupISO 19103 TypeGeoAPI Type
NumericIntegerint / java.lang.Integer
long / java.lang.Long
UnlimitedIntegerunimplemented
Realdouble / java.lang.Double
Decimaljava.math.BigDecimal
Numberjava.lang.Number
Vectorunimplemented
TextCharacterStringjava.lang.String / org.opengis.util.InternationalString
Sequencejava.lang.CharSequence
Characterchar
CharacterSetCodeorg.opengis.metadata.identification.CharacterSet
LanguageCharacterStringunimplemented
Date and TimeDatejava.util.Date
Timejava.util.Date
TruthDateTimejava.util.Date
DatePrecisionunimplemented
Probabilityunimplemented
Booleanboolean / java.lang.Boolean
Logicalunimplemented
Truthunimplemented
DiscreteTruthunimplemented
ContinuousTruthunimplemented
MultiplicitiesMultiplicityunimplemented
MultiplicityRangeunimplemented
EnumerationsSignunimplemented
Digitunimplemented
Bitunimplemented

📌 아직 구현되지 않은 타입
ISO 19103의 여러 객체들은 다른 인터페이스 개발 과정에서 필요성이 없었기 때문에 아직 구현되지 않음
GeoAPI는 필요성이 발생할 경우 추가 구현을 고려


8.1.2 컬렉션 및 딕셔너리 타입 (Collection and Dictionary Types)

📌 GeoAPI의 컬렉션 타입 구현 방식
GeoAPI는 ISO 19103에서 정의한 컬렉션 타입을 Java 표준 컬렉션 프레임워크(Java Collections Framework)를 사용하여 구현합니다.

📌 주요 차이점
GeoAPI 컬렉션은 ISO 19103의 TransfiniteSet 인터페이스를 구현하지 않음

📌 ISO 19103 타입과 GeoAPI 매핑 표

Table 2: Collection and Dictionary Types Mapping

ISO 19103 TypeGeoAPI Type
Transfinite Setunimplemented
Collectionjava.util.Collection
Setjava.util.Set
Bagjava.util.Collection
Sequencejava.util.List
CircularSequenceunimplemented
Dictionaryjava.util.Map
KeyValuePairjava.util.Map.Entry

ISO 19103의 주요 컬렉션 타입 매핑
Collectionjava.util.Collection
Setjava.util.Set
Bagjava.util.Collection
Sequencejava.util.List

아직 구현되지 않은 타입
Transfinite Setunimplemented
CircularSequenceunimplemented

📌 딕셔너리 타입 매핑
Dictionaryjava.util.Map
KeyValuePairjava.util.Map.Entry

GeoAPI는 필요한 경우 추가적인 타입 구현을 고려할 예정


8.1.3 열거형 타입 (Enumerated Types)

📌 GeoAPI의 열거형 타입 구분
GeoAPI는 열거형 타입을 두 가지로 구분하여 처리합니다.

미리 정의된 상수 집합이 변경되지 않는 경우 → Java의 Enum 사용
런타임 또는 코드 확장에서 값이 추가될 가능성이 있는 경우 → GeoAPI의 CodeList 사용

📌 ISO 19103 타입과 GeoAPI 매핑 표

📷 첨부 이미지: Enumerated Types Mapping 표

ISO 19103 TypeGeoAPI Type
Enumerationjava.lang.Enum
CodeListorg.opengis.util.CodeList

ISO 19103의 주요 열거형 타입 매핑
Enumerationjava.lang.Enum
CodeListorg.opengis.util.CodeList

📌 차이점 요약

  • Enum고정된 값 집합 (컴파일 타임에 정의됨)
  • CodeList확장 가능한 값 집합 (런타임에 값 추가 가능)

GeoAPI는 두 가지 접근 방식을 활용하여 다양한 열거형 데이터를 유연하게 처리할 수 있도록 지원


8.1.4 표현 타입 (Representation Types)

📌 GeoAPI의 표현 타입 정의
GeoAPI는 ISO 19123에서 요구하는 핵심 표현 타입만을 최소한으로 정의합니다.
현재는 Coverage 패키지를 구현하는 데 필요한 타입만 포함됨

📌 ISO 19103 타입과 GeoAPI 매핑 표

📷 첨부 이미지: Representation Types Mapping 표

ISO 19103 TypeGeoAPI Type
SchemaUnimplemented
Anyjava.lang.Object
Typeorg.opengis.util.Type
RecordSchemaorg.opengis.util.RecordSchema
RecordTypeorg.opengis.util.RecordType
Recordorg.opengis.util.Record

ISO 19103의 주요 표현 타입 매핑
SchemaUnimplemented (아직 구현되지 않음)
Anyjava.lang.Object
Typeorg.opengis.util.Type
RecordSchemaorg.opengis.util.RecordSchema
RecordTypeorg.opengis.util.RecordType
Recordorg.opengis.util.Record

📌 현재 구현되지 않은 요소
Schema는 아직 GeoAPI에서 구현되지 않음

GeoAPI는 필요에 따라 추가적인 표현 타입을 구현할 예정


8.1.5 이름 타입 (Name Types)

📌 GeoAPI에서의 이름 타입 해석
ISO 19103에서 정의된 이름(Name) 타입에 대한 문서는 많지 않음.
➡ 현재 GeoAPI의 GenericName Javadoc에서 이에 대한 해석을 설명
🔗 참고 링크: GenericName Javadoc

📌 이름 시스템 해석의 핵심 요소
스코프(Scopes)와 네임스페이스(Namespaces)에 대한 해석 포함

📌 NameFactory
➡ GeoAPI에서 이름 타입 인스턴스를 생성할 수 있도록 설계된 확장 요소

📌 ISO 19103 타입과 GeoAPI 매핑 표

📷 첨부 이미지: Name Types Mapping 표

ISO 19103 TypeGeoAPI Type
(constructors)org.opengis.util.NameFactory
NameSpaceorg.opengis.util.NameSpace
GenericNameorg.opengis.util.GenericName
ScopedNameorg.opengis.util.ScopedName
LocalNameorg.opengis.util.LocalName
TypeNameorg.opengis.util.TypeName
MemberNameorg.opengis.util.MemberName

ISO 19103의 주요 이름 타입 매핑
(constructors)org.opengis.util.NameFactory
NameSpaceorg.opengis.util.NameSpace
GenericNameorg.opengis.util.GenericName
ScopedNameorg.opengis.util.ScopedName
LocalNameorg.opengis.util.LocalName
TypeNameorg.opengis.util.TypeName
MemberNameorg.opengis.util.MemberName

GeoAPI는 현재 해석 방식에 따라 이름 시스템을 구현 중이며, 필요에 따라 추가적인 문서화와 확장이 이루어질 예정


8.1.6 파생 타입 (Derived Types)

📌 GeoAPI에서의 파생 타입 처리
ISO 19103에서 정의된 파생 타입(Derived Types)은 대부분 단위(Units) 및 측정(Measurements)과 관련
GeoAPI는 JSR-363 표준에서 정의된 인터페이스를 사용하여 이를 처리

📌 UOMo 인터페이스
파라미터화된 타입(Parameterized Types)을 광범위하게 사용
특정 단위(Unit) 또는 측정(Measure) 타입을 명확하게 정의

📌 ISO 19103 타입과 GeoAPI 매핑 표

ISO 19103 TypeGeoAPI Type
Measurejavax.measure.Quantity
UnitOfMeasurejavax.measure.Unit<? extends Quantity>
Areajavax.measure.quantity.Area
UomAreajavax.measure.Unit<Area>
Lengthjavax.measure.quantity.Length
Distancejavax.measure.quantity.Length
UomLengthjavax.measure.Unit<Length>
Anglejavax.measure.quantity.Angle
UomAnglejavax.measure.Unit<Angle>
Scalejavax.measure.quantity.Dimensionless
UomScalejavax.measure.Unit<Dimensionless>
Timejavax.measure.quantity.Time
UomTimejavax.measure.Unit<Time>
Volumejavax.measure.quantity.Volume
UomVolumejavax.measure.Unit<Volume>
Velocityjavax.measure.quantity.Speed
UomVelocityjavax.measure.Unit<Speed>
AngularVelocityUnimplemented
UomAngularVelocityUnimplemented
NULLnull
EMPTYjava.util.Collections.EMPTY_SET

ISO 19103의 주요 파생 타입 매핑
Measurejavax.measure.Quantity
UnitOfMeasurejavax.measure.Unit<? extends Quantity>
Areajavax.measure.quantity.Area
UomAreajavax.measure.Unit<Area>
Lengthjavax.measure.quantity.Length
Distancejavax.measure.quantity.Length
UomLengthjavax.measure.Unit<Length>
Anglejavax.measure.quantity.Angle
UomAnglejavax.measure.Unit<Angle>
Scalejavax.measure.quantity.Dimensionless
UomScalejavax.measure.Unit<Dimensionless>
Timejavax.measure.quantity.Time
UomTimejavax.measure.Unit<Time>
Volumejavax.measure.quantity.Volume
UomVolumejavax.measure.Unit<Volume>
Velocityjavax.measure.quantity.Speed
UomVelocityjavax.measure.Unit<Speed>

📌 아직 구현되지 않은 요소
AngularVelocityUnimplemented
UomAngularVelocityUnimplemented


ISO NULL 및 EMPTY 값의 처리

📌 GeoAPI에서 ISO NULL 및 EMPTY 값 처리 방식
ISO NULL 값 → Java의 null 키워드를 사용하여 표현
ISO EMPTY 값 → Java 컬렉션 프레임워크의 EMPTY_SET 사용

📌 EMPTY_SET 사용 시 주의사항
Java 제네릭(Generic)의 타입 안정성을 유지하기 위해
java.util.Collections.emptySet() 메서드를 직접 호출하는 것이 권장됨
상수 EMPTY_SET를 직접 참조하는 것보다 컴파일 타임에 타입이 유지됨


8.2 유틸리티 타입의 사용 (Use of the Utility Types)

📌 GeoAPI 유틸리티 패키지의 타입 사용 방식
GeoAPI 유틸리티 패키지의 타입 사용 방식은 Java의 표준 관행을 따름


1. 다국어 문자열 처리 (InternationalString)

📌 org.opengis.util.InternationalString 인터페이스
여러 언어(Locale)로 동일한 텍스트를 저장할 수 있는 컨테이너 역할

📌 사용 예시

NameFactory factory = ...{Implementation dependent}  
Map<Locale, String> names = new HashMap<>();  
names.put(Locale.ENGLISH, "My documents");  
names.put(Locale.FRENCH, "Mes documents");  
InternationalString localized = factory.createInternationalString(names);  
System.out.println(localized);  
System.out.println(localized.toString(Locale.FRENCH));  

📌 주의사항
팩토리(NameFactory)를 얻는 방법은 표준에서 지정되지 않음라이브러리 구현 방식에 따라 다름
toString()의 기본 Locale은 구현에 따라 달라질 수 있음


2. 코드 리스트 (CodeList) 사용

📌 org.opengis.util.CodeList 활용
정적으로 정의된 요소 접근, 새로운 요소 정의, 기존 요소 검색 기능 제공

📌 사용 예시 (MediumName 예제)

MediumName cd = MediumName.CD_ROM;  
MediumName usbkey = MediumName.valueOf("USB_KEY");  

📌 주의사항
valueOf("USB_KEY")를 사용하면 해당 값이 없을 경우 새로 생성됨
일관되지 않은 문자열 사용 시 새로운 요소가 생성될 수 있음

❌ 예제: 잘못된 코드 사용

MediumName med = MediumName.valueOf("CDROM");  

위 코드는 기존의 CD_ROM 값과 다르게 인식되어 새 요소를 생성할 수 있음


3. 단위 변환 (javax.measure.Unit)

📌 JSR-363 (Units and Measures) 기반 단위 변환 예제
길이 단위를 변환하는 예제

📌 사용 예시

Unit<Length> sourceUnit = Units.MILE;  
Unit<Length> targetUnit = Units.KILOMETRE;  
UnitConverter converter = sourceUnit.getConverterTo(targetUnit);  
double source = 123.2;  
double target = converter.convert(source);  

📌 설명
Units.MILEUnits.KILOMETRE 변환을 위한 컨버터 생성
converter.convert(source)를 사용해 123.2 마일을 킬로미터로 변환

📌 주의사항
Units 클래스는 JSR-363 구현체에서 제공해야 함


8.3 ISO 19103과의 차이점 (Departure from ISO 19103)

📌 GeoAPI와 ISO 19103의 차이점 개요
GeoAPI는 ISO 19103에서 정의된 모든 타입을 제공하지 않음
아직 GeoAPI에서 구현된 다른 표준에서 필요로 하지 않는 요소들은 포함되지 않음


1. InternationalString 타입 확장

📌 GeoAPI의 InternationalString 타입은 Java의 CharSequence를 확장
국제화(i18n) 지원을 위해 여러 LocaleString을 저장할 수 있도록 설계
표준 Java 문자열(String) 대신 지역화된 문자열 저장 가능


2. NameFactory 타입 추가

📌 ISO 19103에서 정의된 Name 타입을 보완
GeoAPI의 NameFactory는 Name 객체를 생성하는 공식적인 방법 제공
ISO 19103에서는 객체 생성을 위한 구체적인 방법을 정의하지 않음


3. TransfiniteSet 미지원

📌 GeoAPI의 컬렉션 타입은 표준 Java 컬렉션 사용
ISO 19103에서 요구하는 TransfiniteSet을 확장하지 않음
대신 java.util.Collection 및 관련 인터페이스 (Set, List, Map) 사용

📌 이유
TransfiniteSet 개념은 일반적인 집합(Set)보다 기하학적(Geometric) 개념에 더 적합
GeoAPI는 현재 지리정보 처리에 초점을 맞추고 있어 일반적인 집합에서는 해당 개념을 사용하지 않음


📌 결론
✔ GeoAPI는 ISO 19103의 주요 개념을 따르되, 필요에 따라 일부 요소를 확장하거나 제외함
국제화, 이름 생성, 컬렉션 처리 방식에서 일부 차이를 가짐
TransfiniteSet은 일반 집합보다는 기하학적 연산에 적합하므로, GeoAPI에서는 일반 컬렉션을 유지


8.4 향후 개선 사항 (Future Improvements)

📌 GeoAPI 유틸리티 패키지 관련 향후 개선 사항
향후 GeoAPI 표준 개정에서 다음과 같은 개선이 예상됨


1. GenericName 시스템 개정 가능성

📌 이유
GenericName 시스템은 올바르게 해석하기 어려운 시스템으로 판명
보다 명확한 구조로 개정이 필요할 가능성 있음


2. Record 시스템 개정 가능성

📌 이유
Record 시스템이 아직 명확하지 않음
현재의 정의를 보다 구체적으로 다듬을 필요가 있을 가능성 존재


3. 날짜(Date) 요소 매핑 개선 가능성

📌 이유
Java 표준 라이브러리가 이미 세 번째 시간 관련 데이터 타입을 도입
캘린더 기반 시간 참조를 보다 편리하게 관리하는 새로운 기능이 추가될 가능성 있음

📌 향후 조정 가능성
기존 Date 요소가 새로운 Java 시간 API(java.time 패키지 등)로 변경될 가능성 있음
새로운 기능이 기존 기능보다 편리하다면, 표준 개정에서 이를 반영할 수 있음


📌 결론
GenericNameRecord 시스템의 개정이 논의될 가능성이 있음
✔ Java의 새로운 날짜 및 시간 관련 API가 기존 Date 기반 구조를 대체할 가능성 존재
향후 개정에서 이러한 변경 사항이 반영될 수 있음