서울대에서GIS하기

Cartographer's 의 동료들

지도쟁이 :P — Mon, 14 Oct 2024 23:00:41 +0900

오늘은 지도이야기가 아니라, 지도를 만드는 나의 동료 이야기를 하려고 한다.
지도가 나고, 내가 지도이기 때문에 어쩌면 이것도 지도 이야기일지도 모르겠다.

만화 원피스에 주인공 루피는 해적왕이 되기 위해 동료들을 우선 찾아다닌다.
목표를 달성하기 위해서 동료는 그만큼 중요한 부분이다.

나는 운이 좋게도 기억에 남는 좋은 동료들이 많았고,
직장을 나와서도 다행히 찾아주는 사람이 많았다.
운이 좋았는지, 조상이 쌓은 덕이 많았는지 그들과 함께 했을 땐 항상 좋은 성과와 제품이 만들어졌던 것 같다.

학교에서 만난 인연
회사에서 만난 인연
사회에서 만난 인연

이 모든 인연들이 이어져서 지금의 내가 있다고 해도 틀리지 않았을 것이다.
그 동료들이 나를 인정해 주었다. 칭찬은 고래를 춤추게 하는 것처럼 나도 더 성과가 생겼다.

그 모든 인연이 그렇듯, 그리고 어떤 이유에서 이든
만나면 헤어지는 법이다.
헤어질 때 잘 헤어지는 방법은 나이가 든 지금에도 매우 어렵다.
속세에 미련이 많은 것인지, 계속 좋은 이미지로 남고 싶은데 누구에게나 사랑받기는 어렵다.

당근마켓이라는 회사에 합류하고 나서 좋은 동료를 많이 떠나보냈다.
보통은 타의에 의해서 그리고 자의에 의해서 나간 경우가 대부분이었다.
그리고 나서 깨달은 것은 좋은 헤어짐은 없었다.
보통 성인이 되고 나서 헤어진다는 것은 누군가에게는 상처가 되는 것 같다.

막상 동료들이 떠난다는 사실을 인지하게 되는 경우, 나의 의지로 바꿀 수 있는 것은 거의 없다.
이미 결과가 나온 상태이기 때문에 여기서 질척여봤자 크게 바뀌는 것은 없다.

동료가 떠난다는 소식을 듣고서 마음이 착잡하다.
그래도 미싱은 돌아가야하고, 남은 사람은 미션을 완수하기 위해 새로운 동료를 찾거나
아니면 그 빈자리를 느끼며 당분간은 작업을 할 것이다.

겨울이 지나고 봄이 오면 조금 더 나아지리라 생각이 든다.

잠깐 진짜 지도이야기를 하자면
최근 로컬지도, 즉 동네지도를 위해 표현해야 할 요소가 무엇인지 고민하는 중이라고 지난번 이야기 했었는데
우선 몇몇 요소들을 발견했다.

이런 요소들은 사실 고민한다기보다 동료들과 우연히 이야기를 하다가 문득 나오는 경우가 많다.
또한 이런 요소들을 표현하기 위해서 데이터를 가공해야 하는 부분도 필요하다.

다만 이걸 어떻게 기존의 지도 렌더링 엔진을 활용해서 표현할 수 있는지는 너무 어렵다.

요새, 우리 동네에서만 볼 수 있는 지도가 아니라
지도를 보면 우리 동네가 보이는 지도를 만들고 있다.

요새 일이 즐겁다.
(동료를 떠나보내는 것은 즐겁지 않다.)
다음의 이야기에서부터는 지금 만들고 있는 지도도 보여줄 수 있지 않을까 기대해 본다.

오늘의 지도이야기 : 좋은 동료를 만나는 것만큼, 좋은 동료를 지키는 것 또 한 중요하다. 일이 즐겁다.

Learn from Apple & Google Maps | Apple & Google 지도로 부터 배우기

지도쟁이 :P — Mon, 14 Oct 2024 22:35:05 +0900

2019년 7월 31일에 쓴 글 입니다.

저의 예전 글로부터,

다른 지도 서비스 제공자로부터 제가 찾은 에러들을 기록하고 있었습니다.

대부분 Apple 과 Google 입니다.

이 글을 쓰기전에,

저는 Apple과 Google의 직원들에게 뭐라고 하려고 하지 않습니다, 당신은 그들의 실수를 보게 될 것이지만요.

짧게 말하면, Apple은 아직 그들의 지도를 발전중에 있습니다. (Google 도..)

그리고, 그들의 실수로부터, 저는 지도를 더 정확하게 만들고/레이어링하고/디자인하는 법을 배웠습니다.

적어도, 그들이 만든 같은 실수를 하지 않으려고 노력합니다.

어떤 지역에서는, 제 지도는 그들의 것 보다 더 좋습니다.

