When importing a GEDCOM file I noticed that Gramps does not support a URL as a file reference. GEDCOM 5.5.1 says:
MULTIMEDIA_FILE_REFERENCE:=
A complete local or remote file reference to the auxiliary data to be linked to the GEDCOM context.
Remote reference would include a network address where the multimedia data may be obtained.
It would be nice if Gramps would allow URLs and not only local file names.
btw: it would be nice if Gramps could support more than one file reference per media object; for example to store the front and back pages of a photo or a postcard or to store a preview photo and a pdf document.
A Feature Request was filed in 2011 to add URLs as a valid media path. And there are several related issues.
See 005248 : Media paths should take webURLs
An interesting workaround is that you can use the Import and Text Import to insert Media with URL paths. And you can use SuperTool to change the path to a URL.
But the GUI (the Media Object Editor) will not allow a URL when committing. So, after the URL is in the path, you cannot edit the Title, ID, Date, Privacy, or add Secondary objects (Citations, Attributes, Notes).
The Download media tool is designed to download pictures from websites. In my case the URL is a video and I don’t have the rights to download it. So it should stay as a URL. I will try it.
The more common situation is multiple variations of the same media: different resolutions, formats, media types.
Gramps already has provisions for an original resolution and 2 preset ‘thumbnail’ sizes. And those can be expanded to support more formats with thumbnailer plugins. (There’s a request for an indicator of whether a Path type is relative or absolute. It should probably be expanded to indicate a URL too. See 0013349: Media category view have “Relative” path column with marker and in the Media Filter gramplet)
Yes, this is another interesting use case for more than one media file in a media object. If there is more than one file, the first file is the most important one. If you can show only one image for example in a diagram, Gramps should show the first one, that can be shown. If it is possible to show a gallery, Gramps could present all elements of a media object. For example if the media object contains an audio interview you can store a text file containing the transkription and a photo taken during the interview additionally in the same object.
Yes and yes. Sometimes it is not possible or makes no sense to download and store remote media locally. If you are using Gramps Web you have to store your media files at the Gramps web server. Maybe it is possible to link to those files in your desktop Gramps in order to avoid to store all media files locally.
There is an open question. If there is a need to show a thumbnail instead of a large remote photo, do you store that thumbnail inside the media object or in an external cache or should a thumbnail be generated always on the fly?
Depending on the object, I will often combine the front and back of an image so it just the one image. I do with the WW II draft cards from the U.S… But if it is a large image (page image), I keep them separate images and just add the too (or more) pages the citation’s Gallery tab.
Since the OP @hartenthaler also lists himself as a GrampsWeb user and the patch is related to URLs in media paths, we should also draw the attention of @DavidMStraub to this PR.
The GEDCOM 7 defines ftp, http, https and local file names. Additional URL types may be supported in future versions of GEDCOM. GEDCOM 5.5.1 does not specify the URL types in any way. So I think supporting https is the most important one.
The BLOB context of the multimedia record was removed in version 5.5.1. A reference to a multimedia file was added to the record structure. The file reference occurs one to many times so that multiple files can be grouped together, each pertaining to the same context. For example, if you wanted to associate a sound clip and a photo, you would reference each multimedia file and indicate the format using the FORM tag subordinate to each file reference.
And that’s for references to multiple different media files.
For the multiple URLs, would you expect that to be for different files? Or would there also be the option of fallback URLs for the same digital data? (So it could be used to compensate for busy servers or linkrot.)
I never thought about using several FILE references using a URL. But you are right! It is a good idea. You can have a media object with several FILE URLs. They can link to different copies of the same image for example stored on different servers (maybe used for load balancing). Or they can link to different images, like two connected pages in a church book.
The GUI should prefer the first FILE URL if only one image can be shown. If the first FILE URL is not available the second one could be presented. If the GUI is able to show several FILE URLs (in a gallery) it should present them all.
