* Dealing with MAP, LATI/LONG in import GEDCOM

[JP Ford]

Good day, Just purchased Family Historian 6.27 (FH) and am very excited to be making the leap from RootsMagic 7 (RM). Have been reviewing many forum posts re; export/import and dealing with RM's unique GEDCOM ID's. I have managed to remove the superfluous UID and AMTID records via the UDF list and plugin. What I am seeing now are a few hundred remaining UDF's that are map coordinates, using the record name MAP, with subordinate fields of LAT1 and LONG (see attached screen cap) .

Example MAP records in UDF List

(006).png (12.06 KiB) Viewed 6029 times

I can see that FH keeps these coordinates in a single field "Lat./Long.", so the problems appears to be that RM is exporting them into separate fields (LATI & LONG) and they are not getting parsed correctly into FH. The UDF records are linked to the correct person/event/place, so is there any way, other than copy/paste 800+ times, to correct these??

OR

Am I just better off leaving them out and letting FH do the coordinates for me (assuming that is an option via mapping) I'm comfortable with GEDCOM editing if that is a solution.

[Jane]

Am I just better off leaving them out and letting FH do the coordinates for me (assuming that is an option via mapping) I'm comfortable with GEDCOM editing if that is a solution.

FH currently stores the co-ordinates against the Place records, so I would be tempted to let it do them over time.

I would be tempted to leave those where they are for now and make sure you are happy with the automatic mapping on FH, if there is a problem you can always write a plugin to go through and move them. UDFs don't hurt anything and FH will happily keep them for you.

[tatewise]

One issue to consider is that the RM MAP data is associated with the Address.
Whereas, FH Place name record mapping ignores the Address.
So taking your example screenshot, only Pike, Alabama, United States will get mapped to Lat/Longitude.

If there are multiple Address values for any one Place name, then a Plugin can only transfer one of the LATI/LONG values into the Place record, or if it was really clever perhaps an average of all the LATI/LONG values.

The GEDCOM 5.5.1 Specification defines MAP/LATI/LONG data only for Place names.
So migrating RM plots into any other products is likely to be a challenge.

The how_to:import_from_roots_magic|> Import from RootsMagic (RM) advice needs updating to cover this topic.

[JP Ford]

Thanks for the quick responses!

So, it sounds like I need to keep these for now and think about it these over time, since I have some ADDRESS fields that might contain a specific, otherwise unknown location, as in a burial event that contains:

PLACE: Pike, Alabama, United States (where Pike is a County)
ADDRESS: The Smith Cemetery (with GPS coordinates)

This is because the Smith cemetery has no address and is a "lost" location. IOW, it no longer exists on any map.

If I'm understanding correctly, FH will ignore these coordinates as far as mapping goes. So, I think my initial question is answered, but how do I manage these types of locations? Can I/Do I create custom Places to deal with these types of situations?

[tatewise]

See glossary:places|> Places and Addresses that provides some background advice.
It also has links to many Forum Posts on this much debated topic.

It is not so much using custom Places as ensuring each Place is distinct and can have its own Lat/Longitude.
So for example the Place could be The Smith Cemetery, , Pike, Alabama, USA with the Address field empty.
That Place can have its own Lat/Longitude either auto-plotted, manually plotted, or using a Plugin to copy the UDF.
Notice that there is a blank comma separated space for the unknown Town name.

In the past, the advice would have been to keep the Place and Address parts separate.
But now mapping is only associated with Place fields it is popular to put everything in that field.
What is important is to be consistent. Move all your Address data into the Place fields.
Have the same number of comma separated Place parts everywhere, even if some are blank.

See how Tools > Work with Data > Places handles sorting by column and you will understand the importance.
It helps in other contexts when needing just Towns, or just Counties, etc, to know that is always a specific part counting from one end.

[JP Ford]

Mike - Thanks. I understand completely!

[JP Ford]

Mike,

I thought I understood clearly until I read the KB article you linked to, since the article suggests that I do the opposite (use address for street level, church names, etc.) I read your message as "stop using the address field", but now I wonder if your suggestion to put it all in the Place field was merely a one-off workaround for my unusual example or your recommendation for all Places. Can you clarify?

