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).
@SNoiraud , the question of collating the Media object storage comes up frequently.
I am curious if a workaround using the Narrated Web Site report in combination with other tools might be a viable option?
Does the report collate all the local files into a single folder to simplify the ‘sitecopy’ upload process? Does it do subfolders? And, if so, how does it decide to make the folders?
It seems like moving the the generated folder & discarding the rest of the webpages would be a LOT easier than manually collating Media objects. Then you could re-define your Media folder to point there, run the Media Verify to fix broken paths, Merge Media, & convert the absolute paths to relative.
Another option might be the .gpkg backup with images. Then find a way to flatten the Media object paths in the ZIPped archive. Like the way the junk paths ’ parameter ( -j ) does during extraction?
Gramps doesn’t have an option to archive ONLY Media objects. But you can always discard the XML portion afterwards as a post-process.
The ugly part would be that this orphans the original digital copies instead of moving them. That leaves a mess behind.
No they are stored like all objects. You’ll have directories like that:
images/a/b/da6095ae6b643facac3a80f4ba.jpeg
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.
Yes, I saw that. Thank you. Do you know if the version will be available to Ubuntu 20.04? Currently, it is not: Ubuntu – Package Search Results -- gramps - 5.1.2-1: all is listed there.
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
C:\users\name\Documents
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
/home/name/Documents
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
will have the part before records removed. Media that are in other places like
/home/name/Pictures
will not be affected.
Note that when I mention tools, I try to think about how they are named in English, so you need to interpret those in a liberal fashion, and figure out how they are named in German.
Thank you for the hints. I tried a lot by editing the *.ged file before importing it into Gramps. I still get a lot of errors related to _ALTPATH - as if the program cannot interpret it. Example:
Line ignored as not understood Line 205: 3 _ALTPATH …/Pics/birthday/
I can’t figure out what Gramps is unhappy about.
Note that the Debian/Ubuntu installer for the 5.1.5 update was just published.
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.
The support docs implied the GEDCOM had a dual entry… both the path & the _ALTPATH (which is a custom GEDCOM field).
Could you post a single image chunk from your GEDCOM? Maybe it can be converted to something Gramps can use via the Isotammi SuperTool add-on.
And the GEDCOM import messages about ‘ignored’ and ‘skipped’ are misleading. The unrecognized chunk are preserved are Notes. This allows post-processing with filters, database Python commands & such.
Here is an example snippet from the GEDCOM which brings up the above import message:
@I8@ INDI
1 RIN AB:I8
1 _UID 67AEC2BC4E2A4389BA6DEBC7C0A8E499
1 NAME Firstname /Lastname/
2 SURN Lastname
2 GIVN Firstname
1 SEX F
1 BIRT
2 DATE 12 JUN 1958
2 PLAC Some town
1 OBJE
2 FILE /home/tbsprs/FamilyTree/Pics/birthday/firstname1.jpg
3 _ALTPATH ../Pics/birthday/
3 FORM jpg
1 FAMS @F7@
This is good information.
It confirms the the _ALTPATH is redundant information. The full path (albeit with a variant of the Linux environmental variable “$home”) is embedded for each image.
I do not know if the HOME will be properly parsed by the GEDCOM importer. (Since it might be OS agnostic.)