Web-based программы

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

Wiktor16 написал:

[q]
...вопрос последовательности географических наименований (город, область, страна) - не единственный, есть вопрос еще количества этих полей. Например "район" может быть важным параметром в указании географического места, в нашей местности например довольно часто в пределах одной области встречаются деревни с одинаковыми наименованиями, и введение четвертого параметра было бы очень полезно. К примеру webtrees - поддерживает до 10 уровней определения географических мест.
[/q]

У меня, например, количество этих категорий непостоянно, иногда 3 (страна, область, город), иногда 4 (страна, область, район, село). При таком раскладе города-областные центры отображаются в одном списке с областями, районы в одном списке с городами областного подчинения, сёла сами по себе. В общем всё как надо.

[ Изображение на стороннем сайте: 786a06482d50.jpg ]

Вот только у меня пока часть областных центров включена внутрь соответствующих областей, а часть на одном уровне с областями, а как правильно - я не знаю.

frato написал:

[q]
Вот только у меня пока часть областных центров включена внутрь соответствующих областей, а часть на одном уровне с областями, а как правильно - я не знаю.
[/q]

То что иерархия правильная - это уже хорошо. Но я думаю, что если используется 4-х уровневая структура описания географических мест - то должны быть определены все 4 уровня везде.
Если используется 3-х уровневая иерархия, то нельзя никогда указывать четвертый уровень, чтобы сохранить логику структуры.
То есть в вашем примере часть населеных пунктов находятся на одном уровне с районами, это, наверное не правильно и может вызвать путаницу при импорте\экспорте. Так же я заметил что в этом случае не совсем корректно работает модуль GoogleMaps.
Не всегда кажется логичным указывать все 4 уровня, так например для города Киева это выглядит так:
Киев, город Киев, Киевская область, Украина. что соответствует структуре Город, район, область, страна.

К стати именно в таком формате находится город Киев на сайте GoogleMaps. А в базе Google я думаю поддерживаются определенных стандартов.

И если я использую всегда описание всех уровней вложения, то при экспорте базы в гед файл,
получаю в шапке файла описание количества, порядка и назначения полей описания географических мест - точно соответствующее количеству, порядку следования и описанию мест в теле базы, что теоретически, должно исключить путаницу при обмене данными. Так же в этом случае корректно работает "проверка мест" в модуле GoogleMaps.

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

К стати, глубину уровней вложений в webtrees можно ограничить в настройках дерева:
Макет-Other Сокращать название мест

Wiktor16, извините меня, но найдите в моих текстах, которые были до вашей фразы:

Wiktor16 написал:

[q]
Извините конечно, но из никому не нужного технического спора, это все переходит в полный бред. Откройте любой ged файл и посмотрите что там, если это для Вас загадка. И никому не говорите что для редактирования файлов Exell не нужна никакая программа и таблицы во всех БД одинаковы. Давайте прекратим этот бредоподобный спор на счет таблиц.
[/q]

"высокомерно-хамовитую форму". А уж коли вы первый начали, то не обессудьте. Это конечно же уже оффтоп, поэтому тоже присоединяюсь к просьбе выделись всё это обсуждение в отдельную тему и почистить. Но пока расскажу в качестве оффтопа про высокомерно-хамовитую форму. Я уже 12 лет живу в Германии и вначале был восхищён доброжелательностью и культурой, царящей там. К хорошему быстро привыкаешь и вскоре мы были почти такими же. И вот представляете шок, когда мы впервые снова поехали в Россию. Эта повсеместная агрессивность и злоба настолько бросилась в глаза, что это был просто шок. Было просто удивительно, что мы прожили здесь много лет и этого не замечали. В аэропорту я едва уговорил свою супругу не комментировать вслух первого же увиденного ею милиционера... Таким же шоком было увидеть русское телевидение после немецкого. Я за эти годы был участником множества русских форумов и практически отовсюду ушёл по той же причине - от немецких они отличаются как небо и земля. Но поскольку мы как были, так и остались русскими людьми, то единственный способ вообще посещать Россию и русские форумы и не быть белой вороной - на время становиться такими же как и окружение, тем более, что навыки не теряются. Хотя вначале было трудно сохранять при любых встречах суровый вид, не здороваться с улыбкой, не приветствовать всех подряд, не желать незнакомым людям хорошего дня или выходных, не корёжиться от мата и сплошного хамства и т.п.

Wiktor16 написал:

