Google Chart API

12월 6일에 공개된 API이니 이미 좀 된 얘기지만, 이글루스의 연말 블로그 통계 결산을 보면서

"저런식의 통계를 쉽게 못낼까"

라고 생각하다가, 월 초에 봤던 Google Chart API가 떠올랐다. 그래서 좀 만지작만지작 대다가 이 앞 두 포스팅이 나오게 된 것.

쓰면서 느낀 점, 특히 강점은 우선 별다른 클라이언트 코드가 필요치 않다는 것. 가끔 쓰는 정도면 별도의 툴이나 스크립트 없이 손으로 쓱쓱 작성하고 웹에 링크하 – 고 잊어버리 – 면 된다. 그리고 웹로깅 툴의 통계툴이나 간단한 그래프를 그릴 때에는 복잡한 과정없이 그래프를 그릴 수 있다는 점이 좋다. PHP GD 툴 같은 걸 쓸 때의 삽질이랑 비교하면 거의 -_-;; GD 라이브러리 같은 것으로 그래프를 그리는 거랑 난이도를 비교하면 정말 하늘과 땅 차이 -_-; 선을 어떻게 그리고, 틱간 간격 잡고, 이런거 다 신경쓸 필요가 없다는 것은 무척 좋다. 자동화 되는 부분이,

• 그래프 출력 그 자체
• 틱;tick(눈금) 레이블 그리기, 축;axis 레이블 그리기 등의 작업, 다중 레이블링
• 그래프로 나뉜 영역의 색칠, 파이형 그래프에서 각 구간 그려주기
• 영역의 색, 그래프의 선 색 등의 조절
• 벤다이어그램을 그릴 수 있다!

그렇지만 단점이 없는 것은 아니다. 우선 각  축의 축척;scale을 사용자가 조절할 수가 없다. 일상적인 그래프에서는 흔하지 않지만, 약간만 공학적인 그래프로 들어가면 단순히 선형 증가하는 축이 아니라 로그 스케일로 증가한다거나 제곱;square/세제곱;cube 스케일의 축이 필요한 경우가 생긴다. 이런 경우에 대한 대응은 괴롭다. 각 축에 붙는 틱 표시를

시작 – (중간 1) – (중간 2) – … – 끝

같은 형태로 하게되는데, 이 때 중간 틱의 레이블은 시작/끝의 등간격으로 찍히게 된다. 그래서 로그 스케일 등 선형 스케일이 아닌 경우에는 제대로 표시하려면 일일이 지정해줘야 한다. (혹은 틱 레이블 자체를 해당 단위계의 단위 좌표로 하던가…)

데이터를 전달하는 방법이 3종류인데, 각각 62 / 1000 / 4096의 해상도;resolution†를 갖는다. 문제는 데이터를 전달하는 방법을 선택했으면 축의 최대 크기는 무조건 저 값에 비례해서 계산된다. 만약 4096 해상도를 선택하고 10이란 값을 보내면 10/4096 에 해당하는 지점에 찍히기 때문에 그래프를 그리는 사람이 적절히 정규화;normalization 를 수행해줘야 한다. (처음에 이걸 모르고 그래프가 안 그려진다고 생각했다) 그리고 간단하지 않은 데이터 / 많은 데이터의 경우 값 변화도 좀 귀찮은 일이 된다. 62나 4096 해상도의 경우 urlencode를 했을 때 불변인 일부 알파벳문자/숫자/일부 문장부호를 사용해서 만들어낸 인코딩이라 변환함수가 거의 반드시 필요하다.

또한 처음에 무지 고민하면서 디버깅 했던 문제인데 chart legend를 그리는 위치가 고정되어 있다.(그래프 오른쪽 공간으로) 그런데 바 타입 그래프를 좀 넓게 그려지게 해놨더니, 이게 아예 안 그려져서 내가 인자를 잘못 주고있나 계속 확인했다. 단순히 좌우 폭을 넓혔더니 바로 그려지더라 -_-;; 디버깅 기능이나 유효성 확인 기능도 좀 있었으면 좋겠다.

일정 이상 큰 크기의 그래프 (30만 픽셀 이상)의 그래프는 그릴 수 없다. 대충 600 x 500 정도는 그릴 수 있으니 아주 큰 문제는 아니다.

뭐 이러니 저러니 불평을 하긴 했지만 Origin이나 GNU Plot 수준의 기능을 기대하는 것은 아니니 적당한 기능 집합에 상대적으로 간편하고 단순한 인터페이스라서 chart까지도 검색에 포함시키겠다는 구글의 야망도 어느 정도 성공하지 않을까 생각한다. 결정적으로 가지고 놀기에도 나름대로 재미있다. 그래서 오늘 하려던 레몬펜 테스트는 안드로메다로…

*

† 그래프에서 논리적으로 구분될 수 있는 값의 수다. Google Chart API에서는 저 3가지가 각각 simple encoding, text encoding, extended encoding에 해당한다.