흠. 런던 지하철 구조를 잘 모르겠군요.

일단 서울 지하철 구조와 비슷하다고 가정하면...
환승역을 기준으로 그래프로 나타내면 될 것 같고,
각 환승역과 환승역 사이의 역들은  리스트 형태로 별도로 관리하는 것이 적절할 것 같습니다.

일반적으로 색상을 표현할 때 3바이트로 표현한다.(인간의 색상 분해능과 관련된 값) 따라서 unsinged long형태의 RGB값을 저장하면 될 것 같다. 만약 색상수가 많이 필요 없을 경우 1바이트 내지 2바이트의 char, unsigned short int 형으로 변환하여 기록하면 될 것 같다.
 제한적인 색상을 이용하는 경우라면 팔렛트 개념을 적용하여 색상을 팔렛트 테이블에 기록하고, 이에 대한 인덱스를 외래키 형태로 가지고 있는 형태도 적절할 것으로 생각된다.

효율을 어떻게 보느냐, 즉  속도, 크기 등의 관점에서 바라봄에 따라 달라질 수 있다.

큐는 FIFO(먼저 들어간 요소가 먼저 나옴), 스택은 FILO(먼저 들어간 요소가 맨 뒤에 나옴) 방식이다. 큐는 요소를 추가하는 것은 끝에, 요소를 추출하는 것은 반대쪽 끝에서 이루어지지만, 스택은 동일한 쪽에서 데이터 삽입/삭제가 이루어진다

N차원의 인덱스를 1차원 인덱스로 변환시킨 후 접근한다.
예를 들어 3차원 배열의 크기가 (3*4*5)라 한다면 [i][j][k] = k + 5*j + 20*i 로 계산해서 접근하면 되지 않을까?

그런데...이 문제의 해석이 잘못되어 내가 딴 생각을 할 수도 있다.

그냥 별 다른 생각없이 C/C++의 구조체, 또는 클래스로 표현해 버립니다.
어떤 것을 알고 싶어서 물어 본 것일까요?

저는 웹 사이트에서 주로 보며, wikipedia의 data structure list를 틈나는대로 봅니다.

이에 대한 것은 이미 이 블로그에서 다룬 적이 있다. 유니코드는 일반적으로 한 문자를 2바이트의 값으로 표현한다. 이때 문제가 되는 부분은 엔디안이다. 텍스트 파일로 저장할 때 맨 처음 2바이트를 이용하여 유니코드 텍스트 파일인지를 나타내는 시그니처로 사용한다. 이 시그니처는 엔디안을 구분하는데에도 사용된다. 따라서 파일의 크기는 실제 저장한 텍스트의 용량보다 2바이트가 큰 값이며, 리틀엔디안인지, 빅엔디안인지에 따라서 시그니처 코드의 바이트 순서가 달라진다.