Одиннадцать проверок выгрузки: СК, комплект файлов и обменные форматы
Чужую выгрузку я всегда вскрываю сам. Не потому, что не доверяю, а потому, что беда в ней обычно молчаливая: файлы на месте, даты свежие, приёмник открывает — и только через неделю выясняется, что половина объектов без геометрии или слой стоит на сто метров не там. Ниже — одиннадцать проверок, которые я делаю, и что у меня по ним вышло на замере 21 сентября 2026 года. Числа привожу как есть, с номерами живых заказов, чтобы любой мог повторить тот же счёт у себя.
Система координат: пересчёт, сличение и переход по своему файлу
Самая обидная ловушка — когда «сменил СК» означает, что утилита переписала заголовок таблицы с определением проекции, а координаты остались прежними. Правду человек узнаёт, когда слои разъезжаются. Я проверяю такое одним способом: беру одну и ту же рамку дважды, без указания системы координат и с указанной, и смотрю не на заголовок, а на сами координаты. У меня bbox слоя адресов из градусов (49,115/55,785 — 49,125/55,792) стал метрами (381 797,484/6 183 747,743 — 382 438,004/6 184 514,932), то есть числа пересчитаны, а не переподписаны. Вместе с ними поменялся и .prj: было GEOGCS «WGS 84», стало PROJCS «WGS 84 / UTM zone 39N». Заголовок и геометрия сошлись — это и есть признак настоящего перепроецирования. Заказы 4c4deaf1 (без указания СК) и 20e7520b (EPSG:32639), одна рамка.
Вторая история из той же семьи: одна и та же система в двух записях считается разной, потому что сличение идёт по строке, а не по смыслу. Две записи, отличающиеся только порядком параметров, воспринимаются как разные СК, и слой попадает не туда. Значит, проверять надо не глазами, а сравнением файлов. Я заказал одну и ту же местную систему двумя строками параметров, отличающимися только порядком, и сравнил выдачу побайтово. В архиве шейпов 206 файлов и различий ноль, включая .prj на 622 байта и README; GeoJSON совпал побайтово — 792 004 байта; таблица систем координат в GeoPackage и .mif тоже равны. DXF разошёлся в 5 строках из 229 066 — это штамп времени и два идентификатора, к геометрии отношения не имеющие. Координаты совпали до последнего знака: система записывается в одной канонической форме, а не «как получилось». Заказы 85133f12 и e65267f6.
Третье — переход между системами по конкретному документу. Когда нужен именно он, встроенный список методов не спасает: перебираешь все и упираешься в десятки сантиметров, а эталон живёт в чужом калькуляторе. Я проверял ровно это: свою систему задавал строкой параметров и отдельно подгружал файл сетки перехода NTv2. Файл на 624 байта со сдвигом ровно в одну угловую секунду по широте был принят (разбор показал: NTv2, секунды, из СК-42 в ГСК-2011, 16 узлов), и поправка доехала до выдачи: 234 здания, сопоставленные по идентификатору с таким же заказом без сетки, сдвинулись на медиану 117,702 м (минимум 117,694, максимум 117,708; по осям −103,1 и +56,8 м). Контроль строгий: два заказа без сетки вышли побайтово одинаковыми, значит сдвиг дала сетка, а не случайность. Заказы ccf90f3b и 85133f12. Оговорка честная: следа применённого перехода в самой выдаче пока нет — README и .prj с сеткой и без неё побайтово равны, и получатель файла об этом из файла не узнает.
Зоны и швы: расхождение, которое пляшет при зуме
Симптом узнаваемый: шов между листами то расходится, то наползает, причём величина меняется от масштаба, — так ведёт себя перепроецирование на лету, а не постоянный сдвиг. Я брал две соседние стыкующиеся рамки в одной зоне и тот же участок в соседней зоне и мерил не глазом, а по узлам. 39 дорог и 18 зданий попали в оба листа; 112 узлов западного листа, лежащих в восточной рамке, отстоят от той же линии соседнего листа на 0,0000 м — минимум, медиана, 90-й процентиль и максимум совпали, узлов с расхождением больше миллиметра ноль. Пересчёт соседней зоны в первую дал медиану 0,000000 м. Обрезки по шву тоже нет: узлов ровно на меридиане стыка ноль в обоих листах, объекты выгружаются целиком, а не режутся рамкой. Заказы afb0fe42 и 89f0f3ab (две соседние рамки в EPSG:32639) и fc5c0e14 (тот же участок в EPSG:32640).
Целостность: геометрии против записей и вырожденные объекты
Самый неприятный случай — когда сигнала нет вообще: записи в таблице есть, а геометрия у части объектов пустая. На карте их нет, в атрибутах они есть. Это ловится только пересчётом. Я так и проверял на двух заказах разного размера: 2 250 геометрий против 2 250 записей в .dbf и 7 869 против 7 869. Пустых геометрий ноль, записей, где все атрибуты пусты, ноль, geometry:null в GeoJSON ноль. Доля битых объектов — 0,00 %. Заказы 43a3def8 и df8f90d3.
Рядом стоит бинарный отказ: разошлись геометрии и записи — приёмник не открывает весь слой, а найти испорченную запись нечем, и лечилки иногда выедают больше, чем чинят. Поэтому комплект надо проверять на выходе, а не у получателя. Я пересчитал все 43 слоя тех же двух заказов: геометрий равно записям везде, без исключений. Пять обязательных файлов на месте у каждого слоя — 21 комплект .shp/.shx/.dbf/.prj/.cpg, плюс 11 файлов стилей и README. Кодировка объявлена явно: .cpg — UTF-8, .prj — WGS84, EPSG:4326, так что угадывать ни кодировку, ни систему не приходится.
Третья проверка в этой же связке — вырожденная геометрия в GeoJSON. Файл формально валидный JSON, а приёмник на нём падает, потому что внутри лежит GeometryCollection или линия из одной-единственной точки. На тех же двух заказах, 2 250 и 7 869 объектов, у меня вышло: GeometryCollection ноль, LineString из одной точки ноль, колец полигона короче четырёх точек ноль, geometry:null ноль, пустых coordinates ноль — в обоих файлах. Про второй потолок, коллекцию больше 65 тысяч объектов, скажу так: на предельной рамке в 4 км² выходит 7 869 объектов, то есть до этого потолка дело просто не доходит.
Один файл или комплект: GeoPackage, TAB и MIF
Классика: человек оставляет из архива «только нужное», выкидывает спутников — и слой не открывается, потому что части комплекта связаны между собой. Поэтому я стараюсь отдавать то, что разбирать не надо. GeoPackage приходит одним файлом на 1 609 728 байт, и внутри него 41 слой — адреса, реклама, аэродромное хозяйство, барьеры и дальше по списку; разделять там нечего по устройству формата. Кому нужен именно комплект — он тоже есть и полный: TAB это архив из 161 файла (40 слоёв по четыре файла плюс README), MIF — из 77 (38 слоёв по два файла плюс README). Выбор между «одним файлом» и «комплектом» остаётся за получателем, а не за случаем. Заказ fbd3480c, Казань 1 км².
С этой же парой связана знакомая асимметрия драйверов: одни и те же данные в MIF уходят спокойно, а на TAB запись спотыкается и ругается на идентификатор объекта. Я проверял это честно — заказывал оба формата в одном заказе, на одной рамке, из одних данных, чтобы разница была только в драйвере записи. На 2 295 объектах записались оба, без единого отказа: TAB — 149 198 байт, 40 слоёв, по четыре файла на слой; MIF — 104 455 байт, 38 слоёв. Ошибок про неверный идентификатор объекта не было ни одной, заказ завершился за 9,4 секунды. Разница в числе слоёв — это разница форматов на пустых слоях, а не сбой записи.
Проект с оформлением и предупреждения, которых раньше не было
Две беды в одной: пороги видимости по масштабу теряются при выгрузке, а картинка потом ещё и зависит от DPI машины, из-за чего знаки становятся «лошадиными». Я проверял обе. В проекте QGIS (комплект из 145 файлов) пороги дожили: 22 слоя, 591 правило рендера из 625 несёт масштабные границы — театры видны до 1:10 000, музеи до 1:25 000, — плюс 40 настроек подписей с включённой масштабной видимостью и 17 файлов стилей, где пороги стоят у 116 правил из 135. По DPI я заказал один и тот же лист при 96 и при 300: 337,34×419,89 мм против 337,31×419,95 мм — расхождение 0,01 %. Меняются только пиксели: viewBox 1275×1587 против 3984×4960, ровно в 3,125 раза, то есть на бумаге те же миллиметры. Заказы f4e37059, a51726c9 и a6959118.
И последнее, самое тихое: человек указал свою систему координат, получил файл в градусах и уверен, что он в своей СК. Хуже отсутствия поддержки только молчание. Я закрывал это не списком оговорок, а поведением. Предупреждение о системе координат теперь видно прямо на странице заказа — замер снял у STL блок 414×264 пикселя там, где раньше был нулевой размер, 414×73 у TopoJSON, 414×109 у GeoJSON, на телефоне 305 пикселей в ширину. Часть форматов при этом перестала игнорировать выбор: спутниковая подложка едет архивом с файлом привязки 452931.081/6224636.250 и .prj с проекционной системой, GeoTIFF внутри больше не безымянная локальная система, а код проекции 2591, CSV при проекционной СК зовёт колонки northing/easting. Неверно заданная система в корне запроса теперь отбивается кодом 422, а не проглатывается молча. Оговорка честная: 18 трёхмерных форматов при своей СК ломают геометрию и предупреждают об этом видимо — это отдельная работа.
Все числа выше сняты 21 сентября 2026 года на живых заказах, и каждая проверка повторяема: пересчитать геометрии против записей, сравнить bbox до и после смены системы, сложить два соседних листа по узлам. Если делать это до отдачи файла, а не после, молчаливых сюрпризов у получателя не остаётся.