[CartoDB] 시간과 거리를 당신의 비즈니스 니즈에 맞게 조절해 보세요!

**CartoDB 공식 블로그 Bend Time and Distance Isolines to Your Business Needs by Eva Cabanach 번역글입니다.

지도에서 우리는 간단하게 ‘직선’을 사용해 거리를 계산합니다. 선의 길이는 사용자의 출발점과 목적지를 연결합니다. 하지만 사람 중심의 사용관점에서 본다면 우리가 갈 수 없는 지점- 강, 호수 곳이나 벽 등- 까지 포함해서 정확한 접근을 하는데 어려움이 있었습니다. 건물이나 일방통행 도로와 같은 장벽 안에서 길을 찾아야만 하는 어려움이 있었는데요, 많은 전략적 비즈니스 결정 상황에서 우리가 A와 B점을 ‘실제로’ 접근할수 있는 길로 갈 수 있는 거리를 사용할 수 있다면 많은 전략적 비즈니스 결정이 ‘드라마틱하게’ 바뀔 수 있을 것입니다.

 

하여 앞서 말씀드린 문제를 해결하기 위해 CartoDB는  등치선(Isolines)*을 만들었습니다. 등치선은 한 사람이 실제로 주어진 시간동안 장애물- 건물, 거리 그리고 고려할 수 있는 다른 것들- 을 포함해서 한 지점에서 얼마나 멀리 이동할 수 있는지 측정할 수 있는 방법입니다. 실제로 갈 수 있는 많은 방향이 있기 때문에, 이러한 선은 가능한 마지막 지점의 표면을 연결한 경계선입니다.

 

CarotDB의 Time and Distance Isolines는 시간과 리소스를 절약하는 경로 탐색을 하는 전략적 접근 방식입니다. 이 기술은 앞서서 정보를 제공하고 분 단위로까지 정확한 이동 거리를 측정하고 미터 단위로 세부 정보를 모아서 보여줍니다. 공간 정보로 커버된 특정 지역에서 다수의 거리 지점까지 걷거나 혹은 운전해서 이동하는데 얼마나 걸리는지 추이를 보며 비즈니스 분석과 인텔리전스를 강화하는데  측정해 보세요.

 

인구, 통계 정보 – 나이, 소득 혹은 인종-가 증대되면 Time and Distance Isolines는 행동, 패턴 그리고 트렌드를 이해하는데 도움을 줍니다.  뉴욕 지하철 L 라인의 한 역을 클릭해 보세요. 그러면 대시보드에 주요 인구 통계 정보, 특히나 선택 지역의 타겟 유저에 관련된 정보가 분석되어 보여집니다. 이 정보를 바탕으로 새로운 비즈니스를 시작하거나 지점을 열고 특정 지역의 타깃 고객층에 맞는 적정 가격을 세팅하고, 당신의 유통 채널을 극대화하거나 당신의 타깃 고객을 이해해 지역에 기반한 전략적 결정을 하는 것 등에 결정적 역할을 합니다.

 

Time and Distnace Isolines 기능은 베타 버전으로 이용 가능하며 현재는 오직 Nokia HERE 베이스맵에서만 사용 가능합니다.

더 자세히 알고 싶으시다면 아래 링크를 클릭하세요
*등치선이란? 지도상에서 동일한 값을 가진 점을 이은 선. 등고선, 등심선, 등온선, 등압선, 밀도선 따위를 통틀어 이르는 용어입니다.  

[CartoDB] 모든 것을 세분화하기 – Subdivide All the Things

**CartoDB 공식 블로그 Subdivide All the Things by Paul Ramsey 번역글입니다.

공간데이터를 어렵게 만드는 것 중에 한가지 요인은 위치 데이터가 커버하는 scale이 매우 많다는 것입니다. 대륙만큼 많을수도 있고.. 맨홀 뚜껑처럼 작을 수도 있죠..!

데이터베이스 역시 하나의 포인트부터 수천개로 표현되는 폴리곤까지의 넓은 범위의 데이터를 포함합니다. 큰 객체는 저장하는데 더 많은 시간이 필요하고, 계산하는데 더 많은 시간을 필요로 합니다.

