국토교통부에서는 2015년 1월부터 몇 가지 건축데이터를 개방하고 있다. 2016년 10월 현재에는 건축인허가, 주택인허가, 건축물대장, 폐쇄말소대장, 건물에너지, 건축물유지관리 총 6종의 데이터를 매달 업데이터 하여 개방하고 있다. 이 글은 그 중 건축물대장 데이터에 관한 것이다.
건축물대장은 http://open.eais.go.kr의 '대용량제공서비스'를 통해 매 달마다 10개의 파일로 분리되어 전국 단위로 업로드되고 있다. SQL 데이터베이스 형식의 테이블을 txt로 변환하여 그대로 올리고 있는데, 용량이 매우 커서 보통의 프로그램으로는 열어보기조차 힘들다. 그리고 본래 하나의 주소 단위로 제공되는 건축물대장을 데이터베이스 관리 목적에 따라 10개의 테이블로 분리시켰기 때문에 그 관계들을 파악하는데만 한참의 시간이 걸린다.
이 글은 그 10개 테이블로 분리된 건축물 대장 데이터의 내용과 관계를 설명한 글이며, 한국문화공간건축학회논문집 통권 50호(2015년 5월)에 게재된 '건축물대장 원시데이터의 관계 구조와 탐색적 분석을 통한 데이터 활용'의 내용을 일부 발췌하고 일부 내용을 추가하여 편집한 것이다. (글이 좀 딱딱한 것은 그래서 그렇다)
게재된지 1년이 더 지났는데도, 건축물대장 관련한 내용을 묻는 사람들도 '찾으려 했으나 찾아보지 못했다'고 하여 여기에 옮겨둔다. 학술논문이라는 것이 쓰는 사람들은 참 고생을 많이 하는데, 저작권 및 검색 문제 등 여러가지 문제로 정작 그 지식을 필요로 하는 사람은 쉽게 검색해서 무료로 읽어보기 힘들게 되어 있다.... 각설하고, 시작하겠다.
일반적으로 발급받을 수 있는 건축물 대장
민원24나 세움터 등에서 떼면 종이로 인쇄되는 건축물대장의 종류는 일반적으로 총괄표제부, 일반건축물대장, 표제부, 전유부의 네 가지로 나누어진다. 단어의 뜻만 해독해서는 그 안에 담긴 내용을 감히 짐작할 수 없다. 각각의 개념은 다음과 같다.
건축물 대장의 종류와 내용
그러나 이 구분은 한 가지 기준에 의해 나누어진 것이 아니라 단순히 대장의 종류만을 구분한 것이기 때문에 개념상의 혼란을 줄 수 있다. 이 구분을 건물과 소유자의 상태에 따라 나누어보면 다음과 같다.
건축물의 동 수와 소유권에 따라 발급되는 대장의 종류
그래도 좀 어려운데, 몇 가지 예를 들어보겠다.
1) 한 필지에(혹은 여러 필지에 걸쳐) 하나의 건물이 있고 한 명의 소유주에 귀속되어 있다. 이 경우 일반 건축물 대장 하나를 뗄 수 있다.
2) 한 필지에 높은 건물 하나와 낮은 부속 건물 하나가 있다.(사실 높이는 상관 없다) 그런데 소유주는 한명이다. 그러면 총괄표제부와 각 동별 일반 건축물대장을 뗄 수 있다. 위 표에서 첫번째 경우에 해당한다.
3) 한 필지에 스무개의 상점이 있는 상가 건물 하나가 있는데, 각 상점 주인에게 분양되어 있다. 이렇게 소유주가 여럿인 건물을 집합건축물이라 부르며, 전유공간(각 상점 주인의 배타적 전용 공간인 상점 내부) 외에 복도, 계단, 화장실 등에 대해 분할된 지분을 가진다. 이렇게 분할된 면적에 대한 내용을 담고 있는 대장을 전유부라고 부르며, 이 경우 건축물대장을 떼면 표제부와 각 소유권 별 전유부가 출력된다. 위의 표에서 네번째 경우다.
4) 여러동의 아파트 단지는 건물도 여러채고 소유주도 여러명이다. 따라서 총괄표제부, 각 동별 표제부, 각 소유권별 전유부가 출력된다. 위 표에서 세번째 경우다.
건축데이터 민간개방시스템에서 공개된 건축물 대장 파일
현재 건축데이터민간개방시스템에서 공개되어 제공되고 있는 건축물대장은 위에서 구분된 네 가지 구분과는 달리 총 10개의 파일로 구분되어 있다. 이 글에서는 2015년 2월 15일에 제공된 2015년 1월의 건축물대장 데이터를 사용하였다.
각 파일은 ANSI 코드의 txt형식으로 되어 있는데, 관계형데이터베이스에 적합한 형식 즉 행과 열로 구분되어 있으며 하나의 테이블이 된다. 각 행은 엔터로 구분되어 있으며 하나의 레코드에 해당한다. 각 열의 다른 필드들은 구분자(“|”)로 나누어져 있다. 필드의 목록과 데이이터포맷(문자,정수,실수)은 별도의 엑셀파일로 함께 제공된다. 또한 모든 테이블의 첫 번째 필드에는 ‘건축물대장_PK’가 있는데 이 일련번호에 대한 형식규칙은 공개되어 있지 않다. 서비스 제공자에게 별도로 문의한 결과, '내부적으로만 사용하는 코드'라는 답변을 받았다.
이 PK번호는 각 테이블 내에서 고유값(key)은 아니며 건물 혹은 소유권(호별)에 따라 구분된다. 한 예로 각 호의 전유 및 공용면적 항목들은 여러 개의 레코드로 나누어져 있지만, 모두 동일한 PK값을 지닌다. 동일 건축물의 층별 개요의 경우 PK 값은 모두 동일하다.
제공되는 파일의 개요와 건축물대장과의 관계는 아래와 같다.
건축데이터민간개방시스템에서 제공되는 파일의 종류와 내용
(용량과 레코드 수는 지속적으로 변경되는 것이지만, 전국의 건축물에 대한 데이터라는 점에서 단기간에 10%이상이 변경되는 것은 현실적으로 어렵기 때문에 충분히 참고가 될 수 있을 것이라 판단하여 기록해두었다.)
위의 자료를 손 쉽게 이용하기에는 크게 두 가지 어려움이 있다.
첫째, 각 대장에 포함되는 항목들이 여러 개의 파일로 분산되어 있기 때문에 특정 변수들의 관계를 보려면 분산된 파일 간 레코드들을 매칭시켜주어야 한다. 예를 들어 ‘사용승인일’과 ‘전유공용면적비율’간의 관계를 보려고 할 경우 ‘표제부’와 ‘전유공용면적’ 두개의 파일이 필요하며 그 관계를 주소를 기반으로 연결해주어야 한다. 그런데 이러한 작업이 반복적으로 긴밀하게 수행되기 위해서는 1차적으로, 분리된 파일의 필드와 그 관계들에 대한 조사가 필요하다.
둘째, txt파일의 용량이 크기 때문에 일반적인 사용자들이 많이 사용하는 엑셀과 같은 스프레드시트에서 다루기 어렵다. MS엑셀2013버젼의 경우 최대 입력 가능한 행 수가 1,048,576 행으로, 엑셀에서 열 수 있는 파일은 ‘총괄표제부’가 유일하다. 이것은 어쩔 수 없는 문제로 대용량 txt 파일을 다룰 수 있는 프로그램을 구매하거나 직접 프로그래밍 언어를 사용 하여 파일의 읽어들여야 한다.
테이블 별 필드와 필드 간 관계
각각의 테이블(파일)들은 포함하고 있는 필드의 수가 다른데, 각 테이블별로 포함하고 있는 필드들은 아래 그림과 같다. 테이블을 분리해 놓은 목적에 맞게 차이가 나는 필드들을 포함하고 있는 것을 알 수 있다.
제공되는 파일 각각의 데이터 필드
중복되는 필드들을 제외하면 필드들은 총 120개가 있다. 우선 필요에 따라 활용할 수 있도록 필드들을 크게 9가지로 구분하였다. 구분에 따른 내용은 위 그림의 맨 좌측 분류에, 그리고 아래 표에 나타나 있다.
건축물 대장 데이터에 포함된 모든 필드들의 구분
위의 그림과 표를 보면 대지 위치를 나타내는 필드들이 매우 많고 10개의 테이블에 거의 중복되어 있는 것을 알 수 있다. 특히 전유공용면적의 경우 레코드 수가 7천만 개가 넘는데 각각의 레코드들이 모두 대지에 대한 정보와 구조에 대한 정보를 포함하고 있다. 같은 건물에 있는 1000개의 전유부, 공유부의 레코드들은 같은 대지와 구조정보를 공유한다는 것을 생각해보면 필요 이상으로 파일의 크기가 커진다(20GB이상)는 것을 알 수 있다.
따라서 테이블 간 중복을 최소화하기 위해 자료를 계층적으로 재구조화 하고, 이러한 계층적 스키마를 NoSQL 인 MongoDB의 형식을 빌어 재구성해보겠다.
건축물대장 데이터 재구조화
열 개의 파일을 하나의 구조로 통합하기 위해서는 우선 어떠한 기준에 의해 다른 테이블을 통합할 것인지에 대한 기준을 세워야 한다. 이 과정의 다음 단계는 건축물대장 데이터를 공간정보와 매칭시키는 것이고, 이를 위해 물리적 계층구조를 데이터베이스에도 반영하는 것이 적합하다고 판단하였다.
다시 말해 ‘건물군(총괄표제부)-건물(표제부)-층-전유공용’라는 물리적 포함관계에 따라 계층을 만들고 그 상위에 대지주소를 둔다.
단, 필지에 건물이 한 동 있는 경우 총괄표제부가 없기 때문에 총괄표제부는 건물의 상위 계층이 아니라 동위에 둘 것이다. 재구조화된 데이터의 계층구조는 아래와 같다.
MongoDB의 형식으로 재구조화시켜 표현한 건축물대장 데이터의 관계
(굳이 MongoDB 형식으로 재구조화 시키지 않아도 된다. 10개 파일의 관계를 설명하기 위해 그려보았다)
그림 2는 MongoDB에 데이터를 입력한다고 가정하고 재구조화된 데이터 스키마를 하나의 도큐먼트 형식으로 표현한 것이다. NoSQL 데이터베이스인 MongoDB에서는 계층화된 하나의 레코드를 ‘도큐먼트(document)’라고 부르며 중괄호({ })로 표기한다. 120개의 각 항목들은 표현의 분량상 하나하나 열거하지 못하였으며, 최대한 그림1에 표현된 내용으로 의미 전달에 무리가 없도록 표현하였다.
가장 상위 계층에 ‘대지, 총괄표제부, 건물’을 두고 각각 하위 항목에 필드를 재배열 했다. 건물의 경우 ‘건물(2차)-층(3차)-호(4차)-공용,주택가격(5차)’의 하위 계층을 지닌다. 각 항목의 우측에 관련된 데이터 파일을 ‘OOO.txt’의 형식으로 표현하였다.
데이터를 위와 같이 재구조화 함으로써 대지 및 여러 필드들이 중복되는 부분을 최소화 하였고, 테이블 사이의 관리에 필요한 ‘기본개요’ 테이블과 ‘전유부’ 테이블을 사용하지 않고도 건축물대장이 지니는 모든 데이터를 표현할 수 있게 되었다.
무엇보다도 대지에서 건물로 이어지는 물리적 계층구조를 DB에도 그대로 반영하였기 때문에, 자료의 구성이 직관적이며 공간정보와의 연계 시 도큐먼트 단위로 대응될 수 있다는 장점이 있다.
또한 MongoDB가 지니는 동적 스키마라는 장점, 즉 모든 도큐먼트들이 동일한 키(key)를 가질 필요가 없기 때문에, 키가 없을 경우에 도큐먼트에서 해당 키와 값을 누락시켜도 오류가 발생하지 않으며 따라서 메모리를 절약할 수 있다는 장점도 가진다. SQL과 같은 관계형데이터베이스에서는 레코드가 생성될 때 우선적으로 할당된 변수형만큼 메모리를 차지하기 때문이다. (물론, MongoDB 자체가 SQL 형식보다 일반적으로 파일 용량이 큰 점은 감안해야 한다)
도로명주소 지도와 건축물대장 사이의 주소 기반 제이터 매칭
자바(Java)코드로 위에서 설명된 형식으로 두 자료를 연계하였다.
구체적으로 설명하자면, 무료 소프트웨어인 QGIS 프로그램에서 도로명주소지도의 shp과 dbf파일을 json형식으로 변환할 수 있다. json파일은 MongoDB 의 도큐먼트형식과 거의 흡사하고 여러 언어에서 다루기 편리하기 때문에 json파일로 변환시켜 이용하였다.
자바 코드로 두 데이터를 매칭시킨 후, json 파일에 필요한 항목들을 추가한다. 그렇게 변환된 json 파일은 다시 QGIS에서 읽어들일 수 있다. (물론 QGIS 상에서도 Python을 이용하여 두 자료를 직접 매칭시킬 수 있는 방법이 있다.)
공간정보를 연계하는 것은 QGIS 상의 시각화를 목적으로 두기 때문에, 도로명주소지도 파일을 기준으로 데이터를 매칭시킨 후 건축물대장정보의 일부 항목(사용승인연도, 연면적 등)들을 도로명 주소 파일로 옮겼다.
매칭 결과 도로명주소 지도에 있던 663,148개의 폴리곤 중 597,700건, 즉 90.1%가 건축물대장 정보와 연계되었다. 나머지 65,448건은 대부분 한 필지에 여러 건물이 있지만 동 이름이 누락되어 있거나 표기 형식이 서로 달라 매칭되지 않았다.
마치며
이제까지 세움터에 공개된 건축물대장 데이터를 토대로 구조를 활용에 용이하도록 재구조화 하여 DB에 저장한 뒤 공간정보와 연계하는 작업을 설명하였다. 작업 과정에서 발견한 데이터 활용상의 문제점은 다음과 같다.
첫째, 공개된 데이터에 대한 설명이 부족하다. 건축물대장의 내용이 10개의 파일로 분산되어 제공되기 때문에 네 가지 대장 형식과의 연관성과 관계구조를 파악하는데 많은 시간이 소요된다. ‘데이터 공개’의 취지를 더욱 살릴 수 있도록 원활한 자료의 이용이라는 관점에서 부가적인 설명이 필요할 것이다.
둘째, 데이터 파일을 관계형데이터베이스에 최적화 되어 있는 txt로만 공개하고 있는데, 최근의 추세에 맞추어 MongoDB와 같은 NoSQL의 형식으로의 배포가 고려되어야 한다. 그림 2에서 예시를 들었던 것처럼 물리적 계층에 기반한 계층적 구조의 DB형식이 제공될 경우 필지 중심의 자료 이용이 더 용이할 것이다.
셋째, 매월마다 배포되는 자료의 업데이트가 어렵다. 현재는 전국의 전체 데이터를 하나의 덩어리로 하여 배포하고 있으며, 각각의 데이터 레코드에 대한 고유번호(key)가 부여되어 있지 않다. 따라서 배포된 자료로 이용자가 별도의 DB를 구축하더라도, 다음 달에 업데이트 되어 배포되는 자료를 이용하려면 기존 자료를 삭제하고 다시 DB에 입력하는 작업을 반복해야 한다. 모든 레코드에 고유번호를 부여하고 배포시에 삭제된 고유번호와 새로 추가된 고유번호, 갱신된 고유번호를 함께 배포한다면 자료의 이용이 보다 수월할 것이다. 물론 현재의 자료만으로도 새로운 데이터와 과거의 데이터를 비교해가면서 변화된 부분을 찾아낼 수도 있지만, 작업 시간과 데이터의 무결성이라는 관점에서 생각해 볼 때 삭제 후 새로 입력하는 것이 더 효율적이다.
마지막으로, 지속적으로 지적된 문제이지만, 공간정보와의 연계를 염두에 두어, 건물폴리곤을 포함한 GIS파일과 건축물대장간에 1:1 대응이 될 수 있도록 건물에 고유번호를 부여하는 것이 시급하다. 현재는 한 주소에 여러 동의 건물이 있을 경우 대응시키기가 어렵다.
현재 국가공간정보포털(http://openapi.nsdi.go.kr/nsdi/eios/OpenapiList.do?gubun=F)에 'GIS건물통합정보'라는 이름으로 shape파일과 건축물대장이 결합되어 있으나, 수치지형도 2.0 버젼을 사용하여 최신 건물들이 누락되어 있고, 건축물대장의 모든 항목이 들어가지 않아 원활한 이용이 어렵다.
위의 문제점들이 보완되어 데이터가 공공에게 제공된다면, 공개 당시 의도한 민간 활용의 가능성이 더욱 높아질 것이다.
'Function' 카테고리의 다른 글
| QGIS에서 레이어로 구분된 PDF 만들기 (0) | 2018.03.22 |
|---|---|
| 선거의 득표 수를 어떻게 지도에 표현할 것인가? (0) | 2017.05.22 |
| 서울 36개 업종 증감 인터랙티브 지도 (2006-2014) (2) | 2016.10.21 |
| VWL 텍스트 분석기 0.9 (7) | 2016.10.16 |
| 시각화 : 서울, 26년간 공시지가의 변화 (5) | 2016.09.27 |
