* Ancestry, FTM, FH and workflow

[tatewise]

So it sounds like you are almost sorted.

I will happily update the Export Gedcom File plugin to export FTM compatible Gedcom, plus BOTH full & part images as discussed, and any other simple adjustments that may be required, but stop short at this stage of taking the round-trip recycling of data any further.

What say you?

[Nick-V]

Well that's a generous commitment, Mike. One stage at a time...

I will keep the KB up to date with things I find...if you wish to add more provisos please do so. I hope I can treat it as a single record of what we CAN do today however unacceptably rough it may be to some people. Also to record our thoughts and status as we go.

When the transfer of data to FTM is sufficiently evolved I fully intend to step by step work it back to FH. After that the round trip issue can be investigated again.

Yes, lets keep the scope to getting as much FH data to FTM as we can and in a manner most likely to be reusable in FH albeit that further work will be required when/if we progress to this stage.

[Nick-V]

Mike...I mentioned it before but it may have got forgotten or lost in confusion...

1) Clearly we need all media to be records to facilitate the _PHOTO tag and also direct links from INDI event to source objects (citations) - BOTH currently treats full as records but part as under the INDI
2) There should be an option for full, part or both - BOTH currently doesn't do this but the other options do. I know I explained being able to see both part and full (as FH web allows) but this may also create too much clutter (double images for everything) depending on the cropping carried out and the software importing the results of the plugin.
3) They need to have full paths - BOTH does this

[Nick-V]

I've added to the KB a page on status.

The prototype now provides a basic log of tags to support this demand-lead development approach (something quick for the majority followed by additional functions driven by need). It categorises and reports all tags encountered like this:

• INDI tags: known and work fully
  0 INDI: 3600
  1 NAME: 3500
  1 SEX: 3400
  etc.
  INDI tags: known and work partially
  INDI tags: known and don't work yet
  INDI tags: known and won't work
  INDI tags: unknown but may work

Once enhanced, this approach should make it clear to uses what can and cannot be done. It should also assist development by prioritising and data-mapping step by step - with help from any FH users who wish to assist.

I can't seem to upload a simple text file to the KB as an example so would appreciate some assistance.

[tatewise]

By "upload a simple text file to KB" I guess you mean something like the

Code: Select all

[/b] BBCode tag.

Take a look at [kb]contributeyourknowledge:pageformattingsyntaxreference:extra#non-parsed_blocks|> Contribute Your Knowledge> Page Formatting ~ Extra Text Styles > Non-parsed Blocks[/kb].

[Nick-V]

Actually, I mean upload an attachment (log.txt) file for others (you perhaps) to download. It only appears to allow images (reports wrong file type or something).

[tatewise]

You should be able to use Media manager to upload a text or ged file, etc.
Media manager is the 5th icon from right in toolbar that looks like framed picture.

Then to make it downloadable you must use:
{{pushfile>:pathname|title}}
See the KB FH > Import from The Master Genealogist (TMG) > Quick Fix Plugins downloads.

[Nick-V]

Thanks but I tried that originally. Unfortunately the log.txt reports "Upload denied. This file extension is forbidden!" and the pushfile thing gave me a headache so I'll not bother.

[tatewise]

Try compressing the text file into zip file.

See the Page Formatting ~Links to Elsewhere > Download Links for pushfile shorthand.

[tatewise]

I have asked Jane to relax the file type restrictions on Media allowed in Knowledge Base (12451).

As a workaround I have added an Example Zip Pushfile to how_to:exchange_with_ftm:click_here_for_a_brief_summary_of_the_project_s_status|> A brief summary of project status, which when clicked, can be opened in Windows Explorer to unpack & display the contents, that can then be saved.

{{pushfile>:how_to:exchange_with_ftm:example.zip|Example Zip Pushfile}}

pushfile> is the shortcut to supply a download hyperlink.
:how_to:exchange_with_ftm:example.zip is the namespace and filename.
Example Zip Pushfile is the hyperlink download filename.
{{ | }} is the usual Media curly brackets container inserted by clicking the filename in the Media manager, and all you have to add is pushfile> and perhaps a download filename.

If the download filename is omitted, then the Media filename is used with certain defaults for replacing _ with space, etc.

[ EDIT:
Jane has added TXT and LOG file types. See Media allowed in Knowledge Base (12451).
So example.txt or example.log should work in place of example.zip above. ]

[Nick-V]

Many thanks Mike...that did it. This basic audit log might be useful to identify and record what works and what doesn't.

At present it is helping me to learn what an FH GEDCOM can contain. It is mainly intended to show users what any routine will/will not do and to be useful in the monitoring and prioritising of development.

Unfortunately, the more I look, the more I find...a long way to go for perfection but my own basic tree data goes thru perfectly now. For me it's soon time to turn to the trip back to FH to ascertain if the concept might work.

[tatewise]

That is indeed interesting, but I cannot reconcile the audit report against some other statements.
e.g.
=== INDI tags: known and work fully ===
2 NICK: 220
2 NPFX: 9
2 NSFX: 2
2 _USED: 2
1 SOUR: 11
But how_to:exchange_with_ftm:step_2_create_a_gedcom_using_the_fh_export_plugin|> Step 2 Create a GEDCOM using the FH Export Plugin says:
"FTM uses multiple 1 NAME tags with no children..." i.e. 2 NICK, 2 NPFX, etc, do NOT work.
"FTM citations can only appear at NAME (2 SOUR) level..." i.e. 1 SOUR does NOT work.

=== FAM tags: known and work fully ===
1 NOTE: 1
But how_to:exchange_with_ftm:step_2_create_a_gedcom_using_the_fh_export_plugin|> Step 2 Create a GEDCOM using the FH Export Plugin says:
"I cannot see record notes imported against FAM." i.e. 1 NOTE does NOT work.