[q]
Отдельное спасибо хочу сказать Yulita за большую помощь в тестировании программы в плане потребления ресурсов. С ее помощью была выявлена самая ресурсоемкая функция - функция показания родства между двумя произвольными людьми из дерева. Протестированы результаты ее выполнения при разных значениях лимитов на сервере.

… Разработчик программы сейчас работает над этой проблемой, пока найденое им решение не приемлемо для использования на большинстве хостингов (нужно использовать хранимые процедуры mysql, что далеко не каждый хостер позволяет), поэтому пока найденое им решение не включено в релиз.
[/q]

А есть програмное решение - довольно шустро работает:

"Кстати, программа статистической обработки файлов Гедком и указания всех степеней кровного родства для двух персон гроссо модо готова.…
Программка бесплатная и выложена в свободном доступе."

http://www.genery.com/forum_ru/viewtopic.php?f=1&t=2596

frato написал:

[q]
а как правильно - я не знаю.
[/q]

К стати, обнаружена еще одна полезная функция webtrees по вводу географических мест:
В настройках дерева - вкладка Edit Options -Использовать базу данных GeoNames для автозавершения названий мест
При включении этой функции, во время ввода первых символов названия нового географического - автоматически выпадает список мест.
Но к сожалению база GeoNames по российским и украинским городам (те которые я на вскидку проверил) содержит не полный список всех уровней. Иногда пропущен район иногда область, но это явно видно, поскольку уровни разделены запятыми и нужно в ручную дописывать только пропущенные значения.

yvb написал:

[q]
И речь об электронных таблицах как раз зашла в контексте ввода больших объёмов генеалогических данных в эту базу данных.

Например, данных переписей, списков жителей, содержащих многие тысячи персон. У меня есть заранее подготовленные файлы электронных таблиц с такими генеалогическими данными
[/q]

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

Потом стало интересно заниматься своей родословной, и в базу "Дерева жизни" опять же вручную, т.е. каждая персона с датами, местом рождения/проживания/смерти, документальным обоснованием из метрик, ревизок и исповедок, набито более 6 тысяч, в т.ч. 2 тыс. "кровных".

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

Извиняюсь за оффтопик

vnbob написал:

[q]
А есть програмное решение - довольно шустро работает:
[/q]

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

По поводу определения отчества и вообще различных национальных форм представления полного имени:
Найдена следующая информация:
patronymic (отчество) - это часть имени. Именно часть имени, а не отдельная еденица в идентификации человека.
Кроме отечественной особенности представления имен, в мире существует очень много особенностей, например в некоторых восточных странах понятие "фамилия" вообще отсутствует, в некоторых странах имя формируется из целого ряда имен предков и т.д..
Посему представление имен в разных программах, так или иначе имеет свои особенности.
Формат обмена генеалогическими данными поддерживает очень много особенностей имен в разных национальных форматах, разных представлениях и вариантах.
То есть к GEDCOM не может быть никаких притензий или вопросов по этому поводу, какую информацию в него программа выгрузила - ту информацию он абсолютно четко и несет. Тут уже вопросы к самой программе.
В формате GEDCOM есть следующие теги, передающие данные о имени:
_HNM - еврейское имя
NICK - прозвище
GIVN - Имя
SURN - Фамилия
_AKA - Известен так же как
Кроме этого еще всевозможные префиксы и суффиксы к имени и фамилии
Имя в браке
Имя и фамилия в браке
и тд....
Но есть кроме этого всего тег NAME - который включает всебя полную информацию об имени, в формате:
Имя Отчество /Фамилия/
Помимо этого может включать еще несколько имен, разделенных запятой.
Далеко не все прграммы поддерживают работу со всем этим набором данных. Да и далеко не всегда они нужны.
Но если вдруг эти данные есть в базе - при выгрузке в гед файл - они никуда не пропадут, а будут четко определены.
Далее уже вопрос к программе, в которую вы хотите импортировать эти данные.... Поддерживает ли она работу с этими всеми данными.
Вернемся к отчеству:
Я провел сравнение в ДЖ и webtrees, в каком формате вводится, выводится пользователю и в каком виде экспортируется в файл запись об имени и отчестве:
В ДЖ - для вводи имени и для ввода отчества, представленны отдельные поля ввода.
Вввел данные:
Фамилия Иванов
Имя Иван
Отчество Иванович
Результат - где бы не смотрел в программе - вывод имени по этой персоне только в виде "полное имя" тоесть Иван Иванович Иванов (может плохо смотрел, но другого представления не увидел)
Ну в принципе ничего плохого в этом нет - ведь информация полная и правдивая.
Далее делаю экспорт
в гед файле, по поводу описания имени вижу только одну строку с тегом:
NAME Иван Иванович /Иванов/
Что полностью подтвердило высше рассмотренное представление отчества в гед файле.
Дабы убедиться окончательно, делаю следующее
Завожу в ДЖ персону Петр Петрович Петров
Ввожу так:
Имя - Петр Петрович
Отчество (оставляю пустым)
Фамилия - Петров.
Результат получаю идентичный:
Везде в программе персона числится как Петр Петрович Петров
В выгруженом гед файле:
NAME Петр Петрович /Петров/
Что точно подтверждает, что отчество в генеалогических программах рассматривается как часть имени.
И стандарт обмена данными GEDCOM не может никак ограничивать данные в этом отношении, скорее даже наоборот - далеко не все программы используют все типы данных, с которыми может оперировать GEDCOM.

