GEDCOM export
-
- Posts: 15
- Joined: Sat Nov 28, 2009 12:42 pm
- Location: BW, Germany
GEDCOM export
Hi Warwick,
I have a problem with the gedcom export of iFamily. The following tags are not compatible with the gedcom standard 5.5. or 5.5.1 (and I have problems with the import in other programs):
OCCU in iFamily:
1 OCCU
2 TYPE Vermesser
2 DATE 1991
2 PLAC Leipzig
2 NOTE @EN393@
correct should be:
1 OCCU Vermesser
2 DATE 1991
2 PLAC Leipzig
2 NOTE @EN393@
MAP with LATI/LONG in iFamily:
1 BIRT
2 DATE 14 SEP 1941
2 PLAC Annarode
3 _LATI N51.552422
3 _LONG E11.424580
3 _GMAP ...
2 SOUR @S64@
3 _TOPI Birth
correct should be (for GEDCOM 5.5.1):
1 BIRT
2 DATE 14 SEP 1941
2 PLAC Annarode
3 MAP
4 LATI N51.552422
4 LONG E11.424580
4 _GMAP ...
2 SOUR @S64@
3 _TOPI Birth
It is possible to solve this problem? To do this with a text editor is not so comfortable.
Other enhancement in the program would be a additional field and gedcom tag for the prefered name of a person. In Germany the prefered name could be on first or second (or third and so on) position of two (or more) given names. Now I'm looking for a possibility to mark the prefered name.
Thanks bauschaffender
I have a problem with the gedcom export of iFamily. The following tags are not compatible with the gedcom standard 5.5. or 5.5.1 (and I have problems with the import in other programs):
OCCU in iFamily:
1 OCCU
2 TYPE Vermesser
2 DATE 1991
2 PLAC Leipzig
2 NOTE @EN393@
correct should be:
1 OCCU Vermesser
2 DATE 1991
2 PLAC Leipzig
2 NOTE @EN393@
MAP with LATI/LONG in iFamily:
1 BIRT
2 DATE 14 SEP 1941
2 PLAC Annarode
3 _LATI N51.552422
3 _LONG E11.424580
3 _GMAP ...
2 SOUR @S64@
3 _TOPI Birth
correct should be (for GEDCOM 5.5.1):
1 BIRT
2 DATE 14 SEP 1941
2 PLAC Annarode
3 MAP
4 LATI N51.552422
4 LONG E11.424580
4 _GMAP ...
2 SOUR @S64@
3 _TOPI Birth
It is possible to solve this problem? To do this with a text editor is not so comfortable.
Other enhancement in the program would be a additional field and gedcom tag for the prefered name of a person. In Germany the prefered name could be on first or second (or third and so on) position of two (or more) given names. Now I'm looking for a possibility to mark the prefered name.
Thanks bauschaffender
-
- Posts: 330
- Joined: Sun Oct 19, 2008 7:12 pm
- Location: Cornwall, England
Hi bauschaffender,
As you say, the LAIT & LONG tags are from the 5.5.1 draft document - which is why they are not generated by iFamily which complies with the issued document.
If you need to change this, you could load the .ged file into Textedit and Find & Replace the _LONG and _LATI to LONG & LATI.
I am not 100% sure on the OCCU tag. I believe that it is valid to use the TYPE tag.
Which programs are you importing into as they should all handle the OCCU event but (agreed) not the _LATI which is a private tag?
Regards,
Nigel
As you say, the LAIT & LONG tags are from the 5.5.1 draft document - which is why they are not generated by iFamily which complies with the issued document.
If you need to change this, you could load the .ged file into Textedit and Find & Replace the _LONG and _LATI to LONG & LATI.
I am not 100% sure on the OCCU tag. I believe that it is valid to use the TYPE tag.
Which programs are you importing into as they should all handle the OCCU event but (agreed) not the _LATI which is a private tag?
Regards,
Nigel
-
- Posts: 330
- Joined: Sun Oct 19, 2008 7:12 pm
- Location: Cornwall, England
-
- Posts: 15
- Joined: Sat Nov 28, 2009 12:42 pm
- Location: BW, Germany
Thanks Nigel,
my way to iFamily was the change from MS to MacOS. Under MS I tried some genealogical programs and now with Parallels I still using some additional programs (Ages!, Stammbaumdrucker etc.) for creating charts and therefore I need a correct gedcom export.
An external text editor is like to use a crutch (my opinion). At the moment I do this with the _OCTI tag (change to OCCU). But for the correct form of MAP is this more complex ...
The gedcom standard is not up to date but had a little development in the last years (Gedcon 5.5.1 or 6). The MAP tag with LATI and LONG is very useful (f.i. for the visualization of the way of the family etc. with the gedcom2map tool) and I don't understand why iFamily is still using a custom tag for this today.
Regards
Martin (bauschaffender)
my way to iFamily was the change from MS to MacOS. Under MS I tried some genealogical programs and now with Parallels I still using some additional programs (Ages!, Stammbaumdrucker etc.) for creating charts and therefore I need a correct gedcom export.
An external text editor is like to use a crutch (my opinion). At the moment I do this with the _OCTI tag (change to OCCU). But for the correct form of MAP is this more complex ...
The gedcom standard is not up to date but had a little development in the last years (Gedcon 5.5.1 or 6). The MAP tag with LATI and LONG is very useful (f.i. for the visualization of the way of the family etc. with the gedcom2map tool) and I don't understand why iFamily is still using a custom tag for this today.
Regards
Martin (bauschaffender)
-
- Posts: 330
- Joined: Sun Oct 19, 2008 7:12 pm
- Location: Cornwall, England
Hi Martin,
The problem with GEDCOM is that 5.5 is the only published standard. All the later docs are draft.
Whilst there are some good additions to 5.5.1 it is difficult for a software developer to adopt it as there will possibly be errors or different interpretations giving rise to incompatible transfers - a bit like now really.
Unless Warwick wants to go down that route it will be version 5.5.
The bad news is, there is unlikely to be a new version of the document and I have seen nothing of the xml based version 6 for a long time.
As LATI and LONG seem to be fairly logical and not too far off the _LATI private tag it may be one Warwick would consider implementing.
Still not too sure about the OCCU - I will have another look at the drafts and see if I can make more sense of it.
Regards,
Nigel
The problem with GEDCOM is that 5.5 is the only published standard. All the later docs are draft.
Whilst there are some good additions to 5.5.1 it is difficult for a software developer to adopt it as there will possibly be errors or different interpretations giving rise to incompatible transfers - a bit like now really.
Unless Warwick wants to go down that route it will be version 5.5.
The bad news is, there is unlikely to be a new version of the document and I have seen nothing of the xml based version 6 for a long time.
As LATI and LONG seem to be fairly logical and not too far off the _LATI private tag it may be one Warwick would consider implementing.
Still not too sure about the OCCU - I will have another look at the drafts and see if I can make more sense of it.
Regards,
Nigel
-
- Posts: 15
- Joined: Sat Nov 28, 2009 12:42 pm
- Location: BW, Germany
Hi Nigel,
last time I compared a little bit my complete gedcom export of iFamily with the standard 5.5 (and draft 5.5.1) and I think an absolutely correct export would be a little bit work for Warwick.
I found any tags, they are not totally conform with 5.5. A test import to GEDitCOM (and this program really reads all lines of the gedcom file) doesn't import the type value correct. For all individual attributes I miss the description.
In accordance with the gedcom standard the correct form for all INDIVIDUAL_ATTRIBUTE_STRUCTURE should be (without the RESI tag):
n OCCU <OCCUPATION> {1:1}
+1 <<EVENT_DETAIL>> {0:1}
n RESI {1:1}
+1 <<EVENT_DETAIL>> {0:1}
<Single_angle bracket>
Indicates the name of the appropriate value for this GEDCOM line—<Primitive>. The specific definition of this value is found in alphabetical order in "Primitive Elements of the Lineage-Linked Form," beginning on page 37.
{braces}
Indicates the minimum to maximum occurrences allowed for this structure or line—{Minimum:Maximum}. Note that minimum and maximum occurrence limits are defined relative to the enclosing superior line. This means that a required line (minimum = 1) is not required if the optional enclosing superior line is not present. Similarly, a line occurring only once (maximum = 1) may occur multiple times as long as each occurs only once under its own multiple- occurring superior line.
and so on ... The problem for me is, what happens with my data in the future, when I have to or want to change the program? Just now I have some hundred of persons in my ifamily database. But the number is increasing.
Regards,
Martin
last time I compared a little bit my complete gedcom export of iFamily with the standard 5.5 (and draft 5.5.1) and I think an absolutely correct export would be a little bit work for Warwick.
I found any tags, they are not totally conform with 5.5. A test import to GEDitCOM (and this program really reads all lines of the gedcom file) doesn't import the type value correct. For all individual attributes I miss the description.
In accordance with the gedcom standard the correct form for all INDIVIDUAL_ATTRIBUTE_STRUCTURE should be (without the RESI tag):
n OCCU <OCCUPATION> {1:1}
+1 <<EVENT_DETAIL>> {0:1}
n RESI {1:1}
+1 <<EVENT_DETAIL>> {0:1}
<Single_angle bracket>
Indicates the name of the appropriate value for this GEDCOM line—<Primitive>. The specific definition of this value is found in alphabetical order in "Primitive Elements of the Lineage-Linked Form," beginning on page 37.
{braces}
Indicates the minimum to maximum occurrences allowed for this structure or line—{Minimum:Maximum}. Note that minimum and maximum occurrence limits are defined relative to the enclosing superior line. This means that a required line (minimum = 1) is not required if the optional enclosing superior line is not present. Similarly, a line occurring only once (maximum = 1) may occur multiple times as long as each occurs only once under its own multiple- occurring superior line.
and so on ... The problem for me is, what happens with my data in the future, when I have to or want to change the program? Just now I have some hundred of persons in my ifamily database. But the number is increasing.
Regards,
Martin
-
- Posts: 15
- Joined: Sat Nov 28, 2009 12:42 pm
- Location: BW, Germany
Additionally the following questions:
With iFamily it is possible to associate a person to another, but this associations wasn't exported to the gedcom file (tag ASSO):
ASSOCIATION_STRUCTURE:=
n ASSO @<XREF:INDI>@
+1 TYPE <RECORD_TYPE>
+1 RELA<RELATION_IS_DESCRIPTOR>
+1 <<NOTE_STRUCTURE>>
+1 <<SOURCE_CITATION>>
In the gedcom standard 5.5 it is possible to use approximate Dates, Date periods or Date ranges, but with ifamily only AFT, BEF and ABT. Why not the other possibilities? I read about the same question in other treads ...
DATE_APPROXIMATED like ABT, CAL and EST
Where:
ABT = About, meaning the date is not exact.
CAL = Calculated mathematically, for example, from an event date and age.
EST = Estimated based on an algorithm using some other event date.
DATE_PERIOD like FROM, TO or FROM <DATE> TO <DATE>
Where:
FROM = Indicates the beginning of a happening or state.
TO = Indicates the ending of a happening or state.
DATE_RANGE like BEF, AFT and BET <DATE> AND <DATE>
Where:
AFT = Event happened after the given date.
BEF = Event happened before the given date.
BET = Event happened some time between date 1 AND date 2. For example, bet 1904 and 1915
indicates that the event state (perhaps a single day) existed somewhere between 1904 and 1915 inclusive.
The date range differs from the date period in that the date range is an estimate that an event happened on a single date somewhere in the date range specified.
Regards,
Martin
With iFamily it is possible to associate a person to another, but this associations wasn't exported to the gedcom file (tag ASSO):
ASSOCIATION_STRUCTURE:=
n ASSO @<XREF:INDI>@
+1 TYPE <RECORD_TYPE>
+1 RELA<RELATION_IS_DESCRIPTOR>
+1 <<NOTE_STRUCTURE>>
+1 <<SOURCE_CITATION>>
In the gedcom standard 5.5 it is possible to use approximate Dates, Date periods or Date ranges, but with ifamily only AFT, BEF and ABT. Why not the other possibilities? I read about the same question in other treads ...
DATE_APPROXIMATED like ABT, CAL and EST
Where:
ABT = About, meaning the date is not exact.
CAL = Calculated mathematically, for example, from an event date and age.
EST = Estimated based on an algorithm using some other event date.
DATE_PERIOD like FROM, TO or FROM <DATE> TO <DATE>
Where:
FROM = Indicates the beginning of a happening or state.
TO = Indicates the ending of a happening or state.
DATE_RANGE like BEF, AFT and BET <DATE> AND <DATE>
Where:
AFT = Event happened after the given date.
BEF = Event happened before the given date.
BET = Event happened some time between date 1 AND date 2. For example, bet 1904 and 1915
indicates that the event state (perhaps a single day) existed somewhere between 1904 and 1915 inclusive.
The date range differs from the date period in that the date range is an estimate that an event happened on a single date somewhere in the date range specified.
Regards,
Martin
- Warwick Wilson
- Site Admin
- Posts: 495
- Joined: Sat Nov 15, 2008 12:36 am
- Contact:
Hi,
Thanks for your comments. Nice timing, the coding for adding the associated tags was completed last week and they work well. There is some extra capacity in the iFamily datamodel beyond the gedcom specification and I am still considering how to treat this.
With regards to the between dates, I know the previous developer was ardently against adding this functionality, and normailly he did things for good reasons. Similarly for the OCCU tag, I have checked the 5.5 specifications and there does seem to be a difference there, I am still assessing how/why it is like it is.
So in short, ASSO is already in the next release, but since we are racing against OXS10.8 Lion's release at the moment we cannot say that there will be time to add to our current development list. We will continue to fully consider any suggestions for future releases, please feel free to keep them coming.
Warwick.
Thanks for your comments. Nice timing, the coding for adding the associated tags was completed last week and they work well. There is some extra capacity in the iFamily datamodel beyond the gedcom specification and I am still considering how to treat this.
With regards to the between dates, I know the previous developer was ardently against adding this functionality, and normailly he did things for good reasons. Similarly for the OCCU tag, I have checked the 5.5 specifications and there does seem to be a difference there, I am still assessing how/why it is like it is.
So in short, ASSO is already in the next release, but since we are racing against OXS10.8 Lion's release at the moment we cannot say that there will be time to add to our current development list. We will continue to fully consider any suggestions for future releases, please feel free to keep them coming.
Warwick.
-
- Posts: 15
- Joined: Sat Nov 28, 2009 12:42 pm
- Location: BW, Germany