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

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

Wiktor16 написал:

[q]
Еще есть немаловажный параметр memory_limit (какой лимит памяти выделен одному процессу скрипта)
[/q]

Скорее всего, дело именно в этом. У меня он до безобразия маленький: memory_limit 48M
При создании сайта проскакивала фраза, что для обработки 5000 человек нужно 64 метра, а у меня база 10 тысяч и постоянно пополняется.
Завтра попробую загрузиться на другой сервер, посмотрим, что там покажет.
Странно только, что прямые-то графики он нормально обрабатывает

Yulita написал:

[q]
Странно только, что прямые-то графики он нормально обрабатывает
[/q]

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

Заметил нестыковку Webtrees с ДЖ по населённым местам. Вот как должны отображаться места по правильному:

[ : da4decd1951d.jpg ]

т.е. в England находятся места: Lancashire, London, Suffolk, но при загрузке гедкома из ДЖ получается совсем наоборот:

[ : 11f74ef2ac58.jpg ]

т.е. внутри Донецкой области содержится Украина, а это неправильно.
Это связано с тем, что в гедкоме ДЖ места обозначены так: "страна, область, город", а для Webtrees нужно чтобы места наоборот обозначались: "город, область, страна".

Решение подсказали разработчики "Древа Жизни":

Dmitry Kirkinsky написал:

[q]
Меню "Настройка" - "Настройка программы" - вкладка "Места".
[/q]

Там в поле "Порядок частей места" вместо значения "От страны к адресу" устанавливаем значение "От адреса к стране".

frato написал:

[q]
Если существует более простой способ устранения нестыковки - буду благодарен, если подскажете.
[/q]

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

[q]
1 PLAC
2 FORM City, County, State/Province, Country
[/q]

И судя по всему, скрипт отсортировал данные именно по этому принципу.
И наверное не правильно будет такое переворачивание... логика скрипта от этого не изменится, он будет продолжать понимать именно такой порядок данных при вводе новых записей City, County, State/Province, Country

Наверняка в админке есть установки по этому поводу, наверное нужно копать где то в эту сторону: Google Maps™-Дополнительно и там в самом низу уровни

И\или стоит поиграться с редактированием этого порядка в гед файле до импорта

[q]
1 PLAC
2 FORM City, County, State/Province, Country
[/q]

Стоит с этим разобраться подробнее...

Для чистоты эксперимента - не забывать чистить кеш:
Администрирование - Очистить директорию данных - выделить чекбокс "cache" - нажать кнопку "удалить"

Есть ли возможность в подобных программах объединения разных древ в одно? В Webtrees я такого не нашёл. Может не так искал?

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

yvb написал:

[q]
Есть ли возможность в подобных программах объединения разных древ в одно? В Webtrees я такого не нашёл. Может не так искал?
[/q]

Администрирование->Семейные деревья->Слияние записей

Также можно объединять на родовиде, на фэмилиспэйс, в ДЖ (а из ДЖ потом выкладывать объединённый гедком).

frato написал:

[q]
yvb написал:

[q]

Есть ли возможность в подобных программах объединения разных древ в одно? В Webtrees я такого не нашёл. Может не так искал?

[/q]

Администрирование->Семейные деревья->Слияние записей
[/q]

Тут Администрирование->Семейные деревья->Слияние записей - речь именно о слиянии записей, а не всей базы. То есть можно конечно всю базу так пройти - но это не удобно и долго. Webtrees действительно не умеет полностью объединять две базы сходу. Webtrees все таки больше позиционируется как программа для одновременной совместной работы и для наглядного предоставления информации. Но это умеют другие программы или специальные отдельные утилиты, например http://www.genmerge.com ( есть как платные так и бесплатные). С одной стороны жаль что нет такого функционала в Webtrees, а с другой - может и хорошо что не перегружена лишними задачами. Главное что стандарт GEDCOM это поддерживает. В любом случае плюс стандартизированных программ на лицо - не важно в какой программе вы работаете, не важно где - результат работы всегда можно сохранить, перенести, объединить и т.д.. (речь конечно о стандартизированных программах).

yvb написал:

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

Правильнее будет сказать - Вам так удобнее и возможно быстрее.
Мне например - наоборот. В программу я не ввожу повторяющие записи из списка (не ввожу и не копирую, каждое наименование вводится всего один раз). А это значительно быстрее с учетом большого количества повторяющихся фамилий, географических мест, наименований архивов и т.д..
Причем после ввода в таблицу, данные то еще требуют определенной обработки (или речь идет о вводе данных исключительно ради ввода данных? Без всякого дальнейшего использования введенной информации?) В программе - после ввода исходных данных - сразу же имеем конечный результат - в виде различных и многочисленных справочников, графиков, карт, отчетов и т.д..
Тут не о чем спорить - Вам нравится заполнять таблицы - заполняйте на здоровье, но в мире есть много людей которые давно поняли, что если нужно выкопать большой котлован - удобнее использовать экскаватор (специализированную машину), но если очень хочется и очень нравится - то можно покопать и простой лопатой. Так же и специализированным ПО, можно его использовать для более эффективной работы, а можно и на бумаге вообще вести свою базу. Раз спрос есть на это ПО - значит оно кому то нужно, и за платные версии программ люди платят деньги не за нелюбовь к таблицам, а за более эффективную работу.

Wiktor16 написал:

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

Речь идет не о заполнении таблиц. Существует огромное количество баз сделанных не для генеалогических целей, но содержащих необходимую информацию. В обычных условиях вы берете эту базу и каждую персону вручную переносите в программу, предлагается автоматизировать этот процесс, я например еще с 90-х годов пользуюсь макросом котрорый переводит Excel-евские таблицы в GEDCOM.

KRAN написал:

[q]
предлагается автоматизировать этот процесс
[/q]

и

yvb написал:

[q]
Возвращаясь к таблицам, в них гораздо быстрее вводится информация
[/q]

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

в том числе Webtrees