Find Travel Points in ArcGIS Pro (+Python)

ArcGIS에서 이동 가능 지점 조회하기

"어떤 출발점으로부터 일정 거리 또는 일정 시간 이내에 도달 가능한 지점을 찾기"는 기본적인 GIS 문제 중 하나입니다. 이 포스트에서는 ArcGIS에서 이 과제를 해결하는 방법을 간략히 정리해보겠습니다.

먼저 과제 해결의 기본적인 순서는 이렇습니다:
   (1) data setting
   (2) network dataset 생성
   (3) service area analysis
   (4) spatial join analysis

Fig2. Sequence of Solution

각 순서를 간략히 짚어보고 갑시다. 먼저 (1) 데이터를 생각해보죠. 일단 출발점과 도달점 후보들의 정보가 있어야 합니다. GIS 데이터가 크게 Point, Line, Polygon으로 나누어진다고 했을 때, Point 형태의 장소 목록이 있어야 할 것입니다. 다음으로 장소들 사이의 이동 경로를 표현하는 Line 형태의 데이터가 있어야 합니다.

즉 Point 형태의 장소 데이터와 Line들로 이루어진 경로 데이터가 필요합니다. 그런데 이 데이터들은 본격적인 분석에 들어가기 전에 일정한 가공을 거쳐야 합니다. 특히 Line 데이터를 네트워크 데이터처럼 가공해야 할 필요가 있습니다. ArcGIS에서는 경로 데이터로부터 (2)"network dataset"을 생성하고 사용할 수 있습니다. network dataset을 만들면 ArcGIS가 제공하는 network analysis 기능을 사용할 수 있고, 이를 이후 분석 과정에도 유용하게 사용할 수 있습 니다.

network dataset까지 생성하면 (3) Service Area 분석의 차례입니다. Service Area Analysis는 ArcGIS가 지원하는 Network Analysis 툴의 하나로, 각 지점으로부터 일정 거리 및 시간 동안 도달 가능한 영역을 찾아낼 수 있습니다. "service area"라는 이름이 직관적이죠? 예컨대 안테나 기지국으로부터의 신호가 서비스 가능한 영역을 찾거나, 피자집으로터 일정 시간 이내에 배달 가능한 영역을 찾는 데 이 기능을 이용할 수 있습니다. 우리의 목표는 일정한 거리 및 시간 동안 도달 가능한 "지점"을 찾는 것인데요, "지점"을 찾기 전에 먼저 도달 가능한 "영역"을 뽑아내기 위해 Service Area 분석을 사용하게 됩니다.

마지막으로 (4) Spatial Join Analysis입니다. 이 역시 ArcGIS가 지원하는 분석 툴의 하나입니다. 이 기능은 두 GIS 데이터의 공간적 중첩 영역을 뽑아주는데요, 만일 두 Polygon 데이터가 주어진다면 두 Polygon 사이의 중첩된 새로운 Polygon이 결과로 반환되고, Point 데이터와 Polygon 데이터가 주어진다면 Polygon 영역에 속하는 Point만 추려서 결과로 반환됩니다. 우리는 (3)에서 구한 Service Area의 Polygon 데이터와, 도달 가능한 지점들의 Point 데이터 사이의 Sptial Join Analysis를 실행할 것입니다. 그 결과가 바로 일정 거리 및 시간 동안 도달 가능한 지점들이 되겠지요!

이제 ArcGIS를 보면서 각 순서를 직접 밟아봅시다! 마지막에는 ArcGIS native Python 기능을 이용하는 방법도 소개해 보겠습니다.

1. data setting

먼저 Point 형태의 장소 데이터와 Line 형태의 경로 데이터가 필요합니다. 경로 데이터는 서울시 도로망 데이터를 다운로드 받아서 사용하고, 장소 데이터는 직접 생성하겠습니다.

데이터를 불러오기 전에, 저는 ArcGIS 프로젝트의 데이터베이스에 travel이라는 dataset을 먼저 만들었습니다. 이제 각 데이터는 이 travel dataset 밑에 import해올 것입니다. (Fig8. 참조)

