Общие вопросы по ГАТО (Гос.арх.Тверской обл.)

>> Ответ на сообщение пользователя tu2-167 от 14 июля 2021 14:43
Опять таки Вам повезло, что Вы видимо только взялись изучать тверских. А у меня в Тверском архиве далеко не одна деревня и так же как у вас фамилий нет. И села огромные плюс деревни. Приходится изучать 8 населённых пунктов. Ездила несколько лет в Тверь. А выложили только сейчас и с кошмарным качеством. Чему тут радоваться? Спасибо конечно и на этом, хоть на немного поездки сократили. Но при такой скорости наполнения и при таком качестве многие документы даже при условии их сканирования придется ехать смотреть в ГАТО. Конечно хочется что бы хоть отсканированное было читабельно.

Это очень круто, что ГАТО запустили АИС. И очень круто, что они купили Питерский софт, а не глючный ЭЛАРовский.

Но вот скорость публикации материалов и пространные аргументы про дополнительную проверку уже доступных в читалке оцифровок вызывают недоумение. Ровно как и качество снимков. Текущими темпами публикации для меня, как видимо и для большинства исследователей, польза от АИС только в просмотре неиндексированных описей, а давно доступные в читалке дела мы рискуем увидеть через годы)))

О технической стороне загрузки всех дел разом

Я больше 10 лет занимался веб-разработкой, в т.ч. бэкэндом (серверная часть), и с уверенностью могу сказать, что технически процесс публикации всех материалов разом в автоматическом режиме требует около 4х часов работы программиста невысокой квалификации. За эти 4 часа выполняются следующие этапы работы:
- анализ архитектуры базы данных АИС, чтобы понять, куда именно и в каком формате пакетно подгружать образы
- анализ имеющегося файлового архива и написание скрипта, который составит индекс файлового архива
- доработка скрипта, чтобы он подгрузил весь файловый архив в базу данных АИС
- отладка и финальный запуск скрипта

Для выполнения этой работы не нужно ни участие разработчиков АИС, ни какие-то дополнительные лицензии или инструменты.

Причем у меня есть предположение, что АИС была поставлена разработчиками с уже готовым скриптом для пакетной загрузки, т.к. это утилита первой необходимости.

О 3хнедельном отключении системы для улучшения качества образов

Что же касается вопроса о 3хнедельном отключении системы для улучшения качества образов - тут важно понимать несколько нюансов:
1) Процесс кэширования образов в улучшенном качестве технически не может быть завязан на необходимость отключения системы. Возможно, в системе действительно есть кнопка "изменить формат образов", после нажатия на которую по какой-то причине сервер виснет на время обработки всех образов. Если это так, то опять же, за пару часов работы программиста невысокой квалификации возможно создать скрипт, который будет выполнять ту же работу без остановки АИС, не вешая сервер, не ограничивая доступ к образам (недоступен будет только один образ, обрабатываемый в текущий момент времени, а обработка одного образа - это около пары секунд).

2) Из имеющейся информации не ясно, исходя из чего посчитана цифра в 3 недели: то ли исходя из 960ти опубликованных дел, то ли исходя из всех оцифрованных дел, включая те, которые пока недоступны в АИС. Если первый вариант - то при 1800 делах в АИС отключение потребуется на 6 недель и т.д. А если второе - время отключения не изменится, пока архив не отсканирует новые дела.

Архив - бюджетная организация с планируемым бюджетом. Если в архиве нет штатного программиста, который может взять и сделать работы, которые суммарно займут менее одного рабочего дня, то для нас (исследователей) было бы важно заложить в бюджет на 2022 год этот несчастный день работы наемного программиста)))

О размере жестких дисков на сервере

Видел тут предположения, что низкое качество образов в АИС связано с экономией на серверном оборудовании. Но исходя из разъяснения архива о том, что изменение качества образов возможно переключением настройки в АИС, можно сделать однозначный вывод, что на сервере хранятся все образы в исходном качестве, а АИС создает кэш на основе них. Если исходный образ занимает 10мб (ГАВО, к примеру, выкладывает исходники от 8 до 12мб на цветной разворот), то кэш к нему в хорошем качестве - менее 1мб. То есть, суммарно кэш занимает менее 10% от общего объема образов, и это явно несущественная цифра в плане загруженности хранилища или стоимости жестких дисков.

О необходимости повторной проверки образов перед публикацией в АИС
На мой взгляд, это звучит, либо как глупость, либо как отмаза. ГАВО, к примеру, выкладывает образы без доп. проверки. Действительно, иногда попадаются пропущенные листы (да они и в РГАДА в 350м фонде встречаются). Иногда встречаются дела, которые случайно загрузились в соседние дела, в результате чего при просмотре дела подряд листается по странице то одного дела, то другого. Но все это никак не мешает в целом пользоваться документами, а сотрудники архива охотно исправляют найденные ошибки.

При этом трудоемкость при проверке тысяч дел сотрудником архива перед публикацией и трудоемкость исправления отдельных ошибок в единицах дел после их обнаружения исследователями явно говорит об экономической нецелесообразности проверки всех дел.

Мой вывод
Для исследователей будет оптимальным публикация всех документов в АИС единым скопом, без доп. проверок. В случае невозможности архивом нанять программиста на один день сейчас по экономическим соображениям, целесообразно заложить эту работу в бюджет следующего года.

mititch написал:

[q]

>> Ответ на сообщение пользователя Nick_Kourpan от 14 июля 2021 22:14
Неистово плюсую! Как держатель фотохостинга (правда, маленького) подтверждаю, что 3 недели это если они ручками будут переконвертировать.

[/q]

Тут еще остается за кадром, какой у них хостинг - выделенный сервер или виртуалка. Вот у НИАБа, к примеру, виртуалка)))) Если виртуалка с лимитами на процессорное время, то не удивлюсь, что там реально 3 недели нужно, чтобы просчитать весь кэш))))

Для сравнения показателей - у меня выделенный сервер в Hetzner, оборудование 2015 года, для личного фотоархива написал простенький скрипт на PHP, кэш изображений просчитываю стандартными функциями, около 10000 образов, общий размер исходников около 200гб. В среднем, кэш пересчитывается за 12 часов плюс минус (это PHP 7.3, на предыдущих версиях PHP то же самое занимало около суток). Совсем не ясно, откуда 3 недели. Ну совсем)))

anto написал:

[q]

вместе с софтом они переняли и ухудшение качества до 1600 точек и клеймение

[/q]

Качество веб-версий образов и клеймение - опциональные настройки, а не базовая особенность этого софта. Но они мне тоже не нравятся, я за несжатые образы и отсутствие клеймения)))

anto написал:

[q]

Так что уж лучше б Элар был.

[/q]

Видимо, за поддержку Элару надо платить больше. А этот софт (такой же, как и в СПб) дешевле и, возможно, проще в обслуживании.