다시, 저를 잘못 이해하지 마세요. 저는 Apple의 제품과 Google의 서비스를 사랑합니다.

저는 지도를 만들고/디자인하고/레이어링하고/분석하는 업무를 하기 때문에, 위 모든것들을 다 데이터베이스화 합니다.

균형과 조화

저는 이것들이 얼마나 중요한지 더이상 강조할 수 없습니다 (엄청 중요하다는 말)

잘 훈련된 cartographers 라면 균형과 조화를 고려해야합니다.

특별히, 지도 서비스에 있어서 그것들은 더 중요합니다, 지도 서비스는 모든 청중들을 만족시켜야 하니까요.

Apple 지도와 Google 지도는 균형이 잘 잡혀있습니다. (POIs 빼고요. POIs에 대해 할 말이 더 있습니다만, 이것들은 다음 글에 올릴 예정입니다.).

하지만, 눈엣가시들이 존재합니다.

그들의 데이터와 레이어 순서는 저를 약간 불편하게 만듭니다.

육교에 대해서 이야기 해 봅시다.

어느 날, 저는 나리타 공항에서 도쿄까지 오는 버스를 탔습니다.

저는 평소와 같이 지도를 열었고, 각 서비스들을 비교하기 시작했습니다.

그 두개의 지도 서비스는 이 세상을 다른 방식으로 묘사했습니다.

아마도, Google은 보행자의 관점에 초점을 두지 않는 것 같습니다.

어떻게 실제 세상이 생겼는지 봅시다.

육교는 고속도로 밑으로 지나 갑니다.

그리고, 이것들은 어떻게 Apple과 Google의 서비스에서 레이어 되었는지 입니다.

Apple	Google

데이터 모델링 측면에서, Apple이 맞습니다 (혹은 iPC, Apple 지도의 일본 데이터 제공자).
하지만, Apple의 육교가 끊어져 있는것이 매우 이상합니다.
무슨말이냐면, 육교가 고속도로 밑으로 지나가고, 그들은 숨겨진 지역을 그리지 않는것으로 선택했습니다.
좋은 시도였지만, 애플은 부작용을 만들었습니다.
이 방법은 데이터가 '실폭도로 폴리곤'과 함께 갈때 괜찮습니다.

실폭도로 폴리곤 : 도로 중심선에서 실제 폭 만큼 버퍼된 것

Google의 육교는 괜찮아 보입니다, 하지만 이것은 고속도로 밑으로 지나가야 합니다.

두개의 서비스는 실제와 달리 세상을 표현합니다.

혹은 어쩌면 두개의 서비스는 그들의 자체의 정책이나 철학에 따라 맞습니다.

실폭도로 폴리곤을 사용하지 않는것에 대해 부작용을 말해봅시다.

저는 지도가 확대될 때 실폭도로 폴리곤을 사용하는것을 사랑합니다.

그것들이 사용될때, 지도는 더 풍부해지고 더 넓어집니다.

제 생각에, 지도 데이터에서 '넓어집니다'는 혼란스럽습니다, 왜냐하면 이것은 사실 스크린의 공간을 차지하지만 넓어지기 때문입니다.

방금의 눈엣가시로 돌아갑니다.
만약 Apple이 '실폭도로 폴리곤'을 사용했다면, 고속도로의 중앙분리대가 육교의 끊어짐 없이 추가가 될 수 있습니다
네 이것을 사용하면 이상한 모양을 줄일 수 있습니다 그리고 cartographers는 더 많은 요소들을 추가할 수 있습니다.

일본의 고속도로를 확인합니다.
Google은 '실폭도로 폴리곤'을 사용합니다, 그래서 그것은 도로위 톨 부스라던지 녹지를 보여줍니다. (지금은 데이터를 교체했습니다.)

반면에, Apple 지도는 도로 시설을 보여주지 않습니다.

제가 알기로, 한국과 일본은 '실폭도로 폴리곤' 데이터를 제공하는 두개의 나라입니다.

그럼에도 불구하고, Google은 실폭도로 폴리곤을 일본에만 적용했습니다.

이것은 왜 인지 제가 알고 싶은것 입니다.

도쿄 시내로 움직입니다. 누가 더 잘 묘사했나? 실제 세상 모델링

세상에서 가장 복잡한 도시중의 하나인 도쿄는 데이터화 하기 매우 어려운 도시입니다.

셀 수 없는 육교, 보행데크와 고가도로, 다리, '터널이지만 고속도로 램프지만 고속도로 출구' 등은 다른 나라에서는 절대로 볼 수 없는 것입니다.

메구로 스카이 가든 은 내가 도쿄를 만들때 보는 랜드마크중 하나입니다.

어느날, 저는 그 랜드마크가 구글지도에서 변화된것을 확인했고

그리고 몇일 후 다시 변화된었습니다.

네, 이날이 Google이 그들의 데이터를 Zenrin에서 자체 데이터로 바꾼 날 이었습니다.

