GIS Working History – 페이지 18

2012-01-252017-01-27

[GIS] PostGIS, 공간데이터 테이블 생성에 대한 SQL

진행하고 있는 프로젝트에서 사용하고 있는 공간 DBMS로 PostGIS를 사용하고 있습니다. 공간 테이블을 직접 만들어어 활용해야할 필요가 있어 찾은 내용을 정리해 봅니다.

고유한 ID 값으로써 fid와 기타 필드로써 name 그리고 Geometry 값에 대한 the_geom이라는 이름의 필드를 가지는 테이블을 생성하는 SQL 문의 예는 다음과 같습니다.

CREATE TABLE "tst_table"(
    fid INTEGER PRIMARY KEY,
    name VARCHAR(64),
    the_geom geometry,

    CONSTRAINT enforce_dims_the_geom CHECK (st_ndims(the_geom) = 2),

    CONSTRAINT enforce_geotype_the_geom CHECK 
            (geometrytype(the_geom) = 'MULTIPOLYGON'::text 
        OR 
            the_geom IS NULL),

    CONSTRAINT enforce_srid_the_geom CHECK (st_srid(the_geom) = (-1))
);

1번 줄에 생성할 테이블 명으로써 tst_Table로 지정했습니다. 2~4번 줄이 앞서 언급한 필드들이구요. 6번 줄은 Geometry에 대한 필드인 the_geom의 차원이 2차원, 즉 X와 Y의 쌍이어야 한다는 제약 조건입니다. 그리고 8번 줄의 제약 조건은 Geometry가 MULTIPOLYGON 타입이며 NULL 일 수 있다는 것 입니다. 그리고 13번 줄은 Geometry의 Spatial Reference ID에 대한 제약 조건입니다.

이제 아래는 앞서 생성한 공간 테이블에 하나의 레코도를 추가하는 SQL 문입니다.

INSERT INTO tst_Table 
 (
    fid, 
    name, 
    the_geom
) 
VALUES 
 (
    0, 
    '테스트', 
    ST_GeomFromText('MULTIPOLYGON(((0 0,1 0,1 1,0 1,0 0)))', -1)
);

일반적인 INSERT SQL 문입니다. 단지 주목해야할 줄은 11번입니다. Geometry에 대한 WKT 형식으로 지정했으며 공간참조로 -1을 주었습니다. 이 값은 앞서 공간 테이블을 생성할때 제약 조건과 일치합니다.

2012-01-162017-01-27

[GIS] 정규표현식(regex)를 이용한 WKT 파싱

또 다시 지오메트리에 대한 WKT 형식을 파싱해야할 상황이 생겼습니다. 예전엔 한땀.. 한땀.. -_-; 문자값 하나 하나를 파싱해서 좌표값을 뽑아 냈더랬습니다. 그런데.. 또 이짓을 해야한다고 생각하니.. 손과 뇌에 마비가 와 죽어도 못하겠더군요..

해서.. 뭔가 그럴듯한.. 세련된 방법이 없나.. 궁리를 하다가.. 정규표현식(Regular Expressions)를 이용해 보자라는 생각이 들었습니다. 예전에 정규표현식에 대해 살펴봤던 적이 있었는데.. 이런게 있구나 싶을 정도로만 봐두었던지라.. 떠올랐나봅니다.

실무에서 필요한 기술이라 생각되니.. 정규표현식을 사용하는 방법을 제법 집중해서 살펴보게 되었습니다.. 결국 원하는 결과를 얻어 냈습니다… 해서 정규표현식을 이용해 WKT 형식의 지오메트리의 좌표를 뽑아 내는 코드를 잠시 살펴보겠습니다.

대상이 되는 WKT는 다음과 같다고 하겠습니다.

POLYGON ((100 200, -200 300, -400 500), (10 20, -20 -30, 40 50), (1 2, 2 3, 4 5) )

