그간, 지도를 만들기 위해서 이런 저런 기술을 습득해왔습니다.

어쩌다 보니, 박사과정까지 가게 되었고 박사는 수료한채 (하지만, 논문 검색을 하면 그래도 두자리수 이상의 논문이 나오기에, 학계에 충분한 발자취를 남겼다고 생각합니다..) 회사로 오게 되었습니다.

회사는 대단한곳입니다. 학교와 달리 엄청난 데이터와 인프라가 있습니다. 그리고 실력좋은 동료들도..

기술적으로 성장하였습니다. 기술적으로 뭔가를 남기고 싶었습니다. 그렇지만 회사에 가서 많이 부족함을 느꼇습니다. 거드름을 피우기엔 아직 실력이 부족합니다. 

한편, 제가 다룰 수 있는 데이터와 도구가 이전보다 더 제한적으로 되었습니다.

 

제가 무엇을 더 기여할 수 있을까 고민하였습니다.

지도를 만들기위해서 기술을 배웠고, 지도를 만들면서 어떻게 더 나은 지도를 만들지 꾸준히 생각했습니다.

기술은 북미, 유럽 형님들이 잘 해주시는것 같습니다.

그렇다면 제가 해야 할 것은 지도를 만들때 나의 의도를 잘 담아야하는 것 같습니다. 혹은 나의 의도를 지도를 통해서 잘 전달해야하는 것 같습니다.

그러니까...기술보다 방향을 제안해보려고 합니다.

가령, 얘네들은 A로 표현하고, B로 표현했네? 왜 그랬지? 무슨 의도일까? 그러니까 나는 어떻게 해야하지? 같은 쓸데없는 글입니다. 

 

Cartographer. 이것은 제가 원하는 타이틀입니다.

새로운 둥지는 이곳입니다. 오랜기간 한국생활로 영어 글쓰기가 서툴러졌지만, 계속 proofreading하고 있습니다.

 https://pil0706.github.io/

반응형

N개의 포인트가 포함된 테이블이 있고, 각 포인트별 가장 가까운 포인트를 매칭시키고 싶었음

스택오버플로우에는 고정된 1개의 포인트에서 다른 포인트 셋의 거리를 구하는 것이 주된 정보여서 한동안 헤맸는데,

왜 Arc나 Q에서는 흔하게 있는 최근린분석을 왜 기본 함수로 안갖고 있는 것이 의문이긴 함


TRIAL #1

처음으로 작성한 코드는 아무 생각없이 작성했더니 distance matrix를 만드는 코드를 만들게 되어버림


SELECT ST_Distance(a.[shape], b.[shape]))

  FROM [table] a, [table] b

  ORDER BY st_distance


아무 생각없이 짠 코드는 N^2의 시간을 요구하고 LIMIT을 걸어서 보면 절대론 해선 안되겠다는 생각을 하게 됨



TRIAL #2

굳이 distance matrix를 만들 필요가 없으므로 한가지 꼼수를 생각해봤는데,

해당 포인트들을 하나의 멀티 포인트로 변환한다음에 매번 거리 계산을 할 때 자기 자신을 빼고 거리를 재는 방식

결과는 성공적으로 나오긴 하는데 어떤 포인트와 정확히 매칭이 되는지는 모르고 거리만 return함

또한 인덱싱이 되지 않고, 2N의 시간이 걸려 포인트가 많아질수록 연산량이 대폭 증가


