Isso não está certo.

Tenho duas possibilidades:

1) As estatísticas estão desatualizadas nas tabelas. Reconstrua índices e atualize estatísticas.

2) Como você disse, os registros da tabela Geography são grandes, abrangendo muitas páginas (não que um registro abrange várias páginas, pois não pode, mas o registro está próximo da marca de 8K). Nesse caso, engraçado, criar outro índice não clusterizado no índice clusterizado pode ajudar.

ATUALIZAÇÃO

Estou satisfeito por ter funcionado. Agora alguma explicação.

Em primeiro lugar, se algo não estiver realmente certo e o plano de execução parecer estranho, sempre observe as estatísticas e reconstrua os índices.

A criação de um índice não clusterizado para o índice clusterizado geralmente não deve fornecer nenhum benefício, mas quando a tabela tem muitos registros e o registro está próximo de seu limite de 8 K, é útil. Como você sabe, o SQL quando vai para o disco para carregar um registro, carrega uma página de 8K. De maneira semelhante, indo para os índices, ele carregará uma página de 8K. Agora, com o índice sendo um inteiro de 4 bytes, isso significa carregar o ID para 2.000 registros enquanto ele carregará alguns registros se usar o índice clusterizado (lembre-se de que tudo o que precisamos é o ID para o bit JOIN). Agora, sendo esta uma pesquisa binária, não espero que ajude muito apenas um pouco. Então talvez algo mais não esteja certo, mas difícil de adivinhar não tendo visto o sistema.