Family Tree Manager errors in GEDCOM export

[Nigel Bufton]

I have a GEDCOM which contains:
1 OCCU Weaver
2 DATE 1846
I import the GEDCOM into FTM and then export if back to another GEDCOM. The
above is now:
1 OCCU
2 DATE 1846
2 PLAC Weaver
This is clearly plain wrong!

Another case: if the original data contains a real place, then the
corruption from FTM is:
Input GEDCOM:
1 OCCU Soldier
2 DATE 1807
2 PLAC Falmouth, Cornwall
Output GEDCOM:
1 OCCU
2 DATE 1807
2 PLAC Falmouth, Cornwall; Occupation: Soldier
This again contains the correct occupation data, but in the wrong tag!

In each of the above, the FTM output violates the documented GEDCOM 5.5
standard.

Has anyone else encountered this problem? Is there any way to get FTM to
correctly export data in GEDCOM 5.5 format, or is this just a serious bug in
FTM?

Nigel

[Charlie Hoffpauir]

On Mon, 9 Oct 2006 07:48:01 +0100, "Nigel Bufton" <[email protected]>
wrote:

I have a GEDCOM which contains:
1 OCCU Weaver
2 DATE 1846
I import the GEDCOM into FTM and then export if back to another GEDCOM. The
above is now:
1 OCCU
2 DATE 1846
2 PLAC Weaver
This is clearly plain wrong!

Another case: if the original data contains a real place, then the
corruption from FTM is:
Input GEDCOM:
1 OCCU Soldier
2 DATE 1807
2 PLAC Falmouth, Cornwall
Output GEDCOM:
1 OCCU
2 DATE 1807
2 PLAC Falmouth, Cornwall; Occupation: Soldier
This again contains the correct occupation data, but in the wrong tag!

In each of the above, the FTM output violates the documented GEDCOM 5.5
standard.

Has anyone else encountered this problem? Is there any way to get FTM to
correctly export data in GEDCOM 5.5 format, or is this just a serious bug in
FTM?

Nigel

Nigel,

