* Export Gedcom ASID tag Errors in LFT

[ronk]

When I use the Export Gedcom to LFT plugin, I get what LFT indicates as errors, but seem to be superfluous, since the import to LFT works fine for the object (media) with which they are associated.

Example Gedcom:
0 @F12@ FAM
1 MARR
2 DATE 28 OCT 1913
2 PLAC Holy Trinity Catholic, New Ulm, MN
2 NOTE MR confirmed, Roseann and Caroluius F. Wiltscheck, witnesses, Otto Wiltscheck and Bertha Hillesheim.
1 HUSB @I65@
1 WIFE @I2203@
1 CHIL @I6@
1 CHIL @I17@
1 CHIL @I59@
1 CHIL @I69@
1 CHIL @I70@
1 CHIL @I71@
1 CHIL @I72@
1 OBJE @O2735@
1 OBJE @O2736@
2 _ASID 1
1 OBJE @O2737@
1 OBJE @O2738@
1 OBJE @O2739@
2 _ASID 1
1 OBJE @O2740@
2 _ASID 1

IMPORT ERRORS
----------------------------------------
Main Record: 0 @F12@ FAM
* Unrecog. Line for a Family Record: 2 _ASID 1
----------------------------------------
Main Record: 0 @F12@ FAM
* Unrecog. Line for a Family Record: 2 _ASID 1
----------------------------------------
Main Record: 0 @F12@ FAM
* Unrecog. Line for a Family Record: 2 _ASID 1

IN fact the 6 OBJE's are photos, all together in the Family Media section.
Why are there 3 ASID tags output? I have over 600 of these errors which I choose to ignore at this point. Hope that's OK.
Here's a snapshot of the family in FH:

FH family.jpg (190.53 KiB) Viewed 10218 times

[tatewise]

It all hinges on which Multimedia conversion option you have chosen.

I suspect you have chosen (FILE~ABS) Multimedia via Absolute Link Records.
That mode and (FILE~REL) retain all the FH Media record tags, including all the custom tags described in glossary:gedcom_extension_list|> GEDCOM Extension List, and that includes _ASID among others.
Those modes are intended for special cases such as exporting to FH V5 and to GedSite that understand those custom tags.
The Help & Advice says "FILE~REL retains the original Media format with each local Media Object, distinct Media Record, and relative or absolute file path unchanged. FILE~ABS is the same as FILE~REL but with relative paths converted to absolute paths."

Legacy is correctly reporting _ASID as unrecognised, because they are unique to FH.
I am surprised it is not also reporting _AREA, _NOTE, _DATE, _KEYS, _EXCL & _CAPT as unrecognised too.
But perhaps you are not using Link to Face/Detail, or Media record Note, Date, Keywords, etc.

These are all some of the novelties of the different GEDCOM dialects, especially the handling of Media.

Maybe the Help & Advice could go into more details about which Media options work best with with which target products, and explain the consequences of using other options.

[ronk]

Mike, You helped me in an unexpected way. You see I use LFT for viewing only, and is sharing the FH Media folder/files. I was using FIL~REL, and doing an Text Edit to make them absolute, not realizing that setting FIL~ABS would do that for me! So now there are no interim steps before import to LFT.

Thanks also for the clarification of the unrecognized Gedcom tags. And, yes I am removing Keywords, and moving a number of things to local notes in the Export to Gedcom LFT settting. I was bit curious, though, why FH put out 3 ASID rather than 1 for the 6 family photo OBJE.

Ron

[ronk]