Reading the forum posts I see the debate and the pros/cons of each, so as far as Places goes generally speaking, when I go to Tools..Work with Data...Places, I find that I have 3 columns and in those places that have three or more parts (City, State, County, Country) the State is combined with Country, as in

Col1= "San Antonio",
Col2 = "Bexar", and
Col3= "Texas, United States".

So, I change my column prefs to 4 columns and that fixes the combined parts, so now Col3="Texas" and Col4="United States". All good....

But, (See the screen cap) the Places that do not have 4 parts in the Place entry are all shifted to the left, so they're off by one column.

Screen-2020-02-18_20-20-36.png (7.67 KiB) Viewed 5902 times

If I add the requisite number of commas to that Place, they shift to the right and my State and Country are all lined up in the 3rd and 4th column. So, if I understand you correctly, what I really need to do is add the required number of commas to each Place so that I have consistency with a 4 column Place naming pattern. The it's just a matter of maintaining that by adding commas when I have a place that has less than 4 parts. I'm thinking the rest can go in address and, if I need to note GPS coords for the occasional address, I can just add that in a note.

Does that sound reasonable?

Joel

[tatewise]

Joel,
You do not need to quote an immediately preceding posting in your Reply.

In the past, the advice would have been to keep the Place and Address parts separate.
But now mapping is only associated with Place fields it is popular to put everything in that field.

glossary:places#recommendations|> Recommendations supports my 1st sentence with the caveat "unless you have good reason not too."
glossary:places#geocode_mapping|> Geocode Mapping supports my 2nd sentence and is that "good reason".

You have clearly grasped the features of Tools > Work with Data > Places and maintaining that consistent column format will pay dividends. Note that the blank comma separated columns are usually automatically removed in Diagrams and Reports, etc, by using the FH TIDY option.
If you continue to use Address fields then apply Tools > Work with Data > Addresses in the same way.

If there really are only rare cases where you need the GPS coords for an Address then your proposal will work fine, as long as you understand that those GPS coords will NOT be applied to any automatic mapping within FH. If there is only one Address associated with a Place name then you can put those GPS coords in the Place record Lat/Longitude field and that will map automatically.

It is if you decide that a lot more Addresses need to be mapped that it becomes necessary to migrate all Address data into the Place fields, and increase the number of columns to accommodate that data.

[AdrianBruce]

... maintaining that consistent column format will pay dividends. ...

But the debit side of the consistent column format is that it becomes - in my personal experience - much more difficult to use auto-completion when entering "short" names. For instance, if your place-names include "Texas, USA", you can type "Tex" (say) and you will (with luck) be offered "Texas, USA". If you have standardised on 4 columns for US place-names and have ", , Texas, USA" in the list of place-names, then you must type exactly that combination of commas and spaces before the "Tex" - if you insert extra spaces or lose them, FH will not pick ", , Texas, USA" up in the auto-complete.

Now, if you can train your fingers to type the correct / consistent combination of commas and spaces, feel free to ignore this issue. I'm afraid that I found I was thinking too much and usually failed at the first hurdle because I could never remember whether the first character needed to be a comma or a space.

I'm not arguing against a practice that many people find useful - just suggesting that you might want to practice first to see how you get on.

[tatewise]

Adrian makes a useful point, but should you make a mistake and finish up with several versions of Texas, USA then it is quite easy to Merge them together via Tools > Work with Data > Places and retain their details.

A variant is to ensure that only the trailing comma separated parts are consistent.
i.e.
Last column is Country
Penultimate column is State
and so on, but omitting any blank leading commas.

Then in Tools > Work with Data > Places tick Reverse Display Order so that Country is on left, followed by State, then County, etc.

FH has functions that can pick out the nth comma separated part to extract just County or just State, etc.
If n is positive then it counts from the left, so with 4 columns, n = 3 yields State.
If n is negative then it counts from the right, so for any columns, n = -2 also yields State.

[JP Ford]

Thanks you all. I am familiar with the use of commas to break out placenames and address fields. (It's been a while since I needed to, but I do remember and have no problem with it.) I'll go this route and see how it feels.