녹지와 터널의 색상이 추가되엇습니다.

그래서, Google은 세상을 정확하게 묘사하려고 노력합니다.

그래서, 메구로 스카이 가든을 잘 모르는 사람들에게,
이것은 건물/아파트/하지만 그 안에는 고속도로/램프/출구/IC 그리고 그 위에는 축구장과 정원이 있습니다.

메구로 스카이 가든은 거리에서는 하나의 큰 건물입니다 (그리고, 대부분의 도쿄시민들은 걷거나 자전거를 탑니다)

공중에서 보면, 풋살장과 공중정원이 가장 눈에 띄는 요소입니다.

그나저나, 왼쪽의 카페는 제가 나카메구로에서 가장 좋아하는 디저트/카페입니다

터널의 스타일은 처음 버전보다 많이 개선 되었습니다.

아직도 건물은 보이지 않습니다.

하지만, 새로운 스타일은 공중에서나 보행자 레벨에서의 요소들이 보이지 않습니다.

사실, Apple의 메구로 스카이 가든은 '큰 원'건물을 보여줍니다 (그곳의 녹지는 없지만)

Google은 일본의 공간 데이터의 독립을 발표했습니다.

저는 Google의 cartographers 가 데이터 독립의 부작용을 알았다고 확신합니다.

그럼에도 불구하고, Google은 그렇게 결정했습니다.

저는 그들의 결정 프로세스와 운행이 매우 좋다고 이야기 해야 합니다.

부록

같은 버그 Vs. 그냥 좋지 않은 Endcap?

Google	Apple

From the previous story,

I have been writing errors which I have found from other map service providers.

Most likely Apple and Google.

Before I start to write this article,

I am not blaming employees at Apple and Google though you are going to see their mistakes.

Long story short, Apple still needs to improve their maps. (so does Google..)

And from their mistakes, I have learned how to make/layer/design maps more precisely

At least, I'm trying not to make same mistakes they made.

For certain areas, my map is better than theirs.

Again, don't get me wrong. I love Apple products and devices with Google services

I database-nized all these just because I have been making/designing/layering/analyzing maps for my work.

Balance and harmony.

I can't emphasize enough on the importance of them.

Well trained cartographers should consider balance and harmony when they make maps.

Especially, for map services, they become more important, for maps should satisfy all audiences.

I believe Apple Maps and Google Maps are well balanced.(except POIs. I have more things to say about POIs but it will come to next articles).

Yet, there are some eyesoars.<.br>
Their data and layering orders make me somewhat uncomfortable.

Let's start with pedestrian overpass.

One day, I took a bus from Narita Airport to Downtown Tokyo.

I turned on maps as usual and started to compare services.

The two major map service providers depicted the real world in totally differenct way.

Perhaps, Google is not really focusing on their maps on pedestrian perspectives.

Check out how the real world looks like

The pedestrian overpass goes under the expressway.

and these are how Apple and Google layered in their services

Apple	Google

Data modeling wise, Apple is correct (or iPC, Apple Maps data provider in Japan).
But, this is very bizarre that Apple's pedestrian overpass is disconnected.
What it means is that the overpass goes under the expressway, they chose not to draw the hided parts.
Nice try but Apple created side-effects.
It only works when the data goes with 'real-width road polygon'.

real-width road polygon: buffered polygon from road centerline with its real width

Google's pedestrian overpass seemed to look fine but it should go below the expressway.

Both services did not illustrate the real world as it is.

Or maybe both services are right according to their own policies or philosophy.

Let's talk about side-effects of not using real-width road polygon.

I love using real-width road polygon when the maps are zoomed-in.

When it is used, the map becomes more abundant and spacious.

'Spacious' is a confusing term in map data, I guess because it actually takes space on-screen but spacious

Let's go back to the previous eyesore.

If Apple uses 'real-width road polygon', a center barrier of expressway could have been added without making disconnected pedestrian overpass.

Yes using it can reduce bizarre looking and cartographers can add more features.

Check out an expressway in Japan.

Google uses 'real-width road polygon' so it shows toll booth and green areas on road (though now they changed their data).

On the other hand, Apple Maps does not show road facilities

As far as I know, Japan and Korea are two countries provide the 'read-width road polygon' data.

Nevertheless, Google applied real-width road polygon only in Japan.

This is something I want to know why.

Let's move on to downtown Tokyo. Who illustrated better? Modeling real-world.

Tokyo, as one of the most complex cities in the world, is very hard to database-nized the city.

Countless overpass, pedestrian deck, and overpass, bridges, 'a tunnel but highway ramp but also highway exit' are something you will never find in other countries.

Meguro Sky Garden is one of my landmarks when I map Tokyo.

One day, I have noticed that something has changed on that landmark on Google Maps

and a few days later it changed again.

