OGR неправильно округляет координату X только для слоя MapInfo TAB в EPSG:3857

[MI user]

Добрый день.

Есть проблема с неожиданным округлением до десятых долей координаты X геометрии векторного файла MapInfo в формате TAB в EPSG:3857 в Python.
Подробности ниже.

Среда:

• Windows 10
• Python 3.11
• GDAL 3.9.2

Исходные данные:

• Векторный слой в формате MapInfo TAB в EPSG:3857
• Векторный слой в формате MapInfo MIF в EPSG:3857, экспортированный в MapInfo из исходного файла TAB.

Порядок действий:
1) В Python открываю слой TAB, получаю первую запись, получаю геометрию, вывожу координаты полигона. Вижу округление координаты X каждой точки полигона до десятых.
2) В Python открываю слой MIF, получаю первую запись, получаю геометрию, вывожу координаты полигона. Вижу правильные координаты X каждой точки полигона - до сотых.
На рисунке 1 показан вывод для п.1 и п.2.
3) Для контроля открываю слой TAB в MapInfo и вывожу перечень координат - все координаты с точностью до 7 знака после запятой - см. рисунок 2.
4) Для той же среды выполнения обработка слоёв в формате TAB в других системах координат даёт правильные неокруглённые координаты с большой точностью.

ВОПРОС:
Как в Python получить неокруглённые координаты геометрии при чтении слоя в формате TAB в EPSG:3857?

Приложение:

• Слой в формате TAB
• Слой в формате MIF
• Исходник на Python

[trir]

никак

[spawner]

Мне кажется дело в пределах таблицы, если их уменьшить, то должно быть нормально

[MI user]

Мне кажется дело в пределах таблицы, если их уменьшить, то должно быть нормально

Согласен, охват безусловно влияет на точность координат (вот тут об этом).

Но тогда возникает другой вопрос - как сама MapInfo умудряется извлекать координаты до двух знаков после запятой для формата TAB?

Видимо, надо искать библиотеку для чтения TAB напрямую, без OGR. Есть проект MITAB, может он читает координаты "как MapInfo".

[spawner]

Могу только посоветовать задать систему координат nonearth - 10млн +10млн,а потом читать

Я нормально считывал в nonearth

[Boris]

Мне кажется дело в пределах таблицы, если их уменьшить, то должно быть нормально

Согласен, охват безусловно влияет на точность координат (вот тут об этом).

Но тогда возникает другой вопрос - как сама MapInfo умудряется извлекать координаты до двух знаков после запятой для формата TAB?

Видимо, надо искать библиотеку для чтения TAB напрямую, без OGR. Есть проект MITAB, может он читает координаты "как MapInfo".

1. Вопрос с точностью уже разбирался на форуме. Я в него сам писал . Так что на этом форуме есть источник, и на русском, где проблема расписана с цифрами.
2. Mapinfo никак не читает эти самые сверхточные координаты - она их так пересчитывает, а Python делает какие-то свои необоснованные предположения или округления при печати.
3. Как автор программы, которая копается в бинарном формате файла MAP, замечу что:

• библиотека проекта "проект MITAB" старая - ориентироваться на нее нельзя, т.к. она не знает некоторых новых типов геообъектов в Mapinfo. К тому же, если ничего кардинально не исправили новые поколения программистов GDAL, она и есть основа для чтения/записи MIF/TAB в GDAL/OGR.
• значения в файле MAP - целочисленные, на манер CAD-программ, и то, что отображаются безумные разряды у точек после запятой, - верный признак некорректности границ. И эта целочисленность так вылезает наружу при отображении в Мапинфо. Причем в сторонней программе. Сама Mapinfo покажет максимум 2 разряда, без специальных ухищрений.
• игнорирование совета "проверьте и правильно установите границы карты" не даст нужного результата ни в какой библиотеке, ни каким путем, если данные записываются, а потом читаются из TAB, в котором неправильно заданы эти самые границы. В файле TAB/MAP УЖЕ искаженная информация.
• MIF - единственный разумный вариант для создания данных, т.к. до этапа загрузки геометрических данных в TAB, они не нарушаются по точности, какие бы границы, хоть нулевые, не были указаны. И лучше, затем, пакетно пересчитать в Mapinfo MIF в TAB. Для этого несколько программ еще есть в архивах на просторах интернета. Сам я использую "BatchTools.mbx", 1999 года создания. В 32-х разрядных версиях она работает, используя механизм конвертации запущенной версии Mapinfo.
• Предложенные выше границы +/-10 миллионов км от центральной точки, дают геодезическую точность 0.01 метра всех систем координат. Ибо правило перехода к единицам проекта в MAP файле таково: "1 минимальный интервал = 1/2 миллиарда от разности границ" в единицах выбранной системы координат. Сама Mapinfo любит какие-то неадекватные границы, и по умолчанию их устанавливает. Из этого и вылезают 7-е и прочие разряды в координатах точек. Это давно было опубликовано в одном из форумов Mapinfo, проверено, и неоднократно, на практике.
• Текущие версии OGR для формата TAB/MIF содержат параметр "-lco BOUNDS=", и еще дополнительный механизм описания СК, не просто так, ибо это есть известная и очень неприятная проблема. Поддерживаемая текущим владельцем MapInfo Pro - сам формат MAP предусматривает возможность задания любых единиц с любой точностью: и Int64, и Float, и все версии от 9.0 это должны принимать, но по факту, MapInfo хранит координаты в Int32, хотя напрямую читает любые из сторонних форматов, например, Float из координат SHP-Файлов.

Дополнение: "неадекватные границы" - на самом деле адекватные, с учетом того, что они были давно-давно созданы с опорой на футы, в которых Земной шар гораздо крупнее. И с опорой на дюймы, в которых он существенно мельче. Из-за этого, в метрах эти границы по умолчанию не круглые и описаны с 5-7 разрядами после запятой. А в GDAL они +/- 30 миллионов единиц. Что для метров избыточно, и, к тому же, дает периодическую дробь 1/3:

For a file in LAT/LON (geographic) coordinates: BOUNDS (-180, -90) (180, 90)

For any other projection: BOUNDS (-30000000 + false_easting, -15000000 + false_northing) (30000000 + false_easting, 15000000 + false_northing)