한가지 좋은 예시로 Natural Earth countries file이 있습니다. 왼쪽 링크를 통해 데이터를 다운받아 CartoDB에 업로드하고 SQL을 사용해서 오브젝트의 사이즈를 살펴보세요:

SELECT admin, ST_NPoints(the_geom), ST_MemSize(the_geom) 
FROM ne_10m_admin_0_countries 
ORDER BY ST_NPoints;
  • Coral Sea Islands는 112 byte의 4개의 포인트를 가진 폴리곤으로 표현됨
  • 캐나다는 1MB의 68159개의 포인트를 가진 폴리곤으로 표현됨..!

 

테이블에 있는 절반 이상의 나라들(149개)의 데이터 사이즈는 8kb가 넘고, 그정도면 데이터를 불러오는 데 상당히 많은 시간이 소요됩니다.

SELECT Count(*)
FROM ne_10m_admin_0_countries
WHERE ST_MemSize(the_geom) > 8192;

위의 예시에서 큰 데이터를 검색하고 계산하는 방법을 볼 수 있습니다.
Natural Earth populated places 데이터도 CartoDB에 업로드 해보신 후, 두 테이블을 결합시켜보세요:

SELECT Count(*) 
FROM ne_10m_admin_0_countries countries 
JOIN ne_10m_populated_places_simple places 
ON ST_Contains(countries.the_geom, places.the_geom)

비록 places table(7322)와 countries table(255)는 작은 편이지만, 계산할 때는 느린 편입니다(제 컴퓨터에서는 약 30초정도).

크기가 큰 객체(objects)는 많은 비효율성을 수반합니다:

캐나다나 러시아처럼 지리적으로 큰 지역들은 큰 bounding boxes를 가지고 있습니다. 그래서 index들이 효율적으로 작동하지 않습니다.

물리적으로 큰 오브젝트들은 크기가 큰 꼭지점(vertex) 리스트를 가지고 있습니다. 그리고 그것은 containment 계산을 거치는데 상당한 시간이 소요됩니다. 나쁜 상황을 더 악화시키는 작업이 될 뿐이죠.

그렇다면, 우리는 어떻게 속도를 높일 수 있을까요? 큰 오브젝트를 ST_Subdivide()!를 사용해서 더 작게 만들어보세요.

먼저, 새로운, sub-divided countries 테이블을 생성하세요:

CREATE TABLE ne_10m_admin_0_countries_subdivided AS 
SELECT ST_SubDivide(the_geom) AS the_geom, admin 
FROM ne_10m_admin_0_countries;

Editor의 인터페이스가 인식할 수 있도록, CartoDB로 테이블을 등록하는것을 잊지 마시구요..!

SELECT CDB_CartodbfyTable('ne_10m_admin_0_countries_subdivided');

이제, 동일한 데이터의 사이즈가 255 vertices(약 4KB)를 넘지 않게 되었죠!

 

두 테이블을 다시한번 결합시켜보시고, 어떻게 변화했는지 보세요!

SELECT Count(*)
FROM ne_10m_admin_0_countries_subdivided countries 
JOIN ne_10m_populated_places_simple places 
ON ST_Contains(countries.the_geom, places.the_geom)

제 컴퓨터에서, 리턴 시간은 0.5초밖에 걸리지 않았습니다. 즉, countries 테이블 수가 8633 rows 이지만, 60배나 더 빨라진거죠. 이 subdivision은 두 가지 사실을 알려줍니다:

먼저, 각 폴리곤은 이제 더 작은 지역을 커버합니다. 그래서 index searcher가 폴리곤 내에 있지 않은 포인트를 가져올 가능성이 줄어든거죠.

그리고, 각 폴리곤은 페이지 사이즈보다 작습니다. 그래서 디스크로부터의 retrieval이 더 빨라질것입니다.

사이즈가 큰 공간데이터를 subdividing하는것은 지도의 표현을 더 빠르게 합니다. 하지만 당신의 폴리곤이 subdivided되었을 때, 가장자리가 직사각형으로 표현되는 웃픈 상황이 되지 않으려면, 폴리곤 아웃라인을 꺼야한다는 사실을 잊지 마십시오!

 

**CartoDB 공식 블로그 Subdivide All the Things by Paul Ramsey 번역글입니다.