Yes, this was the day when Google has changed their data provider from Zenrin to their own.

Green areas and color of the tunnel have added.

So, Google is trying to depict the real world as accurate as possible.

So, for those who are not familiar with Meguro Sky Garden,
It is a building/condominium/but inside of it is expressway/ramp/exit/IC and on top of it is a football field and garden.

Meguro Sky Garden is one big giant building at street level (and most of Tokyoite are walking or biking)

From the aerial view, the futsal field and sky garden are the two most outstanding features there.

By the way, the cafe on the left side is one of my favorite dessert/cafe in Nakameguro

The tunnel style improved a lot compared to the first version.

Though I still do not see the building.

But, the new style doesn't seem to have features from pedestrian level nor aerial view.

In fact, Apple's Meguro Sky Garden shows the 'greate circle' building (though there are not green areas)

Google announced the Spatial Data Independence of Japan.

I am sure their cartographers did know the side-effects of data independence

Nevertheless, Google decided to do it.

Their decision process and drive are, I have to say, darn good.

Appendix

Same Bug Vs. Not Good Endcap?

Google	Apple

Learn from Others Mistakes (다른사람의 실수로부터 배우기)

지도쟁이 :P — Thu, 10 Oct 2024 23:02:13 +0900

이 글은 2019년 6월 27일에 쓴 글입니다.
당시 네이버에 재직 중이었으며 글로벌지도 서비스를 하고 있진 않았고 개인적인 관심으로 살펴보았습니다.
살펴보았던 애플과 구글지도도 약 4년이 지난 지금 많은 부분이 달라졌을 겁니다. (데이터 프로바이더와 지도 스타일 등)
감안하시고 읽어주시면 좋겠습니다.

Label과 POI를 제거한 Apple (왼)과 Google (오) 지도의 스크린숏으로 시작하겠습니다.

스크린샷에서 보시다시피, 몇 개의 건물들이 물 위에 있는 것을 발견하였습니다.

이러한 건물 타입은 주로 동남아시아에서 볼 수 있는 것입니다.

하지만, 여러분들은 일본의 어느 지역을 보고 계십니다.

사실, 작년에 트위터를 통해 공개했고, 애플이 반응을 보였습니다. 그리고 전 그들의 연락을 잃었죠.

일본은 제가 좋아하는 나라로써,

Apple과 Google 지도로 자주 돌아다닙니다 그리고 얘네들이 만든 실수를 캡처하려고 노력합니다.

이렇게 축척된 데이터베이스는 같은 실수를 반복하지 않게 도와주고, 실제로 이걸 통해서 제 지도는 Apple과 Google이 만든 실수를 안 하도록 도와주고 결과도 더 좋습니다.

어쨋던,

물 위에 있는 건물은 매우 おかしいです (이상합니다).

저는 그냥 궁금했습니다, 제 지도는 괜찮은데 왜 얘네들이 같은 실수를 만들었는지.

이와 같은 현상에 저는 아래와 같은 결론을 내렸습니다.

A. 데이터의 출처가 여러 곳이다

예를 들면, 수계, 건물, 도로 등 다 여기저기서 온 것입니다.

B. 버뮤다 삼각지대 같이, 이 지역에서만 생기는 투영법 버그

벡터 타일로 서비스를 할 때 유독 이 지역에서만 생기는 '알 수 없는' 이슈? (아마도 제가 너무 많이 간 것 같습니다. 얘네들이 이런 실수를 했을 거라고 믿고 싶지 않습니다.)

C. 내가 틀림

그래서, 얘네들의 데이터를 추적하기로 했습니다.

구글의 데이터 제공업체는 쉽게 찾을 수 있습니다. 과거에는 젠린이었지만, 지금은 아무것도 없네요

다른 나라에서는, 데이터 제공업체를 찾을 수 있습니다, 하지만 낮은 레벨에서는 아니네요.

Apple은 Increment P Corp. 의 데이터를 사용한다고 알렸습니다. 그리고 추측할 수 있는 다른 데이터는 WAZE, OSM 정도일 겁니다.

Google은 아마도 처음부터 수계와 다른 데이터를 만들지 않았을 거라고 생각했습니다.

그래서 추적을 합니다.

