Рельеф из карты: высоты в печать, в движок и прямо в чертёж

Рельеф — то место, где работа с картой обычно рассыпается на четыре отдельные истории. Высоты лежат в одном файле, карта в другом, принтеру нужна третья вещь, а движку четвёртая. Ниже — четыре случая, которые я разбирал руками, и то, чем они у меня кончились. Все числа — с замеров 21 сентября по живым заказам, без округления в свою пользу.

Приёмник пишет «ошибка при открытии файла изображения», а в ГИС файл открывается

Выглядит это издевательски: файл с высотами спокойно рисуется в геоинформационной программе, а нужный вам расчётный пакет отказывается его брать. Я долго думал, что дело в битом файле. Дело не в этом. Приёмнику нужна сетка значений — матрица чисел, где ячейка означает метры, — а ему подсовывают картинку, и он честно отказывается.

Поэтому я заказываю высоты сразу сеткой. На проверке заказ 6edcf93c (рамка Сочи 0,06×0,05°) дал GeoTIFF, у которого SampleFormat=3, 32 бита, float32, 216×180 ячеек, тег NODATA 42113 равен −9999, а значения лежат в диапазоне −1,3…185,0 м при среднем 27,8. Такой файл открывается как одноканальная матрица чисел — режим «F», — а не как изображение.

Если приёмник не переваривает и float-TIFF, на ту же рамку я беру текстовую сетку ESRI ASCII Grid: в том же заказе это elevation.asc с заголовком ncols 216, nrows 180, cellsize 0,000277778, NODATA_value −9999, рядом .prj и пояснительный файл. А когда нужна именно картинка — для подложки или быстрого взгляда, — я беру её отдельным восьмибитным растром на ту же рамку (RGBA uint8) и не смешиваю два этих дела в одном файле. Точность самих высот здесь не обсуждается: разговор о форме отдачи, а не о подробности источника.

Карта высот под движок: ровная сторона, сырой RAW и готовые множители

Второй случай — про импорт ландшафта. Импортёру нужна сторона из его собственного ряда и шестнадцать бит на отсчёт, а на руках большой кусок, который приходится резать и пересохранять руками, теряя по дороге и точность, и терпение.

Я перестал резать и стал заказывать карту высот сразу нужной стороной. Заказы 37b271de и e4842563 по Сочи дали архив с PNG в режиме I;16 ровно 1009×1009 и 4033×4033 и рядом сырой .r16, uint16 little-endian, на 2 036 162 и 32 530 178 байт — это в точности «сторона × сторона × 2», как и ждёт импорт; диапазон отсчётов 0..65535. В сопроводительной записке heightmap_info.txt лежит формула перевода отсчёта в метры (height_m = −1,27 + sample/65535 × 186,25), длина стороны участка на земле 5 566 м, шаг узла 1,38 м и готовые множители под Unreal, Unity и Blender — вертикальный масштаб я больше не подбираю на глаз.

Про большую сторону: она не «галактический размер». Заказ на 4033 отдался за 9,8 секунды и без урезания.

И сразу честная оговорка, без которой всё остальное превращается в обещание: шаг узла 1,38 м — это шаг той сетки, которую я заказал, а не обещание, что источник настолько подробен. Придумать детали, которых в исходных высотах нет, не может ни один инструмент.

Горизонтали приходят в том же файле, что и карта

Третий случай знаком каждому, кто готовил подоснову: карта есть, а рельефа в ней нет. Высоты ищешь на стороне, скачиваешь чужой набор, потом сводишь его с картой руками — и каждый раз заново проверяешь, совпали ли рамка и координаты.

Я это делать перестал: горизонтали приходят прямо в чертеже. Заказ 05f26031 (рамка Сочи) дал в DXF 305 горизонталей с высотой в координате Z — 268 тонких и 37 жирных, 19 уникальных значений от 0 до 180 м с шагом 10, 57 подписей высот, 255 бергштрихов и 16 отметок высот. Всё разложено по отдельным слоям: contours_thin, contours_bold, labels, hachures, elevation_marks — включать и гасить можно по одному. Шаг сечения виден по самим значениям, так что перед работой не приходится гадать, что это за линии и через сколько метров они проведены.

Отмывку рельефа я беру отдельным растром с геопривязкой — заказ 27f4d158: hillshade 1728×1440, LA, 8 бит, 193 градации серого, GeoTIFF с привязкой. Здесь вторая оговорка, и она честная: внутри чертежа отмывки нет и быть не может. Отмывка — картинка, а чертёж состоит из линий; это два разных файла, которые просто ложатся на одну рамку. Сводить их руками не нужно именно потому, что рамка и координаты у них общие.

Из высот сразу в 3D-редактор, без пересадок

Четвёртый случай — про цепочку. Хочется получить модель местности и править её обычным трёхмерным редактором, а выходит две-три конвертации подряд, и на каждой что-то теряется: то масштаб, то нормали, то сама возможность понять, в чём теперь измеряется высота.

Я беру модель местности сразу как STL. Заказ c8f2531e (z_exaggeration=1, Сочи) — бинарный STL на 3 848 584 байта, 76 970 треугольников, 38 880 уникальных вершин, координаты в метрах: X ±2 419 м, Y ±2 783 м, Z от −1,27 до 184,98 м. Обратите внимание на последнее число: диапазон по высоте совпадает с диапазоном исходной сетки высот из первого раздела. Это и есть проверка того, что по дороге ничего не подменили. Вертикальное преувеличение задаётся при заказе, поэтому макет под печать и модель под правку получаются одним и тем же путём.

Если нужен не рельеф, а застройка, на ту же рамку приходит городская модель. Заказ 21403495: STL на 133 928 треугольников; OBJ — архив с buildings.obj на 320 674 вершины и 185 144 грани плюс файл материалов; glTF 2.0 — 44 меша и 44 материала, меши и материалы разделены. Каждая из этих отдач самостоятельная: перегонять по дороге нечего, и терять на пересадках тоже нечего.

Четыре случая — четыре разных файла, но рамка у них одна. Именно это и убирает ту самую ручную сводку, на которой обычно уходит вечер.