서울시 도로망 데이터는 정부에서 만든 "Z_KAIS_TL_SPRD_MANAGE" 데이터를 사용했습니다. (왜인지 도로망 데이터는 국토교통부 사이트(들)에 올라왔다가 사라졌다가를 반복합니다... 링크가 계속 바뀌어서, 인터넷에서 "Z_KAIS_TL_SPRD_MANAGE"로 검색해서 찾아보는 편이 낫습니다.) 이 도로망 데이터는 seoul_raods라는 이름으로 불러왔습니다.

이제 seoul_raods를 바로 network dataset으로 변환하면 될까요? 변환 자체는 기술적으로는 가능합니다. 하지만 추가적 가공 없이 바로 network dataset으로 변환하게 되면 실질적인 네트워크 데이터로 사용할 수 없게 됩니다. 네트워크는 'edge'와 'node'로 구성됩니다. 서로 다른 'node'들을 여러 'edge'들이 연결하는 형태가 네트워크 입니다. 도로망과 같은 경로를 네트워크로 파악한다는 것은, 도로들의 교차점(junction)을 node로, 그리고 도로들을 edge로 파악한다는 것을 뜻합니다. 따라서 교차점의 정보가 제대로 주어져야 제대로 된 경로를 생성할 수 있습니다.

하나의 도로망 데이터는 여러 개의 Line들로 이루어져 있습니다. 만일 데이터 속의 각 Line이 실제 도로의 교차점마다 분절되어 있다면 굳이 추가 가공을 할 필요가 없습니다. ArcGIS와 같은 GIS 소프트웨어가 알아서 각 Line의 끝점을 교차점으로 파악하고 처리해주기 때문입니다. 하지만 데이터 속 Line들이 실제 교차점마다 분절되어 있지 않다면, 직접 분절을 해줘야 합니다. 서울시 도로망 데이터가 바로 그 경우입니다. 서울시 도로망 데이터 속 Line들은 실제 교차점마다 분절되어 있지 않기 때문에, 이를 그대로 network dataset으로 변환해 사용할 경우 실제 교차점을 통한 이동 경로를 찾을 수 없게 됩니다.

Fig3. Lines are not segmented

위 그림은 seoul_roads를 프로젝트의 map 위에 표시한 것입니다. 파란색 선이 각 도로인데, 특별히 가운데 십자로 교차하는 두 도로만 눈에 띄게 색상을 달리했습니다. 가로 방향의 초록색 도로와 세로로 뻗은 주황색 도로가 각각 하나의 Line Object를 이루고 있습니다. 이 상태로는 둘의 교차점이 잡히지 않기 때문에, 교차점에서의 실제 이동 가능한 경로가 누락되게 됩니다.

Fig4. Edit>Planarize

Fig5. Planarize Settings

ArcGIS의 Planarize라는 기능을 이용하면 Line들 사이의 교차점을 따라 각 Line을 더 작은 Line들로 분절할 수 있습니다. Edit 메뉴에서 Planarize를 클릭하면 뜨는 Pane에서, seoul_roads의 line object들을 선택한 후, Cluster Tolerance를 대강 0.0001m 정도 주고 실행하면 됩니다. 이때 모든 line을 선택할 경우 실행 시간이 꽤 길어지기 때문에 보고자 하는 지역의 line만 선택해도 좋습니다.

Planarize 실행 후 다시 맵에서 위 교차로를 확인해보면 아래 그림과 같이 실제 교차점을 따라 Line이 잘 분절된 것을 볼 수 있습니다. (색상은 직접 수정했습니다.) 이 상태에서 network dataset을 생성하게 되면 교차점에서의 좌회전 우회전도 모두 이동 경로로 제대로 계산됩니다.

Fig6. Lines are segmented

이어서 Point 형태의 장소 데이터를 직접 만들어 줬습니다. 이 데이터에는 hot_places라는 이름을 붙이겠습니다. hot_places의 field로 NAME도 만들어줍니다. 결과는 아래 그림과 같습니다.

Fig7.

여기까지 작업하고 나면 Catalog Pane에서의 데이터 구조는 다음과 같이 나타납니다:

Fig8. Catalog Pane

2. network dataset

