Игорь Лебедь писал(а):В итоге решение Александра, получается, лучшее. К тому же проверка "на дурака" (просто открыть файл sxf в QGIS) выдала в свойствах слоёв UTF-8, причём без варианта смены кодировки, как для шейпа, так что видимо панорамовцы проапгрейдили создание sxf до UTF-8.
Я склоняюсь и делаю: предварительно перегоняю все SXF из архива ( 1 / 2 / 10 км ) номенклатурных листов в формат TAB MapInfo (+ добавляю семантику и генерирую ObjectKey, анал. Панорама) и таким образом формирую архив из SXF tab'ов.
При обработке 2 км н.л. обнаружил только 2 серьезно проблемных SXF: один починил, а другой по моему дефектный и Панорама на него сильно ругается, и там только один слой не вполне похоже полноценный -- его буду игнорировать.
Теперь имею GDAL со встроенными моими процедурами от 2014 года, и теперь вот написал и тестирую программу, которая использует произвольный GDAL (ogr2ogr и ogrinfo) и на базе уже существующих моих функций встраиваю семантику + ObjectKey (но в этом случае имею несколько меньше информации, а это все очень важная информация для генерации ObjectKey: не могу отличить векторный тип объекта если есть предположительно аналогичный невекторный тип (это редко возможно, если вообще возможно - это можно изучить), и его полный код не имеет вид "V...", т.к. не имею точной информации о типе объекта в понятиях SXF, а также имею несколько больше параметров по объектам когда изнутри GDAL работаю c объектами, чем это позволяет формат MapInfo -- но это редко тоже предположительно может повлиять на результат).
Особенно грустно что не выводится ObjectNumber (анал. Панорамы) -- этот параметр помог бы буквально по записям сравнить и обнаружить посимвольно отличие между выводе из Панорамы и из GDAL, а без этого сравнение при внешнем просмотре и визуальном сравнении - это конечно не радует (можно только надеяться, что алгоритм уже раньше отлажен, и сейчас ловить отдельные несогласованности для нового кода...; можно по имени сравнивать - но это писать новый код, и не очень эффективный, как уже представляется...)
Но здесь мы имеем плюсы с точки зрения адаптации новой версии GDAL (можно использовать произвольную), да и погрешность будет незначительная как кажется - в основном вероятность что "векторный" объект запишется как "обычный" и я его не смогу отфильтровать (для наших задач векторные объекты не очень и нужны и мы их обычно отфильтровываем).
Проблема с encoding при сплошной обработке н.листов не сможет не проявится, но по видимому буду обрабатывать таким "новым" способом только сбойные SXF с помощью "старого" алгоритма на базе GDAL 2014 (поэтому если проблема и существует, то не пытаясь найти подходящие для теста SXF, можно и пропустить - так как "сбойных" SXF пока мало ).