Problems importing from GRAMPS
Brought to you by:
canajun2eh,
yalnifj
Menu
▾
▴
#1512 Problems importing from GRAMPS
I've run into a problem importing a GEDCOM from GRAMPS. GRAMPS exports email addresses and URLs like this:
1 OBJE
2 FORM URL
2 FILE username@comcast.net
1 OBJE
2 FORM URL
2 FILE www.domain.com
PhpGedView assumes those are media files, and treats them as it would a missing media file, and describes them as "Format: net" and "Format: com". As a result, anyone with an email address or URL gets a default media icon displayed in various places, linked to a missing file page.
Would it be possible to recognize FORM URL as an email address or link, instead of treating it like an unknown file type?
Thanks.
Logged In: YES
user_id=1254634
Originator: NO
I wouldn't want to get into an argument here, but I do think it is GRAMPS that should be changing for this, not PGV.
1 - The GEDCOM spec defines OBJE as:
"Pertaining to a grouping of attributes used in describing something. Usually referring to the data
required to represent a multimedia object, such an audio recording, a photograph of a person, or an
image of a document."
2 - an emal address is not, technically (I think) a URL
3 - Again, from the GEDCOM spec (5.5.1) the correct tags are: WWW and EMAIL. These are what PGV correctly uses.
Logged In: YES
user_id=33094
Originator: YES
Well, that's a pretty convincing argument. I'll take it up over there.
However, in the best case, that will still only change files created in the future. On the assumption that PhpGedView already makes allowances for non-standard input files to allow for the quirks of various programs, I'd still suggest considering handling "FORM URL" as a recognized non-standard variation.
Logged In: YES
user_id=1061833
Originator: NO
Dave
Why not use a good text editor and a grep search and replace and change these GEDCOM facts to the WWW or EMAIL tags?
-stephen
Logged In: YES
user_id=634811
Originator: NO
If you posted the question at a gramps forum, please post the link here.
Logged In: YES
user_id=33094
Originator: YES
Having learned from nigelo that PGV using GEDCOM 5.5.1, I filed a feature request for (at least partial) 5.5.1 export support in GRAMPS.
http://bugs.gramps-project.org/view.php?id=1145
This is odd...
I've hacked GRAMPS to output EMAIL tags (to the best of my ability, not knowing Python).
The resulting GEDCOM contains this line:
1 EMAIL me@domain.com
After upload and import to PGV, that line has been changed to:
1 EMAI me@domain.com
When I view my record, it says:
Unrecognized GEDCOM Code: EMAI
What's up with that?
okbigkid:
Yup, I can do that or hack GRAMPS (if I can resolve the error above). But that workaround doesn't change that PGV would benefit from greater interoperability. It's great that PGV supports 5.5.1. But does it make sense to require strict 5.5.1 on import? The best thing for users is for PGV to import the widest range of GEDCOMs with the least amount of trouble. While it need not be top priority, it makes sense to recognize and handle various non-standard GEDCOM tweaks during import.
Logged In: YES
user_id=1254634
Originator: NO
Digger
On the 'EMAI' issue - that is caused by a recent error in PGV. I saw a mention of it a couple of days ago. It's just been fixed. Get svn 1393, or the patch for 4.1 stable in Patches section here and re-import; or change all 'EMAI' to 'EMAIL'.
On "While it need not be top priority, it makes sense to recognize and handle various non-standard GEDCOM tweaks during import" - I do agree - but where do you draw the line. In fact PGV does already handle a huge number of these very succesfully. Perhaps these GRAMPS ones could be added, but can anyone give the pgv development team a list of all the ones they should consider, from all the software around? To be fair, even PGV isn't spotless when it comes to adhering to the GEDCOM standard.
Logged In: YES
user_id=1061833
Originator: NO
Dave
Ditto to Nigel's reply on my behalf. Personally, I think PGV already does too much "patching" or unique handling of programs that, for proprietary reasons only, don't output files according to the GEDCOM standard. There are actually only a few progs are strict to the code, PGV and GEDEDITCOM, being among them, and even PGV still allows use of deprecated coding, like CEME.
Stephen
Logged In: YES
user_id=33094
Originator: YES
nigelo:
Cool, thanks. That fixed EMAIL import.
"where do you draw the line"
Very good point. I doubt such a list exists. Which basically reduces it to a case-by-case decision based on things like the popularity of the software, how unambiguous the detection of the non-standard tag is, and whether the tag represents data or a feature that exists in PGV. In my opinion, the GRAMPS "FORM URL" passes that test.
okbigkid:
I certainly agree that export should be as strict as possible, if only to encourage others to do the same. However, I believe that import needs to be much more flexible because, as you say, "There are actually only a few progs are strict to the code." Which I think means we come to opposite conclusions based on the same input. :)
Anyway, this is just a suggestion/request for consideration of (IMHO) an improvement. (I'd have submitted a patch along with it, but I don't yet understand functions_import.php, which seems to be where the magic happens.) If it's not judged to fit the goals of the project, so be it. I'm certainly not here to make demands. There are more important things in life than 'FORM URL'...
Logged In: YES
user_id=634811
Originator: NO
does this affect 4.1?
Logged In: YES
user_id=634811
Originator: NO
Any idea if this is an issue with 4.1?
Logged In: YES
user_id=1466942
Originator: NO
<<I think PGV already does too much "patching" or unique handling of programs that, for propretary reasons only, don't output files according to the GEDCOM standard.>>
Part of PGV's success is that it *does* cope with the non-standard output of a wide range of third-party applications.
Also, don't forget that the "import" functions are also called after a manual gedcom edit, so if a user typed the above directly, PGV would still have to address the issues.
It can't be that hard to add in a "if ($FORM != 'URL')" somewhere along the line....
Logged In: YES
user_id=1061833
Originator: NO
Greg
<<Also, don't forget that the "import" functions are also called after a
manual gedcom edit, so if a user typed the above directly, PGV would still
have to address the issues.>>
YES, and it's this very action, recently modified, that has brought about BUG:
http://sourceforge.net/tracker/index.php?func=detail&aid=1768907&group_id=55456&atid=634867
"For every action, there is an equal, and opposite reaction." My comment on PGV was that the programmers have spent a LOT of time accommodating some pre-existing errant programs that output data with simply no other way to term it, BAD formatting. Eventually, because of the quoted action mentioned above, we end up with a very complicated edit/approval routine that craps out the system, even with 140mb of RAM devoted to it. If the import routines and data management happened ONLY at initial import, then fine - they should be inclusive rather than exclusive or proprietary - but it is the second factor, their use upon manual edit and subsequent approval, that can be the fly in the ointment.
JOHO, Stephen