다음으로 seoul_roads로부터 network dataset을 만들어야 할 차례입니다. 먼저 network dataset을 생성할 dataset을 준비해야 합니다. 새롭게 dataset을 만들어 앞서 작업한 데이터 클래스들을 옮겨줘도 되지만, 여기서는 지금까지 작업한 travel dataset을 그대로 사용하겠습니다.

Fig9. Analysis>Tools>Create Network Dataset

리본 패널의 Analysis 메뉴에서 Tools를 클릭하면 오른쪽에 Geoprocessing Pane이 뜹니다. 여기서 Create Network Dataset을 검색해 선택합니다. 이어서 Create Network Dataset Pane의 설정값을 다음과 같이 설정합니다.

• Target Feature Dataset: travel dataset (어떤 dataset으로부터 데이터를 불러올지 설정하는 항목)
• Network Dataset Name: travel_nd (만들어질 network dataset의 이름. 원하는 이름 사용)
• Source Feature Classes: seoul_roads (만일 다른 경로 데이터도 같이 쓰고 싶다면 추가해주면 됨)
• Elavation Model: (고도(z축) 좌표 정보가 있다면 사용하면 되지만 여기선 사용 안 함)

이제 Run을 눌러 실행시키면 travel_nd라는 이름의 새로운 network dataset이 travel dataset 밑에 생성됩니다.

Fig10. Create Network Dataset Settings

그런데 travel_nd는 Catalog Pane에서도 생성되고, Contents Pane(왼쪽 패널)에도 생성되는데요, 추가 가공이 필요하기 때문에 Contents Pane에서는 일단 삭제해줍니다.

이제 Catalog Pane에서 trave_nd를 우클릭 하고 property를 클릭합니다. 그럼 다음과 같은 창이 열리는데요, 여기서 network dataset의 속성을 설정해줘야 합니다.

Fig11. Network Dataset Properties

General 항목은 넘기고, Source Settings에 들어가봅니다. 여기서 첫번째 Sources 패널을 보면 "Edges"와 "Junctions" 항목이 있습니다. 여기서 "Edges"로는 seoul_roads를 사용한 것이고, Juntions는 ArcGIS가 새로 생성해준 것이라고 생각하고 넘어가면 됩니다.

Sources Settings에는 Vertical Connectivity 패널도 있는데요, 이건 3차원 z축 좌표 정보도 있을 때의 연결 방식을 설정하는 것으로 여기서는 넘어가겠습니다.

이어서 Travel Attributes 항목으로 들어가 봅니다. 여기서 Costs 패널에 가면 다양한 이동 비용 산정 방식을 설정할 수 있습니다. Restrictions와 Descriptors 패널에서는 차량 출입 불가나 높이 제한 등 다양한 경로상의 제한과 조건을 설정할 수 있습니다. 여기서는 모두 넘어가고 첫번째 Travel Modes 패널로 가겠습니다.

Fig12. Travel Modes

Travel Modes에서는 걷기, 달리기, 차량 등 다양한 Travel Modes를 설정할 수 있습니다. travel mode가 있어야 이후 Service Area 분석도 사용할 수 있습니다. 처음에는 아무런 모드도 만들어져 있지 않은데요, 여기서는 가장 기본적인 walking 모드를 생성하겠습니다. (Fig12. 참조)

속성 설정을 마쳤으면 이제 network dataset을 build해야 합니다. 다시 Catalog Pane에서 travel_nd를 우클릭 후 build (network)를 선택해 Run을 실행하면 network dataset이 build되고 Contents panel에도 추가됩니다.

3. service area analysis

이제 network dataset을 이용해 Service area 분석을 실행해 봅시다. 먼저 리본의 Anaylsis>Network analysis를 클릭하고 "Network Data Source"로 방금 만든 network dataset인 travel_nd를 지정해줍니다.

Fig13.

다시 아까의 Network analysis를 클릭하면 뜨는 여러 툴 중 Service Area를 선택합니다. Service Area를 클릭하면 바로 travel_nd를 source로 하는 데이터가 생성되어 Contents Pane에도 추가됩니다. 하지만 아직 실제로 만들어진 건 없습니다. 아직 Service Area 분석이 실행된 건 아닙니다.

