* Emigration Fact - Copying and Using Both Copies

[Chrisv]

The Emigration Fact and the Immigration Fact both appear to be different than other Fact types in that they have an additional "To" box that can be filled in to show where/to the individual was going. I have instances of Emigration and also instance of Departure from Municipality. They each use very different registers, which is why I want to differentiate the two Fact types.
I made a copy of the Emigration Fact and renamed it, but from what I have read in the help files, one will eclipse the other, making one fact disabled. I would solve this by simply making a New Fact, but I can't figure out what adds the additional "To" box.

On a different question, but similar - Is it possible to make an Event Fact with the additional Information box that Attribute Facts all seem to have at the beginning, but Event Facts do not have? See below for examples:

Attribute Information Box

Attribure Informational Box.PNG (95.77 KiB) Viewed 1386 times

Emigration "To" Box

Emigration (To) Box.PNG (72.76 KiB) Viewed 1386 times

[ColeValleyGirl]

You can't create a Custom Fact with both From and To boxes, unfortunately. Nor can an Event have a Value -- only Attributes can have Values.

Do you use both the Immigration and the Emigration fact? One possibility would be to edit the Emigration fact to be a Departed from Municipality fact. However, if you needed yet a third type, you would be out of luck.

[Gowermick]

One does wonder why you want an Immigration AND an emigration fact. Surely an emigration from one place means an immigration to another.
So an Emigration fact, which contains both From and To places, covers both events.
My great uncle emigrated from London to NZ, which naturally meant he immigrated to NZ from London at the same time. I have one fact to cover both events. The date is shown as frm xxx to yyy, to cover period of transit.

[Mark1834]

That's fine, Mike - I have done the same in the past. But GEDCOM has both, so FH has to have both to support its claim of complete GEDCOM compliance. I have recently split them to separate facts in my database, as they typically have different sources in the departure and arrival countries, but that's my choice - FH is happy with either.

[ColeValleyGirl]

Whereas I have hidden 'Immigration' and renamed 'Emigration' to be 'Travelled' which covers my needs better. However, I'm suspecting that 'Departed from Municipality' is something subtly different.

[tatewise]

You will have to wait until GEDCOM 7.0.1 is supported by FH to allow Custom Events to have a value like Attributes.

The Emigration/Immigration To/From fields are a special FH feature of just those two events that confuses many new users.

One way to add 'meta-fields' is explained in FHUG Knowledge Base Narrative Report Fact Sentence Templates under Custom Fact Fields by using labelled note text.
e.g.
[[
To: Kolum, Friesland, Netherlands
]]

[ColeValleyGirl]

Mike, true, but can you show the labelled text in the list of Facts on the fact tab, or an Individual Summary Report, for example? Or is it just useful in Narrative reports?

[tatewise]

Yes and Yes.

Needs Tools > Fact Types... Edit... Advanced... Summary Template:
Flew from {_place}< to {=GetLabelledText(%FACT.NOTE2%,"To: ")}>

Fact To.png (53.17 KiB) Viewed 1288 times

Needs ISR Inc. [[private]] Notes enabled if the labelled note is inside [[ private ]] brackets.

ISR To.png (5.98 KiB) Viewed 1288 times

[ColeValleyGirl]

Thanks. Pity about having to include private notes in the ISR, which means I can't use it.

[LornaCraig]

Sentence.jpg (11.62 KiB) Viewed 1261 times

That's impressive. The Wright brothers only managed 4 miles in 1903!

[tatewise]

It does not have to be a [[private]] note but that may cause other problems.

An alternative is to create a 2nd local Note via the All tab. Just ensure the 1st local Note has at least some white-space text.
To: New York

Then use Template: < to {=GetLabelledText(%FACT.NOTE2[2]%,"To: ")}>

OR to allow the labelled text in either 1st or 2nd local Note use
Template: < to {=GetLabelledText(%FACT.NOTE2%,"To: ")}>< to {=GetLabelledText(%FACT.NOTE2[2]%,"To: ")}>

The only drawback is the 2nd local Note is not shown in the Facts tab, although is shown in the Notes tab.

Yet another option, is to use a Custom Attribute instead of an Event and use its Value as the To: field.

Lorna, I did that on purpose to see who would react
BTW: He flew East in a hot air balloon and refuelled when necessary! No large oceans to cross going East.