The problem is in FTM's internal data structure. There is no way (in
FTM versions up to no. 8, (I don't have any later versions), to make a
distinction between a location (place) and a comment. This and many
other internal data structure "abnormalities" force FTM to a
non-standard GEDCOM as well. (But then, many genealogy programs
produce "non-standard" GEDCOMs... that's why Gary Bonham wrote Gedcom
Explorer many years ago.) Programs that do a good job on converting
FTM native files to "their" native files, like TMG Genbridge and
RootsMagic, have a provision for allowing the user to indicate during
the conversion process whether a tag is for a comment or a location
(globally). But this is only really useful if the FTM user has been
consistant. The real problem with FTM (my opinion only) is that it
allows the user to be very sloppy with data input. Sloppy data input
results in sloppy genealoglies.

OTOH, the strength of FTM is that it does a very good job of producing
charts and reports. A really diligent user can overcome the
limitations, but it's easy for a novice to really mess things up,
without ever realizing it. (Been there, done that.)

Charlie Hoffpauir
http://freepages.genealogy.rootsweb.com/~charlieh/

[singhals]

Charlie Hoffpauir wrote:

On Mon, 9 Oct 2006 07:48:01 +0100, "Nigel Bufton" <[email protected]
wrote:


I have a GEDCOM which contains:
1 OCCU Weaver
2 DATE 1846
I import the GEDCOM into FTM and then export if back to another GEDCOM. The
above is now:
1 OCCU
2 DATE 1846
2 PLAC Weaver
This is clearly plain wrong!

Another case: if the original data contains a real place, then the
corruption from FTM is:
Input GEDCOM:
1 OCCU Soldier
2 DATE 1807
2 PLAC Falmouth, Cornwall
Output GEDCOM:
1 OCCU
2 DATE 1807
2 PLAC Falmouth, Cornwall; Occupation: Soldier
This again contains the correct occupation data, but in the wrong tag!

In each of the above, the FTM output violates the documented GEDCOM 5.5
standard.

Has anyone else encountered this problem? Is there any way to get FTM to
correctly export data in GEDCOM 5.5 format, or is this just a serious bug in
FTM?

Nigel




Nigel,

The problem is in FTM's internal data structure. There is no way (in
FTM versions up to no. 8, (I don't have any later versions), to make a
distinction between a location (place) and a comment. This and many
other internal data structure "abnormalities" force FTM to a
non-standard GEDCOM as well. (But then, many genealogy programs
produce "non-standard" GEDCOMs... that's why Gary Bonham wrote Gedcom
Explorer many years ago.) Programs that do a good job on converting
FTM native files to "their" native files, like TMG Genbridge and
RootsMagic, have a provision for allowing the user to indicate during
the conversion process whether a tag is for a comment or a location
(globally). But this is only really useful if the FTM user has been
consistant. The real problem with FTM (my opinion only) is that it
allows the user to be very sloppy with data input. Sloppy data input
results in sloppy genealoglies.

Now, now, Charlie! That's not "sloppy", it's "highly customizable."

It is considered a feature of great value.

Cheryl

[Nigel Bufton]

"singhals" <[email protected]> wrote in message
news:[email protected]...

Charlie Hoffpauir wrote:

On Mon, 9 Oct 2006 07:48:01 +0100, "Nigel Bufton" <[email protected]
wrote:

I have a GEDCOM which contains:
1 OCCU Weaver
2 DATE 1846
I import the GEDCOM into FTM and then export if back to another GEDCOM.
The
above is now:
1 OCCU
2 DATE 1846
2 PLAC Weaver
This is clearly plain wrong!
snipped
Nigel,

The problem is in FTM's internal data structure. There is no way (in
FTM versions up to no. 8, (I don't have any later versions), to make a
distinction between a location (place) and a comment. This and many
other internal data structure "abnormalities" force FTM to a
non-standard GEDCOM as well. (But then, many genealogy programs
produce "non-standard" GEDCOMs... that's why Gary Bonham wrote Gedcom
Explorer many years ago.) Programs that do a good job on converting
FTM native files to "their" native files, like TMG Genbridge and
RootsMagic, have a provision for allowing the user to indicate during
the conversion process whether a tag is for a comment or a location
(globally). But this is only really useful if the FTM user has been
consistant. The real problem with FTM (my opinion only) is that it
allows the user to be very sloppy with data input. Sloppy data input
results in sloppy genealoglies.

Now, now, Charlie! That's not "sloppy", it's "highly customizable."

It is considered a feature of great value.

Cheryl

The same is true of the current version (16) so the deficiency has
perpetuated for years.

Most of the leading programs have separate date and description fields for
event data entry; FTM is somewhat unusual in its approach. Nevertheless, as
FTM seems to encourage ambiguous input for its "place or description" field,
the GEDCOM export should put it in a TEXT tag, not a PLAC tag.

FTM does import GEDCOMs interestingly, though. If it finds both place and
description, it constructs a compound "place or description" field as, for
example: "London; occupation: Tailor". (Of course, it exports this compound
description as the PLAC.)
Perhaps FTM should be called SINO software: Standard In, Non-standard Out.

Charlie's right, using the PLAC tag is "sloppy". The TEXT/DESC/NOTE tags
provide "highly customizable".

Nigel

[T.M. Sommers]

Nigel Bufton wrote:

"singhals" <[email protected]> wrote in message
news:[email protected]...
Charlie Hoffpauir wrote:
On Mon, 9 Oct 2006 07:48:01 +0100, "Nigel Bufton" <[email protected]
wrote:

I have a GEDCOM which contains:
1 OCCU Weaver
2 DATE 1846
I import the GEDCOM into FTM and then export if back to another GEDCOM.
The
above is now:
1 OCCU
2 DATE 1846
2 PLAC Weaver
This is clearly plain wrong!
snipped

The same is true of the current version (16) so the deficiency has
perpetuated for years.

Most of the leading programs have separate date and description fields for
event data entry; FTM is somewhat unusual in its approach. Nevertheless, as
FTM seems to encourage ambiguous input for its "place or description" field,
the GEDCOM export should put it in a TEXT tag, not a PLAC tag.

That would be non-standard, too. OCCU tags are instances of
INDIVIDUAL_ATTRIBUTE_STRUCTUREs:

n OCCU <OCCUPATION>
+1 <<EVENT_DETAIL>>

TEXT tags are not part of EVENT_DETAILs.

FTM does import GEDCOMs interestingly, though. If it finds both place and
description, it constructs a compound "place or description" field as, for
example: "London; occupation: Tailor". (Of course, it exports this compound
description as the PLAC.)
Perhaps FTM should be called SINO software: Standard In, Non-standard Out.

Charlie's right, using the PLAC tag is "sloppy". The TEXT/DESC/NOTE tags
provide "highly customizable".

DESC is part of the SUBMISSION_RECORD, and is for the number of
generations of descendants in the file; DSCR is for physical
descriptions of people. A NOTE would work, but the proper way to
indicate an occupation is the way you have it above, with the
description of the occupation on the same line as the OCCU tag.
Any program that thinks that anything on the same line as an OCCU
tag (or any number of other tags that work the same way) is a
place is just plain broken.

--
Thomas M. Sommers -- [email protected] -- AB2SB

[Hugh Watkins]

Nigel Bufton wrote:

I have a GEDCOM which contains:
1 OCCU Weaver
2 DATE 1846
I import the GEDCOM into FTM and then export if back to another GEDCOM. The
above is now:
1 OCCU
2 DATE 1846
2 PLAC Weaver
This is clearly plain wrong!

Another case: if the original data contains a real place, then the
corruption from FTM is:
Input GEDCOM:
1 OCCU Soldier
2 DATE 1807
2 PLAC Falmouth, Cornwall
Output GEDCOM:
1 OCCU
2 DATE 1807
2 PLAC Falmouth, Cornwall; Occupation: Soldier
This again contains the correct occupation data, but in the wrong tag!

In each of the above, the FTM output violates the documented GEDCOM 5.5
standard.

Has anyone else encountered this problem? Is there any way to get FTM to
correctly export data in GEDCOM 5.5 format, or is this just a serious bug in
FTM?

which version?

I use FTM 16
free on lin update from 2006

Hugh W


--

new phone = new daily blog
http://upsrev622.blogspot.com/

family history
http://hughw36.blogspot.com

[Nigel Bufton]

"Hugh Watkins" <[email protected]> wrote in message
news:[email protected]...

Nigel Bufton wrote:

I have a GEDCOM which contains:
1 OCCU Weaver
2 DATE 1846
I import the GEDCOM into FTM and then export if back to another GEDCOM.
The
above is now:
1 OCCU
2 DATE 1846
2 PLAC Weaver
This is clearly plain wrong!

(snip)

Has anyone else encountered this problem? Is there any way to get FTM to
correctly export data in GEDCOM 5.5 format, or is this just a serious bug
in
FTM?

which version?

I use FTM 16
free on lin update from 2006

Hugh W

All versions including 16.

The issue is that FTM doesn't have separate fields for description and place
of events (a shortcoming compared with other leading products). Therefore,
if you put "Weaver" in the field for an occupation and export the GEDCOM,
FTM will export it as PLAC. This will confuse most programs that you might
be transferring the GEDCOM to. (They will generally import it as
occupation=blank, place="Weaver")

The other major deficiency with FTM is that it doesn't export OBJE tags for
media (images). Again, fine if you are OK with being locked in, but not
useful for GEDCOM transfers.

All in all, FTM's capability with exporting GEDCOM files is far inferior to
some of the other leading products.

Nigel