이제 리본 영역을 보면 아래 그림처럼 Service Area Layer 패널이 추가되어 있습니다. 이어서 Service Area Layer 패널에서 Import Facilities를 클릭하면 뜨는 창에서, Input Locations에 hot_places를 추가하고 Apply 실행해줍니다. hot_places를 service area의 기준 지점들로 삼겠다는 설정을 해준 것입니다.

Fig14. Service area settings

다시 Service Area Layer 패널러 와서, Cutoffs 설정에서 거리 및 시간 범위를 설정해줍니다. 우리는 network dataset의 속성을 설정하면서 거리를 기준으로 한 travel mode만 만들었기 때문에 여기서도 거리를 기준으로 한 cutoff만 사용하겠습니다. 여기서는 100, 500, 1000 meter로 값을 설정했습니다. 즉 0~100, 100~500, 그리고 500~1000m 범위의 service area를 보겠다는 얘기입니다. 이제 Run을 클릭해주면, 그동안 설정한 내용을 토대로 한 service arear의 "영역"들이 생성됩니다. 이 새롭게 생성된 데이터는 Catalog Pane의 Serive area layer 밑의 Polygons 항목으로 표시됩니다. 만일 이 데이터를 저장해 나중에도 사용할 계획이라면, feature class로 export해주면 됩니다.

Service Area/Polygons의 Attributes table을 열어서 지도와 함께 살펴보면 다음 그림과 같습니다.

Fig15. Service areas

이 service area 테이블의 FacilityID 필드는 hot_places의 각 Point의 OBJECTID로부터 생성된 것입니다. 그리고 FromBreak과 ToBreak 필드는 방금 설정한 cutoff 버퍼의 하한/상한선을 나타냅니다. 즉 위 그림에서 첫번째 열은 OBJECTID=10 이었던 hot_place인 남대문으로부터 500~1000m 사이에 이동 가능한 영역을, 두번째 열은 100~500m 사이에 이동 가능한 영역을 나타냅니다. 이 이동 거리는 당연히 travel_nd network dataset를 바탕으로 계산된 것입니다!

4. spatial join analysis

마지막으로 spatial join analysis를 이용하겠습니다. 앞서 구한 Service Area/Polygons와 hot_places 사이의 Spatial Join 분석을 실시하면, 어떤 Service area 내부에 있는 hot place의 목록을 추려낼 수 있습니다. 이 목록이 곧 한 지점으로부터 일정 거리/시간 내 도달 가능한 지점의 목록이 됩니다.

리본의 Analysis 패널에서 Spatial Join을 클릭한 후, 다음과 같이 설정값을 입력합니다. (Fig16. 참조)

• Target Features -> Service Area/Polygons
• Join Features -> hot_places
• Output Feature Class -> JoinResult (새로 만들어질 join 데이터의 이름. 원하는 이름 사용)
• Join Operation -> Join one to many (하나의 영역이 여러 place와 중첩될 수 있으므로)
• Match Option -> Contains (Intersect가 아님!)

Fig16. Spatial Join Settings

아울러 Fields에서 새롭게 생성될 필드를 추가해 줘야 합니다. Target Features의 필드는 새로운 테이블의 필드로 계승되지만, Join Features는 그러지 않기 때문에 직접 필드를 추가해 줍니다. Add Fields를 클릭해서, hot_places의 NAME 필드는 JOIN_NAME으로, OBJECTID 필드는 JOIN_OBJECTID로 추가되도록 설정했습니다.

실행하게 되면 JoinResult라는 이름의 Spatial Join 데이터가 새롭게 생성되는 것을 볼 수 있습니다. 이 데이터는 출발점과 이동 거리의 버퍼 범위 및 도착 가능 지점의 정보를 담고 있습니다.

JoinResult의 Attributes Table을 살펴봅시다 (Fig17.). FacilityID가 필드가 출발점이고, FromBreak과 ToBreak은 service area buffer의 하한/상한값을 보여줍니다. JOIN_OBJECTID는 각 출발점으로부터의 각 service area 안에 있는 지점, 즉 도달 가능 지점의 ID입니다.

