* Listing both places for emigrated / immigrated attributes

[ELM]

I am trying to write a query that lists all the emigrated / immigrated attributes listing both places in these attributes. To get the first place I can use %FACT.PLAC% but how do I get the other place.

[LornaCraig]

Emigration and Immigration are special cases because they are the only Facts which can have two place fields (and only in FH).
I haven't found a way of getting the second place in a Fact query, but no doubt if it is possible someone will tell us how!

However you can get it in an Individual query.

The columns will be Emigration Place %INDI.EMIG.PLAC>% and Emigration Place (to) %INDI.EMIG._PLAC>%
These can be found by expanding the Emigration event in the left hand panel.

The rows will be Add unless... %INDI.EMIG[1].PLAC>% is null
and Add unless... %INDI.EMIG[1]._PLAC>% is null

[tatewise]

Theoretically, in a Fact Query the data ref %FACT._PLAC% should work, but strangely is not allowed.
That is a bug that was discovered during FH V6 Beta testing early in 2015 and is logged with Calico Pie.
It came up again in the topic Deleting Unused Fact Type (13508).
You could report the problem to Calico Pie again and hopefully they will fix it one day.

The data ref %FACT% will list the entire fact details such as:
Emigrated January 1901 from London to New York

[LornaCraig]

A related problem is that in the Map Window when you click on a place marked on the map the pop-up box does not list the uses of a place when it was the second place in an emigration or immigration event.
This was reported to Calico during Beta testing, and is still not fixed.

[tatewise]

Perhaps Calico Pie are trying to kill off that 2nd Place field by restricting its usefulness?

[E Wilcock]

I can see why they might want to do that. But I hope they wont. The response of one group currently designing a proposed genealogy database was to dismiss the idea of two place Tags entirely. Not correct practice.

My view is somewhat different. I want software that is easy for people to use. fh has an enormous advantage when it comes to helping users put stuff into it. The boxes are marked with labels one can understand. And it is very easy indeed to enter sources as one goes along.

And the same with emigration. I am a bit dyslexic and could never remember which was immigration and which was emigration and in any case might not want to enter the same fact twice. fh fields of place from and to, at least ensure that the facts are correctly entered even if later relegated to a Notes field.

Plotting repeated travels with genealogy software is a real nightmare. In program after program users devise custom Tags to help with this. As if we genealogists are constantly having to work round rules set by programmers, rather than the programmers observing what ordinary every day family historians need.

fh has the advantage of working from a text file. It isnt a relational database and it should surely offer us the advantages of that. And make data entry as easy as possible. After all, it isnt compulsory to enter two places in any Tag unless one chooses too. I want custom 2 place Tags allowed too.

The fact that Mike and others here understand the issues and advantages when other computer experts did not, seemed to me so significant that I opted to stay with fh.

[ELM]

Thank you for your replies. I am disappointed that the second place in immigration/emigration facts has not been fully implemented and may be killed off. I am in the camp that think there are other events that require a second place and the need for these second places to be mapped.
Is the wish list still active?

[E Wilcock]

I want it - with custom Events allowed to have two places as well - but I havent formally asked for it as I dont understand how the wish list and voting works.

[AdrianBruce]

... I am disappointed that the second place in immigration/emigration facts has not been fully implemented and may be killed off. ...

I wouldn't take that suggestion too literally - good programmers are always cynics (how else will they understand the idiocies of user input?). NB - the reverse does not apply - cynics are seldom good programmers!

Nonetheless, I have often thought that Calico Pie do have a tendency to do 90% of a job - e.g. in the Individual's property box, you can customise several(?) of the tabs but not the Fact tab itself. Adding "Employer" to the occupation fact (which I do in the Responsible Agency for that Occupation on the All tab) can only be done otherwise on a Custom tab, where you need to explicitly code OCCU(1), OCCU(2), OCCU(3), OCCU(4), etc. etc. Pain.

[tatewise]

Adrian, you have a good point, but it is quite different from the 2nd Place request.

You are asking for existing standard Gedcom sub-fields of a Fact to be labelled and displayed via a Data Ref in the Facts tab, in much the same way as is possible in the Main and custom tabs. That would be highly desirable.

Whereas the 2nd Place request is for a non-standard _PLAC field (and possibly other custom fields) to be added to the FH variant of Gedcom as (legal user-defined) extensions of every Fact.
This thread also highlights that the non-standard nature of the 2nd _PLAC field has lead to its implementation being 'overlooked' in various workspace windows such as Fact Queries and the Map Window.

[AdrianBruce]

Adrian, you have a good point, but it is quite different from the 2nd Place request.
...

Sure - I understand that - I was just adding background but it's worth you clarifying

... You are asking for existing standard Gedcom sub-fields of a Fact to be labelled and displayed via a Data Ref in the Facts tab, in much the same way as is possible in the Main and custom tabs. That would be highly desirable.
...

I've just tried to find this in the Wish List because this isn't the first time that we've talked about the inability to customise the tags appearing on the Facts tab. I can't find it - but that doesn't mean anything - it could be there with different wording.

If you can't find it either, then I'm happy to raise this as a Wish-List item (not the both places bit, but the standard tags in an event being on the facts tab).

[Peter Collier]

With apologies in advance for my linguistic pedancy, but why would an immigration or emigration event ever be associated with two places?

• Emigrate -- to migrate from a place (from Latin EX: out of + MIGRARE: move)
  Immigrate -- to migrate to a place (from Latin IN: in to + MIGRARE: move)

It is logical enough that a person can only immigrate to, or emigrate from, one place at a time. It is therefore right that each event is only associated with one place. It is nonsensical to talk of emigrating to somewhere, or immigrating from somewhere.

If you want to record the points of arrival and departure in the same fact, then you are looking to record a migration (rather than specifically an immigration or emigration) – if there is such an event set up as default?

[tatewise]

@Adrian, no there does not appear to be a Wish List entry for customising the Facts tab.
So feel free to add a New Wish List Request but consider how the customisation would apply to different Facts.
Would every Fact gain the same customised field, or would they only apply to specified Facts?
Would custom field(s) be interwoven between standard fields or only added at the base (above or below Sentence)?

[BillH]

Peter,

That is probably true in theory, but not in practice. People usually know where they are going when they emigrate. They buy a ticket to somewhere, they don't buy a ticket from somewhere.

Sometimes people emigrated from someplace to someplace else, but never immigrated because they died in route. It is kind of nice to know where they were headed when they died.

Even Norwegian parish records from the early 1800's always listed where people were going when they were leaving the parish.

[mezentia]

The problem is not restricted to emigration/immigration, but also applies to passenger lists, typically involving travel by sea, where the date and port of departure and date and port of arrival are to be documented as a single event. I've created a Passenger List event that uses a custom sentence template together with meta-tags in the note field to create an appropriate sentence that combines all this information, including the vessel's name, shipping line, Captain's name, etc. The only problem is remembering the meta tag names; it would be so much nicer to be able to design a custom event entry form.

[tatewise]

You don't need to remember the meta-field labels, because every time you create a new Passenger List event it can populate the Note field with the labels (or any other text you like).

See how_to:narrative_report_fact_sentence_templates|> Narrative Report Fact Sentence Templates under Custom Fact Fields where it refers to the Auto-Create Note field option. This advice has been added recently.
i.e.
Tools > Fact Types > Passenger List > Edit > Advanced > Override Templates > Auto-Create Note

Just rememeber to use Ctrl+Enter to insert a line break after each label.

Another trick is to click on the Sentence box for the Passenger List event in the Facts tab.
That reveals the Template with the GetLabelledText functions where the labels are used.