Комментарии 40
Отличный пост и идея, спасибо! Есть планы по монетизации?
Мне кажется, тут не хватает возможности экспортировать все персональные данные в полу-машинный формат, из которого даже после третьей мировой ваши потомки смогли бы достать ценную информацию. Такой возможностью хранить одновременно и текст, и медиа-файлы обладает bencode-формат.
Для генеалогических данных есть специальный формат GEDCOM. Поддержка его при импорте и экспорте — одна из актуальных задач.
Касательно bencode: наверное в него очень просто записывать, но расковырять назначение полей в таком файле без подробной документации будет сложно. Пока что был вариант сделать экспорт в zip-архив: медиа-файлы лежат как есть, данные экспортируются в виде JSON/XML.
Касательно bencode: наверное в него очень просто записывать, но расковырять назначение полей в таком файле без подробной документации будет сложно. Пока что был вариант сделать экспорт в zip-архив: медиа-файлы лежат как есть, данные экспортируются в виде JSON/XML.
Это desktop проект на C#, так? Если да, то, как по мне, много зависимостей: PostgreSQL, Elastic, приложение для OAuth.
Я, как пользователь MyHeritage, предпочитаю работать с самодостаточной копией программы (имею в виду не online). С 8-ой версии, они перешли от ZIP'ованного текстового формата к SQLite базе.
У вас PG был выбран по причине бОльшей функциональности? Почему не SQLite? Или эти зависимости нужны только для серверной стороны? Этот момент немного непонятен. Обычный пользователь, врядли, поставит себе указанные зависимости.
Я, как пользователь MyHeritage, предпочитаю работать с самодостаточной копией программы (имею в виду не online). С 8-ой версии, они перешли от ZIP'ованного текстового формата к SQLite базе.
У вас PG был выбран по причине бОльшей функциональности? Почему не SQLite? Или эти зависимости нужны только для серверной стороны? Этот момент немного непонятен. Обычный пользователь, врядли, поставит себе указанные зависимости.
Не совсем: это веб-проект, который нужно поставить на собственный веб-сервер. Аргументация такого подхода и преимущества перед десктопным приложением описаны в самом начале.
Согласен, что установка требует больше усилий, чем хотелось бы (хотя у меня скачать два инсталлятора и прощелкать next-next-next занимает не более 5 минут). Насколько я понимаю, с данной проблемой помог бы docker, но мне пока не доводилось с ним работать. Если кто-то из читателей сможет помочь — буду признателен.
Плюс использования OAuth в том, что весь геморрой с авторизацией (двухфакторка, смена пароля, восстановление и т.д.) ложатся на Facebook. Если отказаться от этой зависимости — придется все это реализовывать самостоятельно и требовать настроенный email-сервер для отправки писем. По сравнению с этим настроить приложение все-таки гораздо проще.
Согласен, что установка требует больше усилий, чем хотелось бы (хотя у меня скачать два инсталлятора и прощелкать next-next-next занимает не более 5 минут). Насколько я понимаю, с данной проблемой помог бы docker, но мне пока не доводилось с ним работать. Если кто-то из читателей сможет помочь — буду признателен.
Плюс использования OAuth в том, что весь геморрой с авторизацией (двухфакторка, смена пароля, восстановление и т.д.) ложатся на Facebook. Если отказаться от этой зависимости — придется все это реализовывать самостоятельно и требовать настроенный email-сервер для отправки писем. По сравнению с этим настроить приложение все-таки гораздо проще.
Я, возможно, невнимательно прочитал момент, что это веб-проект. Для серверной реализации, такой вариант в порядке вещей.
Но, для меня, иметь локальную базу у себя, а не где-то на сервере, гораздо важнее. Потому что, если сервис прекратит работу, то все данные будут утеряны. Так, я терял доступ к Bitbucket, по причине блокировок IP Amazon серверов (сейчас уже всё нормально, но осадок остался), прекращение работы QIP — у меня там была почта. Я минимизировал последствия этого тем, что имел копии данных локально (и, конечно, не в одном экземпляре). Ну, и проблемы у самого хостера никто не отменял.
Да, у online решений с одной стороны есть несомненные плюсы, но есть и минусы в плане того, что данных у пользователя, фактически, нет — только доступ к ним.
Но, для меня, иметь локальную базу у себя, а не где-то на сервере, гораздо важнее. Потому что, если сервис прекратит работу, то все данные будут утеряны. Так, я терял доступ к Bitbucket, по причине блокировок IP Amazon серверов (сейчас уже всё нормально, но осадок остался), прекращение работы QIP — у меня там была почта. Я минимизировал последствия этого тем, что имел копии данных локально (и, конечно, не в одном экземпляре). Ну, и проблемы у самого хостера никто не отменял.
Да, у online решений с одной стороны есть несомненные плюсы, но есть и минусы в плане того, что данных у пользователя, фактически, нет — только доступ к ним.
Еще раз: у вас есть полный физический доступ к базе и файлам, Bonsai никак не ограничивает возможности для их защиты.
Например, вы создаете собственную виртуалку в облаке и ставите на нее весь необходимый софт, включая базу и веб-сервер. Вы не зависите ни от каких провайдеров услуг, кроме собственно Amazon/Digital Ocean/Azure, а шанс их внезапного выхода из бизнеса без сохранения ваших данных я считаю принебрежимо малым. Даже если ваш IP попадет в черный список, вы можете хотя бы зайти на сервер с помощью прокси и сохранить все ваши данные.
Если это вам кажется недостаточно безопасным режимом — Bonsai можно развернуть на собственном «железном» сервере, который стоит у вас в квартире. Тогда вы вообще не будете зависеть ни от чего, кроме электричества и интернета.
В обоих случаях делать бэкапы крайне важно, но эта задача остается лично на вас. Я для себя сделал просто периодическую задачу, которая каждый день делает dump базы и кладет его на два запасных диска.
Например, вы создаете собственную виртуалку в облаке и ставите на нее весь необходимый софт, включая базу и веб-сервер. Вы не зависите ни от каких провайдеров услуг, кроме собственно Amazon/Digital Ocean/Azure, а шанс их внезапного выхода из бизнеса без сохранения ваших данных я считаю принебрежимо малым. Даже если ваш IP попадет в черный список, вы можете хотя бы зайти на сервер с помощью прокси и сохранить все ваши данные.
Если это вам кажется недостаточно безопасным режимом — Bonsai можно развернуть на собственном «железном» сервере, который стоит у вас в квартире. Тогда вы вообще не будете зависеть ни от чего, кроме электричества и интернета.
В обоих случаях делать бэкапы крайне важно, но эта задача остается лично на вас. Я для себя сделал просто периодическую задачу, которая каждый день делает dump базы и кладет его на два запасных диска.
Для меня, online подразумевает доступ для множества пользователей.
Мне не составляет проблем поставить весь этот софт, но для простых пользователей, которые умеют, разве что, работать с браузером, этот вариант может не понравиться. Как минимум, PostgreSQL может не стартовать «из коробки». Сколько не пробовал, всегда приходилось лезть в конфиги и вносить правки (вероятно, мне просто везло на такое и у других всё сразу работало). Пробовал с разными Linux дистрибутивами. Под Windows не пробовал, возможно, там всё работает.
Это, что касалось концепции продукта. Что касается самого продукта, то он представляет интерес. Мне, как раз, интересна возможность online доступа тоже. Он сейчас работает только под Windows? Можно ли скомпилить для работы в Linux средах? В последних VS, вроде, было что-то такое, хотя, могу ошибаться.
Мне не составляет проблем поставить весь этот софт, но для простых пользователей, которые умеют, разве что, работать с браузером, этот вариант может не понравиться. Как минимум, PostgreSQL может не стартовать «из коробки». Сколько не пробовал, всегда приходилось лезть в конфиги и вносить правки (вероятно, мне просто везло на такое и у других всё сразу работало). Пробовал с разными Linux дистрибутивами. Под Windows не пробовал, возможно, там всё работает.
Это, что касалось концепции продукта. Что касается самого продукта, то он представляет интерес. Мне, как раз, интересна возможность online доступа тоже. Он сейчас работает только под Windows? Можно ли скомпилить для работы в Linux средах? В последних VS, вроде, было что-то такое, хотя, могу ошибаться.
Доступ для множества пользователей работает. Есть даже три группы пользователей:
Насчет установки: как вы понимаете, сервер нужно настроить только один раз для семьи. Все остальные читатели и редакторы могут заходить через браузер как на любой другой сайт, и им не придется думать о базе данных, эластике и прочей ерунде. Я постараюсь облегчить первоначальную настройку с помощью докер-образа, но превратить этот процесс в однокнопочный все равно не получится: как минимум владелец должен будет настроить процесс бэкапа так, как ему удобно.
Насчет операционных систем: все компоненты Bonsai (рантайм, фреймворк, зависимости) являются кроссплатформенными. Я использую Windows и пока не проверял, но запустить его на Linux должно быть вполне возможно — в лучшем случае просто сразу заработает, в худшем придется поправить пару строк.
- Администратор: полный доступ.
- Читатель: может просматривать все страницы, но не редактировать их. Есть мысль о том, чтобы все-таки разрешить читателю редактировать страницу про самого себя.
- Гость: по умолчанию не видит ничего. Может подать заявку на регистрацию, которую должен проверить админ. Тогда гость сам становится читателем или админом.
Насчет установки: как вы понимаете, сервер нужно настроить только один раз для семьи. Все остальные читатели и редакторы могут заходить через браузер как на любой другой сайт, и им не придется думать о базе данных, эластике и прочей ерунде. Я постараюсь облегчить первоначальную настройку с помощью докер-образа, но превратить этот процесс в однокнопочный все равно не получится: как минимум владелец должен будет настроить процесс бэкапа так, как ему удобно.
Насчет операционных систем: все компоненты Bonsai (рантайм, фреймворк, зависимости) являются кроссплатформенными. Я использую Windows и пока не проверял, но запустить его на Linux должно быть вполне возможно — в лучшем случае просто сразу заработает, в худшем придется поправить пару строк.
Делайте виртуалки сами, локально. Выкладывайте для тех потенциальных пользователей, кто не сразу решится на подвиг установки из девяти шагов. Используйте сами для тестов и как бекапы полностью работоспособной настроенной системы в какой-то стадии разработки — делайте снепшоты.
Виртуалки локально — это совсем несложно. И очень полезно для веб-проекта (и для любого, требующего сложного процесса установки и настройки). Я сам долго откладывал в своём проекте, потом жалел о том, что столько откладывал. Один раз разберитесь с установкой OS (может быть даже разных). Попробуйте конвертирование разных форматов виртуалок (VMware, Virtual Box) — люди любят разные фломастеры.
Виртуалки локально — это совсем несложно. И очень полезно для веб-проекта (и для любого, требующего сложного процесса установки и настройки). Я сам долго откладывал в своём проекте, потом жалел о том, что столько откладывал. Один раз разберитесь с установкой OS (может быть даже разных). Попробуйте конвертирование разных форматов виртуалок (VMware, Virtual Box) — люди любят разные фломастеры.
Спасибо, это хорошая идея — попробую сделать на досуге.
Да, вас тут ещё про Docker спрашивают. Ещё один совет до кучи — сначала сделайте переход на Linux, а потом уже пробуйте Docker. Docker под Windows — это проблемно, медленно и почти бесполезно, как мне показалось. А начать в любом случае лучше с простых виртуалок. Пусть будут как промежуточный шаг в направлении виртуализации-контейнеризации.
Docker образ будет?
Да, есть в ближайших планах. Пока не доводилось им пользоваться, но разберусь. Больше интересует, что при встраивании чужих приложений (elastic, pgsql) происходит с лицензией?
Встраивать ничего не придется. Разверните соответсвующие контейнеры (elastic, pgsql) рядом с контейнером своего приложения. https://docs.docker.com/compose/ вам в помощь.
Образ для докера сделали, в Readme описан процесс установки. Если есть время — пожалуйста, попробуйте?
Из тех, что я смотрел, самыми приятными в использовании показались Gramps (бесплатный)
Мне не понравился. По юзабилити и дизайну далек от коммерческих приложений (по крайней мере от MyHeritage). Может как-нибудь сделают что-нибудь получше на Авалонии :)
Я просмотрел множество вариантов. Самый эстетически приятный был на сайте MyHeritage
Мне тоже больше всего понравилась визуализация там.
Данные хранятся в базе в виде направленного графа и, в теории, его должно быть несложно визуализировать. На практике же именно с отображением дерева возникло больше всего сложностей.
А еще есть экзотический вариант визуализации с помощью интерфейса к Git. Писал о таком осенью Генеалогическое древо внутри Git.
Задумайтесь на минуту: веб в нынешнем его виде существует едва ли двадцать лет, а семейная история подразумевает хранение веками.
Если пофантазировать, то деревья будут все больше и больше объединяться, т.к. количество заинтересованных и качество сервисов будут расти. Возможно, крупнейшие социальные сервисы (vk, facebook) внедрят функциональность по генеалогическим деревьям и лучше продумают вопросы смертности (сейчас большой потребности нет).
Первоочередные задачи — ускорить отображение дерева, разрешить загрузку документов в виде PDF и добавить тонкую настройку прав доступа.
Думаю логичным решением является доступ по email. Хотя может действтительно нужно что-то еще более тонкое, чтобы часть дерева или часть инфы можно было шарить всем, а часть — определенному кругу лиц.
Социальные сервисы типа вышеупомянутых — имхо, зло. Весь интернет должен быть социальной сетью, без деления на отдельные несовместимые между собой песочницы, старающиеся свой контент отгородить заборами. И отнимающие силы разработчиков, которые должны были быть потрачены на весь веб целиком, а не оазисы социальности в пустыне.
Но сама идея — объединять генеалогические деревья-«бонсайчики» при рождении ребёнка — по-моему, замечательная. Автор должен оценить. Можно через экспорт-импорт слияние реализовать. Ну и просто перекрёстным связям уделить больше внимания. Есть бездетные браки, есть крёстные-крестники. Наконец, просто друзья-подруги — на семейных фото иные встречаются чаще многих кровных членов семьи. Если есть возможность завести внешний IP (или пользоваться сервисом для динамического IP), то можно делать ссылки даже с одной домашней виртуалки на другую.
Фича хороша и для популяризации проекта. Она может редко используемая, но такая понятная, хорошо иллюстрируемая. Умильно-сентиментальная. Цепляюще-запоминаемая.
Но сама идея — объединять генеалогические деревья-«бонсайчики» при рождении ребёнка — по-моему, замечательная. Автор должен оценить. Можно через экспорт-импорт слияние реализовать. Ну и просто перекрёстным связям уделить больше внимания. Есть бездетные браки, есть крёстные-крестники. Наконец, просто друзья-подруги — на семейных фото иные встречаются чаще многих кровных членов семьи. Если есть возможность завести внешний IP (или пользоваться сервисом для динамического IP), то можно делать ссылки даже с одной домашней виртуалки на другую.
Фича хороша и для популяризации проекта. Она может редко используемая, но такая понятная, хорошо иллюстрируемая. Умильно-сентиментальная. Цепляюще-запоминаемая.
Идея с объединением деревьев действительно прикольная, но реализовать ее как следует будет невероятно сложно. По сути, это превратит централизованную систему в децентрализованную, со всеми вытекающими последствиями — необходимостью синхронизации дальнейших изменений, правами доступа, разрешением конфликтов, пересылкой больших файлов… Хотя через десять лет все равно придется полностью переписывать — там подумаем :)
Мне кажется, что с полнотекстовым поиском вы поторопились. Надо поставить русскую морфологию, например, отсюда github.com/postgrespro/hunspell_dicts и все должно работать. Дело в том, что по-умолчанию используется стеммер snowball, который довольно тупой.
Короче говоря, можно все настроить с постгресом. У меня в ЖЖ есть несколько постов на тему FTS . Прошлой осенью я делал доклад в Лиссабоне на PGConf.eu, там тоже можно посмотреть на предмет словарей. Если что непонятно, обращайтесь. Меньше зависимостей, проще система.
Вот, что получается:
Понятно, что ничего хорошего не получится. Если поставить hunspell_ru_ru, то ситуация лучше
russian_aot_hunspell выдает побогаче
Можно в конце-концов сделать словарь синонимов и вбить туда исключения, я рекомендую использовать dict_xsyn для гибкости.
select ts_lexize('russian_stem','Иванова'), ts_lexize('russian_stem','Иванов'), ts_lexize('russian_stem','Иван');
ts_lexize | ts_lexize | ts_lexize
-----------+-----------+-----------
{иванов} | {иван} | {ива}
(1 row)
Понятно, что ничего хорошего не получится. Если поставить hunspell_ru_ru, то ситуация лучше
select ts_lexize('russian_hunspell','Иванова'), ts_lexize('russian_hunspell','Иванов'), ts_lexize('russian_hunspell','Иван');
ts_lexize | ts_lexize | ts_lexize
-----------+-----------+-----------
(null) | {иван} | {иван}
(1 row)
russian_aot_hunspell выдает побогаче
select ts_lexize('russian_aot_hunspell','Иванова'), ts_lexize('russian_aot_hunspell','Иванов'), ts_lexize('russian_aot_hunspell','Иван');
ts_lexize | ts_lexize | ts_lexize
----------------------------------+-----------+-----------
{иванов,иваново,ивановец,иванов} | {иванов} | {иван}
(1 row)
Можно в конце-концов сделать словарь синонимов и вбить туда исключения, я рекомендую использовать dict_xsyn для гибкости.
Короче говоря, можно все настроить с постгресом. У меня в ЖЖ есть несколько постов на тему FTS . Прошлой осенью я делал доклад в Лиссабоне на PGConf.eu, там тоже можно посмотреть на предмет словарей. Если что непонятно, обращайтесь. Меньше зависимостей, проще система.
Круто, но…
Я думаю, реализация на тёплом ламповом PHP + MySQL была бы более востребована массами, поскольку такой хостинг проще найти по доступной цене.
.NET в облаке — это, конечно, современно, но обывателю ввязываться в это ради генеалогического дерева нецелесообразно.
Ну, и с технической точки зрения организация всего генеалогического зоопарка в виде P2P выглядела бы революционно…
В любом случае ещё один бесплатный генеалогический веб-движок — это отлично :)
.NET Core 2.1+
Я думаю, реализация на тёплом ламповом PHP + MySQL была бы более востребована массами, поскольку такой хостинг проще найти по доступной цене.
.NET в облаке — это, конечно, современно, но обывателю ввязываться в это ради генеалогического дерева нецелесообразно.
Ну, и с технической точки зрения организация всего генеалогического зоопарка в виде P2P выглядела бы революционно…
В любом случае ещё один бесплатный генеалогический веб-движок — это отлично :)
У меня не было цели сделать популярный или революционный продукт продукт. Я делал в первую очередь удобный инструмент для себя, поэтому и технологии выбирал на свой вкус. Так уж случилось, что я считаю PHP одним из самых плохо спроектированных языков на свете, и похоже что это начали понимать даже сами разработчики, но холивар оставим на другой раз.
Что же до простого обывателя — ему достаточно будет запустить docker-образ и не придется думать о том, на чем написан движок. Хостинг для виртуалок в 2019 году очень широко распространен и стоит вполне доступно.
Что же до простого обывателя — ему достаточно будет запустить docker-образ и не придется думать о том, на чем написан движок. Хостинг для виртуалок в 2019 году очень широко распространен и стоит вполне доступно.
Давно хочу прикрутить подобный график как в ELK для webtrees. Можно по-подробнее в чем там проблема с временем рендера? Как поможет перенос логики на бэк?
Есть свойство thoroughness. Чем меньше значение — тем быстрее рендерится, чем больше — тем качественнее получается граф. По умолчанию там стоит значение 7, но оно дает довольно «шумный» граф с множеством лишних пересечений. Для хорошего результата приходится использовать значение 400, но тогда layout считается заметно дольше — порядка 5 секунд.
Перенос логики на бэк позволит позволит потратить эти 5 секунд один раз после сохранения страницы, а потом показывать ее моментально из закешированных данных, вместо того чтобы заново пересчитывать их каждый раз при открытии страницы.
Перенос логики на бэк позволит позволит потратить эти 5 секунд один раз после сохранения страницы, а потом показывать ее моментально из закешированных данных, вместо того чтобы заново пересчитывать их каждый раз при открытии страницы.
А можете скинуть на pastebin или еще куда-нибудь кускок данных которые подаются сюда?
пардон, закрыл вкладку, а когда вернулся на предыдущую страницу и обрадовался, что полунаписанный комментарий остался — то не обратил внимания, что комментарий не в ту ветку попал.
Скачал проект, чтобы посмотреть исходники на досуге. Обожаю смотреть код реальных проектов, кто и как делал те или иные решения.
А вот насчёт будущего не проекта даже, а по поводу данного конкретного файла данных скажу так. Будучи реалистом я думаю, что через 50 лет кто-то опубликует ментаграмму на хапле-хапле:
Все совпадения случайны :)
А вот насчёт будущего не проекта даже, а по поводу данного конкретного файла данных скажу так. Будучи реалистом я думаю, что через 50 лет кто-то опубликует ментаграмму на хапле-хапле:
«Надо же, мой дед носил хипстерские шмотки еще до того, как это стало мейнстримом». Первым делом я сохранил в мемокристалл данные (представляете, там не было ни одного голографического снимка! а некоторые побились и выглядели чёрно-белыми) и решил: «Хочешь сделать что-то хорошо — сделай это сам!»
Все совпадения случайны :)
Тоже сталкивался с проблемой, как у автора, искал решения и даже начинал пилить свой велосипед. Действительно, из standalone движков более или менее работоспособен только webtrees, от одного внешнего вида которого воротит. Еще есть один более приличный, но платный проект TNG. Автор занимается им в одиночку вот уже 18 лет. Конечно, выглядит тоже не очень современно, да и внутри тоже заметны тренды нулевых. Оба движка на православном PHP + MySQL.
На мой взгляд, сервис подобного рода должен быть «гибридным», т.е. уметь работать и с локальной базой, и с удаленной для многопользовательского доступа. Например на PouchDB.
На мой взгляд, сервис подобного рода должен быть «гибридным», т.е. уметь работать и с локальной базой, и с удаленной для многопользовательского доступа. Например на PouchDB.
По поводу Graphviz: покажите плз пример данных, который он отрисовал некорректно? (желательно в *.dot) В графвиз куча различных настроек, приёмов и движков для отрисовки, часто основной сложностью становится выбор нужных параметров. Graphviz это индустриальный стандарт в визуализации графов, я крайне рекомендую не выкидывать его из списка кандидатов. Кроме того вы пользуетесь Viz.js, а не самим Graphviz. Судя по описанию проекта, это сборка на Emscripten обычного графвиза, так что поведение у Viz.js и Graphviz теоретически д.б. одинаковое, но я бы перестраховался и попробовал отрисовать все проблемные графы в традиционном Graphviz.
К сожалению, тестовые скрипты для генерации DOT-синтаксиса канули в лету, но вот небольшой пример. Нужно сгенерировать вот такой граф:
Первая крупная проблема — из коробки выглядит неприятно:
Вторая проблема: для получения хорошего внешнего вида приходится подбирать параметры руками, т.е. если из некоторых произвольных данных получилось сделать красивый граф, то добавление одного лишнего элемента может его полностью разломать. Другие мелкие проблемы — viz.js больше по размеру, кастомизировать внешний вид плашек сложнее.
В итоге ELK.js оказался гораздо проще и для данной задачи вполне устраивает.
Моя лучшая попытка на DOT
digraph G {
splines=ortho
n1 [label="Иванов Иван Иванович", shape=rect, width=3, fixedsize=true]
n2 [label="Иванова Анна Николаевна", shape=rect, width=3, fixedsize=true]
n3 [label="Иванов Михаил Иванович", shape=rect, width=3, fixedsize=true]
n4 [label="Иванов Константин Иванович", shape=rect, width=3, fixedsize=true]
n5 [label="Иванов Алексей Иванович", shape=rect, width=3, fixedsize=true]
x1 [label="", fixedwidth=true, width=0.01, height=0.01]
{n1 n2} -> x1 [arrowhead=none]
x1 -> {n3 n4 n5} [arrowhead=none]
}
Первая крупная проблема — из коробки выглядит неприятно:
Вторая проблема: для получения хорошего внешнего вида приходится подбирать параметры руками, т.е. если из некоторых произвольных данных получилось сделать красивый граф, то добавление одного лишнего элемента может его полностью разломать. Другие мелкие проблемы — viz.js больше по размеру, кастомизировать внешний вид плашек сложнее.
В итоге ELK.js оказался гораздо проще и для данной задачи вполне устраивает.
Выравнивание групп нодов традиционно делается через объявление подграфов, +можно добавить ещё фиктивных нодов-точек и вручную управлять их раскладкой. Хотя да, это избыток ручных настроек и я не знаю как с ним бороться.
Вот корректный граф:
Да, при splines=ortho «из коробки» стрелки из родителей выглядят некрасиво/неодинаково, не знаю с чем это связано, при других значениях spline всё выглядит более однородно. Хак в данном случае — направить рёбра n1->n1n2->n2 вместо n1->n1n2<-n2
Вот корректный граф:
gv
digraph G {
splines=ortho
node[shape=rect]
edge[arrowhead=none]
{
rank=same
n1 [label="Иванов Иван Иванович"]
n1n2 [label="", shape = point]
n2 [label="Иванова Анна Николаевна"]
n1->n1n2->n2
}
n3n4n5 [label="", shape = point]
{
rank=same
n3 [label="Иванов Михаил Иванович"]
n4 [label="Иванов Константин Иванович"]
n5 [label="Иванов Алексей Иванович"]
}
n3n4n5->{n3 n4 n5}
n1n2->n3n4n5
}
Да, при splines=ortho «из коробки» стрелки из родителей выглядят некрасиво/неодинаково, не знаю с чем это связано, при других значениях spline всё выглядит более однородно. Хак в данном случае — направить рёбра n1->n1n2->n2 вместо n1->n1n2<-n2
В поиске того же что и автор помыкался по коммерческим десктопным приложением, самыми удобными для меня оказались Древо Жизни и Семейная летопись но я еще не осмелился приобрести ни то, ни другое. Теперь очень хочется пробовать Bonsai, мне он кажется гибче и сочетает в себе положительные стороны этих двух десктопных приложений.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Bonsai: фамильный вики-движок