한번 피마골로부터 일정 거리 내 도달 가능 지점들을 봅시다. 피마골의 OBJECTID는 6이므로 FacilityID=6을 봅면 됩니다. FromBreak=500, ToBreak=1000을 보면, 피마골에서 500~1000m 사이에 있는 JOIN 지점들이 나옵니다. 세종대왕상, 광화문, 우정총국, 서울광장이 뜨네요. 이 지점들은 서울시 도로망을 이용해 피마골로부터 500~1000m 내에 이동할 수 있습니다.

Fig17. Result

Using Python

요즘 웬만한 분석 소프트웨어는 Python API를 제공합니다. 또다른 GIS 소프트웨어인 QGIS도 Python API를 제공하죠.

ArcGIS Pro는 데스크톱에 설치된 프로그램 내부에서 자체적으로 Python 구동 환경을 가동하는 방식을 지원합니다. 즉 ArcGIS Pro를 설치하게 되면 별도의 Python 머신이 함께 설치됩니다. 그러다보니 프로그램 용량도 꽤 무겁죠.

ArcGIS native Python을 사용하는 방법은 크게 두 가지 입니다. 하나는 ArcGIS Pro를 열고 그 안에서 Python Notebook 및 window를 이용하는 것입니다. Analysis 패널에서 Python 버튼을 선택하고 사용하면 됩니다. Python Notebook은 jupyter notebook을 ArcGIS Pro 안에서 작성한다고 생각하면 되고, Python window 방식은 ArcGIS Pro 안에서 터미널 방식을 이용하는 것이라고 생각하면 됩니다. notebook을 사용할 경우 프로젝트 내부의 directory에 저장하면서 작업 내역을 관리할 수 있습니다.

또 하나의 방법은 별도의 Python 스크립트 파일을 작성한 후, 이를 ArcGIS의 Python 머신으로 실행시키는 방법입니다. window의 경우 대체로 c:\Progra~1\ArcGIS\Pro\bin\Python\scripts\propy.bat 같은 명령어를 사용하여 python 스크립트 파일을 실행시키게 됩니다.

지금까지 정리한 내용들을 ArcGIS의 Python API를 통해서도 수행할 수 있긴 합니다. 하지만 대규모로 자동화된 작업이 필요한 게 아니라면, 각종 Analysis tool을 GUI 환경이 아닌 파이썬 구문으로 해결하는 것은 오히려 번거러울 수도 있습니다. 보고자 하는 "이동 거리"의 값들이 사전에 정해져 있다면, spatial join analysis까지는 GUI 환경에서 수행한 후, python으로 join 결과를 불러와서 조회하는 스크립트만 짜도 됩니다.

해당 스크립트의 예시입니다: https://github.com/AcheuleanGraph/tech.blob/blob/main/gis/arcgis-travel/pys/travel.py

사실, 이 경우 굳이 ArcGIS의 Python API를 사용할 필요도 없이, 작업 결과를 table 형식의 파일로 저장한 후, 그 파일을 읽어오는 python 스크립트를 짜도 됩니다. 이 경우 ArcGIS의 Python 머신을 사용할 필요도 없겠죠.

ArcGIS 내에서 python notebook을 이용해 앞선 작업들을 수행하는 노트북 예시도 올려두었습니다: https://github.com/AcheuleanGraph/tech.blob/blob/main/gis/arcgis-travel/pys/travel.ipynb

Wrap Up

얼핏 간단한 문제인데도 GIS는 신경 쓸 점이 많습니다. 일단 데이터 세팅 단계부터 만만치 않죠. 앞서 사용한 서울시 도로망 데이터만 해도 원 데이터에 교차점이 반영되어 있지 않다는 것을 모르고 바로 네트워크 분석에 들어가면 상당히 당황스러운 결과를 얻게 됩니다. 그리고 사실 앞서 수행한 방식은 고도(z축) 정보를 무시했기 때문에, 실제 교차점을 있는 그대로 반영한 것이 아니기도 합니다. 고가도로가 있을 수도 있으니까요. 😅

GIS 소프트웨어를 다루는 일은 언제나 까다롭고도 흥미로운 경험을 제공합니다. QGIS와 ArcGIS, 그리고 이들의 Python API를 보면 서로 닮았으면서도 다르다는 인상이 드는데요, 소프트웨어의 제도적 동형화와 차별화를 연구할 수 있는 흥미로운 사례 아닐까요. 🔬