Программы для обработки данных из метрических книг : ВГД

На сайте ВГД собираются люди, увлеченные генеалогией, историей, геральдикой и т.д. Здесь вы найдете собеседников, экспертов, умелых помощников в поисках предков и родственников. Вам подскажут где искать документы о павших в боях и пропавших без вести, в какой архив обратиться при исследовании родословной своей семьи, помогут определить по старой фотографии принадлежность к воинским частям, ведомствам и чину. ВГД - поиск людей в прошлом, настоящем и будущем!

Мне кажется даже по одному листу много нестыковок. У обоих матерей отчества правильно нераспознаны: первая, скорее всего Семеонова, вторая- Евфимова. По священнику вообще "пальцем в небо". Он и Ггопов и Ппов, а на самом деле Попов. И.д псаломщика Александр превратился в " кракозябру". А если в Мк нет фамилий, то все равно всю МК придется перепроверять в ручную. Хотя идея, да, хорошая. Мне вот интересно, а "полуслепые" МК она читает?

Gloyko написал:

[q]
Мне вот интересно, а "полуслепые" МК она читает?
[/q]

Что такое "полуслепые" МК? Если дадите файл, я могу его прогнать там.

>> Ответ на сообщение пользователя microArt от 22 июня 2017 20:41

Здравствуйте! Елена, а вы ещё не создали для себя такую волшебную "настольную" программу? Видела, что у вас есть БД по приходам.

arkan1973 написал:

[q]
Для частного использования многим достаточно Excel.
Если навыки чуть выше, то можно использовать Access, запилив форму ввода со справочниками губерний, уездов, волостей, населенных пунктов. Полноценная СУБД позволяет устанавливать между записями отношения child/parent то есть по сути выстраивать цепочки родственных связей. Наличие справочников существенно ускорит ввод и обеспечит единообразие и стандартизацию введенных данных.

Но это все для себя-любимого....

[/q]

Я тоже пока всё забиваю в Excel, c Access:ом мне пока не подружиться, а хотела сделать что-то похожее на "БД Население Барнаула на основе метрик" с созданием справочников имён, приходов, ссылкой на фонд, автоматическим ID брака и т.п.

Kraut написал:

[q]
Ускоряем индексирование МК о рождении
[/q]

http://vilejski-uezd.by/xfa-bl...-knig.100/

Очень интересный вариант если бы можно было (или можно?!) добавлять ещё графы.

>> Ответ на сообщение пользователя Arcobaleno от 25 октября 2019 22:36

Подскажите, а где вы встречали фамилию Спиридонов и Пелагиада в одном месте? Новенький на форуме, пытаюсь найти записи по фамилиям Спиридоновы-Денежные.

Igortuff написал:

[q]
>> Ответ на сообщение пользователя Arcobaleno от 25 октября 2019 22:36

Подскажите, а где вы встречали фамилию Спиридонов и Пелагиада в одном месте? Новенький на форуме, пытаюсь найти записи по фамилиям Спиридоновы-Денежные.
[/q]

Здравствуйте!
Если Вы хотите связаться с Arcobaleno напишите ей личное сообщение или лучше на адрес эл.почты, который указан в профиле, так как Arcobaleno больше двух лет не появлялась на форуме.
Более подробно, как работать на форуме, как искать сведения про предков, читайте в темах
https://forum.vgd.ru/1304/
https://docs.vgd.ru/kak-najti-predkov

Удачи в поисках!

Уже давно в планах написать программу для формирования базы записей метрических книг и ее последующего анализа для идентификации личностей, выявления связей между записями и оценки вероятности совпадений.
Цель у меня прикладная и личная - по некоторым территориям большая часть записей МК не содержит фамилии. Хочется попробовать устанавливать их программно и отыскивать родственников с использованием более поздних данных и поиском совпадений (по вероятным датам рождения, имени, отчеству и т.п.).
Если пойдет - можно сделать и коммерческий продукт.
Основной функционал -- формы ускоренного ввода данных метрических книг. Блок анализа и поиска с вывода потенциальных записей-совпадений, а также формированием списка личностей-предков, с расчетом и выводом вероятности совпадения.

Есть опыт программирования и написания десктопных приложений на Python.

Rychagov написал:

[q]
У меня ещё вопрос появился.
Собираюсь основывать базу по приходам.
Приходы привязывать к уездам, которые привязаны к губерниям.
Но ведь случалось так, что менялось территориальное деление - что делать в таком случае?
[/q]

Измените методику. За единицу возьмите не приход, а населенный пункт, который может быть привязан к нескольким разным территориальным единицам (в зависимости от времени) и приходам (иногда даже в один момент времени - встречалось такое).

Прочитал тему целиком, взялся за работу, могу сообщить предварительные выводы.