Mike,
Spoke too soon. The ABS paths to LFT work OK, but I had mentioned I lost Export Gedcom plugin settings some time ago. I found that only a few of the media are importing to Legacy (the first ones for an individual or family, and many of the notes are missing, even though they are in the Gedcom. I determined that this may have been happening ever since I updated to V3.2 from v3.0. I did this about the same time I lost the settings. I didn't notice until now because I don't often use Legacy (for viewing).

So, I downgraded to V3.0, all imported to LFT properly, except the option for FIL~ABS is missing in V3.0. (UPDATE:However, see following post)To run V3.0 I used the Export Gedcom File.dat and .fh_lua. from Backup settings. I compared the LFT Extra Options, and all are identical, except for the 1 added option of 'Tidying the Address' field. Other Options settings are identical. On the Basic option, only the added 'private text' option which is left default.

Also with Export Gedcom v3.0 I don't get the unrecognized ASID errors either. I verified that there are no ASID tags in the v3.0 Gedcom. Any idea on what happened from V3.0 to V3.2? I will stay with V3.0, but I like the added the FIL~ABS option in V3.2.

Attached are option as set in v3.2 and v3.0, as well as parts of the Gedcom respectively. LFT may be ignoring OBJE's following the newly added ASID tags. There are ~3700 ASID lines in v3.2 Gedcom, and that is the difference in total lines as well between the files.

v3.2................
0 @I65@ INDI
1 NAME Charles Frank /Wiltscheck/
2 GIVN Charles Frank
2 SURN Wiltscheck
1 SEX M
1 BIRT
2 DATE 16 OCT 1887
2 PLAC Sigel Twp, Brown Co, MN
1 OCCU Farmer
2 DATE (c1920,30)
2 PLAC Home
1 DEAT
2 DATE 12 MAR 1943
2 PLAC Sleepy Eye, Brown Co, MN
1 FAMC @F24@
1 FAMS @F12@
1 OBJE @O260@
1 OBJE @O261@
1 OBJE @O262@
1 OBJE @O263@
1 OBJE @O264@
1 OBJE @O265@
2 _ASID 1
1 OBJE @O232@
2 _ASID 6
1 OBJE @O266@
1 OBJE @O267@
1 OBJE @O268@
1 OBJE @O269@
1 OBJE @O270@
2 _ASID 1
1 OBJE @O271@
1 NOTE (Research):mrec,ww1reg,c1920,30,40,hstone
1 NOTE 1900 census: birth is oct , 1887 vs. 1888 from other source
2 CONT
2 CONT Family moved to Sleepy Eye on May 1st, 1943, shortly after Charles' death.

v3.0.................................
0 @I65@ INDI
1 NAME Charles Frank /Wiltscheck/
2 GIVN Charles Frank
2 SURN Wiltscheck
1 SEX M
1 BIRT
2 DATE 16 OCT 1887
2 PLAC Sigel Twp, Brown Co, MN
1 OCCU Farmer
2 DATE (c1920,30)
2 PLAC Home
1 DEAT
2 DATE 12 MAR 1943
2 PLAC Sleepy Eye, Brown Co, MN
1 FAMC @F24@
1 FAMS @F12@
1 OBJE @O260@
1 OBJE @O261@
1 OBJE @O262@
1 OBJE @O263@
1 OBJE @O264@
1 OBJE @O265@
1 OBJE @O232@
1 OBJE @O266@
1 OBJE @O267@
1 OBJE @O268@
1 OBJE @O269@
1 OBJE @O270@
1 OBJE @O271@
1 NOTE (Research):mrec,ww1reg,c1920,30,40,hstone
1 NOTE 1900 census: birth is oct , 1887 vs. 1888 from other source
2 CONT
2 CONT Family moved to Sleepy Eye on May 1st, 1943, shortly after Charles' death.

[ronk]

Hope you can help Mike. Not sure what has happened, duplicated caption notes, even with v3.0 and 2.6 Export Gedcom plugin, both for LFT and TNG options, getting duplicated caption note output as such (1 for every time the media linked in FH).


0 @O131@ OBJE
1 TITL Peter Hengel & Katherine Fehlen Family (Peter's Funeral)
1 FILE Media\photos\P19030921 Hengel(Fehlen),anna funeral-peter family9.jpg
2 FORM jpg
1 NOTE Caption Note: Katherine (Fehlen) Hengel and 8 living children (4 deceased) in 1903 the day of Peter Hengel's funeral.
2 CONT Caption Note: Katherine (Fehlen) Hengel and 8 living children (4 deceased) in 1903 the day of Peter Hengel's funeral.
2 CONT Caption Note: Katherine (Fehlen) Hengel and 8 living children (4 deceased) in 1903 the day of Peter Hengel's funeral.
2 CONT Caption Note: Katherine (Fehlen) Hengel and 8 living children (4 deceased) in 1903 the day of Peter Hengel's funeral.
2 CONT Caption Note: Katherine (Fehlen) Hengel and 8 living children (4 deceased) in 1903 the day of Peter Hengel's funeral.
2 CONT Caption Note: Katherine (Fehlen) Hengel and 8 living children (4 deceased) in 1903 the day of Peter Hengel's funeral.
2 CONT Caption Note: Katherine (Fehlen) Hengel and 8 living children (4 deceased) in 1903 the day of Peter Hengel's funeral.
2 CONT Caption Note: Katherine (Fehlen) Hengel and 8 living children (4 deceased) in 1903 the day of Peter Hengel's funeral.

Within FH, there is no duplication, but the photo is appropriately linked 8 times. Is there a setting I'm overlooking?

Actually, v3.2 works OK for TNG, since it appears to ignore the ASID records, and doesn't duplicate the caption notes either. It's LFT and the ASID's that are giving me fits and the reason for these initial post. However, didn't think I'd have an LFT issue with 3.2 as well as 3.0 and 2.6. I wasn't using 3.0 very long, but v2.6 was in use for some time, I think.

I find that if I delete the ASID tags in the LFT Gedcom, it imports fine, so I'm looking at having an editor do that.

[ronk]

OK, I used a simple Text Edit macro on the Gedcom from Export Gedcom v3.2 (LFT), to find and remove all lines with ASID. The import to Legacy looks very good, no captions, no duplication, and all media and notes appear to be present, and the FIL~ABS works well.

So now I can use Export Gedcom v3.2 plugin, and dismiss the older versions, not understanding though, what happened there.

[tatewise]

I am not sure why those differences arise between V3.0 and V3.2 because I don't believe any Media export changes were made.

See plugins:help:export_gedcom_file:output_media_style|> Export Gedcom File ~ Output Media Style for details about how the Media options affect output.

[ronk]

Looked over your referenced explanation, but do believe the caption notes were not put out for every media link before as I saw with v3.0. What purpose does the ASID have in the 3.2 LFT export? It was not there before when using FIL~REL, and the FIL~ABS option was a recent addition to the plugin, was it not? Focusing on v3.2, I shall have to continue with a macro after export to cleanse the ASID records which were not present in earlier versions (at least before 3.0).

[tatewise]

I will investigate those issues when I get a moment.

[tatewise]

I found that moment and found the explanation, but not sure about the best solution.

Up until V3.0 only exports to (FH5 ) Family Historian 5 would retain the custom tags such as _ASID & _KEYS.

V3.1 introduced (FILE~ABS) as well as (FILE~REL) and for those modes retains all custom tags such as _ASID & _KEYS unless explicit rules remove them. That was done because those modes were intended for (FH5 ) Family Historian 5 and (GST) GedSite that require them to be retained. Perhaps in hindsight that was a mistake, without adding rules to allow _ASID and _AREA to be removed entirely.

I suspect a similar explanation applies to the Caption Link/Notes.

Let me think about it.

[ronk]

Take your time Mike. Using Export Gedcom v3.2, I have the simple workaround aforementioned. ASID tags are easily removed with an editor macro and the caption statements are not duplicated in v3.2, neither in TNG or LFT.

One comment. You indicated that now with FIL~REL the ASID are retained with v3.2. But FIL~REL. which I was using, has been there with 2.6, and there were no ASID tags output then, so you must have had a 'rule' excluding them before for LFT.

TNG apparently handled the v3.2 ASID tags fine,..merely ignoring them, without bypassing any following valid Gedcom lines like LFT did.

Just glad you found a reason for the changes and that I not losing my sanity..

[ronk]

Mike, could I ask a question re: Export Gedcom Plugin settings? Where (and other plugins' settings) are they saved? I thought it was the .dat file, but apparently not. There's only a couple lines in it. I looked briefly at the .lua file, but the code is beyond my current skills to decipher.

The reason I ask is that in recent testing of the older Export Gedcom versions, I copied from the FH settings backup folder, the older .lua and .dat files from past backups. Not a full restore, just the 2 like named .dat and .lua files. Or does miss the associated custom settings at the time the backup was done?

[tatewise]

The .fh_lua files in the Plugins folder are the Plugin Lua script files that can alos be viewed/edited via Tools > Plugins > More>> > Edit.

The .dat files in the Plugin Data folder alongside, do hold Plugin settings, but only a few global settings that apply to that Plugin for all PC accounts and all Projects.

Plugins can potentially save settings anywhere, but there are three conventional locations.

1. The ProgramData sub-folder path above applies globally.
2. The user's AppData\Calico Pie\Family Historian\Plugin Data folder can hold settings for all Projects of that user.
3. Most commonly the Project's own Plugin Data folder, alongside the Media folder, holds the settings per Project, and that is where all the Export Gedcom File dialogue tabs save the settings. So you would have to retrieve them from a Project backup.

[ronk]

Thanks Mike. That might explain some of my strange results when trying the older versions of Export Gedcom v2.6 and v3.0. I might have been trying to use mismatched settings (v3.2) with them, since I didn't copy/restore the associated project plugin dat file, only the global one. I was afraid to use the Backup & Restore for fear of overwriting later Gedcom data.

[tatewise]

Switching back & forth to various Plugin versions usually works OK, at least for mine. I do it quite often to check that Plugin settings migrate satisfactorily.

Using Restore of a Project full Backup will never compromise your Gedcom, because a whole new Project will always be created rather than overwrite an existing one. I suggest you try it to familiarise yourself with the process and check your Backups actually work, just in case you ever need to use them.

[ronk]

OK, will do some reading/testing. BTW...neglected to mention, as to earlier mismatched plugin settings...in order to switch back and forth, I had actually renamed plugins, putting in the version numbers in the lua filename, thinking I would have to avoid duplicate entries, and therein the associated plugin data settings perhaps was mixed up, since I forgot about the project plugin data folder files alongside the media folder.

[tatewise]

My Plugins are designed to use the same .dat filename regardless of what suffix is added to Plugin name. So Export Gedcom File will use same settings .dat file as Export Gedcom File V2, etc. Essentially they use the Title as shown in the Details Provide by Plugin pane of Tools > Plugins, and that Title must be the leading text of the Plugin name, otherwise it complains.

It is all designed to ensure consistent naming, and yet allow differently suffixed versions to use the same settings, which helps with my development testing.

[ronk]

OK, which I assume means any new options you add to your plugins will accommodate the users settings in the older versions, and vice versa. I was fearful, not knowing what's going on 'under the covers' , that switching to older version, that the new options in the settings might cause a 'crash' or mixed results.

Also, the issue I had was trying to retrieve my settings after they were reset to default after the 'hidden window' glitch I mentioned earlier on, while maintaining separation of what I thought were separate associated settings. I hope that makes sense.

It appears my worries were unfounded. Thanks for the clarification.

[tatewise]

You were wise to be wary.
I cannot vouch for Plugins by other Authors, and sometimes I don't cater for all the possibilities when there are just too many to test exhaustively. Alternatively, sometimes the changes are so great I am forced to make the Plugin reset some settings to defaults. However, most Plugins with 'sticky' settings use labelled meta-values and just recognise the labels that apply to the current version and discard the rest, which means those discarded values will assume default values when a later version is run.