У меня только 93 таких объектов

Бывает что отменяют объект и дочерние объекты остаются актуальными но без привязки

частично понял в чем дело

ISACTIVE="0"

ISACTIVE="1" отсутствует

а я это все снес

Все проблемные объекты у меня добавлены в интервале 2020.01.21-25

кто то после новогодних полез работать не протрезвев

вот например строка, которая присутствует в единственном экземпляре
<ITEM ID="36370758" OBJECTID="1009023" PARENTOBJID="1011123" CHANGEID="2760405" OKTMO="56701000" PREVID="0" NEXTID="0" UPDATEDATE="1900-01-01" STARTDATE="1900-01-01" ENDDATE="2079-06-06" ISACTIVE="0"/>

ObjId 95254004 - Нальчик, я в 2ГИС нашёл

не понял при чем тут Нальчик

Я по названию нашел его в Нальчике, правда в названии ошибка

кого 'его'?

OBJECTID=1009023 это улица в Пензе. OBJECTID=1011123 это собственно Пенза. в иерархии эта связь присутствует, собственно соответствующую строку я выше вот скинул. но поле ISACTIVE=0 выставлено за каким то хреном... особенно хорошо это выглядит совместно с PREVID=0 и NEXTID=0. т.е. связь эта никогда не менялась, сразу добавили неактивной... мда...

а ISACTIVE=0 я почистил, что бы от дубликатов ненужных избавиться. к слову, после этого они все равно остались. пропали только когда вычистил все с NEXTID != 0

а теперь получается, что это не дубликаты, а просто кривые записи

Там к каждому изменению официальный документ прикручен

какие изменения, если  PREVID=0 и NEXTID=0

В любом случае должен быть документ

Всем привет, у меня возникли вопросы с расчетом размера выходного файла во время использования функции gdalwarp.
Используется ERDAS ECW/JP2 v4.x and v5.x SDK для декомпрессии (бесплатная лицензия для декомпресии).
Дано:
Растр ECW размером 15 650 961 511 байт.
Размер 43334 х 950000
Количество каналов = 4 (0, 1, 2, 3)
Тип данных хранимых в пикселах = Byte
так как это ECW, из информации в GDAL.org, 8 Bits или 16 bit на каждый канал (1 и 2 байта соответственно).
Из файла (gdalinfo) узнаем степень сжатия файла по параметру COMPRESSION_RATE_TARGET = 2, где 2 получено при расчете от 100% = 100/(100 - TARGET), где TARGET = 0 (Нет компрессии), 5 = 80%.
То есть для моего случая 100(100 - 20) = около 2, как и указано в  COMPRESSION_RATE_TARGET.

Для расчета предполагаемого исходного файла, размера без компрессии = 43334 х 950000 х 4 х (1 или 2) =
= для 1 байта  = 164 669 200 000 байт  (около 164 Гб) размер без компрессии
= для 2 байт    = 329 338 400 000 байт (около 330 Гб) размер без компрессии

Сравнив с размером исходного файла, получаем =

164 669 200 000 / 15 650 961 511 = Сжатие почти в 11 раз

или

329 338 400 000 / 15 650 961 511 =  Сжатие почти в 21 раз


Для получения будущего GeoTiff из ECW , с использованием LZW компрессирования, проведем такие же расчеты для GeoTiff:

Растр GeoTiff размером ???? байт.
Размер 43334 х 950000
Количество каналов = 4 (0, 1, 2, 3)
Тип данных хранимых в пикселах = Byte
так как это GeoTiff, из информации в GDAL.org, 8 Bits или менее.

43334 х 950000 х 4 х 1 = 164 669 200 000 байт , размер без компрессии


На данный момент при декомпрессировании в GeoTiff размер должен быть приблизительно около 800 669 200 000 байт, а на данный момент УЖЕ ПО ФАКТУ БОЛЕЕ 1 855 297 071 482 байт (1,70 ТБ)

В чем я просчитался и какой фактический размер будет получен?

В расчете размера ECW overviews нужно учитывать и прибавлять к тому, что я уже рассчитал?