1. Проектов высокой степени готовности не нашел. То что есть обычно имеет ограниченный функционал. О своей работе рассказывал пользователь Rychagov, но до концовки и образца дело не дошло, на форуме его давно нет (

2. Excel, макросы VBA стал бы использовать только для маленьких проектов. Сам я этот вариант пробовал, - уже на нескольких сотнях фамилий понимаешь, что это абсолютно негодные инструменты для построения реляционной базы данных и ее анализа. Ну то есть в принципе делать что-то можно, но это как строить небоскреб из мусора в гараже...
Для первого подхода я выбрал Python + sqllite, т.е. реляционная БД, которая хорошо подходит для наших целей.

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

4. Проблема определения человека по ФИО , в том виде как это обсуждалось в данной теме, по большому счету отсутствует.
Основным структурным элементом базы является запись в метрической книге. Личность должна "создаваться" в результате анализа базы данных, после ее создания. Причем, каждый раз результат может быть иным, т.к. базу можно изменять (уточнять, исправлять ошибки) и дополнять. Выявление однофамильцев, ошибок присущих самим данным - это вопрос качества алгоритма анализа, но не ввода и хранения данных.

5. Ключевая проблема - структуризация или семантический анализ отдельных блоков данных при их вводе.
Например, в Книге рождений достаточно просто структурировать данные о дате и порядковом номере рождения, имени т.к. тут вариаций связанных с формой ввода и положением элемента в последовательности практически нет. Иное дело - текст записи о родителях и крестных, который весьма вариативен.
Сейчас вижу два основных способа решения задачи по разбиению этих блоков на структурные единицы (ФИО отца + его сословие и место жительства, религия, ФИО матери и т.п.).
№1 - структурированный ввод, с оригинальным для программы многовариантным алгоритмом разбиения на структурные единицы, с использованием оговоренных сокращений
№2 - использование готовых модулей семантического анализа, например, Natasha. Это более гибкий инструмент, но полученный результат все-равно нуждается в оригинальной переработке + доп вес программе.
Способы №1,2 можно комбинировать. Но легкого решения нет. Гарантированно будут ошибки для специфичных случаев, но продумал способ с ними бороться: программа на лету разбирает вводимый текст, демонстрируя пользователю "разобранный" вариант и сигнализирует об ошибках и несоответствиях, которые можно будет исправить в отдельных формах заготовленных под каждый структурный элемент.

В моем случае легкораспознаваемый шаблон ручного ввода записи, например, о рождении, может выглядеть так (структурные элементы определяются пробелами и переносом строки при вводе):

3 28 1 март евдокия (РОЖДЕНИЕ - №3 за год рождение (женщины) 28 февраля, крещенной 1 марта)
д полюбово к поликарп тимофеев лазарев васса борисова п (РОДИТЕЛИ: отец - деревни полюбово крестьянин Поликарп Тимофеевич Лазарев...
д починок к иван минаев макашенков д полюбово к евдокия пименова лазарева" (КРЕСТНЫЕ: крестный - деревни Починок крестьянин...

Следует заметить, что часть формируемых данных записи, которая будет сохранена в БД, например пол ребенка, фамилия жены, может определяться программно, после семантического распознавания, а также с учетом значений других структурных элементов (месяц рождения/крещения, лист, информация о священниках исполнявших обряд).

6. Для более качественного анализа и поиска связей потребуется создание нескольких библиотек. В их числе - перечень имен и их вариаций, например: Иван, пол - муж, вариации - Иоан, Иоанн и т.п..

7. Вопросы общей базы и доступности. Один из вариантов -- создание онлайн версии программы, которая бесплатно предоставляет базовый функционал пользователю, взамен на право доступа к введенным им данным (100 и более летней давности - под жесткие ограничения персональных данных не попадаем). Они, очевидно, имеют самостоятельную немалую ценность.

Продолжая тему автоматического распознавания, пытаюсь найти массив данных чтоб модель нейросети натренировать. Есть в свободном допуске например https://www.kaggle.com/dataset...ng-dataset , но это 20 век почерк, надо метрики. Транскирбуса модели тоже тренировали наверное на более легко читаемом почерке.
Мне даже не массив данных а просто несколько страничек насобирать, я потом сам разрежу и подготовлю. Где найти вот.

parija написал:

[q]
Продолжая тему автоматического распознавания, пытаюсь найти массив данных чтоб модель нейросети натренировать. Есть в свободном допуске например https://www.kaggle.com/dataset...g-dataset, но это 20 век почерк, надо метрики. Транскирбуса модели тоже тренировали наверное на более легко читаемом почерке.
Мне даже не массив данных а просто несколько страничек насобирать, я потом сам разрежу и подготовлю. Где найти вот.
[/q]

Посмотрите здесь https://cloud.mail.ru/public/4HPb/yn7dZfQjr. Здесь метрики Сине-Никольской церкви, Опочецкого уезда, Псковской губернии за 1,5 века. Есть все варианты почерков.