I haven’t used xdot. I have just used dot on Kubuntu and macOS. A typical command line statement is like this.
dot input.dot -v -Tpdf -o output.pdf
Generally I produce the chart in pdf format, usually A0 or A1 size for printing. But I don’t know why it isn’t working for you. If you get Gramps to produce a pdf or png file (instead of a .gv), does that work?
As for filters, when creating a person filter, there is a rule (in the general filters section) for People with the . So the approach that I would try would be to create a filter (filter1) that selects all the people with the selected name. Then create a second filter (filter2) with two rules
people matching filter1
spouses of filter1
Then create the relationship graph using filter 2.
A 1MB dot file sounds rather large. It might be easier to start with a smaller number of people, and when the method has been sorted out, apply this to the full set of people that you want.
In my experience, relationship graphs are only practical up to around 800 people on one chart.
I created the filters you suggested and it returned both the person and that person’s children. It did not return just the children. Then I expanded the Filter1 flexibility and re-named it SpecificPeople.
The added flexibility was to set up SpecificPeople to look for a list of IDs in the example.gramps tree. (Please use this example tree when asking questions about building a Custom Filter. It lets us reproduce each others results and eliminates having malformed tree data causing issues.)
Usually, I set something like the SpecificPeople to look for people with a “Tag”. Then I do not have to remember the RegEx (Regular Expressions) pattern matching format. (And so I can quickly re-target the filter and see the targeted people with the Tag color.) But in this case, I used the Clipboard context menu to “Create Filter from the person selected…” as a shortcut.
@emyoulation I’m using tags for people, but these tags indicate the region, not the kinship between individuals. So, in principle, I can and plan to use these tags in this case, but they don’t sufficiently limit the number of people. Many of them will be redundant. And adding new tags to build a dot file is impossible. Imagine, I’ve set hundreds of tags, finished doing it, and then I add one person to the database. I will have to manually analyze all her family ties and all her associations with other individuals (to an unlimited depth of connections) to decide whether to add such a tag to her. This should be done by the program. It took a person, added her relatives and all associations. Then it took each of the relatives and each of the associations and did the same for them. And so recursively until the connections run out.
Returning to my previous question, I showed where the problem is in the screenshot.
I hope it’s clear enough. In your option, I see a regular expression with a list of IDs. I have only 1 ID, to which I’m trying to also attach his children and display all three on the screen. But it turns out either just the parent (filter 1) or only his children (filter 2). I can’t understand how to show all three. Thank you.
By the way, listing all the necessary IDs with a regex brings us back to the same problem as tags - it’s impossible to keep up-to-date.
And I also showed in another screenshot what I eventually try to get with these reports.
It’s manual work, but I quickly realized that drawing all of this by hand is extremely difficult, and keeping it up-to-date is even harder. In the screenshot, it’s not necessary to read the names, but you can see that green is people who have the same last name, but I can’t yet connect them into one family. They can be relatives or just people with the same surname. That’s why I want to look at them through associations. All uncolored people are either godparents, wedding witnesses, or other associations. As you can see, between two green cards, there can be chunk of more than one associative person.
How can I extract such people list using filters?
Tags are for temporary use, Attributes are for permanent use. The Regions are unlikely to change and are probably better attributes than Tags.
I often use Tags to simplify and accelerate repeated filtering. Obviously, each Rule in a custom filter adds to the filter’s execution time.
So when creating a very complex Custom Filter that takes too long to run interactively, I use that Filter in the Add/Remove Tag addon tool to create a complex set of Tagged objects. Then I might manually add or remove Tags from some objects. Or compound the set of Tag objects using another Custom Filter Now I can use the Filter Gramplet to filter on that Tag instead of using the Custom Filter. Filter on Tags is faster on each refresh of the view.
You are also thinking of a “List of IDs” too narrowly. A list may contain 1 item as easily as it could contain multiple items.
Your screen capture does not show the filter names in the Filter2 rules. However, it does suggest one possibility.
Maybe the naming of your rules is revealing a bug? The gylphs in the filter name include Cyrillic unicode characters that are not in the simple ASCII character set. And they include mathematical and set operator symbols. (i.e., Ф phi, periods or commas, plus)
Try simplifying the names to “Filter1” and “Filter2”. If it returns different results, we have a Localization bug to report.
@emyoulation Regarding the use of tags by region, I wasn’t clear enough in my wording. I have only a few, and they are called something like:
Research Direction (Poltava)
Research Direction (Kyiv)
This doesn’t mean the person necessarily lived there, but it means that everyone I met during the study of this region (even from other localities) gets this tag.
The thing is, I often have repeating full names, and it’s challenging to distinguish people. At the same time, I can’t give them a specific locality in the attributes because they migrated. In our area, mass relocations were a norm of life.
So specifying a locality needs to be linked to a specific date, i.e., in the properties of events, not in the attributes of the person.
Regarding the mistake in the filter name - there really are bugs either with Cyrillic or with special characters. Because when I named the filters F1 and F2, I finally saw a father and his two children. Thank you for this because the issue with the filters is finally behind, and I can continue my work!
Regarding the use of the mass tagging Add/Remove Tag, I think I understood how you use it. You filter out everything you are interested in, and then you mass assign some temporary filter, which you then use for the same reports, exports, etc. After that, you delete the tag, right? I’ll try this way, and I think I came up with an idea on how to recursively and relatively quickly apply tags where needed in semi-manual mode. If it works, I will tell you how I did it.
@Urchello Could you paste in the original (problematic) names for your Filters?
To transcribe the bug report to the MantisBT system, I’d have to look up the Cyrillic symbols. It would take extra time and I am likely to make mistakes … and use similar looking characters that will not reproduce the problem.
We help troubleshoot here and help people find workarounds.
Once a problem is isolated, it has to be put in MantisBT in hopes that it will pique the interest of a developer.
Sure!
The filter 1 name: Черниш П.Ф.
The filter 2 name: Черниш П.Ф. + прямі родичі @emyoulation I also can make git pull and test your fix if you want.
I tried to recreate the problem using the Example.gramps sample tree. It did not exhibit the problem. (Both the person and his 8 children were found by the filter.)
Renaming a filter does not make the change in any other filter that makes reference to the renamed filter. The same is true if a filter makes reference to a Tag. Alter the Tag name in the database, the filter using it will not know about the change. Create a filter based upon a Gramps ID, if you alter the ID (go from 4 digits to 6), the filter will not know about the change.
I understand, I’ll keep this in mind when using tags and filters. But other users might encounter the same issues and will spend their time trying to figure out the reason, as well as your time by opening new discussions on the forum.
If this is the intended functionality, maybe there can be a note at the bottom of the window in red text stating:
"When renaming a tag/filter, you should consider that..."
I’ve seen a similar message in the events. It informed that changes in the event will affect all places where this event is used. Something like that.
But this is up to you. If I’m the first one to bring up this issue during the entire existence of Gramps, maybe it’s just me :).
Honestly, I feel like I’m trying to use Gramps at the edge of its capabilities, so not everything goes smoothly for me. However, the more I use it, the more I appreciate what Gramps can do. There are many routine spots that could be improved to make the workflow faster, but the functionality is truly impressive.
In any case, thank you very much for your help and for clarifying these nuances.
Have a great day. And please, let me know if I can be of any help.
Maybe not intended, but it is a functionality limitation.
You will find the same for Report and Tool options. Their information is stored in report_options.xml and tool_options.xml in the user’s \gramps\ folder. Changes made elsewhere may have an adverse effect on the static settings from the last time you accessed the tool or report.
Because of my massive use of filters and this hell that is the non-automatic renaming of references which consume filters which can change names, I defined a nomenclature for naming my filters. Part of it is in the filter name, part of it is in the comment. So each filter looks like this:
The compensatory advantages to all this terminology are in particular that:
in the event of renaming a filter I can find wherever it is consumed and modify this consumer so that it uses the new name,
a second advantage is that thanks to the number of filter indicated in comments, I can rename my filters in bulk by editing the custom_filters.xml file in Notepad++
In the filter editor, I can also classify them functionally by sorting them by their name (therefore their category number),
or by their sequential number by sorting them by the comment, which makes it possible to simply find a filter which would have been renamed for example, this number never changing.
Looks like not only me have troubles )))
Maybe authors will think about moving filters into db with a separate filter_name attribute? If this is possible of course. But probably it could be a big job. @emyoulation@DaveSch@hewettp
There are a number of issues with Filters being identified by index in the Gramps file format too. Filters and Rules are not 'object’s in the database and references to them seem to be more fragile.
In notes, you can reference an object. If trees are merged, any moved reference (because of duplication) is resolved. And dead links are pruned.
If you have saved Books of reports, they typically reference Custom Filters. They can become invalid if the set of rules and/or custom filters is changed.
Or simply if you reload your Gramps backup file in a new database. I save the id of my filters in a final book page because of that issue to be able to re-create them after a data restoration.
