Это как раз та задача, к которой я приступаю, сразу после публикации Глобуса в свет:)
Да уж, про фактор 5 я явно погорячился, а вот фактор 3 уклоны, которые пешеходами воспринимаются как значительные, как раз делает визуально заметными и при просмотре в вашей библиотеке. Так что вы эту фичу не выбрасывайте, пригодится.
А что за формат карты рельефа ddm? Откуда данные, чем конвертированы? Я смотрю, там нет лишнего шума, применялась какая-то фильтрация/сглаживание? Можно ли скачать всю планету? Давно хочу нарезать тайлы с рельефом, как с затенением (hill shading), так и с раскрашенной картой высот и изолиниями.
В данных есть пробелы. Качество уже не вспомню какое, источник предоставляю ниже по тексту. Тайл с расширением ddm - это простой массив чисел - высот в метрах, тип float(простите кажется integer но также 4 байта), представляющий сетку размером 33х33. Тайл веб меркаторовской сетки. Кеш тайлов сделан из данных скачанных по этой ссылке http://www.viewfinderpanoramas.org/Coverage%20map%20viewfinderpanoramas_org3.htm точность srtm30 примерно 90 метров между высотами. Исходные данные хранятся в *.hgt файлах wgs84 размером 1х1 градус, это видно скачав клетку с приведенного сайта. Тайлил при помощи утилиты https://github.com/OpenGlobus/OpenGlobus/tree/master/Tools/HeightsAdapter/HeightsAdaptater но на нее нет документации, т.к. я планировал чтобы глобус имел возможность подключать любые подходящие источники с высотами например свой источник тайлов на геосервере, или открытые данные Cesium AGI, но заодно сделал свой формат, для простоты и эксперимента. Если нужно подробнее - поясню в картинках. Скажите.
п.с.
Данные на глобусе рендерятся “как есть” с применением карты нормалей, которая строится прямо по полученным данным из ddm, т.е. интерактивно, сразу после загрузки тайла. При рендеринге применяется небольшой фильтр - блюр, который дает такой приятный шейдинг(который к сожалению приводит к небольшим артефактам по краям)но зато экономит траффик и делает узор рельфа читаемым и понятным.
Нечаянно запостил это сообщение(точнее предыдущее) если можно удалите его.
Понятно. Я тоже оттуда брал.
Во, вот про это я и спрашивал.
Я точно такую же утилиту писал сам, только для 129х129 (а если быть точнее, то 131х131 с захватом ряда пикселей с каждого края, чтобы сделать бесшовную карту нормалей). Мне показалось, что у вас смещений меньше, поэтому и написал сюда с вопросом. Но сейчас присмотрелся - они просто менее заметны из-за сглаживания. Хотя допускаю, что я в своей утилите что-то напутал с координатами. Я до сих пор не знаю, пиксель показывает высоту “средней точки” квадрата, состоящего из граней этого пикселя, или он показывает высоту левой-верхней вершины. Делал на глаз по известной местности. Позже буду перепроверять.
Кстати, а зачем сохранять в массив 4-битных чисел, когда изначально числа 16-битные? Я, правда, работал через TIFF с задействованием утилиты gdalwarp, возможно в HGT битность выше, но точности-то уже все равно нет.
По поводу источников данных: когда я еще в прошлом году набрёл на viewfinderpanoramas, я не нашел внятной информации о копирайтах. Связался с автором. С его слов понял примерно следующее: карта главным образом основана на SRTM и на ASTER GDEM, плюс есть какие-то данные из других источников, являющихся общественным достоянием. Это так, для информации.
Еще вопрос… а где и как вы хостите такое количество тайлов? Объем-то небольшой, а количество большое.
Я выбирал размер грида тайла маленьким(33х33) из соображений, что тайлы постоянно загружаются, удаляются из памяти, снова загружаются, поэтому они должны быть маленькими как можно меньше, кстати винт на котором лежит тайловый кеш отформатирован с таким расчетом, что один тайл занимает один кластер 
В hgt вроде бы действительно 16 битные данные. hgt хранит высоты распределенные как бы по градусной сетке wgs84, при конвертации в меркаторовскую сетку(так чтобы высоты были распределены по меркаторовской сетке), я решил вычислять высоты меркаторовской сетки ориентируясь по высотам сетки hgt, которая wgs84. И так получалось, что в меркаторовской сетке кругом координаты - узлы, которые не совпадали с координатами из hgt, я предположил, что буду пересчитывать высоты(меркаторовской сетки) по треугольникам, которые образуются по исходным данным. Для большей точности расчеты происходят в double, а сохраняются в float, т.е. 4 байта.
пример:
hi hi+1
-----------------
| |
| * |
| mk |
| |
-----------------
hj hj+1
где, h - это высоты из файла hgt которые соответсвуют координатам srtm30, mk - координата меркаторовской сетки, в которой надо найти высоту(она не совпадает с высотой h).
Свой север. Но для глобуса, он не столь важен, только как источник данных для ландшафта. Можно использовать любой другой источник. Даже свой, тот-же геосервер.
Понятно. Я работу по преобразованию в меркатора поручил gdalwarp.
Там ведь порядка 20 миллионов файлов, да?
Кеш тайлов очень большой, конечно, если принять точность srtm 3 секунды, тогда максимальный индекс глубины равен 15, для меркатора 2^15 = 32768, итого тайлов 32768^2 = 1073741824. Плюс тайлы на зумах от 1 до 14 
Это полный кеш тайлов.
Без кеша: 26129 файлов(данные по одном градусу). Это занимает 70 гигабайт.
П.С.
Моим алгоритмом кеш делался примерно 4-5 дней, на довольно стареньком ноутбуке, что я полагаю неплохой результат.
Исправлено! Благодаря вашему замечанию, алгоритм рисования рельефа был значительно улучшен!
-Увеличена на порядок скорость шейдинга рельефа
-Улучшено качество шейдинга рельефа
-При строгом просмотре в надир, сохраняется детелизация рельефа
Сделал пример контрола о котором я описал выше:
http://openglobus.org/examples/CustomControl/customControl.html?e=865052.73335,4553806.30533,4390959.04115&f=0.15276,0.18156,0.97144&u=-0.00640,0.98314,-0.18274