I am using Ahnenblatt 3.27 and Gramps 5.1.2 on Ubuntu 20.04. The family tree has been built in Ahnenblatt for many years and contains about 200 people. Images are distributes across the disc and are named inconsistently.
Recently, I discovered Gramps and it looks very promising to me. I very much appreciate that it is open source and under active development.
I wonder what would be a good path to migrate the project from Ahnenblatt to Gramps. I already understand that an export to *.ged will contain all the collected information.
Here is a few questions I came up with:
How can I (automatically) migrate the images (distributed across folders) so Gramps recognizes them?
How can I (automatically) rename images files in the file system to reflect the name of a person?
How can I identify and fix stored images path which point to an image which cannot be found?
Is there other topics which I should pay attention to when migrating the project?
a lot of the answers will be based on how Ahnenblatt works. if it is practical to scan over every image in Ahnenblatt maybe you can rename one file at a time (remember the original so you can put it back) and see what fails in a full scan. otherwise, you would need to extract data from the Ahnenblatt database.
Basically all images are stored in one folder. You can define where that is. The image file name is your choice.
Just wondering if the path name to the image would be in your gedcom import file and you could do a global change before you did the import???
Since files are not included in a gedcom, you will have to manually copy the images to the target folder.
Experiment before you get too far.
Yes, but you can have subfolders. When I visit someone (X) and find images, I create an X subfolder and put the scanned images in that subfolder. It is easier to find the real image: it will be with this person if he is still alive or with one of his children (descendants).
No they are stored like all objects. You’ll have directories like that:
The last character from the image name will give the first subdirectory. In our example “a” => images/a
The penultimate character will give “b” for the subdirectory in images/a => images/a/b
The image name is build from the media handle.
storing the media objects with filenames based on their handle (internal Gramps ID) is a good thing in many ways.
The concept of meaningful filenames and folder structure mirroring a pseudo family tree structure is futile organizational busy-work.
Gramps doesn’t aspire to be a document management system … yet its database still gives broader organization context than could EVER be squeezed into a ‘rationalized’ file & path naming convention. Being forced to abandon the micromanaging of file organization actually saves headaches.
If Gramps is on the same box as the original Ahnenblatt, there is a good chance that the GEDCOM will have viable paths that Gramps will recognize. However, the Ahnenblatt support forum indicated they have a “relative path” feature equivalent to our Base path for relative media paths in the Preferences. So you would need to manually set the Gramps preferences to the same as the Ahnenblatt Alternative Path (Alternativpfad).
If the trees are to be on different machines, you probably want to use the Ahnenblatt portable to offload the files to a USB stick & then migrate that to the new box BEFORE generating the GEDCOM export. This should eliminate the likelihood of path difficulties.
Yes. I am using Ahnenblatt portable (now 3.36) because I run it out Linux with Wine.
I depend on the relative folder structure path because I copied all the files over from a Windows machine a while ago and had to rebuild the folders in order to let Ahnenblatt discover them. I would love to flatten the folder structure but there is a lot of bad file names such as “unknown1.jpg” and so on. Therefore, a renaming mechanism based on the person data would be helpful. I realized I cannot modify the *.ahnbytecode but I could work on the *.gedplain text file.
Assuming that all other data like names, events, notes, places and sources transfer OK through GEDCOM, a quick way to transfer media is to keep the structure as you had that with Ahnenblatt, where some of your media might be in your Documents and other media may be in the Pictures folder. If they are exported with full paths, the GEDCOM may have lots of entries with paths like
which Wine mapped to some Linux folder.
Now, when you import these to Gramps running in Linux, these paths must be changed to something like
and that’s an easy job for the Gramps media manager tool. You may also need that to replace all remaining \ with /, and that’s just as easy.
After that, you can use the database check & repair tool to verify that all paths are valid, and if they are, you can run another tool to generate checksums for all media, and reorder them in any way you want. Now, when you run that tool again, it will search your drive to find where they were moved.
Before this, you may also use the media manager to replace all absolute paths with relative ones. If you do that, the base path set in preferences will be substracted from the paths stored by Gramps, as far as they actually are within that base path. So, if you have a base path like
Gramps is only giving you a warning that Gramps does not understand the tag because _ALTPATH is a custom GEDCOM tag; because the tag begins with an underscore character (_) and those tags are not part of the GEDCOM standard.
Judging by the name my guess is it has something to do with a path , can you ask the Ahnenblatt developers how it should be interpreted ?
FYI Here is a feature request asking that Gramps support Custom GEDCOM tag Import(s) from Ahnenblatt 3.21.
Here is an example snippet from the GEDCOM which brings up the above import message:
1 RIN AB:I8
1 _UID 67AEC2BC4E2A4389BA6DEBC7C0A8E499
1 NAME Firstname /Lastname/
2 SURN Lastname
2 GIVN Firstname
1 SEX F
2 DATE 12 JUN 1958
2 PLAC Some town
2 FILE /home/tbsprs/FamilyTree/Pics/birthday/firstname1.jpg
3 _ALTPATH ../Pics/birthday/
3 FORM jpg
1 FAMS @F7@