WITH point_set 

  AS(SELECT ST_Multi(ST_Union([shape])) 

      FROM [table]

SELECT a.[id], ST_Distance(a.[shape], ST_Difference(b.st_multi, a.[shape]))

  FROM [table] a, point_set b

  ORDER BY st_distance

  

TRIAL #3

KNN을 이용한 거리를 재면 인덱싱이 된다고 해서 이 방법으로 시도

<-> 을 LIMIT 1을 걸어서 최근값 1개만 받아내고, 자기자신을 제외하기 위해 id가 서로 다른 <> 값들을 받아냄

인덱싱이 되어있기 때문에 LIMIT 1로 상당히 빠르게 값을 return 하고,

그 결과를 CROSS JOIN 해서 각 포인트들이 서로 매칭되는 것을 알 수 있음 


SELECT a.mid, a.name_dp, closest_pt.mid, closest_pt.dist

  FROM [table] a

  CROSS JOIN LATERAL

    (SELECT mid, name_dp,

      a.[shape] <-> b.[shape] as dist

      FROM [table] b

      WHERE a.[id] <> b.[id]

      ORDER BY a.[shape] <-> b.[shape]

     LIMIT 1) AS closest_pt

  ORDER BY closest_pt.dist


APPLICATION 

위의 방식을 이용해서 내가 원하는 데이터에 적용해봄

내가 다룰 데이터는 만개 단위의 포인트이므로, 분석을 하고자 하는 지역을 적당한 크기로 자르고 싶었음

따라서 해당하는 좌표값을 찾은 뒤에 적당한 반경을 설정하고 그 영역에 속하는 포인트들 중 

특정 칼럼에 원하는 값을 지닌 포인트들만 골라서 다시 테이블로 만들어 분석함


WITH sampling_table

  AS(SELECT

      FROM [table]

      WHERE [column] IN ([target value])

      AND ST_DWithin(

        [shape]

        ST_SetSRID(ST_MakePoint([X][Y]), [EPSG]), [radius]))

SELECT a.[id], closest_pt.[id], closest_pt.dist

  FROM sampling_table a

  CROSS JOIN LATERAL

    (SELECT [id],

      a.[shape] <-> b.[shape] as dist

      FROM sampling_table b

      WHERE a.[id] <> b.[id]

      ORDER BY a.[shape] <-> b.[shape]

     LIMIT 1) AS closest_pt

  ORDER BY closest_pt.dist



기존에 10분이 넘게 걸리던 작업이 1분 내로 값이 나옴

기쁨

반응형

엄청 어렵다.

회사일도 바쁘고 집안일도 많이 있고

날은 너무 덥고


기존의 분석을 해서 이를 컨텐츠 생산하는게 매우 어렵다. 시간도 매우 많이 들기도 하고

약간 스크랩 형식으로 바꾸면 어떨까 생각도 든다.

반응형

생각정리.


역시나 밤은 생각이 많아진다.

이래서 사람은 밤에 자나보다.


5년간 기거했던 관악구, 낙성대동을 떠나려니 기분이 묘해서

연구실 사람들을 만났다.

미싱은 여전히 잘도 돌고있었다.

QGIS 를 부쩍 많이 다루고 있고 회사내 개발자분들에게도 '전도'를 하고 있어서 신기하기도 하다.


너무 업데이트가 안되서 죽었다고 생각하는데, 역시나 컨텐츠를 올리는거는 쉽지 않다.

동영상 컨텐츠가 부쩍 증가하고 있는데, 동영상이 쉬울지는 모르나 편집또한 큰 노고가 든다.


역시나 글로 회포를 푸는게 아재가 되어가는 나에게는 맞는듯.


이글을 20년후에 지금 꼬꼬마들이 읽으면, 아 아재감성이라고 할 것 같다.

건조기에서 빨래 가져와야겠다.

생각정리 끝.


PS : 시간날때 업데이트 합니다.

컴터 포맷 3일전에 했어요 그리고 다시 Postgresql이랑 Postgis설치중이에요.

QGIS 3.0도 설치중입니다.

반응형

불필요한 vertex 제거하기


v.build.polylines GRASS 사용



혹은 Dissolve를 하게 되는경우 Pseudo-node 제거가 가능해짐

반응형

좌표가 있는 CSV를 importing 후 postgresql에서 ST_MakePoint를 이용하여 Point 를 만들기


1. 테이블에 geometry 컬럼 추가 및 좌표 설정

alter table part_test

add column shape type geometry(point, 4326);

이거다...

add column shape geometry(point, 4326);



2. geometry 컬럼에 Lat, Lon 넣어 계산

update part_test

Set shape = ST_SetSRID(ST_MakePoint(lat, lon), 4326);



근데 왜 안되냐.. 

반응형

'지도쟁이들 분석노트 > :P 지도를 만드는' 카테고리의 다른 글

글쓰기  (0) 2018.07.17
Pseudo-node 제거하기  (1) 2018.04.05

당분간 진행을 바꾸려고 합니다

당초엔 나중에 책으로 만들고 싶은 마음에 모델빌더라는 주제로 디테일하게 내용을 점차 채워나가려고했으나...

생각보다 제 시간이 빠듯하게 흘러가고, 글쓰는데 예상 이상의 에너지가 소모되고, 현재 프로세싱모델 보다 다른 공부에 가중치를 두고싶어요.

그래서 글이 '이런저런 문제를 해결하고 싶으면 이렇게하면 되요!' 에서 '난 이 문제를 이렇게 해결했어요!'로 바뀔 것 같네요.




0. 

아파트를 평가하는 내용의 작은 부동산 관련 프로젝트에 참여하면서 작업한 내용입니다.

제가 해결해야되는 문제는 '아파트에서 통학하게 되는 초등학교들까지의 거리를 구하는 것' 입니다. 아파트와 초등학교를 매칭하는 작업 및 거리를 구하는 작업을 수행해야합니다.


초등학교는 무조건 가까운 곳에 가는 것이 아니고 학군개념이 존재합니다. 그 학군에 존재하는 거주자들은 지정된 초등학교에 통학하게 됩니다. 학군자료를 구해왔습니다. 아래 그림의 예시를 보면 저 범위에 포함된 거주자들은 서울세검정초등학교에 다니게 됩니다.


그리고 필요한 아파트 정보와 서울시의 초등학교 위치정보를 구해옵니다. 각 아래와 같이 분포하고 있고, 초등학교의 경우 데이터가 멀쩡하다면 한 학군에 한 개씩 배정되어 있겠지요.(실제로는 공동학군이 존재해서 조금 더 머리아픕니다.) 


'초등학교 통학 구역'의 폴리곤 데이터와 '아파트', '초등학교'의 포이터 데이터를 통해 각 아파트에 매칭되는 초등학교를 구하고, 그 거리를 계산하는 것이 목적입니다.




1. 

초등학교 통학 구역, 즉 학군을 key로 사용해서 아파트와 초등학교의 정보를 엮었습니다.

i. 각 초등학교에 매칭되는 학군 ID를 부여합니다.

ii. 각 학군을 iteration 하며, 학군 내에 존재하는 아파트와 ID와 매칭되는 초등학교를 매칭시킨 뒤, 거리를 구했습니다. 


 i - 초등학교에 학군id 부여

각 학군 id 마다 iteration을 하며, 'Select Layer by Location'을 통해 학군 위에 존재하는 학교를 선택하고 그 id를 부여합니다. 

학군 id를 부여하기 위한 expression은 "%Value%" 을 사용하면 됩니다.


* 혹여나 의문이 있으실까봐. 학군을 굳이 초등학교 이름을 매칭하는 속성기반의 방법이 아닌 location 기반으로 넣어준 것은.. 학군과 초등학교 데이터의 갱신일이 달라 생기는 결함을 줄이기 위함이었고, 내용에 다루진 않지만 이렇게 하는 것이 공동학군을 처리하기 편했습니다.




 ii - 아파트와 학교간 매칭 및 거리 계산

학군 id 마다 iteration을 하며, 학군 위에 존재하는 아파트들과 id와 매칭되는 초등학교를 선택한 뒤, point distance를 통해 매칭과 거리계산을 한꺼번에 수행했습니다.

학군 파일을 iteration row selection을 통해 학군id 마다 iteration하고, 이를 이용해 아파트 포인트에 select by location을 수행하여 학군 위에 존재하는 아파트들을 선택합니다. 동시에 초등학교는 속성정보인 학군id를 통해 매칭합니다. 속성정보 매칭을 위한 expression은 "학구도" LIKE '%Value%' 입니다.

* arc 내에서 ""과 '' 사용이 헷깔립니다. 저는 파이썬 관련 문법이면 "", 쿼리 관련은 '' 은 사용한다는 방식으로 기억하고있습니다.


2. 

쨘! 아파트마다 초등학교와의 매칭 및 초등학교까지의 거리를 계산했습니다. 결과는 각 학군id가 이름인 테이블들로 추출됩니다. 이를 하나의 파일로 append 한 뒤, FID를 통해서만 매칭된 형태(Point Distance의 추출결과)에 필요한 정보를 각 아파트 및 초등학교와 join해서 가져오면 됩니다.

직접 구현해서 활용하고 싶으시면 주황색육각형으로 표시되는 Iteration과 노란색 네모로 표시되는 Tool들을 위주로 살펴보시면 전체 흐름 따라가실수 있습니다.



Iteration은 정말 편리하고 강력한 도구입니다. 모델빌더의 다른 기능들은 노다가를 하기 귀찮아서 사용할 때가 많지만, iteration이 필요한 부분은 모델빌더가 아니면 안되거든요. 물론 arcpy를 통해 같은 기능을 사용할 수도 있지만, 직관적이고 간편하게 flow를 짤수 있는 것은 모델빌더의 큰 장점입니다. 경험상 iteration을 편하게 다루기 위해서는 iteration마다 활용되는 Value의 값을 잘 활용해야 되더군요. 고로 각 부분의 expression을 유의해서 살펴보시면 좋을 것 같습니다.

반응형

0.

ModelBuilder를 통한 공간조인 및 속성조인의 활용에 대해 다룬다.

공간정보를 다루다보면 여러가지 형태의 조인을 자주 활용하게된다. ArcGIS를 사용한다면 조인 자체는 간단하게 수행할 수 있지만, 작업한 여러 형태의 데이터를 추출하고 정리하는 것은 귀찮은 작업이다. 이때 ModelBuilder를 활용하는 방법이다. 본인은 국공유지 중 무단으로 점거된 필지를 추출하는 작업을 수행해봤고, 이때 활용한 ModelBuilder를 통해, 공간조인 및 속성조인을 다뤄보려고 한다.



1. 시나리오

주어진 데이터는 다음과 같다. 

Parcel : 연속지적도를 기반으로 생성된, 필지 단위의 데이터.

Object : 건물, 컨테이너박스 등의 시설물객체. 


목표는 위치정보만을 활용할 수 있는 레이어들이 주어졌을 때, 공간조인을 통해 관계를 추출하는 것이다. 즉, 각각 parcel 위에 존재하는 object에 대한 레이어, object가 올라가있는 parcel의 레이어를 추출하는 것을 최종목표로 한다.

ArcGIS는 공간조인을 위해 Spatial Join, Select by location 등(실질적으로 같은 작업의 다른 이름이다)의 기능을 제공한다. 공간조인을 통해 중첩되는 object과 parcel에 대한 정보를 추출하고, 추출한 정보와 기존의 각 object, parcel 레이어들을에 대해 속성정보 기반의 테이블 조인을 수행해 필요한 레이어를 생성한다. 실질적인 작업은 다음과 같은 순서로 이루어질 것이다.

  1.  공간조인 기능을 활용해 parcel 위에 존재하는 object들을 추출한다.
  2.  추출한 I를 기반으로, object가 존재하는 parcel을 추출한다.


2. ModelBuilder

전체 과정을 모델빌더로 작성하면 다음과 같다. 특히, 1번을 통해 I을 수행하고, 2번을 통해 II를 수행한다.

2.1 Spatial Join

"Spatial Join"이라는 공간조인 툴을 활용해 object와 parcel의 위치관계 정보를 추출했다. 

"Spatial Join"를 사용하기 위해서 다양한 입력변수 및 option을 입력해야된다. ArcGIS 기본적으로 입력해야되는 각 항목들에 대해 친절하게 설명을 해주기에 그때그때 읽어보면서 사용하면되고, 어떤 상황에서 필요한 툴이 무엇인지 아는 것이 중요하다. 고로 이러한 문제가 해결하기 위해 "Spatial Join"을 활용한다는 것만 확실히 기억하도록하면 된다. 여기서는 필수적인 항목인 Target Features, Join Features, Matching option에 대해서만 간략하게 언급하고 넘어가겠다.

Match option은 공간조인을 하는 방법을 선택하는 옵션으로 경우 굉장히 다양하다. "intersect", "closest", "HAVE_THEIR_CENTER_IN", "within", contains" .... 등. 여기서 설명하기에는 너무 방대하고, ArcGIS는 간단한 설명을 함께 제공해주니 이를 읽어보고 목적에 부합하는 것을 사용하는 것이 가장 좋다. 본 작업에서는 데이터의 특성(간략하게, parcel의 형태가 장방형인 것들이 다수 존재하고, object 데이터가 불완전했기 때문에 엄밀한 기준의 매칭을 할 필요가 있었다)으로 인해 object의 중심점이 parcel 내부에 위치하는 경우에 대해서 공간조인을 수행하는 "HAVE_THEIR_CENTER_IN"를 선택했다. 

Target Features와 Join Features는 각각 공간조인을 수행할 때 결과로 추출되는 레이어, 기준이 되는 레이어를 뜻한다. 공간조인의 목적과 Match option에 따라 올바른 선택을 해야한다. Target과 Join이 바뀔 경우 같은 공간조인에 대해 주체가 object냐 혹은 parcel이냐에 대한 문제가 아닌 상이한 결과가 추출된다. 거꾸로 한 경우, 중심점이 object 내에 존재하는 parcel이 추출될 것이다! 얼마나 다른 결과일지 상상해보라.

* 참고로 "Select by location" 이라는 툴도 비슷한 역할을 수행한다. 툴을 열어보면 입력 항목 및 옵션 등이 "Spatial Join"과 완전히 동일한 것을 알 수 있다. 차이점은 "Spatial Join"은 공간조인 후, 새로운 레이어로 결과를 추출해 주는 반면에, "Select by location"은 물론 동일한 결과에 대해, 각 항목들을 select만 한 채로 작업을 마무리 한다. 본 모델에서는 'parcel 위에 존재하는 object에 대한 레이어'를 한번에 추출하기위해 "Spatial Join"을 사용했다.

"Spatial Join"에 object를 Target Features, parcel을 Join Features로 연결한다. Match option은 "HAVE_THEIR_CENTER_IN"을 선택했다. 결과는 object_SpatialJoin.shp로 추출되고 다음과 같다. parcel 위에 존재하는 object들만 선택이 된 것을 확인할 수 있다.


2.2 Join

"Add Join" 툴을 기반으로, 생성한 object_SpatialJoin 레이어와 속성정보를 통한 조인을 활용하여 object가 위에 존재하는 parcel을 추출한다. 

object_SpatialJoin에는 연관된 object와 parcel의 필드가 모두 존재하기 때문에 이를 활용해 parcel과 테이블 조인을 수행했다. 필드 기반의 Join을 위해서는 각각 특징이 있는 여러 Tool이 존재하지만 본 작업에서는 "Add Join"을 활용했다. "Add Join"은 ArcGIS를 활용할 때 가장 기본적으로 사용하는 Join 툴이다. 레이어나 테이블에 마우스 우클릭을 통해 Join/Relate를 선택해 수행하는 방법이 "Add Join"에 대응된다. 입력 및 동작이 이와 같기 때문에 따로 설명은 하지 않겠다

*혹은 "Join Field"라는 툴을 사용할 수도 있다. 차이점을 살펴보면, "Add Join"의 경우 테이블을 조인한 상태로 작업을 끝내지만, "Join Field"의 경우 조인 후, 입력 테이블 혹은 레이어에 테이블조인한 레이어나 테이블의 필드를 복사해서 가져온 뒤, join을 제거하는 것까지의 작업을 수행한다. 기존의 데이터에 특정 값을 추가하는 등의 특정 목적의 작업수행에서는 하나의 툴로 깔끔한 결과를 얻을 수 있지만, 작업속도가 상대적으로 많이 느려진다. 본 작업에서는 'object가 올라가있는 parcel의 레이어를 추출', 즉, 기존 레이어에 값을 추가하는 것이 아닌 새로운 레이어를 생성하는 것이 목적이기 때문에 "Add Join"을 활용했다.

이후의 과정은 조인한 테이블을 바탕으로 새로운 레이어를 추출하는 것에 대한 내용이다.

"Copy Feature" 툴을 통해, "Add Join"을 통해 얻은 object가 올라가있는 parcel에 대한 데이터 복사하여 새로운 레이어로써 추출했다. 이를 위해 약간 팬시한 트릭을 사용했다. "Spatial Join"과 "Add Join"의 과정에서 모두 'Keep All Target Features' 항목을 off 해 두었다. 이를 통해 "Copy Features"까지의 flow를 보면 추출되거나 조인된 항목만을 전달하고 있다. 즉, parcel(3)에는 object_SpatialJoin과 조인된 parcel들만 존재한다. 그렇기 때문에 조인된 항목을 select 후 "copy feature"를 사용할 필요 없이, 바로 결과를 추출할 수 있다.

마지막으로 "Remove Join" 툴을 이용해 레이어간의 조인을 제거했다. 큰 문제는 아니지만, "Remove Join"을 수행하지 않는다면 parcel 데이터가 object_SpatialJoin과 조인된 parcel들만 존재하는 parcel(3)의 형태로 유지되게 된다. 즉,  parcel과 parcel_CopyFeatures가 같은 형태로 출력된다. 직관적이지 않은 형태이므로, 모델빌더 내에서 처리하기 위해서 "Remove Join"을 수행해 Join을 없앰으로써 parcel 데이터를 기존의 형태와 같게 만든 후 출력하도록 한다. parcel_CopyFeatures를 'precondition'으로(모델빌더의 점선의 화살표 형태) Remove Join에 연결해주어 parcel_CopyFeatures이 추출되기전에 Join이 해제되지 않도록 한다.

1. "Add Join"의 Layer Name or Table View에 parcel data를, Join Table에 object_SpatialJoin를 입력한뒤, 조인을 위한 공통필드를 선택한다. 2. "Copy Feature"를 통해 object_SpatialJoin와 조인된 parcel 데이터(즉, 우리의 목표)를 복사하여 parcel_CopyFeatures.shp 파일로 저장한다. 3. "Remove Join"을 통해 Join을 해제한다.

결과는 위와 같다. object들이 존재하는 parcel들이 추출된 것을 확인할 수 있다.


3.

설명을 위해 중간 과정의 파일을을 모두 보여주었지만, 위와 같은 모델빌더를 실행시키면 과정이 한번에 실행되고, 'object_SpatialJoin.shp', 'parcel_CopyFeatures.shp' 두개의 파일들이 지정된 장소에 생성되어 있다.

분리되어 관리되는 지역들에 대해 반복적인 공간조인 작업을 수행해야 할 때, 공간조인하는 과정에서의 파일을 모두 저장해서 관리해야될때, 나의 작업 상황을 동료에게 공유해야 될 때 이와 같은 모델빌더를 작업해서 활용하면 편리하다. 

반응형

공간정보를 다루다보면 데이터의 특성상 반복적인 작업을 정말 많이 수행하게된다. 

다루는 지역이 많아서든, 여러 조건에 대해 같은 작업을 수행해서든... 여러 이유로 인해 반복작업을 수행한다.


모델빌더를 사용하면 이러한 작업을 상당부분 축소할 수 있다. 

또한 나의 작업상황을 메뉴얼화할 때, 동료와 공유해야할 때 이를 통하면 굉장히 편리하다.



내가 아는 것을 어떻게 전달할지 고민을 해보았다. 내가 전통적으로 arcGIS나 ModelBuilder를 배운것이 아니기에, 체계적인 방식으로 전달할 수 있을 것 같진 않다. 하여 내가 필요에 의해 만들 었던 여러가지 모델빌더들을 그 상황과 함께 전달하려한다. 내가 데이터를 다루어보며 불편했던 문제들을 해결하기 위한 실용적인 방법들이기 때문에, 이러한 것들이 필요한 사람들이 있지 않을까 싶다.



PS.

목표는 ModelBuilder를 통해 구현한 모델빌더를 연재하고, 그와 유사한 형태로 QGIS의 Model Processer를 재현해보는 방식으로 연재해보려한다.



반응형

안녕하세요. SY입니다.

서울대 공간정보연구실의 석사이며, P님의 후배입니다.

학연을 통해 게시판 지분을 얻어냈습니다.


결론부터 말하면

저는 게시판에 ArcGIS의 ModelBuilderQGIS의 Processing Model에 대해서 연재할 계획입니다.




구구절절한 사연입니다.


"석사과정의 2년이라는 짧은 기간을 보낸 후 어떤사람이 되어있어야할까, 2년동안 내 몸값을 어떻게 올려야할까.."

에 대한 고민을 많이 했습니다. 연구실의 환경 및 제 관심사를 종합고려해보면 제가 목표하는 전문성의 방향은 '공간정보전문가 + 인공지능전문가'이지 싶습니다.

이러한 전문성을 논문만으로 증명하기에는 제가 무능력하다는것을 깨달은 참입니다. 하여, 그래도 공간정보를 할 줄은 안다는 일종의 certification을 남기고싶어 공간정보전문가 필님의 도움을 받아(본인 블로그니깐 많이 도와주지 않을까요?) 내가 해왔고, 할 수 있는 것들에 대한 기록을 남기는 것이 목표입니다.


목표로하는 공간정보전문가의 수준은.. 혼자서 프로젝트 하나를 맡아서 해결할 수 있는 사람이 되는 것 입니다.

연구실에 입지분석과 같은 공간정보 SW 활용이 필요한 의뢰가 들어오면 모두가 P님을 찾습니다. 간지폭발오지고지리고렛잇고아리랑고개를 넘어버리는 부분이죠. 이것이 제 목표입니다.


프로젝트 등을 통해 공간정보를 뒤적여보며 활용했던 ArcGIS의 ModelBuilder에 대해 연재해보려합니다. ModelBuilder의 장점은 보고서가 간지나집니다.  ... 그리고 복잡한, 혹은 반복적이고 지루한 작업을 시스템화 할 수 있습니다. 전문가로써의 멋짐을 담당하는 부분이자, 1인 프로젝트를 가능케하는 하는 부분이라고 생각합니다. 


이러한 이유들로 인해 게시판에 ModelBuilder에 대해 연재하려고 합니다. 1년 후 졸업할 때 쯤, 굉장히 실력이 늘어있을 제 모습이 기대됩니다 ^.^ ㅎ.ㅎ ㅋ.ㅋ ㅐ.ㅐ *.*

또한 여기에 더해 현직에 계시는 P님의 조언을 받아, model builder에 대응되는 QGIS의 processing model에 대한 내용을 공부해가며 같이 연재하려고합니다.



PS.

공부하면서 올려야해서 연재주기가 어떨진 모르겠습니다.

단기적인 목표는 게시물들의 퀄리티를 인정받아, P님과 YM님이 작성하고 계시는 QGIS 책에 한챕터 자리차지하겠다고 비벼보는 것입니다.


반응형

+ Recent posts