Теперь рассмотрим что получается в этом случае в webtrees:
При добавлении того же Петра Петровича Петрова (в качестве имени указывл Петр Петрович, Фамилия Петров)
Отображение в прграмме то же самое
при экспорте получаем:
1 NAME Петр Петрович /Петров/
2 GIVN Петр Петрович
2 SURN Петров

То есть строка NAME Петр Петрович /Петров/ идентична по формату и по содержанию
Но webtrees умеет оперировать более полными данными
Помимо этого, отдельно указывается имя GIVN Петр Петрович и фамилия SURN Петров
Ведь не всегда полное имя есть в точности имя+фамилия
Всяческие там приставки St или von и т.д... Соответственно webtrees сможет предоставить всю эту информацию, правильно ее отобразить и правильно экспортировать. А вот будет ли оперировать программа, куда будут загружены эти данные - это уже вопрос к ней.
Так к примеру при выгрузке этой записи из webtrees в ДЖ, Петр Петрович петров точно так же отображается, но в ДЖ уже нет данных отдельно по GIVN и SURN.
Это видно потому что при экспорте опять из ДЖ - этих данных в гед файле не будет. И не потому что что то не так с импортом\экспортом, или плох стандарт обмена. Дело в том что ДЖ просто не оперирует вообще с этими данными.
Фух...

Надеюсь понятно объяснил....
Есть еще что сказать по этому поводу, но уже позже....

Мне удалось всё-таки найти программу, которая поддерживает импорт-экспорт в таблицы. Программа бесплатная и на мой не слишком опытный взгляд довольно мощная, по крайней мере в описании утверждается о поддержке до 2 миллиардов записей. Программа немецкая, но поддерживает в том числе и русский интерфейс, но описание есть только на немецком. Программу можно скачать здесь. Вот в связи с этим хочу здесь предложить по теме web-based программы то, что хотел сказать с самого начала, встряв в эту тему. При наличии такой программы под рукой (а возможно есть ещё аналогичные программы), получается очень удобное решение. Вы можете вносить данные хоть в саму программу непосредственно, хоть собирая их в большом объёме в интернете или где-либо ещё в таблицу, а затем импортируя их в эту программу и даже если вам эта программа не нравится, вы всегда можете экспортировать данные в гедком и внести их в вашу любимую программу. Это, так сказать вариант для внутреннего домашнего употребления. А вот при наличии экспорта в таблицу у вас появляется параллельно хороший вариант и для веба. Заключается он в следующем. Вы выбираете какую-нибудь из множества имеющихся вики, устанавливаете её на своём хостинге и автоматически получаете весь вики-потенциал с возможностью групповой работы, разграничением прав допуска и пр. Но, как известно, для внесения информации в вики требуется специальное форматирование текста. Так вот что я и хотел сообщить - в Excel и аналогичных программах довольно легко можно реализовать подготовку готового кода для создания страниц вики. Продвинутые специалисты могут вообще всё это автоматизировать. И эта технология пригодна не только для описания персон, но и для построения любых других окологенеалогических баз данных. Именно так был заполнен мой сайт-вики и именно так я в течение 8 лет поддерживал сайт, на котором постоянно требовались изменения и в котором HTML также автоматически готовился программами электронных таблиц.

Добавление. Ещё программы нашёл с импортом-экспортом в таблицы - Ahnenblatt и Oxy-Gen. Подозреваю, что таких программ много, тогда непонятно почему здесь многие ополчились на таблицы.

Заметил, что пропали некоторые мои сообщения. Не вижу смысла участвовать в цензурируемой дискуссии. Всем успехов

в том числе Webtrees