Can you explain?

[Nick-V]

I'll try, it's a work in progress and hopefully my mistakes will lead to improvements! Also, my emphasis has shifted a little from documenting to doing, consequently the facts are improving but the explanations might not be.

As you've probably guessed, the report groups and orders tags according to my choice. Not in file order, etc.

It reports incoming tags and is attempting to provide an indication of the effectiveness of what happens next.

The KB explanation of what FTM can/not do is correct. The report of incoming tags is correct. Somewhere in the middle is processing to make things work. A lot in the case of the various name tags. I've attempted to explain my choices to deal with FTM's constraints in the KB but from memory for a example, 2 NICK and 2 NPFX have to become 1 ALIA and 1 TITL. 2 NSFX gets appended to NAME. 2 _USED becomes 1 ALIA. As foreign as it may sound, it MIGHT BE the best we can do for now and provides half a chance or reconstituting things...albeit with obvious constraints.

As per KB citations, 1 SOUR gets demoted to 2 SOUR under the first NAME...best we can do.

I can't remember the NOTE thing right now but it'll become clearer shortly...I am probably saying FTM will not handle 1 NOTE for FAMily records so I need to do something else (like 1 SOUR) or have already...

[tatewise]

So if I understand correctly
=== **** tags: known and work fully ===
means those FH tags migrate data into FTM, but only after applying certain translations to some of the tags.

What might be more useful is:
=== **** tags: known and work fully untranslated ===
and
=== **** tags: known and work after translation ===

[Nick-V]

1 NOTE do import to FTM under 0 FAM. I am uncertain what I noticed to write that comment but it was while considering _STAT and I've now edited it a bit. Indeed, I am probably changing my opinion on STAT. I said ignore it (good and pragmatic when you have no other choices) but in future we could use other FTM's FAM events and/or notes.

Thanks for keeping me on my toes.

[Nick-V]

Yes that audit category could be split into 2.

[tatewise]

That would certainly help confirm what the Export Gedcom File Plugin needs to translate.

On a small point of terminology. Please take care to use record and tag appropriately:

record means one of the 10 Gedcom Record types that match the 10 tabs in FH Records Window, and begin with the level 0 tags: 0 INDI, 0 FAM, 0 NOTE, 0 SOUR, 0 REPO, 0 SUBM, 0 SUBN, 0 OBJE, 0 _PLAC, and 0 HEAD.

tag means any subsidiary level Gedcom tag, and confusingly some have the same name as a level 0 tag: 1 NOTE, 2 NOTE, 1 SOUR, 2 SOUR, 2 OBJE, 2 _PLAC, etc.

Some level 1 tags are so important they are usually called facts (events & attributes): 1 BIRT, 1 CENS, 1 RESI, 1 OCCU, 1 MARR, 1 DEAT, etc.

[Nick-V]

Yes I acknowledge the confusion between normal versus Gedcom terminology. I can see how normal use of records, record types, data types, keys and use of a level character requires care when dealing with this particular file. I'll try to be clearer, just ask if there is anything that is not clear.

I think the "correct" terminology to use could be debated...by others.

EDIT
Simple non-technical folk like me think you read records...one read, one record. I now see the GEDCOM spec regards its data as multi-line records and this and other matters are explained quite well in the "Concepts" paragraphs at page 11 of fhugdownloads:contents:gedcom_standard_release_5.5|> GEDCOM Standard Release 5.5.

[Nick-V]

BTW Mike...

...to crop images, does the export use a routine inbuilt to FH or a widely available external routine or what? Clearly it doesn't use IrfanView via the command line like Jane's previous export.

[tatewise]

I am not aware of any IrfanView command line offering from Jane.
Her Convert File Links Plugin and my Plugin both use the plugins:getting_started#online_links|> Getting Started Writing Plugins > Online Links ~ IM - Digital Imaging Tool, which is an LUA library module.

[Nick-V]

FYI fhugdownloads:contents:rjt_family_historian_converter|> Family Historian Converter v1.3.0.0 by Jane TaubMan can be used to export FH to PHPGEDVIEW - crops images, etc.

You don't happen to know a VBA or command line cropping tool do you?

[tatewise]

Ah, I had forgotten about that FH Converter from Jane, because it has been superceded by her Plugin.
BTW: Both work for any destination, not just PHPGEDVIEW.

I suspect IrfanView supports command line cropping.

Is what you need a temporray workaround until the Export Gedcom File Plugin generates cropped BOTH images via Media Records?
If so, then I will focus on that enhancement first.
Have you any preference for how the Media Records should be Titled?
I was thinking of using the Full Frame Title plus the _AREA coordinates in order to survive the round-trip?

[davidm_uk]

From a previous thread (scroll down to post by Bonzo):

Captions for photos and images (12383)

Imagemagick supports command line cropping (and much more). I use it when exporting my family photos to a media player, and to produce thumbnails at the same time. It seems quite fast.

[Nick-V]

David...noted, many thanks I'll look at Imagemagick. I also know that Jane used IrfanView so a couple of options.

Mike...a workaround might be a good idea. No strong opinion on title yet so I would simply go with the title only. Other data may like coordinates will probably find themeselves in a note but we can sort all of the note/round trip principle out at one time, later.

Yes outputting all images as object records would be good. To include both full, part or both on an option. Of course with links for both full and part.

I'm not quite ready for the trip back quite yet...want to take the FH/FTM direction further than I personally need it so I can learn what is/not possible.

[tatewise]

I was asking about part image Titles, because if they simply inherit the full image Title, then there may be many Media Records all with the same Title, which could be confusing, and makes identifying the full image difficult.