[ColeValleyGirl]

Thanks, Mike.

[Chrisv]

Unfortunately, (or fortunately) I have their Emigration, Immigration and their Departure from Municipality documents. I guess I could just jumble them all together into one Event, but that just seems to be too messy. It is my Great (x3) Grandfather, after all. And I use use private [[#Research]] notes extensively, so that won't work. Probably the best thing to do is to combine the Immigration and Emigration into one Event as Gowermick suggested, and to use the other for the Departure from Municipality, since I have many instances of other persons using this Event.

Can you use an attribute as an event to take advantage of the Value field as Mike suggested? Is there a reason not to use an attribute as an Event when this field may be useful for other purposes than a value? The FHUG Knowledge Base seems to indicate that it is okay?!? (see below)

Attribute Snip.PNG (131.65 KiB) Viewed 1223 times

[BillH]

One does wonder why you want an Immigration AND an emigration fact. Surely an emigration from one place means an immigration to another.
So an Emigration fact, which contains both From and To places, covers both events.
My great uncle emigrated from London to NZ, which naturally meant he immigrated to NZ from London at the same time. I have one fact to cover both events. The date is shown as frm xxx to yyy, to cover period of transit.

The problem with this is that the date of emigration and the date of immigration are usually not the same. For some of my ancestors the emigration date is more than a month before the immigration date.

Bill

[Gowermick]

Bill,
You never spotted my last sentence, which covers that eventuality

[BillH]

I did miss that.

I like having two different facts so that if I have any other facts which occurred between the emigration and the immigration, they sort in the correct order on the facts tab.

For example...

Emigration
Marriage (on the ship)
Immigration

Bill

[ADC65]

Unfortunately, (or fortunately) I have their Emigration, Immigration and their Departure from Municipality documents. I guess I could just jumble them all together into one Event, but that just seems to be too messy.

I just use the Arrived and Departed fields, and use the narrative field to describe what happened:

Screenshot 2022-12-24 212157.jpg (37.23 KiB) Viewed 1153 times

I did use the Immigration and Emigration fields a long time ago, but became unhappy with them as I felt just arriving somewhere didn't fit my perception of 'immigration' (others may not care of course).

[AdrianBruce]

...
I did use the Immigration and Emigration fields a long time ago, but became unhappy with them as I felt just arriving somewhere didn't fit my perception of 'immigration' (other's may not care of course).

Yes, I think that this is one of those things that a number of us do in different ways. In fact, I'm not even totally convinced that I do it in a consistent way on my own data. For what it's worth, just to make you think....

Point 1 - I hid the Immigration event. I really don't see why I need both Emigration and Immigration, so let's just describe one end of the journey. I happened to choose "Emigration", which may be a reflection of me living in a country (the UK) whence most people emigrated. Should you live in the Antipodes, or on the other side of The Pond, you might make the opposite decision.

Also, "Immigration" these days has a dual meaning - when I passed through Immigration at St. Louis in 1999, my task was to convince them that I had zero intention of staying. Rather the opposite of my relatives' permanent-ish arrival in the USA earlier on.

Point 2 - I seem to use "Emigrated From" with a single place-name (for maximum GEDCOM compatibility), and then a Custom Event of Arrival at New York City or wherever. If someone went out and then came back permanently, I think I just do a Custom Event of Departure, then a Custom Event of Arrival, for the outbound journey, and repeat the pair for the return journey. However, without the ability to interrogate my relatives over their intentions, it might be thought a bit debatable. And yes, lots of story in the Notes...

[Chrisv]

So what I think you are saying Adrian, is to simply not use the Immigration or Emigration Events, but instead to create from scratch an Immigration and Emigration event and use the Place field to state where "coming from" on one and "arriving to" in the other. A very simple, yet effective solution. I could then use the Emigration as my Departing from Municipality event (which I have many of).
This will also solve the problem that Bill pointed out in that the dates of the two are typically a month apart and events can happen in between the two.
This gets back to my question about possibly using an Attribute as an Event so the Value field could be used as needed. Could this cause a problem, or did I miss the answer somewhere amidst the technical talk that went over my head (still trying to process some (most) of it)

[ColeValleyGirl]

Mike, would it be worth an KB article on these options?

[AdrianBruce]

So what I think you are saying Adrian, is to simply not use the Immigration or Emigration Events, but instead to create from scratch an Immigration and Emigration event ...

I don't even create new Immigration or Emigration events - I just use the exiting ones but don't bother to fill in the "other" place - i.e. on Emigration I fill in the ordinary Place item and ignore the "other", i.e. the "To" place. That appears to go through perfectly sensibly without anything odd like an empty item. And, for my purposes, I've ignored the Immigration fact type as I use a custom event of Arrival for "the other end" of the Emigration.

... This gets back to my question about possibly using an Attribute as an Event so the Value field could be used as needed. Could this cause a problem, or did I miss the answer somewhere amidst the technical talk that went over my head (still trying to process some (most) of it)

OK - not quite sure myself about whether recording an Event (in the real world sense) as an Attribute (in Family Historian) comes in again, but I can't see any likelihood of a problem within FamilyHistorian. The distinction between those two concepts is debatable. In (the current) FH it's simple and robust - if it has a value, it's an Attribute and vice versa, while Events don't and can't have values. In that elusive concept known as the real world, Attributes describe ongoing states and Events describes changes to ongoing states - though we are unlikely to record matched pairs in FH except in special circumstances - e.g. the attribute Occupation is changed by / terminated by the Retirement event.

All of this means that it's all a bit odd and people are quite likely to have already described (real world) Events by (FH) attributes just so they can get a value in. If there were any ongoing issues, I'm sure they'd have appeared and I don't remember seeing any. Indeed, I already have some (FH) Attributes that the arguably (real world) Events. Like "Awarded", for instance - that's an FH attribute with a value of the medal or whatever that's awarded, but the psychological emphasis is on the (real world) event itself. Or it is in my files.

As for what would happen in other software if you fed them such a GEDCOM, I can't promise but because which is which is such a debatable concept, I doubt anyone's made too much of the distinction. But no promises...

[tatewise]

How would any product (including FH) know that you are misusing an Attribute to represent a real-world event?
That association only exists in your head!
As far as any software is concerned, an Attribute fact is an Attribute, and an Event fact is an Event.

The only scenario that some pedantic software might complain about is if you assign a Date Range to an Attribute.
i.e. The Attribute happened sometime 'between <date X> and <date Y>' which only makes sense for an Event.
Attributes should use a Period Date such as 'from <date X> to <date Y>'.
The only software I'm aware of that complains like that is a few very rigorous GEDCOM compliance testers.

However, I'm most cases the Date will have a single simple date value that is valid for both Attributes and Events.

[ColeValleyGirl]

The only scenario that some pedantic software might complain about is if you assign a Date Range to an Attribute.
i.e. The Attribute happened sometime 'between <date X> and <date Y>' which only makes sense for an Event.

My mother had blonde hair sometime between 1964 and 1969. I have a photo of it (undated) when all 4 of her youngest daughters were present and walking, and I know that her hair was its natural black at my father's funeral in early 1969.

There's an attribute (Appearance) where a 'between' date makes sense.

[tatewise]

OK, that makes an even stronger case.
However, the GEDCOM 5.5.1 specification only associates Date Periods with Attribute states and Date Ranges with Event single dates, which is why some aggressive GEDCOM compliance checkers complain if used the other way round.
In general though, most software does not care.

[KFN]

From a purely GEDCOM standpoint I don't understand where a FROM and TO location can be entered! I only see one place to enter a location that makes sense!

In GEDCOM v5.5.1 the EMIG tag (old domicile) and IMMI tag (new domicile) would have a single PLAC and DATE tags.

A relative of mine emigrated from Trondheim Norway on March 21, 1911, passed through Copenhagen and Southampton, England before Immigrating to the USA at New York on April 5, 1911.

There are at minimum 2 GEDCOM events (EMIG and IMMI) each with a place and a date, or the possibility of of adding two more "custom events" we can call "stop overs" (not a combination of IMMI and EMIG) . I took the approach of two events for all of these events with the "stop overs" noted in text of the EMIG tag.

Most of my relatives that left Norway or Eastern Europe took close to a month to get from one place to another when they moved to the USA because they took several boats to cross "the pond".

Even when my family moved within Norway and registered their new location with the church, the dates were not on less than a week apart, and were at times longer apart due to "official delay" in registering.

I realize I'm late to this discussion but I wanted to put my two cents in!