프로그웍스는 2년 전 자비와 노고를 들여 국가지점번호지도서비스(이하 지점번호)를 제작하여 인터넷에 공개했습니다. 지점번호를 제작한 이유는 인터넷을 통해 조회되거나 또는 다운로드 받을 수 있는 공공개방정보가 없었기 때문입니다. 지도서비스로 공개한 이유는 긴급 구조 등으로 이용되는 지점번호의 좋은 취지를 알리기 위함입니다.
그러나 행정안전부 주소정책과에서 서비스를 내릴 것을 전화를 통해 권고하더군요(좋게 표현해서). 제가 비공개 공간정보를 허락없이 제작하여 서비스한다는 사유였습니다.
2년전 지도서비스 개설 후 국토지리정보원으로부터 보안사항 위반을 연락 받았습니다. 지도서비스의 배경지도로 OSM(OpenStreetMap)을 사용했는데 이 부분을 지적하며, 서비스를 폐쇄하던지 또는 배경지도를 바꿀 것을 권고했습니다. 그래서 브이월드 2D 배경지도로 변경한 사례가 있습니다. 아래 링크를 참고하십시오.
주소정책과에서 행정안전부 및 국토교통부의 보안관련 규정을 언급하며 서비스를 내려야한다고 저에게 얘기했습니다. 사유는 납득할 수 없습니다. 단지 그런 규정이 있다는 것만 얘기하고 저의 물음에는 답이 없는 일방적 통보이니까요.
제가 납득하지 못하는 이유는 아래와 같습니다.
첫번째, 비공개 공간정보라면 그에 대한 명확한 공지가 있어야 합니다. 지점번호의 공개가 범법행위라면 지점번호 부여체계 등 관련 정보를 미디어에 지속적으로 노출시킨 관련 부처 및 공공기관은 범법행위를 저지르고 있는 것인가요? 매년 지자체가 등산로 등에 설치하는 지점번호 표지판 설치도 불법 행위인가요? 지점번호 표지판의 훼손은 없는지, 필요한 곳은 없는지, 어떻게 알려야 하는지 활동을 하는 2020년 6월 발대식을 가진 "국가지점번호 지킴이"도 보안 위반 단체인가요?
두번째, 만일 지점번호의 인터넷 공개가 불법이었다면 2년 전 이미 언급이 되었어야 합니다. 2년전 OSM으로 제한하여 사용을 금지시킨 국토지리정보원이 책임을 다하지 않은 것입니까? 행정안전부의 산하 기관이 아니라서 기관이 담당하는 부분만 언급하고 2년 동안의 범법 행위를 방관한 것입니까? 아니라면 행정안전부와 국토지리정보원의 공간정보 관련 보안 규정이 다른 것입니까? 또는 사용이 적법하지 않은 OSM을 아예 인터넷 접속 단계에서 막지 않은 경찰청 내지는 인터넷진흥원 등의 잘못입니까?
세번째, 국가지점번호는 공간정보가 아닙니다. 공간정보기본법에 따르면 공간정보를 아래와 같이 정의합니다. < "공간정보"란 지상ㆍ지하ㆍ수상ㆍ수중 등 공간상에 존재하는 자연적 또는 인공적인 객체에 대한 위치정보 및 이와 관련된 공간적 인지 및 의사결정에 필요한 정보를 말한다.>
지점번호는 산, 강, 나무 같은 자연적인 객체가 아닙니다. 도로, 항만, 건물 같은 인위적인 객체도 아닙니다. 지점번호는 단지 식별명을 가지는 가상의 위치 격자 명칭입니다. 따라서 국가지점번호 단독으로 개인 또는 시설을 특정할 수 있는 의사 결정에 필요한 어떤 정보도 가지지 않습니다. 배경지도 위에 표현되는 지점번호가 특정 위치를 나타내는 것이 문제가 된다면, 인터넷을 통해 주소/시설물 검색을 지원하는 모든 지도서비스가 금지되어야 합니다.
네번째, 통화로 언급한 보안관리규정의 적용 대상이 일반 국민은 아닙니다. 국가의 안보를 위협하는 비공개 정보라면 지점번호가 명확하게 비공개 정보로 규정되어있어야 합니다. 단지 중앙부처와 산하기관에 적용되는 훈령, 예규 등의 규정으로 핍박하는 것은 받아들일 수 없습니다. 국가지점번호는 비공개정보이니 절대 공공이든 민간이든 인터넷에 공개하면 안된다는 정확한 근거가 있어야 합니다.
다섯번째, 국가는 국민의 안전과 재산을 위해 존재한다고 배웠습니다. 헌법 제34조 6항은 "국가는 재해를 예방하고 그 위험으로부터 국민을 보호하기 위하여 노력하여야 한다." 라고 규정합니다. 국가지점번호가 "산악, 해양 등 비거주지역에서의 기관마다 서로 다른 위치표시체계를 일원화하여 소방·경찰·국립공원 등 관계기관이 정보공유·협업을 통해 신속한 구조·구급 등 취약지역의 안전관리체계 강화 "하는 목적을 가지고 있다면, 국민이 이를 알고 있어야 그 목적을 이룰 수 있습니다.
개인이 인터넷에 정보를 공개하는 것은 많은 책임이 따릅니다. 저는 블로그를 운영하며 지점번호 관련 많은 문의를 받았습니다. 생활주소인 도로명주소를 얘기하고 도로명주소를 보완하는 지점번호에 대해 왜 필요한지 알렸습니다. 지점번호에 관심이 있는 구독자가 계십시다. 이에 관심이 있는 구독자가 소수라 할지라도 저는 그 분들을 위해 서비스를 유지할 책임을 가지고 있습니다. 정말 내려야 한다면, 프로그웍스를 이용하고 격려해주신 구독자님들을 납득시킬 수 있는 사유와 함께 서비스 폐쇄를 요청하셔야 합니다.
지금 사용하는 클라우드서비스의 이용기간이 만료되어 당분간 국가지점번호지도서비스를 내려야할 것 같습니다. 절대 부당한 요청에 굴복하는 것이 아님을 말씀드립니다^^ 약간의 시간이 걸리겠지만 더 좋은 환경에서 서비스를 이어나가겠습니다.
프로그웍스를 성원해주시는 구독자님들께 깊이 감사드리며, 좋은 정보 공유를 위해 계속하여 정진하겠습니다.
위키피디아는 "디지털 트랜스포메이션(Digital Transformation, DT 또는 DX, DT)은 클라우드 컴퓨팅을 활용하여 문제를 해결하고 소유 중인 하드웨어 사용자에 대한 의존성을 줄이되 구독 기반 클라우드 서비스에 의존성을 증대시키기 위해 새롭고 빠르고 자주 변화하는 디지털 기술을 사용하는 방식을 말한다. " 고 디지털 트랜스포메이션을 정의하고 있습니다.
가만히 보니 단순히 기술적인 용어가 아닙니다. 기업의 비즈니스 및 서비스 생산 방식의 변화까지도 포함하고 있습니다. 더 찾아보니 LG CNS 블로그의 정의가 꽤 유용합니다. 요약하면 "기존 사업 서비스 모델이 줄 수 있는 고객 가치를 개선하고, 동시에 이를 제공하기 위해 필요한 운영 체계를 최적화하며 경쟁사들이 제공하지 못하는 새로운 형태의 신규 사업 서비스 모델을 개발해 차별화된 고객 만족과 내부 운영 효율화를 추구하는 일련의 '기업 혁신 활동'을 말합니다"
개인적 견해이지만 결론부터 말하자면 공간정보서비스 분야의 DT는 민간기업의 공간정보관련서비스를 수요자가 구매하여 서로의 비즈니스가 상생하는 생태계가 만들어지는 것이라고 생각합니다. 실제 공간정보서비스를 위한 기반환경을 서비스하는 비즈니스, 실제 사용자 관점에서 엔드유저 서비스를 제공하는 비즈니스가 서로 협력하는 비즈니스 환경이 만들어지는 것입니다. 이의 한 부분으로써 공간정보서비스 분야에서 DT를 실현하는 성과로써 지도서비스를 얘기하고자 합니다.
우리는 서비스를 개발하며 지도서비스 또는 지도API를 이용합니다. 네이버, 카카오 등 민간사업자가 제공하는 지도API를 이용하거나 국토지리원의 바로이맵, 브이월드 등 공공부문이 제공하는 지도API를 이용합니다. 민간사업자가 제공하는 API를 이용하는 경우 과금이 발생하는 대신 안정적 접속환경을 보장받을 수 있고, 공공부분의 경우 무료로 이용할 수 있지만 속도 등 안정적 이용은 보장받을 수 없습니다. 공통적인 것은 2D 환경만 수용한다는 것입니다. 물론 브이월드가 3D 지도 API를 서비스했지만, 이는 현재 웹기술과는 거리가 있습니다.
저는 공간정보서비스의 3D 전환을 DT관점에서 얘기하려 합니다. 3D를 구현하는 기술적인 방법은 더 이상 새롭지 않습니다. 하지만 우리나라의 어떤 공간정보서비스도 3D 지도 환경 위에서 제공되지 않습니다. 이는 여러가지 원인이 있지만
첫째, 우리나라 전체를 수용하는 3D 지형정보를 구축하는데 드는 비용이 높다. 둘째, 3D를 렌더링 하는 사용자PC의 컴퓨팅 파워가 높아야 한다. 세째, 3D 환경에 어울리는 비지니스 콘텐츠의 발굴 또는 렌더링 방법에 대한 고민이 미흡했다.
첫번째 제약 요소는 다음과 같습니다. 국토지리정보원에서 항공영상과 DEM 정보를 무상으로 제공하지만, 실제 서비스에서 호출되는 데이터 형식으로 전환하는 비용과, 이의 운영을 위한 인프라 환경 구성 비용이 예산을 초과하는 경우가 대부분입니다. 지형정보를 3D로 표현하기 위해서는 실제 영상 이미지와 DEM이라는 높이 정보를 동시에 요구합니다. 따라서 서비스용 리소스 저장을 위하여 기존 2D 지도 대비 2배의 저장 공간을 요구합니다. 원본에 대한 저장 비용까지 고려하면 비용은 더욱 높아집니다.
이런 제약조건을 신규 비즈니스 전환을 위한 기회로 받아들이는 생각의 전환이 필요합니다. 공간정보서비스의 3D 전환을 위하여 3D 콘텐츠를 생산하는 사업자가 첫번째 제약조건을 극복하고 3D 콘텐츠 제공자 역할을 할 수 있습니다. 지금처럼 국토지리정보원이 유일한 리소스 제공자일 필요는 없습니다. 국민에게 봉사하는 관점이 아닌, 민간의 비즈니스를 풍부하게 하는 조력자로써 무료가 아닌 유료서비스로 안정적으로 3D 지도 리소스를 제공한다면 제공자와 수요자 모두가 비즈니스 목적을 이룰 수도 있습니다.
두번째 제약요소는 업계 스스로의 문제입니다. 3D 콘텐츠의 렌더링을 위해 고사양의 PC를 요구하지만 최근 컴퓨팅 파워의 눈부신 발전은 모바일폰에서도 3D 렌더링을 지원합니다. 문제는 공간정보 업계 스스로가 공공정보화사업을 주력 비즈니스로 영위하며 기술의 구현 범위를 제한한 것에 있습니다. 만일 즉시 이용가능한 고품질의 3D 지도서비스가 API 수준에서 제공된다면 이 것의 이용으로 3D 기반 서비스 제공이 가능합니다.
컴퓨팅 기술의 발전은 인프라 환경의 고민없이 콘텐츠 제작에 집중할 수 있도록 합니다. 이는 기회입니다. 제한을 두지 않고 내가 제공하려 하는 콘텐츠 또는 서비스에 역량을 발휘하면 되니까요.
세번째 제약요소는 GIS를 위한 공간정보서비스를 고집하기 때문에 발생합니다. 공간정보업계에 종사하시는 분들과 3D 관련하여 얘기를 나누게 되면, 지하 시설물을 얘기하고, 경관 분석을 얘기합니다. 좀 더 시각을 넓혔으면 합니다. 마이크로소프트는 Flight Simulator를 통해 전지구적인 범위에서 Real3D를 구축해가고 있습니다. 이는 GIS가 아닌 게임입니다. 결국 더 넓히면 Real World 에 Fun & Joy라는 가치를 담고 있습니다. 공간정보가 주력이 아닌 다른 산업을 풍부하게 하는 조력자(Enabler)의 역할을 하고 있습니다.
이의 모방이 DT라면 이를 통해 새로운 기회를 만들 수 있습니다. 단순히 공간정보서비스 제공이 아니라 어떤 산업 분야에서 어떻게 사용될 수 있는지 고민을 하고 이의 해결책을 찾는다면 시장은 커질 것이라고 믿고 있습니다. 기존의 Choropleth Map, HeatMap, 아이콘 등으로 시각화하는 것이 2차원 환경에서 주류였다면 여기에 더해 높이라는 가치를 제공하는 방법을 찾는다면, 그 안에서 3D 환경에서 사용자 UX의 가야할 방향을 찾을 수 있습니다.
공간정보서비스의 DT를 지원하는 3D 지도서비스
프로그웍스는 "하늘지도"라는 카테고리에서 "하늘지도 3D 지도서비스 API"를 소개하려 합니다. API 사용자는 이의 이용을 통해 어려운 3D를 조금이라도 쉽게 이용하게 하려합니다. API 사용자는 기존 공간정보서비스를 WebGL이라는 기술 기반 위에서, 법이 허용하는 범위 내에서 가장 정교한 3D 지형정보를 활용하도록 하겠습니다. 20cm급 고해상도 항공영상과 5m급 DEM 정보를 기반으로 만든 1m급 DEM 정보를 통해 렌더링 되는 고정밀 3D 국토정보 API입니다. 또한 이 API는 클라우드환경에서 제공되어 사용자의 증가에 능동적으로 대응하도록 인프라가 설계되었습니다. 최근 영상은 물론 과거영상까지 3D렌더링을 지원할 예정입니다.
현재 제작 중으로 정식으로 판매하지는 않습니다. 하지만 "아파트엔서비스"를 통해 일부 샘플을 제작하여 보여드리고 있습니다. 향후 많은 사업자가 이 API를 이용하여 다양한 3D 공간정보서비스를 개발하기를 기대합니다. API 발급 비용은 아직 내부 협의 단계로 밝히긴 어렵지만, 충분히 납득할 수 있는 비용으로 과금될 예정입니다.
이 후 지속적으로 하늘지도3D API를 소개하고, 이를 활용하는 쇼 케이스를 공개할 예정입니다.
아래 링크는 하늘지도API를 이용하여 제작된 드론센싱 애니메이션의 동영상 입니다. 배경 3D 리소스(항공영상 및 고도)는 삼아항업이 제작한 것입니다. 드론이 장성댐 인근을 비행하며 센싱하는 간단한 시나리오 입니다. 동영상을 인코딩한 PC가 태블릿이라 인코딩 품질이 좋지는 못합니다. 하지만 앞으로 나아가고자 하는 방향은 보입니다.
투자의 관점에서 최근 몇 년의 아파트시장을 한 줄로 요약하기에 딱 좋은 말입니다. 더 정확하게 서울을 포함한 수도권에 해당하는 말입니다. 최근 몇 년 수도권에서 아파트를 매입하신 분은 꽤 훌륭한 시세 차익을 얻었습니다. 호가 상승 시류에 편승하지 못하신 분은 속상할 수 밖에 없는 안타까움이 있습니다.
<나우앤서베이, 설문조사>
흔히 수도권이라고 하는 지역 중 일부 단지의 가격 상승을 "아파트엔"을 가지고 얼마나 상승했는지 비교하겠습니다. 비교되는 단지는 임의로 선정했습니다.
가장 선호도가 높은 중소형 단지를 기준으로 비교를 진행했습니다. "아파트엔"은 아파트 단지를 전용 면적에 따라 아래와 같이 5가지 유형으로 분류합니다.
초소형(40㎡이하) : 공급면적 기준 21평 이하
소형(40㎡초과60㎡이하) : 공급면적 기준 21평 초과 25평 이하
중소형(60㎡초과85㎡이하) : 공급면적 기준 25평 이상 32평 이하
중대형(85㎡초과135㎡이하) : 공급면적 기준 32평 이상
대형(135㎡초과)
단일 면적의 평균 금액과는 차이가 존재합니다. 이렇게 하는 이유는 면적 그룹 유형 별 비교 대상을 확대하여 지수 산출의 객관성을 부여하기 위함입니다. 또한 다른 단지와 비교를 통해 인사이트를 얻게 하기 위함입니다. 전용 면적을 기준으로 하는 이유는 공급 면적의 경우 건설 시기, 서비스 면적 등 다양한 요인에 따라 단지 별 차이가 존재합니다. 또한 아파트의 공급 면적을 알려주는 국가 공인의 자료는 없습니다. 건축물 대장에 관련 정보가 포함되어 있지만 단지 별로 작성된 형식이 달라 일관되게 적용되기 어려운 문제점이 있습니다. 관련 기관에 문의하니 아파트 분양사에 직접 전화해서 알아보는 것이 가장 빠르다고 하더군요^^
호가상승비교
결론을 먼저 말하자면 "비싼 단지가 많이 올랐다" 입니다. 일부 상승하지 못한 단지도 있습니다.
은마아파트의 경우 2020년 6월 기준 2016년 대비 무려 8.5억 정도 가격이 상승했습니다. 아파트의 노후화에 따라 아파트엔지수가 95에서 94로 하락했지만 절대적 가격지수는 유지되며 지속적으로 현가 가치가 상승했음을 알 수 있습니다. 역시 강남불패입니다.
< 대치동 은마아파트>
공덕동 삼성래미안3차의 경우 거의2배에 가까운 가격이 상승했습니다. 아파트엔지수도 86에서 88로 상승한 것을 볼 수 있습니다. 아파트엔지수를 보면 2020년 6월 해당 아파트 거주자는 전국의 아파트가 100개라면 88개의 아파트에 입주할 수 있다라고 할 수 있습니다. 가격으로만 보게되면 100개 중 96개를 선택할 수 있다는 것을 의미합니다. 공덕역 인근 아파트단지의 경우 3개 노선의 환승역인 공덕역 등 교통편의, 초등학교를 품은 아파트, 여의도로 이어지는 금융 인프라 등 무엇하나 빠지지지 않습니다.
<공덕동 삼성래미안3차>
성남시 분당구, 하남시, 시흥시 등도 가격이 크게 상승한 것을 볼 수 있습니다. 그에 따라 아파트엔지수도 상승했습니다. 시흥시는 수도권에서 비교적 호가가 낮은 곳이었지만 신규 아파트의 경우 아파트엔지수가 68에서 76으로 무려 8단계 정도 상승했습니다. 신안산선 전철 목감역 신설의 영향이 큰 것 같습니다. 역시 전철역 개통만한 호재가 없네요.
<하남시 풍산아이파크1단지>
<시흥시 엘에이치네이처하임>
특이하게 고양시의 경우 아파트엔지수가 80에서 75로 하락했습니다. 실제 가격 상승도 타지역 대비 크지 않습니다. 가격은 올랐지만 아파트의 가치로 환산했을 때 오히려 선택지가 좁아졌음을 알 수 있습니다. 일산을 놓고 봤을 때 3호선 전철, 경의선 전철이 있습니다. 또한 호수공원, 종합병원 등 거주 인프라도 그리 나쁜 편이 아닙니다. 서울 중심으로 접근이 훨씬 좋은 은평구 대단지 개발, 고양시 원흥마을 개발 등 경쟁 단지의 영향을 받았을 것이라 보입니다. 어쩌면 저평가일 수 있습니다.
<분당구 시범한신>
<일산동구 강촌마을(동아)>
대부분의 수도권은 서울의 배후도시입니다. 정확하게 서울 어느 지역의 배후도시인지가 가격에 큰 영향을 끼칩니다. 성남시(분당)의 경우 강남구 및 서초구와 접근성이 좋습니다. 고양시(일산)의 경우 최초 강서구, 마포구, 종로구, 영등포구 등의 배후 도시로 계획되고 만들어졌지만 다른 지역의 개발을 통해 직접 접근성이 과거보다 불편해 졌습니다.
마치며
수도권단지의 가격 상승을 아파트엔지수와 비교했습니다. 아파트 호가는 다른 단지의 가격 변동과 비교하여 상대적으로 판단해야 합니다. 아파트엔지수는 상대적 가격변화를 반영하는 지수입니다.아파트엔지수를 통해 우리 단지의 가격이 다른 단지만큼 상승했는지 또는 다른 단지보다 호가가 상승하여 실질적 보유가치가 상승했는지를 알 수 있습니다. 혹시 호가가 떨어지더라도 아파트엔지수가 유지된다는 것은 아파트의 현가 가치는 유지되고 있다는 것을 의미합니다.
혹시 아파트엔지수가 떨어졌다고 속상할 필요도 없습니다. 아파트엔지수는 아파트를 평가하는 수많은 방법 중 한가지 일뿐입니다. 대한민국은 개인 자산의 약 80% 정도가 부동산에 편중된 나라입니다. 결국은 우상향할 수 밖에 없습니다.
20년, 제가 공간정보 분야에서 일한 시간입니다. 20년을 일하고 보니 아쉬운게 있습니다. 공간정보에 종사하는 것은 대부분 공공 부문의 정보화용역 사업을 하는 것이라 열심히 했지만 남는 것이 없습니다. 용역은 용역일 뿐, 갑의 행복만이 존재하니까요. 그래서 무엇인가 남기고 싶었습니다. 호랑이가 아니어서 가죽을 남길 수도 없고 배움이 짧아 이름을 남길 수도 없습니다. 그래서 인터넷에 서비스라도 남겨보자고 마음먹었습니다.
누구나 관심을 가지는 주제와 모두를 대상으로 하는 서비스를 기획했습니다. 그리고 탄탄한 설계를 통한 제작이 아닌 프로토타입(베타서비스)을 공개하고 사용자 인터뷰를 통해 지속적으로 보완해가는 방법론을 적용합니다. 기술적으로 상용 클라우드서비스(IaaS) 환경에서 PostGIS 등 공개SW를 이용하고 공공개방되는 데이터를 적극 활용합니다.
아파트엔 서비스는 ...
아파트엔서비스는 호갱노노 등 요즘 관심을 받는 프롭테크(Property + Technology) 분야의 서비스입니다. 여타 부동산 앱과 구분되는 차이점은 매물을 중개하는 서비스가 아니라는 것과 아파트의 위치, 주변 학교 등 물리적 특징을 소개하는 서비스가 아니라는 것입니다. 아파트엔 서비스는 아파트의 가격을 결정하는 원인요소의 지수화를 통해 아파트의 투자가치를 평가하는 서비스 입니다.
아파트엔 서비스는 아파트를 대상으로 제공되는 BI (Business Intelligence : 비즈니스 인텔리전스) 서비스 입니다. 위키피디아를 인용하면비즈니스 인텔리전스는 데이터를 수집하고, 이 데이터를 가공하여 올바른 의사결정을 내릴 수 있도록 지원하는 시스템 및 기술입니다. 아파트엔 서비스는 아파트를 투자 자산 측면에서 바라보고 개별 아파트의 보유 가치를 평가합니다.
아파트 신호등! 아파트엔
빨간색, 노란색 녹색으로 아파트의 가치를 요약합니다. 누구라도 한 눈에 지도 위에 표시되는 색상으로 아파트의 가치를 구분할 수 있도록 합니다. 혹시 아파트 마커를 클릭한다면 좀더 상세한 정보를 볼 수 있습니다. 아래 4분면 그래프에서 점이 오른 쪽에 있을 수록 투자가치가 좋다는 것, 위에 있을 수록 실거주 가치가 좋다는 것을 의미합니다. 베타 기간이라 현재 틀릴 수도 있습니다.
아파트엔지수아파트엔 서비스는 투자 또는 보유 가치 평가를 위한 기준으로 아파트엔지수를 정의합니다. 아파트엔지수의 시간적 흐름에 따른 분석으로부터 아파트의 자산 가치 변화를 추적하게 합니다. 아파트엔지수는 아파트 가격을 결정하는 여러 원인인자를 종합하여 부여되는 점수입니다. 점수가 높을 수록 좋고, 1 ~ 100 까지의 숫자로 나타납니다.아파트엔지수가 전달하는 인사이트(Insights)는 다음과 같습니다.아파트엔지수가 시간의 흐름에 따라 변동이 없다면, 다른 아파트의 가치가 변한 비율만큼 가치가 유지됨을 의미합니다. 만일 아파트엔지수가 상승했다면 우리 아파트의 절대적 가치가 상승했다는 것을 의미합니다. 가격은 상승했더라도 아파트엔지수가 하락했다면 상대적으로 보유가치가 하락했다는 것을 나타냅니다.
앞으로는...
Fun & Joy 또는 사용자의 관심을 위하여 아파트 관련 사회적 이슈나 분석 정보를 게시할 예정입니다.
전국의 모든 아파트를 아파트엔지수라는 점수를 부여한 것에 대한 부담이 있습니다. 하지만 보통의 부동산서비스가 실거래가만으로 이미 서열을 매기고 있습니다. 오히려 가격을 포함한 다른 요인으로부터 지수를 부여했기에 좀 더 객관적이라고 생각합니다.
베타이기에 평가를 위한 모델 부분에 지속적 개량이 수행될 예정입니다. 저희 프로그웍스를 아껴주시는 많은 분들께 작은 응원과 격려 부탁드립니다. 또한 격려와 응원에 보답하고자 서비스 제작 중 터득한 노하우도 본 블로그를 통해 점차로 공개하겠습니다.
본 카테고리의 이전글(PostGIS를 이용한 격자 만들기)에서 사각형 그리드 격자를 만들었습니다. 격자를 제작한 목적은 이전글에서 설명했듯이 특정 데이터셋의 격자별 집계 수행을 통해 분석을 진행하기 위함입니다. 본 게시글을 통해 실제 집계를 설명합니다.
1. 데이터 준비
격자는 준비했습니다. 실제 집계의 대상이 되어야 하는 데이터가 필요합니다. 저는 "공공데이터포털(data.go.kr)"에 접근하여 "데이터셋 > 표준데이터"메뉴에서 "전국 CCTV 표준 데이터"를 선택했습니다. CSV형식으로 제공받았기에 실제 PostGIS에 적재하는 전처리 작업이 요구됩니다. 전처리 작업 절차는 아래와 같습니다.
Qgis에서 "쉽표로 구분된 텍스트 레이어 추가" 후 형상을 확인합니다. 이 후 DB연결을 통해 PostGIS에 적재합니다.
Qgis에서 Import된 레이어를 선택한 후 내보내기를 실시하여 Shp 형식으로 저장합니다.
Qgis에서 데이터베이스 연결 후 "파일가져오기"를 실시하여 PostGIS에 적재합니다.
원본에 위도, 경도 속성이 존재하며, 좌표계는 4326입니다. 필자는 PostGIS에 적재 후 좌표계를 5179로 변환했습니다. 미리 제작된 격자가 5179좌표계이기 때문에 변환했습니다.
마지막으로 공간인덱스를 생성합니다.
2. 집계 실행
실제 질의는 아래처럼 단순합니다. SQL의 세부사항을 설명하지는 않겠습니다. 격자개수만큼 박복하며 교차여부를 검사하여 CCTV를 격자별로 개수합니다. 즉 격자 개수가 많으면 많을 수록 실행 성능은 떨어질 수 밖에 없습니다. 집계하고자 하는 대상에 따라 격자크기가 결정되야 합니다. 또한 눈썰미가 있다면 "count()"함수를 대신하여 숫자 필드를 대상으로 sum, median 등 다양한 함수의 적용이 가능합니다. 개수가 아닌 양, 추세 등이 중요한 경우입니다.
CREATE TABLE tempsubtotal AS SELECT count(*) AS cnt, bound.geom AS geom FROM temp_20200206020231 bound LEFT JOIN ms101_20200207020227 counted ON ST_Intersects(bound.geom, counted.geom) GROUP BY bound.geom;
이 후 Qgis를 통해 PostGIS에 접속하여 새로이 생성된 집계 테이블을 레이어로 추가한 후 보게되면, CCTV가 많을 수록 짙은 빨간색으로 나타나는 것을 볼 수 있습니다. 이는 Qgis의 시각화 속성을 이용한 것으로 고정색이 아닌 특정 컬럼을 대상으로 시각화를 지정한 것 입니다.
데이터 및 처리는 PostGIS 에서 수행하고, 시각화는 사용자가 가지는 도구를 이용합니다. 아마도 실제 프로젝트에 적용한다면 데이터 처리 영역과 시각화 영역은 특별한 경우를 제외하고 철저히 분리하는 것이 좋습니다.
3. 맺으며
PostGIS 사랑스럽지 않습니까? DBMS에 SDE(Spatial Data Extension)를 추가하는 것만으로 GIS업무의 많은 부분을 처리할 수 있습니다. 시각화라는 부분을 제외하면 일반적 공공정보화사업에 무리없이 사용될 수 있습니다. 정의도 제대로 못하는 GIS엔진이 정말 필요할까요?
제게는 PostGIS가 그런 존재입니다. 사용하면 할수록 대견스럽고 사랑스럽습니다. 데이터 시각화라는 부분만 제외하면 대부분의 공간정보 처리가 가능합니다. 한동안 바쁘다는 핑계로 포스트 작성에 소홀했습니다. 하지만 사랑이 변할 수 있나요. PostGIS가 제공하는 함수(ST_Translate)를 이용하여 격자 데이터를 만들겠습니다. 응용하면 "Hexagonal Grid"등 반복되는 도형을 가지는 격자 데이터를 생성할 수 있습니다. 모양은 아래 그림을 참조하십시오.
격자의 쓰임은 다음과 같습니다. 첫째, 격자 단위로 다른 객체(POI 등)를 위상관계(Topology)에 따라 집계해서, 개별 격자 별 밀집도가 높은 지역을 식별하기 용이합니다. 둘째, 불변하는 집계(Sub Total) 데이터를 생성하는 기준 도형이 될 수 있습니다. 변하지 않는 격자를 기준으로 데이터 생산 시점 별 집계를 수행하여 일관된 비교가 가능한 시계열 데이터를 생성할 수 있습니다. 이러한 기준은 행정경계도 가능하겠지만 인구의 가감 등으로 향후 변경이 발생할 여지가 있기 때문에 격자가 기준으로 적합할 수 있습니다.
이러한 격자는 육각형의 벌집 모양으로도 반복할 수 있지만 가장 쉬운 바둑판 형식의 격자를 제작하겠습니다. 인터넷에서 "Fishnet Grid"를 검색하면 다양한 제작 방법을 찾을 수 있습니다. 저는 PostGIS의 공간함수를 이용하여 SQL Function을 제작합니다. 제작된 Grid는 Qgis에서 형상을 확인합니다.
1. 함수 원형 및 설명
CREATE OR REPLACE FUNCTION __progworks_rect_grid_on_linearUnit_M( grid_count_x integer, grid_count_y integer, grid_size_x integer, grid_size_y integer, start_x double precision, start_y double precision, target_srid integer) RETURNS varchar AS $$ DECLARE target_table_name text; BEGIN EXECUTE format('SELECT ___progworks_new_table_name(''%s'')', 'temp' ) INTO target_table_name; EXECUTE format('CREATE TABLE IF NOT EXISTS %I AS SELECT i+1 AS col, j+1 AS row, ST_Translate(cell, i * %s + %s, j * %s + %s) AS geom FROM generate_series(0, %s - 1) AS i, generate_series(0, %s - 1) AS j, (SELECT ST_GeomFromText(''POLYGON((0 0, 0 %s, %s %s, %s 0,0 0))'') AS cell) AS ORIGIN;', target_table_name, grid_size_x, start_x, grid_size_y, start_y, grid_count_x, grid_count_y, grid_size_y, grid_size_x, grid_size_y, grid_size_x ); EXECUTE format('SELECT UpdateGeometrySRID(''%I'', ''geom'', %s);', target_table_name, target_srid ); return target_table_name; END $$ LANGUAGE plpgsql;
2. 함수 설명
위 함수의 입력 파라미터를 간단히 설명하면 입력된 좌표(start_x, start_y)를 바둑판의 시작점(우리나라에서 사각형의 좌하단 지점)으로, 가로길이(grid_size_x)와 세로길이(grid_size_y)의 격자가, 가로축 방향으로 지정된 갯수(grid_count_x), 세로축으로 지정된 갯수(grid_count_y)만큼 가지는 격자를 생성하라는 것입니다.
이 때, 생성되는 격자는 지정된 좌표계(target_srid)를 가지도록 정의합니다. 굳이 SQL 함수 이름 끝에 LinearUnit_M을 붙여준 이유는 meter로 거리를 나타내는 좌표계를 사용하라는 뜻입니다. 4326으로 표시되는 경위도 좌표계는 AngularUnit의 degree를 사용하는 구면좌표계로 위경도에 따라 정확한 거리 지정이 불가능합니다. 물론 좁은 지역이라면 상관없습니다. 하지만 정확한 격자크기의 보장을 위해 평면으로 투영된 좌표계 사용을 권장합니다.
함수 내부를 보면 미리 정의된 격자 폴리곤이 WKT 형식으로 존재합니다. 기준 폴리곤은 가로, 세로 각각 0을 기준으로 사용자가 지정한 크기(grid_size)로 이루어지도록 정의 됩니다. 이후 질의 실행에 따라 generate_series 함수가 호출될 때 마다 ST_Translate 함수가 기준 폴리곤을 지정된 위치로 옮기며 새로운 개별 격자를 생성하는 형식입니다.
실제 함수를 실행하여 등록한 후 아래와 같이 함수를 호출합니다. 만들어진 격자는 Qgis를 통해 확인하겠습니다.
공공정보화사업 부문에 편중될 수 밖에 없는 공간정보산업의 영세함으로, 접하게 되는 고객의 대부분은 공공부문에 근무하고 계십니다. 프로젝트 관련하여 많이 받게되는 질문은 "GIS Engine은 어떤 것을 사용합니까?" 입니다. 수행해야 하는 프로젝트가 물품구매 형식의 GIS Package SW 납품이라면 쉽게 답할 수 있습니다. 그러나 보통 공간정보 분야 용역사업은 어떤 목적을 이루기 위한 개발 사업입니다. 필자는 "GIS Engine" 이 무엇이지 쉽게 설명하고 싶은데 사전에서 찾을 수 없습니다. 물론 Wikipedia에서도 찾을 수 없는 Local 정의어 입니다. 어떻게 표기를 해야할지도 모르겠습니다.
인터넷 탐색으로 Arcgis Engine의 정의는 찾을 수 있습니다. "ArcGIS Engine is a complete library of embeddable GIS components for developers to build custom applications"
ArcGIS 엔진은 개발자가 GIS 응용 어플리케이션 개발을 할 수 있도록 지원하는 컴포넌트의 집합인 것 같습니다. 그렇다면 GIS엔진은 흔히 말하는 경로찾기, 지오코딩 등 수많은 서비스 또는 컴포넌트가 언어나 사용자 환경에 상관없이 호출되어 사용될 수 있도록 하는 어떤 것들의 집합이라고 정의할 수 있을까요? 어렵습니다. 여기에도 모순은 존재합니다. 안타깝게도 저에게 질문을 던진 고객은 공무원 이며 개발자가 아닙니다. 아무리 좋은 컴포넌트를 준다고 한 들 사용할 수 없습니다. 또한 프로젝트 결과물의 최종 사용자도 대부분 일반 사용자이거나 공공기관 업무용 SW로 공무원을 대상으로 합니다. 이 분들은 절대 개발을 하지 않습니다. 컴포넌트 집합이라고 정의하면 사용자가 너무 한정됩니다.
일반적으로 GIS SW 또는 공간정보 분야 서비스 어플리케이션은 아래와 같이 구성됩니다. 저는 사용자 UI를 가지고 GIS Data에 대한 CRUD가 발생하기 위해 대부분 3계층으로 구성합니다.
1. 데이터를 제공하는 "Data Provider 계층" ==> 서버영역 2. 데이터를 처리하는 "Process 계층" ==> 서버, 클라이언트 영역 3. 데이터를 보여주는 "Presentation 계층" ==> 클라이언트 영역
3계층으로 구성되는 배치 구성을 통해 GIS Engine을 정의할 수 있을까요? 위의 3가지가 유기적으로 연결되는 것은 특정 비즈니스 목적에 맞도록 어플리케이션이 제작되는 것입니다. 이는 주문형 SW로 특정 업무분야(재난, 교통, 통계,...)에 최적화되는 것으로 GIS엔진이라고 정의하기는 무리가 있습니다.
"Data Provider" 계층은 파일시스템 또는 DBMS 영역으로 독립적 구성을 가집니다. 공간속성을 가지는 GIS Data는 "Data Provider"계층에서 수용해야하는 많은 종류의 데이터 중 단지 하나일 뿐입니다. 범용성, 활용성 등을 고려하면 오히려 GIS엔진보다 훨씬 넓은 영역입니다.
"Process"계층은 어쩌면 GIS엔진이라고 정의할 수 있을 것 같습니다. 흔히 말하는 공간연산 등 굳이 공간정보를 다루는 특화된 기능이 적재될 수 있는 공간입니다. 여기에도 모호한 부분이 존재합니다. 공간정보를 다루는 기능의 구현형식이 XML Web Service, Restful Service,.. 무엇이 되든 결국은 개발자 또는 전문가를 대상으로 하고 단독으로는 존재할 수 없는 문제가 있습니다.
"Presentation"계층은 GIS엔진이라고 정의할 수 있을까요? 이 또한 어려워 보입니다. Presentation계층에서 가장 중요한 것은 Data 시각화 입니다. 최근의 정보화 추세는 Thin Client 방식의 구성을 선호합니다. 당연히 데이터 영역과 시각화 영역을 분리합니다. 업무 목적에 따라 같은 데이터라도 시각화 형식은 다를 수 있습니다. 시각화의 목적은 데이터를 통해 Insight를 얻는 것입니다. 이는 보통 "BI(Business Intelligence"라고 말하며 그 부분에 공간정보의 시각화도 포합됩니다.
일반적으로 말하는 GIS정의만으로 어떤 목적을 설명하기는 어렵습니다. 빅데이터가 생산되는 최근의 정보 환경에서 하나의 기술 또는 정의만으로 목표를 달성하기는 너무 어렵습니다. 실제 요즘 모든 분야에서 GIS 기술은 활용되고 있습니다. 최근 코로나 바이러스 상황에서 코로나 지도가 바로 인터넷에 공개되는 것은 GIS기술이 얼마나 빠르게 수요시점에 적용될 수 있는가를 말하고 있습니다. 이러한 수요란 공급자가 아닌 사용자가 결정하는 것으로 GIS 엔진의 필요성이나 기능은 사용자 환경에 따라 다를 수 있습니다.
확실한 한가지는 타 기술 분야와 융합될 수 있는 유연함이 GIS엔진이 가져야하는 조건입니다. 필자의 20년 경험으로 GIS엔진을 정의할 수 없네요.두서없이 길었지만 필자가 전하는 의견은 단 하나입니다.
무얼 만들지, 누구를 위해 만들지가 중요한 것 같습니다. GIS엔진의 모호한 정의는 자칫 프로젝트를 어렵게 할 수 있습니다. 애매모호한 요청에는 두리뭉실한 답변이 갈 수 밖에 없습니다. 굳이 공공정보화사업이라면 GIS엔진을 말하기보다는 이루고자하는 가치를 명확히 하는 것이 중요합니다. GIS엔진(?)은 그 다음에 고민하는 것이 맞을 것 같습니다. 공간분석이라는 그 들만의 리그에서 벗어나야 하지 않을까하는 소견을 밝히며 마무리합니다.