OSM과 Natural Earth는 아마 가장 쉬운 공개된 데이터이지 않을까 합니다. 그래서 얘네들의 데이터를 먼저 확인해 보았습니다.

   1. Natural Earth  

   2. Open Street Map (planet.osm.pbf)  

   3. Openstreetmap Data -> [Data Web](https://osmdata.openstreetmap.de)

A.1. Natural Earth

얘네가 제공하는 데이터의 정확도는 1 : 1000만, 다운로드할 가치도 없겠지만 해봅니다.

네, 너무 명확합니다.

A.2. Open Street Map

Open Street Map의 수계를 열어봅니다.

이거는 약간 꼼수인데, osmosis와 OGR을 이용하여 수계를 추출합니다.

OSM Taginfo는 정말로 짜증 나지만 다음과 같은 필터 조건을 사용했습니다 natural=water and natural=coastline.

더 자세한 정보는 여기로 가십시오 -> OSM taginfo

(imposm3와 postgis를 사용할 수 있지만, 제 업무와 관련된 일이 아니기에 그냥 쉬운 방법으로 갑니다)

세계 osm.pbf 파일을 다운로드하고 수계만 추출했습니다.

다운로드하는데 오래 걸렸습니다. (24시간 동안, 저의 집의 네트워크와 제 iMac (i5 3.2 GHz, 24GB 1600 MHz)으로 16% 밖에 못 받고 있더군요). 그래서 geofabrik을 대신 사용했습니다. 원하는 국가/지역을 선택할 수 있습니다. 추출하고, 데이터를 변환했습니다.

그냥 openstreetmap을 보여줘도 될 거라는 생각을 했습니다. 왜냐하면 기본적으로 같기 때문입니다. (항상 목표로 도달하기 위한 쉽고 빠른 길이 있더군요)

이상한 지역에 대한 데이터 결과입니다.

빌딩 없음
Google과 Apple의 강은 polygon이나 OSM 은 line

여기, OSM에서 추출한 데이터와 Openstreetmap을 보여드립니다.

A.3. Openstreetmap Data -> Data Web

이 데이터에 대한 기대가 없습니다..

해안선은 OpenStreetMap or Natural Earth보다 디테일하지만 내륙에 수계는 없습니다.

그럼, 이제 뭐지? 뭐가 남았지?

B. 투영법?

하지만, 두 개의 서비스 회사가 같은 지역에 같은 문제가 있을 거라 생각하지 않습니다.

C. 내가 틀렸나?

그냥 모르겠습니다.

Google과 Apple의 건물을 구할 수 없었습니다.

하지만, 하나 말할 수 있는 것은 일본에서 수계 혹은 땅과 건물이 일치하지 않는 것입니다. 공교롭게도 두 개의 서비스 회사에서 같이 적용됩니다.

다른 사소한 실수들은 여기에 올리는 것이 의미가 없었습니다.

하지만, 이 현상은 저에게 눈엣가시였기에 올리는 계기가 되었습니다.

I am going to start with screenshots of Apple (L) and Google (R) Maps without labels and POIs.

I have found out a few buildings on water bodies, as you may notice from the screenshots.

This type of residence is usually in the Southeast Asia.

But, you are looking at somewhere in Japan.

In fact, I reported last year through Twitter and Apple asked me where that was.

And I lost their contacts.

Japan as a country I like,

I do wonder around Japan through Apple and Google Maps quite often
and try to capture as many mistakes as I can.

Those databases help me not to make same mistakes (on that location) as they have made and it really does help my map look better.

Anyway,

buildings on water, that's very おかしい (weird).

I was just curious why they did make the same mistakes because my map looks just fine. (the screenshot below is my map in the same spot)

I came out with conclusions below, which causes this phenomenon: buildings on water.

Data did not come from one source

for instance, water bodies, buildings, road links all are from different sources

Like the Bermuda triangle, only that part of the world has projection bugs

when service providers convert spatial data to vector tiles, that area has 'unknown' issues? (I maybe went too far. I don't want to believe they made those mistakes.)

I may be wrong

So, I tracked their data sources first.

Google's data provider's attribution can be easily found and it used to be Zenrin but now it does not show anything.

In other countries (Singapore, in the follwing screenshots), you still can find the data providers but not in lower zoom level.

Apple announced that they use Increment P Corp. data for Japan.

But, Increment P or Zenrin provide the global water bodies?

I believe Apple and Google probably drew global water bodies from 'somewhere' and made details after.

Which means that they did not make water bodies from the scratch.

I assumed that possible open-source data could be added to Apple and Google Maps are WAZE, OSM, and Natural Earth.

So, I tracked possible open-source data down one by one.
- 1. Natural Earth
- 2. Open Street Map (planet.osm.pbf)
- 3. Openstreetmap Data -> [Data Web](https://osmdata.openstreetmap.de)

Natural Earth

they provide as accurate as 1 to 10 Million scale, I guess I do not have to download them but I did.

Okay, it is too obvious.

Open Street Map

Let's go with Open Street Map's water area.

This is a little bit tricky though

I had to install osmosis to extract water bodies and OGR convert them to familiar format like 'shape'.

OSM Taginfo is really pain in the butt

but I just used natural=water and natural=coastline.

for more detail, you may go here -> OSM taginfo

(you could use imposm3 and PostGIS but this isn't my work-related so I use the. simplest way to do)

I downloaded world osm.pbf file and extracted water boundaries only.

You can try with the planet site but it will take forever to download (for 24 hours, with my house network and my iMac (i5 3.2 GHz, 24GB 1600 MHz) was only able to download 16% of planet data).

I used geofabrik instead, where you can specify your target country/region.

After I did extract and convert the data, I could just show openstreetmap because it is the same as planet.osm.pbf (There always are the easiest and fastest way to achieve your goal.)

These are the data results of the bizarre area.

No OSM Building provided in OSM.PBF
Google and Apple seemed to have the river in polygon but OSM provides the only line

Here's the data I extracted from OSM.PBF and Openstreetmap

Openstreetmap Data : Data Download Link

I guess I don't have much expectation on their data..

The coastline detail is much better than OpenStreetMap or Natural Earth though inland waterbodies didn't exist.

So... what now, what's left?

Projection?

But, would it be possible that both services have the same projection bugs in the same area?

I am wrong?

I was not able to get building polygons from both Google and Apple.

But what I can tell is the water polygons or land polygons are not compatible with buildings in Japan.

This applies to both services coincidentally.

Other trivial errors, it was meaningless to post them here.

But buildings on water phenomena were somewhat eyesore to me and I decided to post.

동네지도와 Cartographer

지도쟁이 :P — Wed, 9 Oct 2024 18:02:29 +0900

19년 4월에 신기한 뉴스가 있었다. 그리고 내가 하는 일의 간단한 설명이었다.

디지털 카토그래퍼 : 소비자의 욕구에 맞는 다양한 지도를 디지털화하는 디지털 카토그래퍼는 여러 사람과 협업하며 일을 진행하므로 위성 정보를 분석하는 능력부터 지도 기획, 도안, CAD 작업, JAVA, C 언어 등 컴퓨터 프로그램까지 전반적인 지식을 알고 있어야 한다.
(출처 : https://www.dailypop.kr/news/articleView.html?idxno=38634)

대부분 카토그래퍼 (cartographer)를 검색하면 자율주행 관련 SLAM 라이브러리가 뜬다. 지도를 만드는 관점에서는 뭔가 비슷한 것 같긴한데..

아무튼, 조용한 곳에 앉아서 글을 쓰는 게 학교를 떠난 후 처음일 것 만 같다.

나는 약 1년전 네이버에서 지도를 만드는 일을 떠나 작은 중소기업에서 다른 컨셉의 지도를 만들고 있다.

네이버지도가 대국민을 위한 정말 Universal 한 지도 (Universal을 치환할 수 있는 우리말을 모르겠다) 라면 동네지도는 우리 동네에서 쓰는 지도라고 봐야하지 않을까 싶다.

동네지도에 뭐가 필요할까, 일반적인 Web/Mobile Map과는 어떻게 달라야하는지 요새 최대 고민이다.

동네이야기를 담으려면 동네의 이야기가 있어야 한다.

옛날 남산 아랫자락에 살았을 땐 아랫층 아저씨랑 배달하는 동네 학생들이랑도 이야기하고 근황도 물어보기도 했는데, 요새 옆집에 누가 사는지도 모르는데 동네 이야기를 어디서 들어야할지도 모르겠다.

아직 까진 동네지도에 뭐가 필요한지 모르겠어서 SM Town의 아이돌 멤버처럼 이것저것 담아볼 예정이다. 이것저것 담아보면 누군가는 좋아하는 요소가 있겠고 많을 수록 모두다 좋아하지 않을까 싶다.

그 요소들을 적절하게 그리고 가독성있게 담아내는게 내 일인가? 근데 그건 디자이너도 잘 하지 않나?

오늘의 지도이야기 : 나는 무엇을 하는 사람인가?

Label Placement (지도 라벨 배치, 지도 주기 배치)

지도쟁이 :P — Wed, 9 Oct 2024 17:42:09 +0900

현업에서는 라벨이라고도 불리고 주기라고도 표현한다.

현업을 하기 전에 "주기"라 함은 군대에서 명찰을 주기라고 불렀던 걸로 기억한다.

헷갈려서 나는 그냥 현업에서도 Label (레이블)이라고 부른다.

누군가에게 도움이 되고 내가 하는일 도 기록하기 위해서 과거 github blog의 있던 내용을 다시 그냥 이곳에 붙였다.

한편 Mapbox Studio나 Maputnik 의 Max Width의 경우 한글은 이상하게 지원이 안 되는 것 같다.

(아래의 내용은 19년 6월에 쓴 내용이다.)

이때 진심 미국의 거대 지도 서비스 팀으로 이직하고 싶은 마음이 미친듯이 들어서 영어로 블로그를 써봤다. 나이가 드니까 한국이 제일 좋단 생각이라 한국에 당분간 스테이 예정.

지도 제작자로써 (적어도, 저는 저를 그렇게 부르고 있습니다.),

POI와 레이블 (폰트)는 지도보다 더 중요하다고 보고 있습니다.

Basemap이 아무리 잘 만들어있어도,

레이블과 POI의 마커(아이콘)가 정말 별로이면, 일반 사용자들은 지도를 좋게 평가할 수 없죠.

지도 제작자가 시간을 얼마나 퍼부었는지 중요하지 않습니다.

나쁜 디자인의 레이블과 좋은 Basemap이 만나는 순간 지도는 오염될 수밖에 없죠. (까마귀 노는 곳에 백로야 가지 마라. 미꾸라지 한 마리가 물을 더럽힌다?)

따라서, POI와 이에 따른 부분들 (폰트, 색상, 아이콘, 마커, 등등)은 중요합니다.

그렇지만 저는 색신이상에 타이포그래피를 배워본적도 없는 사람이기에 가독성이 높은 지도를 만드는 것은 항상 힘듭니다.

그래서 도서관에가서 해당 서적을 읽고 공부를 하지만,

저를 특별한 지도제작자로 만들기엔 충분하지 않습니다.

제가 최근 공부?연구?하는것은 동양의 지리학 (즉, 풍수지리)입니다.

물론 입지선정에 초점이 맞추어져있진 않습니다. 동양의 사상? 생각을 어떻게 하면 지도에 넣을 수 있을까?입니다. (물론 지도제작이라는 학문 자체는 서양에서 온 문물입니다만..)

제가 좋아하는 나라중에 하나인 일본은 아직도,

우리의 예전 풍습처럼 오른쪽에서 왼쪽, 위에서 아래로 읽는 문화가 만연해있습니다.

저는 이를 어떻게 일본지도 혹은 일본을 좋아하는 사람들을 위한 지도에 가져올 수 있을까를 고민했습니다.

왜냐하면, 지도제작자에게는 일반인을 위한 지도를 고려해야 하지만

지역주민을 위한 지도도 함께 고려해야 하는 의무가 있으니까요.

Glocalization, 이것이 아마 제일 중요한 것일 겁니다.

그리고 지도제작의 타깃이 되는 나라의 문화/풍습을 이해하는 것도 성공적인 지도제작에 필요한 키입니다.

어쨌든, 위의 것들이 제가 지도를 만들 때 고려하는 철학입니다.

다시 한번, 저는 서양에서 공부한 (동양의) 지도제작자로서 가독성과 정보전달이 높은 지도에 관심이 많습니다.

그렇지만, GIS 방법을 이용하여 어떻게 동양의 문화를 서양의 지도 제작방법과 융합할 수 있을지 고민합니다.

Mapbox가 그 고민을 해결해 준 듯합니다.

오늘 Mapbox가 세로 방향의 레이블 표현실험을 블로그에 남겼는데요 아래에 스크린숏이 있습니다.

API가 공개되면 실험을 좀 해본 뒤에 결과물을 공유하도록 하겠습니다.

추가로, 동/서양의 지도 제작 차이법을 공유드립니다.

개인적으로 동양의 지도의 가독성은 매우 좋지 않았다고 생각합니다 (어쩌면 제가 한자를 읽지 못해서 일지도 모릅니다).

우리 문화를 낮춰보려고 하진 않습니다,

왜냐하면 과거에는 좌표계등의 콘셉트가 없었기 때문이죠.

하지만, Mercaotors가 정말로 멋진 지도를 만든 것은 사실이고 (제가 Web-Mercator의 좌표계를 최애 하지만, Mercoator의 좌표계가 완벽하다는 것은 아닙니다.)

그의 지도로 유럽사람들이 세계를 지배한 것은 사실이니까요.

Mecator's Map in 14 C	Old Korean Map in 14 C

아무튼, 새로운 장난감을 선사해 주신 Mapbox에게 감사드립니다.

--- 6월 25일,
오늘 Mapbox studio를 갖고 놀아봤습니다.
우연찮게도 세로 쓰기를 지원하더군요.
Max Width를 1로 줄이는 약간의 꼼수를 부려보았습니다.
제가 어떻게 했는지 비디오를 첨부합니다.
한국어는 이 꼼수로는 적용되지 않아 보입니다만, 일본어와 중국어는 잘 적용되어 보입니다.

As I am a cartographer

(at least, that how I call my self),

I think POI and labels (fonts) are more important than basemap.

Let's say the basemap looks legit.

Yet, the labels and POI markers (or icons) are bad,

then the MAP does not look alright. (which is obvious)

No matter how much time you spent to make the basemap,

the awful labels (or fonts) will contaminate the overall map design
(I used the word 'contaminate', because it really does).

Therefore, cartographers should spend a lot of time into POI and its assembled parts (font, color, icon, marker, and so forth).

I, however, am color blind and not trained as a typographer, making maps with good readability is somewhat challenging.

So, what I did was going to a library and read books about typography (or font in my term) and chromatics (or coloring in my term).

But this is not enough to make myself to be a unique cartographer.

I thought about what makes me different among all cartographers in the world.

When I was in college in the U.S.,

(I guess Asians are no longer unique these days, but they were in up north Minnesota)

I, sometimes, was being focused in my department.

So, I guess I better use the 'Asian' card in cartographers' world.

What I tried was researching the 'Asian' way of geography (풍수지리),

also known as Feng Shui (in Chinese).

Mostly, the Asian way of geography is focused on location-allocation,

such as 'Where is the best location for my ancestors' graveyard' or 'Where is the best location for a house'

But, I decided to do 'how to implement Asian way of thoughts in making maps'.

One of my favorite countries, Japan, still a lot of people are reading books in vertically/right to left.

I thought about how I am going to apply that Japan's unique reading method to maps.

Because cartographers duties are not only making maps for the generals, but the locals.

Glocalization is probably the most required condition for cartographers, I believe.

Also, understanding the target country's culture and custom is the key to drag to successful map service.

Anyway, these are few of my philosophies about making maps.

Again, as I am a 'Asian' cartographer, who were educated in the U.S., better readability and more information comes first.

But, I am also considering how I am going to mingle with Asian culture with westernized cartography methods, along with GIS knowledge.

Well, it seems like Mapbox already did that for me.

Today, Mapbox did the experiment with vertical label placement in Tokyo, Japan.

When this API comes for the public, I will monkey around and post it.

Additionally, I am sharing the difference of making maps of the East and the West.

I, personally, think Asian maps had very BAD readability (or maybe that is because I do not know how to read Chinese character, Kanji).

I have to say I am not condescending Asian cartographers,

for in the past western maps also did not have any concepts of projections and others.

But, this is the fact that Mercator did make a really awesome map (but I am not saying Mercator projection is perfect,

yet Web-Mercator projection is my favorite)

and at the end, the Europeans conquered the world until the world war II.

Mecator's Map in 14 C	Old Korean Map in 14 C

Anyway, thanks Mapbox for a new toy.

--- June 25th,
I was playing with Mapbox studio and found out, as of right now,
Mapbox does support vertical placement label.
It is a little trick that you just change Max Width to 1

Here, I attached a video of how I did.
Korean doesn't seem to be working with this trick but Chinese/Japanese are working well

다시 2년만에 공지

지도쟁이 :P — Tue, 8 Oct 2024 00:10:29 +0900

3년만에 공지를 쓰고 다시 2년.. (https://snugis.tistory.com/notice/158)

도합 5년 만인가...

결국 돌고 돌아 이전의 둥지로 다시 돌아왔다.

과거 사용했던 블로그에서 글을 이전해오고 있고, 블로그 레이아웃도 변경하려고 한다.

22년 9월 3일 이후 끄적이다가 실패했다.

다시 진짜 해야지

3년만에 공지

지도쟁이 :P — Sat, 3 Sep 2022 23:03:24 +0900

이 블로그는 이제 기술 블로그에서 그리고 그룹 블로그?에서

저 개인의 그리고 지도관련 이야기로 다시 시작합니다.

3년만인가...

지도쟁이 :P — Sat, 3 Sep 2022 23:00:13 +0900

유튜브도해보려고 했고, 영어로 블로그를 써보려고 했다.

영어로 쓴 블로그는 분석이나 기술보다도 지도 철학 (a.k.a., Cartography) 에 대해서, 그리고 지도 데이터에 대해서 이야기를 해보고 싶었다.

나처럼 게으른 사람이 있을까..

몇 달 열심히 했다. 몇 달 열심히 했는데 귀찮아 졌다.

그리고 영어를 못하는것을 알게되었고 (우리말도 못함) 개인의 일과 회사의 일이 겹쳐져 거의 모든 온라인 사회 관계와 단절되어있었다.

그러다가 다시 현타가 왔는지, 혹은 살아야 겠다?는 생각 때문인지, 아니면 나태한 나를 보고 한심했는지 다시 마음을 다져본다.

블로그도 스킨도 편집하고, 카테고리도 다 정리했다.

우연의 일치일까.. 새로 시작되는

진짜 오랜만에 쓰는 글이다. 정확히는 3년만이다.

정말 아무 의미없이 블로그를 다시 시작해야겠다고 생각는데 2019년 9월 3일이 마지막글이었다.

기술 블로그에서 이제 내 이야기를 써보고 싶다.

지도를 생각하는... 위치를 이전 할 까 합니다.

지도쟁이 :P — Tue, 3 Sep 2019 00:01:53 +0900

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

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

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

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

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

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

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

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

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

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

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

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

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

https://pil0706.github.io/

POSTGIS, 테이블 내 가장 가까운 포인트 찾기, 성공적

지도쟁이 :P — Thu, 27 Dec 2018 14:22:22 +0900

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분 내로 값이 나옴

기쁨