예이므로 올바른 폴리곤은 아닙니다. 단지 WKT 형식이라는 점에만 유념해 주시면 됩니다. 이 WKT을 보면 폴리곤이 3개의 파트로 구성됩니다. 정규표현식을 이용해 3개의 파트에 대해 각 파트를 구성하는 좌표를 쭉… 뽑아내 보는 코드는 아래와 같습니다.

var wkt:String = 
    "POLYGON ((100 200, -200 300, -400 500), " + 
    "(10 20, -20 -30, 40 50), (1 2, 2 3, 4 5)) ";

var removePrefix:String = wkt.replace(/\bpolygon\b\s*\(/i, "");
var removePostfix:String = removePrefix.replace(/\s*\)\s*$/, "");
var parts:Array = removePostfix.match(/\(.*?\)/g);

for each(var part:String in parts)
{
    var vertices:Array = part.match(/[+-]?\d*(\.?\d+)/g);
    var cntVertices:uint = vertices.length;
    trace("\nPOLYGON VERTICES LIST");
    for(var iVertex:uint=0; iVertex    {
        var x:Number = vertices[iVertex];
        var y:Number = vertices[iVertex+1];
        trace("\tVERTEX: (" + x + "," + y + ")");
    }
}

실제 결과는 다음과 같습니다.

POLYGON VERTICES LIST
    VERTEX: (100,200)
    VERTEX: (-200,300)
    VERTEX: (-400,500)

POLYGON VERTICES LIST
    VERTEX: (10,20)
    VERTEX: (-20,-30)
    VERTEX: (40,50)

POLYGON VERTICES LIST
    VERTEX: (1,2)
    VERTEX: (2,3)
    VERTEX: (4,5)

정규표현식을 이제 막 익힌 제가 머리를 쥐어짜가며 구성한 코드입니다. 4개나 되는 정규표현식을 사용했습니다.. 정규표현식에 숙련된 자라면 휠씬 빠르고 적은 수의 표현식으로 동일한 결과를 얻어 낼 수 있을거라.. 생각해 봅니다.

아! 위의 코드는 예는 ActionScript입니다. 물론.. 정규표현식은 C#, JavaScript, C, PHP 등등 매우 많은 언어에서 사용할 수 있는 기능입니다. 각 언어에 따라 정규표현식에 대한 API가 다르지만 정규표현식 자체는 거의 동일합니다.

2011-11-242018-12-20

[GIS] BlackPoint-Xr, 갤럭시탭 10.1에서 테스트, 이상 무!

3주전인가.. 마침.. 갤럭시탭 10.1을 테스트할 수 있는 기회가 생겨서 기존에 블랙포인트로 개발된 데모 시스템 하나를 갤럭시탭 10.1에서 테스트해 보았습니다.

기존에 사용하는 테스트 디바이스의 경우, 화면 해상도도 작고.. 싱글 코어인 상황인지라.. 갤럭시탭 10.1의 더욱 커진 화면 해상도에 대한 메모리 사용에 대한 문제 발생 여부와 듀얼 코어에 대한 스레드 안정성에 대한 문제가 발생할 가능성이 있다고 판단되었지만.. 다행히도 두가지 문제점이 실제로 발생하지 않았습니다.

그러나 화면 해상도가 커짐에 따라 지도 표출 속도가 저하되는 문제가 발생했습니다. 몇가지 개선을 통해 속도를 향상시켜 놓았으나.. 좀 더 근본적으로 이 문제를 개선할 방안을 고민 중입니다. 현재로써는 SHP 파일을 바로 사용하는 방식인데… 이를 자체 포맷 형태로 변환해 사용하는 방식을 지원하는 것을 통해 속도를 개선시킬 계획입니다.

아래의 화면은 갤럭시탭 10.1에서 블랙포인트의 데모를 올려 실행시킨 화면에 대한 스크린샷입니다.

블랙포인트는 지오서비스(www.geoservice.co.kr)에서 개발된 안드로이드 기반의 GIS 맵 엔진입니다.

2011-06-222017-01-27

[GIS] 유용한 PostGIS의 SQL 문

geometry 필드를 가진 테이블이 구성하는 Row들이 구성하는 하나의 MBR을 얻는 쿼리문은 아래와 같으며 결과는 BOX(MinX MinY, MaxX MaxY) 형태입니다.

select ST_extent(the_geom) from public."tst_Table";

다음은 지정된 테이블의 스키마를 얻는 쿼리문입니다. attname은 필드명이며 atttypid는 필드타입에 대한 id 코드입니다. 그리고 atttypmod는 타입이 가변 길이 문자열(varchar type)일때 허용 최대 길이이며 실제보다 4만큼 더 크며 타입이 문자열이 아니면 -1입니다.

SELECT
    attname, atttypid, atttypmod
FROM 
    pg_attribute, pg_type
WHERE 
    typname = 'tst_Table' AND 
    attrelid = typrelid AND 
    attname NOT IN ('cmin', 'cmax', 'ctid', 'oid', 'tableoid', 'xmin', 'xmax');

atttypid에 대한 코드값에 해당하는 의미는 다음과 같습니다.

atttypid=16 : ‘boolean’
atttypid=17 : ‘bytea’
atttypid=18 : ‘char’
atttypid=19 : ‘name’
atttypid=20 : ‘int8’
atttypid=21 : ‘int2’
atttypid=22 : ‘int2vector’
atttypid=23 : ‘int4’
atttypid=24 : ‘regproc’
atttypid=25 : ‘text’
atttypid=26 : ‘oid’
atttypid=27 : ‘tid’
atttypid=28 : ‘xid’
atttypid=29 : ‘cid’
atttypid=30 : ‘oidvector’
atttypid=210 : ‘smgr’
atttypid=700 : ‘float4’
atttypid=701 : ‘float8’
atttypid=702 : ‘abstime’
atttypid=705 : ‘unknown’
atttypid=1007 : ‘_int4’
atttypid=1033 : ‘aclitem’
atttypid=1034 : ‘_aclitem’
atttypid=1042 : ‘bpchar’
atttypid=1043 : ‘varchar’
atttypid=1082 : ‘date’
atttypid=1083 : ‘time’
atttypid=1184 : ‘timestamp’
atttypid=1266 : ‘timetz’
atttypid=1700 : ‘numeric’
atttypid=2500 : ‘int1’
atttypid=2569 : ‘nucl’
atttypid=2570 : ‘prot’
atttypid=2522 : ‘nchar’
atttypid=2530 : ‘nvarchar’
atttypid=278 : ‘ntext’

다음은 geometry를 가지는 테이블의 지오메트리 타입을 얻는 쿼리문인데 하나의 테이블에 동일한 지오메트리 타입을 가지는 도형만 저장하고 있다는 가정이 필요합니다.

select GeometryType(the_geom) from public."tst_Table" limit 1;

그리고 어떤 MBR에 걸치는 도형을 공간검색하는 쿼리문은 다음과 같습니다.

SELECT
    the_geom
FROM  
    public."tst_Table"
WHERE 
    ST_Intersects 
    (
        the_geom, 
        ST_MakeEnvelope(456315, 382558, 460432, 386381, -1)
    );

위의 공간검색 쿼리는 PostGIS의 JDBC API를 사용하면 쉽게 지오메트리의 타입과 좌표값 등을 얻을 수 있습니다. 물론 자바 언어뿐 아니라 C언어에 대한 API도 제공합니다.

위의 SQL문은 MBR을 기준으로 MBR과 중첩되는 것을 검색하는 예이며 아래는 기준을 일반적인 지오메트리를 WKT 형식으로 받아 중첩되는 것을 검색하는 예입니다.

SELECT 
    *, ST_BOX2D(the_geom) 
FROM 
    public."tst_Table"
WHERE 
    ST_Intersects
    (
        the_geom, 
        'LINESTRING (244049 543725, 244134 543762)'::geometry
    );

덧붙여 검색 필드로써 ST_BOX2D를 사용해 검색된 항목의 MBR까지 얻어오도록 하였습니다.

2011-06-192017-01-27

[GIS] GeoService-Xr에서 새로운 DBMS 추가를 위한 인터페이스 구현

새로운 DBMS를 GeoService-Xr에 추가하기 위한 클래스 간의 관계를 정리해 봅니다. 이번에 새롭게 추가해야할 DBMS는 PostgreSQL에 기반한 PostGIS입니다. PostGIS이므로 공간검색이나 공간 데이터에 대한 관리는 모두 PostGIS의 기능을 그대로 사용합니다. 시간 상으로 PostGIS를 깊이 있게 살펴본 상태는 아니지만.. 지금까지의 느낌으로는 깔끔합니다. 속도 역시 빠릅니다. 아래 그림은 새로운 DBMS 추가 확장에 대해 관련이 있는 클래스만을 떼어 놓은 GeoService-Xr의 클래스 관계도입니다.

사용자 삽입 이미지
보시면… GeoService-Xr이 지원하고 있는 공간 데이터의 소스가 어떤 것인지를 알 수 있습니다. 현재는 파일기반, MySQL 그리고 ArcSDE입니다. 여기에 더해질 PostGIS가 가능합니다. 또한 편집이 가능한 데이터 소스는 MySQL과 PostGIS라는 것도 파악할 수 있습니다. 즉, 편집을 위한 인터페이스를 선언하고 있는 클래스가 XrEditableSpatialAccess인데 이 클래스를 상속받고 있는 클래스가 XrMySqlAccess와 XrPostGISAccess이기 때문입니다.

공간 데이터 서비스 및 공간 데이터의 편집이 가능한 공간 DBMS를 새롭게 추가하기 위해서 XrEditableSpatialAccess를 상속받아야 하며.. 이때 구현해야할 인터페이스 매서드의 개수는 13개입니다. 먼저 최상위의 Access 클래스에 대해 구현해야할 추상 매서드는 다음과 같습니다.

getAccessType : Access의 타입 반환함(AccessType이라는 enum 타입의 값 반환)
connect : 파일 열기, 소켓 오픈 등과 같은 데이터 소스 접근 준비
build : 파일이나 DB로부터 공간 쿼리가 실제 가능하도록 준비

그리고 SpatialAccess에 대해 구현해야 할 추상 매서드는 다음과 같습니다.

getMBR : 지정된 row에 대한 MBR을 얻음
collectConnectionInfo : 필드구성, 전체 row 수, 공간 도형 타입, MBR 정보를 얻음
queryByMBR : MBR에 포함되는 공간 데이터를 쿼리함

그리고 최종적으로 XrEditableSpatialAccess에 대해 구현해 줘야할 추상 매서드는 다음과 같습니다. 만약 편집 기능이 필요치 않을 경우 이 클래스의 추상 매서드는 구현할 필요가 없습니다.

updateFeature : 편집된 공간 데이터를 update 시킴
deleteFeature : 지정된 공간 데이터를 삭제함
insertFeature : 새로운 공간 데이터를 추가시킴
checkExistFID : 지정한 FID가 이미 존재하는지 검사함
checkExistFIDs : 지정한 FID 리스트가 존재하는지 검사함
writeEditedHistoryData : 공간 데이터에 대한 편집 이력을 기록함(반드시 구현할 필요는 없음)
getDBResource : 데이터 소스에 접근하기 위한 DB 리소스를 얻음

이상으로 XrGeoService-Xr 공간 서버에서 새로운 DBMS를 새롭게 지원하기 위해 구현해야할 인터페이스에 대한 정리였습니다.