Editing Places in FH7


johnfirr@...
 

I decided to do a tidy up on my list of places in FH7. In some cases I have duplicate places because I may have changed how I have input over the years and using merge records has been perfect for sorting these out.

However I have hit a problem where I have a single place occurrence with a typo. So for instance I have a place recorded as Camberwell, london, England. I have put lower case l rather than L at start of London. This not only looks messy but it means Maps is not geocoding this particular place. Problem is I cant seem to edit the word London. I can select the record but it wont let me change anything. Am I missing something obvious?
thanks
John Firr


Andrew Braid
 

Yes. I had exactly the same problem. When you want to edit the place name click on the box with three dots on the right hand side of the name.


On Tue, Jan 5, 2021, 19:01 johnfirr via groups.io <johnfirr=yahoo.co.uk@groups.io> wrote:
I decided to do a tidy up on my list of places in FH7. In some cases I have duplicate places because I may have changed how I have input over the years and using merge records has been perfect for sorting these out.

However I have hit a problem where I have a single place occurrence with a typo. So for instance I have a place recorded as Camberwell, london, England. I have put lower case l rather than L at start of London. This not only looks messy but it means Maps is not geocoding this particular place. Problem is I cant seem to edit the word London. I can select the record but it wont let me change anything. Am I missing something obvious?
thanks
John Firr


Robert Jordan
 

Hi John
The way to make amendment is in the Indivual record so locate the individual containing the incorrect spelling and change it there. The incorrect spelling will still be held in the places record. If you want to completely delete record in place record there are ways. I will send details tommorrow

Rob Jordan

On Tue, 5 Jan 2021, 19:01 johnfirr via groups.io, <johnfirr=yahoo.co.uk@groups.io> wrote:
I decided to do a tidy up on my list of places in FH7. In some cases I have duplicate places because I may have changed how I have input over the years and using merge records has been perfect for sorting these out.

However I have hit a problem where I have a single place occurrence with a typo. So for instance I have a place recorded as Camberwell, london, England. I have put lower case l rather than L at start of London. This not only looks messy but it means Maps is not geocoding this particular place. Problem is I cant seem to edit the word London. I can select the record but it wont let me change anything. Am I missing something obvious?
thanks
John Firr


Mike Tate
 

I am sorry to contradict Rob, but changing Place names in Individual record Fact Place fields is unwise for the very reason he gives.

It creates a brand new empty Place record and leaves the misspelt Place record behind with any Lat/Long geocoding, linked Media, Notes, etc.

 

Also if that Place name is misspelt in several Facts then each one must be changed by hand.

 

The neat way is to edit the Place record via the Places tab in the Records Window or via the Tools > Work with Data > Places... window.

That one change then updates every Place name linked to that Place record and all the Place record details are retained intact.

 

Mike Tate

 

From: family-historian@groups.io <family-historian@groups.io> On Behalf Of Robert Jordan
Sent: 05 January 2021 21:05
To: family-historian@groups.io
Subject: Re: [family-historian] Editing Places in FH7

 

Hi John

The way to make amendment is in the Indivual record so locate the individual containing the incorrect spelling and change it there. The incorrect spelling will still be held in the places record. If you want to completely delete record in place record there are ways. I will send details tommorrow

 

Rob Jordan

 

On Tue, 5 Jan 2021, 19:01 johnfirr via groups.io, <johnfirr=yahoo.co.uk@groups.io> wrote:

I decided to do a tidy up on my list of places in FH7. In some cases I have duplicate places because I may have changed how I have input over the years and using merge records has been perfect for sorting these out.

However I have hit a problem where I have a single place occurrence with a typo. So for instance I have a place recorded as Camberwell, london, England. I have put lower case l rather than L at start of London. This not only looks messy but it means Maps is not geocoding this particular place. Problem is I cant seem to edit the word London. I can select the record but it wont let me change anything. Am I missing something obvious?
thanks
John Firr


Robert Jordan
 

I am loath to say this but Mike Tate’s comment is way off the mark and he has already admitted to posting confusing comments on this matter on a different thread. I said yesterday that I would advise on methods to deal with your issue but Mike was unwise enough to contradict me before I had chance to give you the information.

You said that you have ONE record where the spelling is incorrect.

You may know of that particular record but if you are unsure the go to FIND type in the incorrect place spelling in the search field and uncheck all the boxes at the bottom except PLACE and MATCH CASE and then FIND NOW. It will list all the records where the incorrect spelling is listed. Then click DISPLAY RESULTS IN RESULTS WINOW.  That will give you a list of all the individual records and the fact which contains the incorrect PLACE. If you only have a few results then the quickest way would be to go into each record and change the spelling manually.

If there are many records to change the quickest way is to firstly change one INDIVIDUAL record to the correct spelling then go to Tools/Work with data/Places. Find the correct spelling and the incorrect spelling and highlight them and then MERGE. You can then choose, obviously, the correct spelling to merge the two records.

What FH does when a PLACE record is changed is to produce two PLACE RECORDS. One with the correct spelling and one with the incorrect spelling. Assuming that there is no longer any record containing the incorrect spelling, the first with a positive number of links and the second with 0 links (not one empty place record as suggested by Mike Tate).

To take the matter further FH builds up PLACE records with no links because it does not automatically delete those records.

If you wish to clean up your database and remove clearly unwanted and unused records then there are two options I take no credit for these. The first was suggested by Lorna Craig

You can do this in the Records window, because it remembers the last three sorts you have done and when you choose a new sort order it uses the previous sort order as a subsidiary sort. So you can sort by one category within another.

Click the column heading for Latitude/Longitude to bring all the places with no geocoding to the top of the list (I think the default sort order is ‘Sort Ascending’ but if not, right click on the column heading and choose Sort Ascending).

Then click the heading of the Links column to sort (ascending) by number of links. 

The places at the top of the list will now be those with neither links nor geocoding.

Add these to a named list and then use Lists > Empty Named List to delete the records in the list.

The second offered, I think, by Graham Kent, apologies if I have this wrong

  1. Make a copy of the PLACES query provided with fH7,
  2. On the Column tab, add a new column with a heading of "Links to" and an expression of "=LinksTo(%_PLAC%)",
  3. On the Rows tab, add a filter with condition of "Exclude unless", Expression is "%_PLAC.LATLONG%" and operator is "is null",
  4. On the Rows tab, add a filter with condition of "Exclude unless", Expression is "=LinksTo(%_PLAC%)" and operator is "is less than" and value is "1".

Both of these work fine.

Robert Jordan


Virus-free. www.avast.com


Lorna Craig
 

Robert,

 

While the bulk of the information you have given in your answer is broadly accurate, I think you may have slightly misunderstood the original problem, and therefore given a very long answer to something which has a very quick solution.   In his question, Johnfirr made it clear that he is already familiar with the MERGE technique (one of the things you mention) but cannot use it in this case because he doesn’t have a pair of records to merge, he only has one record for the Place and it has the incorrect spelling.  So he simply needs to know how to change the spelling in that one Place record.  John’s problem was that he didn’t know how to edit the name in the title field of the place record.

 

A reply was given by Andrew Braid a few minutes after the original question came in: “When you want to edit the place name click on the box with three dots on the right hand side of the name.”   Alternatively simply double-click in the name field.   This opens the Edit Place Name window, where the name can be changed.  This change will then apply to every instance of the use of that Place.   There will be no left over unused Place record.  Job Done. 

 

Lorna

 

From: Robert Jordan
Sent: 06 January 2021 09:12
To: family-historian@groups.io
Subject: Re: [family-historian] Editing Places in FH7

 

I am loath to say this but Mike Tate’s comment is way off the mark and he has already admitted to posting confusing comments on this matter on a different thread. I said yesterday that I would advise on methods to deal with your issue but Mike was unwise enough to contradict me before I had chance to give you the information.

You said that you have ONE record where the spelling is incorrect.

You may know of that particular record but if you are unsure the go to FIND type in the incorrect place spelling in the search field and uncheck all the boxes at the bottom except PLACE and MATCH CASE and then FIND NOW. It will list all the records where the incorrect spelling is listed. Then click DISPLAY RESULTS IN RESULTS WINOW.  That will give you a list of all the individual records and the fact which contains the incorrect PLACE. If you only have a few results then the quickest way would be to go into each record and change the spelling manually.

If there are many records to change the quickest way is to firstly change one INDIVIDUAL record to the correct spelling then go to Tools/Work with data/Places. Find the correct spelling and the incorrect spelling and highlight them and then MERGE. You can then choose, obviously, the correct spelling to merge the two records.

What FH does when a PLACE record is changed is to produce two PLACE RECORDS. One with the correct spelling and one with the incorrect spelling. Assuming that there is no longer any record containing the incorrect spelling, the first with a positive number of links and the second with 0 links (not one empty place record as suggested by Mike Tate).

To take the matter further FH builds up PLACE records with no links because it does not automatically delete those records.

If you wish to clean up your database and remove clearly unwanted and unused records then there are two options I take no credit for these. The first was suggested by Lorna Craig

You can do this in the Records window, because it remembers the last three sorts you have done and when you choose a new sort order it uses the previous sort order as a subsidiary sort. So you can sort by one category within another.

Click the column heading for Latitude/Longitude to bring all the places with no geocoding to the top of the list (I think the default sort order is ‘Sort Ascending’ but if not, right click on the column heading and choose Sort Ascending).

Then click the heading of the Links column to sort (ascending) by number of links. 

The places at the top of the list will now be those with neither links nor geocoding.

Add these to a named list and then use Lists > Empty Named List to delete the records in the list.

The second offered, I think, by Graham Kent, apologies if I have this wrong

  1. Make a copy of the PLACES query provided with fH7,
  2. On the Column tab, add a new column with a heading of "Links to" and an expression of "=LinksTo(%_PLAC%)",
  3. On the Rows tab, add a filter with condition of "Exclude unless", Expression is "%_PLAC.LATLONG%" and operator is "is null",
  4. On the Rows tab, add a filter with condition of "Exclude unless", Expression is "=LinksTo(%_PLAC%)" and operator is "is less than" and value is "1".

Both of these work fine.

Robert Jordan

 


Mike Tate
 

Sorry, Robert, I have to disagree with some of your advice.

Firstly, it is much clearer to refer to the Place box associated with Facts as the Place ‘field’.

To call it a Place ‘record’ is confusing in the terminology used by FH, which has at most 12 Record types (shown as tabs in the Records Window).

The Place Records are quite distinct from the Place fields and behave differently.

 

You say:

“If you only have a few results then the quickest way would be to go into each record Place field and change the spelling manually.”

and

“If there are many records fields to change the quickest way is to firstly change one INDIVIDUAL record Place field”.

 

The quickest way is to change the incorrect Place Record name via the Places tab of the Records Window. That is it ~ job done.

No merging of Place Records is needed and no risk of unlinked Place Records so no database clean-up is needed.

 

Mike Tate

 

From: family-historian@groups.io <family-historian@groups.io> On Behalf Of Robert Jordan
Sent: 06 January 2021 09:12
To: family-historian@groups.io
Subject: Re: [family-historian] Editing Places in FH7

 

I am loath to say this but Mike Tate’s comment is way off the mark and he has already admitted to posting confusing comments on this matter on a different thread. I said yesterday that I would advise on methods to deal with your issue but Mike was unwise enough to contradict me before I had chance to give you the information.

You said that you have ONE record where the spelling is incorrect.

You may know of that particular record but if you are unsure the go to FIND type in the incorrect place spelling in the search field and uncheck all the boxes at the bottom except PLACE and MATCH CASE and then FIND NOW. It will list all the records where the incorrect spelling is listed. Then click DISPLAY RESULTS IN RESULTS WINOW.  That will give you a list of all the individual records and the fact which contains the incorrect PLACE. If you only have a few results then the quickest way would be to go into each record and change the spelling manually.

If there are many records to change the quickest way is to firstly change one INDIVIDUAL record to the correct spelling then go to Tools/Work with data/Places. Find the correct spelling and the incorrect spelling and highlight them and then MERGE. You can then choose, obviously, the correct spelling to merge the two records.

What FH does when a PLACE record is changed is to produce two PLACE RECORDS. One with the correct spelling and one with the incorrect spelling. Assuming that there is no longer any record containing the incorrect spelling, the first with a positive number of links and the second with 0 links (not one empty place record as suggested by Mike Tate).

To take the matter further FH builds up PLACE records with no links because it does not automatically delete those records.

If you wish to clean up your database and remove clearly unwanted and unused records then there are two options I take no credit for these. The first was suggested by Lorna Craig

You can do this in the Records window, because it remembers the last three sorts you have done and when you choose a new sort order it uses the previous sort order as a subsidiary sort. So you can sort by one category within another.

Click the column heading for Latitude/Longitude to bring all the places with no geocoding to the top of the list (I think the default sort order is ‘Sort Ascending’ but if not, right click on the column heading and choose Sort Ascending).

Then click the heading of the Links column to sort (ascending) by number of links. 

The places at the top of the list will now be those with neither links nor geocoding.

Add these to a named list and then use Lists > Empty Named List to delete the records in the list.

The second offered, I think, by Graham Kent, apologies if I have this wrong

  1. Make a copy of the PLACES query provided with fH7,
  2. On the Column tab, add a new column with a heading of "Links to" and an expression of "=LinksTo(%_PLAC%)",
  3. On the Rows tab, add a filter with condition of "Exclude unless", Expression is "%_PLAC.LATLONG%" and operator is "is null",
  4. On the Rows tab, add a filter with condition of "Exclude unless", Expression is "=LinksTo(%_PLAC%)" and operator is "is less than" and value is "1".

Both of these work fine.

Robert Jordan

 

Virus-free. www.avast.com


johnfirr@...
 

Wow. Thanks all.
Sorry did not want to stir up controversy!. Clearly this mapping bit is potentially more complex than I thought. Having said that Lorna and Andrew your summary was correct my problem was the simple one of not realising you needed to click on the three little dots at the end. This has resolved the problem.

Robert thanks for the advice, I had seen your original thread before I posted but I think your issue was a little more complex as it involved redundant places? Mine was just down to sloppy data entry on my part ( I should clarify that I had more than one! and many where I had missed the country off meaning they showed up in all sorts of odd countries, who knew there was a Massachusetts in India?. I have nevertheless squirreled that particular thread in my evernote file for useful future reference.

Mike, what can I say? You have solved so many problems on here and certainly I have never received anything other than good advice, your time and attention is much appreciated.

So thanks to all, genuinely appreciate the time people put in on this thread to help those of us with database challenges.

I,m now going to be cheeky and ask a supplementary. The editing seems to have worked and I have checked back in individuals focus windows to confirm that changes I have made in the Places record list are reflected in the individuals Fact lists. The mapping also seems to have adjusted itself. But as its complicated I just want to check that if I edit or merge places does the geocoding for latitude etc adjust automatically or is there something I need to do to "recode" the list? I only ask because the conversation above shows me that the mapping function is perhaps more complicated than I might have thought?
regards
John


Lorna Craig
 

When you merge two Place records you choose which one is to be the  final merged record, and the geocoding in that record will remain unchanged.   When you edit the name of a record the geocoding remains unchanged.  If you then want to refresh the automatic geocoding, select the record(s) in the Records window and click Map>Map Location of Selected Place Records (or use Tools>Work with Data> Places, select them there then click View in Map>View in Map Window.)   Then, in the Map Window toolbar use Map>Geocoding>Refresh Geocoding.

 

By the way, in order to avoid accidentally refreshing the geocoding for a Place you have previously geocoded manually, it is recommended that you use Tools>Preferences>Map Window and set Mark Auto-geocodes as Tentative if...  to Always, and tick Block Refresh for Non-tentative Geocodes. 

 

Lorna

....I just want to check that if I edit or merge places does the geocoding for latitude etc adjust automatically or is there something I need to do to "recode" the list? I only ask because the conversation above shows me that the mapping function is perhaps more complicated than I might have thought?
regards
John

 


Mike Tate
 

The principles of merging any type of record are fundamentally the same, but depend on several factors.

 

If a particular field is allowed multiple instances, such as Notes or linked Media, then the Merge keeps all instances from both records.

 

If a particular field is only allowed one instance, such as Lat/Long geocoding, then the Merge applies some simple rules.

When only one of the two records has a value in that field, or the value in both records is the same, then that value is kept in the merged record.

It is only when both records have a different value in that field that a decision is needed.

Whichever record is chosen as the final or preferred record then its field value is kept by default, but that can be reversed in the Merge Record dialogue.

 

So when Lorna says for the final merged record the geocoding in that record will remain unchanged is not strictly correct.

If the preferred final record has no geocoding, but the other record does, then that other geocoding will be used by default, but can be manually overridden.

 

Mike Tate

 

From: family-historian@groups.io <family-historian@groups.io> On Behalf Of Lorna Craig via groups.io
Sent: 06 January 2021 13:50
To: family-historian@groups.io
Subject: Re: [family-historian] Editing Places in FH7

 

When you merge two Place records you choose which one is to be the  final merged record, and the geocoding in that record will remain unchanged.   When you edit the name of a record the geocoding remains unchanged.  If you then want to refresh the automatic geocoding, select the record(s) in the Records window and click Map>Map Location of Selected Place Records (or use Tools>Work with Data> Places, select them there then click View in Map>View in Map Window.)   Then, in the Map Window toolbar use Map>Geocoding>Refresh Geocoding.

 

By the way, in order to avoid accidentally refreshing the geocoding for a Place you have previously geocoded manually, it is recommended that you use Tools>Preferences>Map Window and set Mark Auto-geocodes as Tentative if...  to Always, and tick Block Refresh for Non-tentative Geocodes. 

 

Lorna

....I just want to check that if I edit or merge places does the geocoding for latitude etc adjust automatically or is there something I need to do to "recode" the list? I only ask because the conversation above shows me that the mapping function is perhaps more complicated than I might have thought?
regards
John

 


Lorna Craig
 

Mike is correct, of course, but he is thinking of performing the merge in the standard way which can be used for any record type, by selecting the records to be emerged in the Records window then using Edit>Merge/Compare Records.  On the other hand I was thinking of Using Tools>Work with Data>Places, where you can select the records to be merged and then click the Merge button.  In that case you only get to choose one whole record for the final version, and you cannot ‘pick and choose’ which parts are retained.  So if you do it that way the final record will have whatever geocoding was in the record you selected for the final version, even if it had none and one of the other records did have geocoding.

 

Lorna

From: Mike Tate
Sent: 06 January 2021 14:18
To: family-historian@groups.io
Subject: Re: [family-historian] Editing Places in FH7

 

The principles of merging any type of record are fundamentally the same, but depend on several factors.

 

If a particular field is allowed multiple instances, such as Notes or linked Media, then the Merge keeps all instances from both records.

 

If a particular field is only allowed one instance, such as Lat/Long geocoding, then the Merge applies some simple rules.

When only one of the two records has a value in that field, or the value in both records is the same, then that value is kept in the merged record.

It is only when both records have a different value in that field that a decision is needed.

Whichever record is chosen as the final or preferred record then its field value is kept by default, but that can be reversed in the Merge Record dialogue.

 

So when Lorna says for the final merged record the geocoding in that record will remain unchanged is not strictly correct.

If the preferred final record has no geocoding, but the other record does, then that other geocoding will be used by default, but can be manually overridden.

 

Mike Tate

 

From: family-historian@groups.io <family-historian@groups.io> On Behalf Of Lorna Craig via groups.io
Sent: 06 January 2021 13:50
To: family-historian@groups.io
Subject: Re: [family-historian] Editing Places in FH7

 

When you merge two Place records you choose which one is to be the  final merged record, and the geocoding in that record will remain unchanged.   When you edit the name of a record the geocoding remains unchanged.  If you then want to refresh the automatic geocoding, select the record(s) in the Records window and click Map>Map Location of Selected Place Records (or use Tools>Work with Data> Places, select them there then click View in Map>View in Map Window.)   Then, in the Map Window toolbar use Map>Geocoding>Refresh Geocoding.

 

By the way, in order to avoid accidentally refreshing the geocoding for a Place you have previously geocoded manually, it is recommended that you use Tools>Preferences>Map Window and set Mark Auto-geocodes as Tentative if...  to Always, and tick Block Refresh for Non-tentative Geocodes. 

 

Lorna

....I just want to check that if I edit or merge places does the geocoding for latitude etc adjust automatically or is there something I need to do to "recode" the list? I only ask because the conversation above shows me that the mapping function is perhaps more complicated than I might have thought?
regards
John

 

 


Mike Tate
 

You live and learn.

I had expected the Tools > Work with Data > Places Merge… would use the Edit > Merge/Compare Records default rules, but clearly not.

That is probably because the former allows multiple Place records to be Merged, whereas the latter only allows two.

 

The consequence is that only the chosen Place record is preserved. Any Media, Notes, Lat/Long, etc, in the other Place record(s) gets discarded.

So take more care when using the Tools > Work with Data > Places Merge… method.

 

Mike Tate

 

From: family-historian@groups.io <family-historian@groups.io> On Behalf Of Lorna Craig via groups.io
Sent: 06 January 2021 15:00
To: family-historian@groups.io
Subject: Re: [family-historian] Editing Places in FH7

 

Mike is correct, of course, but he is thinking of performing the merge in the standard way which can be used for any record type, by selecting the records to be emerged in the Records window then using Edit>Merge/Compare Records.  On the other hand I was thinking of Using Tools>Work with Data>Places, where you can select the records to be merged and then click the Merge button.  In that case you only get to choose one whole record for the final version, and you cannot ‘pick and choose’ which parts are retained.  So if you do it that way the final record will have whatever geocoding was in the record you selected for the final version, even if it had none and one of the other records did have geocoding.

 

Lorna

From: Mike Tate
Sent: 06 January 2021 14:18
To: family-historian@groups.io
Subject: Re: [family-historian] Editing Places in FH7

 

The principles of merging any type of record are fundamentally the same, but depend on several factors.

 

If a particular field is allowed multiple instances, such as Notes or linked Media, then the Merge keeps all instances from both records.

 

If a particular field is only allowed one instance, such as Lat/Long geocoding, then the Merge applies some simple rules.

When only one of the two records has a value in that field, or the value in both records is the same, then that value is kept in the merged record.

It is only when both records have a different value in that field that a decision is needed.

Whichever record is chosen as the final or preferred record then its field value is kept by default, but that can be reversed in the Merge Record dialogue.

 

So when Lorna says for the final merged record the geocoding in that record will remain unchanged is not strictly correct.

If the preferred final record has no geocoding, but the other record does, then that other geocoding will be used by default, but can be manually overridden.

 

Mike Tate

 

From: family-historian@groups.io <family-historian@groups.io> On Behalf Of Lorna Craig via groups.io
Sent: 06 January 2021 13:50
To: family-historian@groups.io
Subject: Re: [family-historian] Editing Places in FH7

 

When you merge two Place records you choose which one is to be the  final merged record, and the geocoding in that record will remain unchanged.   When you edit the name of a record the geocoding remains unchanged.  If you then want to refresh the automatic geocoding, select the record(s) in the Records window and click Map>Map Location of Selected Place Records (or use Tools>Work with Data> Places, select them there then click View in Map>View in Map Window.)   Then, in the Map Window toolbar use Map>Geocoding>Refresh Geocoding.

 

By the way, in order to avoid accidentally refreshing the geocoding for a Place you have previously geocoded manually, it is recommended that you use Tools>Preferences>Map Window and set Mark Auto-geocodes as Tentative if...  to Always, and tick Block Refresh for Non-tentative Geocodes. 

 

Lorna

....I just want to check that if I edit or merge places does the geocoding for latitude etc adjust automatically or is there something I need to do to "recode" the list? I only ask because the conversation above shows me that the mapping function is perhaps more complicated than I might have thought?
regards
John

 

 


Victor Markham
 

I would like to say one thing about this when it comes to places in Yorkshire. Always add East, North or West to the Yorkshire county name. I have no idea what happens with geo coding or even the revised boundaries which now includes South Yorkshire. Here are some examples are Scalby, North Yorkshire. There is Scalby, East Yorkshire. The first os North of Scarborough and the second next to Gilberdkye, West of Hull. Another example is Hessle, East Yorkshire and Hessle, West Yorkshire. The first is West of Hull and the second near Wakefield. There could be other similar names in Yorkshire. Would geo coding recognise the differences?

Would geo coding also recognise Sheffield, West Yorkshire or Sheffield, South Yorkshire (as it is today due to revised admin boundary changes). I prefer to stick to the original boundaries which in reality are still there butnot as admin boundaries.

Victor

On 06/01/2021 3:00 pm, Lorna Craig via groups.io wrote:

Mike is correct, of course, but he is thinking of performing the merge in the standard way which can be used for any record type, by selecting the records to be emerged in the Records window then using Edit>Merge/Compare Records.  On the other hand I was thinking of Using Tools>Work with Data>Places, where you can select the records to be merged and then click the Merge button.  In that case you only get to choose one whole record for the final version, and you cannot ‘pick and choose’ which parts are retained.  So if you do it that way the final record will have whatever geocoding was in the record you selected for the final version, even if it had none and one of the other records did have geocoding.

 

Lorna

From: Mike Tate
Sent: 06 January 2021 14:18
To: family-historian@groups.io
Subject: Re: [family-historian] Editing Places in FH7

 

The principles of merging any type of record are fundamentally the same, but depend on several factors.

 

If a particular field is allowed multiple instances, such as Notes or linked Media, then the Merge keeps all instances from both records.

 

If a particular field is only allowed one instance, such as Lat/Long geocoding, then the Merge applies some simple rules.

When only one of the two records has a value in that field, or the value in both records is the same, then that value is kept in the merged record.

It is only when both records have a different value in that field that a decision is needed.

Whichever record is chosen as the final or preferred record then its field value is kept by default, but that can be reversed in the Merge Record dialogue.

 

So when Lorna says for the final merged record the geocoding in that record will remain unchanged is not strictly correct.

If the preferred final record has no geocoding, but the other record does, then that other geocoding will be used by default, but can be manually overridden.

 

Mike Tate

 

From: family-historian@groups.io <family-historian@groups.io> On Behalf Of Lorna Craig via groups.io
Sent: 06 January 2021 13:50
To: family-historian@groups.io
Subject: Re: [family-historian] Editing Places in FH7

 

When you merge two Place records you choose which one is to be the  final merged record, and the geocoding in that record will remain unchanged.   When you edit the name of a record the geocoding remains unchanged.  If you then want to refresh the automatic geocoding, select the record(s) in the Records window and click Map>Map Location of Selected Place Records (or use Tools>Work with Data> Places, select them there then click View in Map>View in Map Window.)   Then, in the Map Window toolbar use Map>Geocoding>Refresh Geocoding.

 

By the way, in order to avoid accidentally refreshing the geocoding for a Place you have previously geocoded manually, it is recommended that you use Tools>Preferences>Map Window and set Mark Auto-geocodes as Tentative if...  to Always, and tick Block Refresh for Non-tentative Geocodes. 

 

Lorna

....I just want to check that if I edit or merge places does the geocoding for latitude etc adjust automatically or is there something I need to do to "recode" the list? I only ask because the conversation above shows me that the mapping function is perhaps more complicated than I might have thought?
regards
John

 

 


Neil Grantham
 

I don't know the answer about geocoding, but I use the boundaries in place at the time of the event.

EG, I was born in Coventry, which was Warwickshire at the time, and recorded as such in FH. My children's births are recorded as Coventry, West Midlands.

I haven't made much use of the map to see what FH makes of it.


Best Wishes


Neil.





------ Original Message ------
From: "Victor Markham via groups.io" <victor@...>
To: family-historian@groups.io
Sent: Wednesday, 6 Jan, 2021 At 15:29
Subject: Re: [family-historian] Editing Places in FH7

I would like to say one thing about this when it comes to places in Yorkshire. Always add East, North or West to the Yorkshire county name. I have no idea what happens with geo coding or even the revised boundaries which now includes South Yorkshire. Here are some examples are Scalby, North Yorkshire. There is Scalby, East Yorkshire. The first os North of Scarborough and the second next to Gilberdkye, West of Hull. Another example is Hessle, East Yorkshire and Hessle, West Yorkshire. The first is West of Hull and the second near Wakefield. There could be other similar names in Yorkshire. Would geo coding recognise the differences?

Would geo coding also recognise Sheffield, West Yorkshire or Sheffield, South Yorkshire (as it is today due to revised admin boundary changes). I prefer to stick to the original boundaries which in reality are still there butnot as admin boundaries.

Victor

On 06/01/2021 3:00 pm, Lorna Craig via groups.io wrote:

Mike is correct, of course, but he is thinking of performing the merge in the standard way which can be used for any record type, by selecting the records to be emerged in the Records window then using Edit>Merge/Compare Records. On the other hand I was thinking of Using Tools>Work with Data>Places, where you can select the records to be merged and then click the Merge button. In that case you only get to choose one whole record for the final version, and you cannot ‘pick and choose’ which parts are retained. So if you do it that way the final record will have whatever geocoding was in the record you selected for the final version, even if it had none and one of the other records did have geocoding.

Lorna

From: Mike Tate
Sent: 06 January 2021 14:18
To: family-historian@groups.io
Subject: Re: [family-historian] Editing Places in FH7

The principles of merging any type of record are fundamentally the same, but depend on several factors.

If a particular field is allowed multiple instances, such as Notes or linked Media, then the Merge keeps all instances from both records.

If a particular field is only allowed one instance, such as Lat/Long geocoding, then the Merge applies some simple rules.

When only one of the two records has a value in that field, or the value in both records is the same, then that value is kept in the merged record.

It is only when both records have a different value in that field that a decision is needed.

Whichever record is chosen as the final or preferred record then its field value is kept by default, but that can be reversed in the Merge Record dialogue.

So when Lorna says for the final merged record the geocoding in that record will remain unchanged is not strictly correct.

If the preferred final record has no geocoding, but the other record does, then that other geocoding will be used by default, but can be manually overridden.

Mike Tate

From: family-historian@groups.io <family-historian@groups.io> On Behalf Of Lorna Craig via groups.io
Sent: 06 January 2021 13:50
To: family-historian@groups.io
Subject: Re: [family-historian] Editing Places in FH7

When you merge two Place records you choose which one is to be the final merged record, and the geocoding in that record will remain unchanged. When you edit the name of a record the geocoding remains unchanged. If you then want to refresh the automatic geocoding, select the record(s) in the Records window and click Map>Map Location of Selected Place Records (or use Tools>Work with Data> Places, select them there then click View in Map>View in Map Window.) Then, in the Map Window toolbar use Map>Geocoding>Refresh Geocoding.

By the way, in order to avoid accidentally refreshing the geocoding for a Place you have previously geocoded manually, it is recommended that you use Tools>Preferences>Map Window and set Mark Auto-geocodes as Tentative if... to Always, and tick Block Refresh for Non-tentative Geocodes.

Lorna

....I just want to check that if I edit or merge places does the geocoding for latitude etc adjust automatically or is there something I need to do to "recode" the list? I only ask because the conversation above shows me that the mapping function is perhaps more complicated than I might have thought?
regards
John


--
Neil Grantham
-------------------
Using FH 7 & AS 7
Researching Grantham, Skuce, Barrow, Birchall.


Lorna Craig
 

The mapping function uses modern place/county names, so when you record a place with its historic name it is advisable to use the Standardized field in the Place record to inlcude the modern name.  The standardized field will then be used for geocoding, but the historic name will be displayed.   Coventry, Warwickshire, England and Coventry, West Midlands, England initially display in slightly different places (the pin for the former is placed roughly in the middle of the county of Warwickshire).  But if you enter Coventry, West Midlands in the standardized field for Coventry, Warwickshire and then refresh the geocoding you will see the pin jump to the centre of Coventry.


On 06/01/2021 15:43, Neil Grantham via groups.io wrote:
I don't know the answer about geocoding, but I use the boundaries in place at the time of the event.

EG, I was born in Coventry, which was Warwickshire at the time, and recorded as such in FH. My children's births are recorded as Coventry, West Midlands.

I haven't made much use of the map to see what FH makes of it.


Best Wishes


Neil.



------ Original Message ------ From: "Victor Markham via groups.io" <victor@...> To: family-historian@groups.io Sent: Wednesday, 6 Jan, 2021 At 15:29 Subject: Re: [family-historian] Editing Places in FH7

I would like to say one thing about this when it comes to places in Yorkshire. Always add East, North or West to the Yorkshire county name. I have no idea what happens with geo coding or even the revised boundaries which now includes South Yorkshire. Here are some examples are Scalby, North Yorkshire. There is Scalby, East Yorkshire. The first os North of Scarborough and the second next to Gilberdkye, West of Hull. Another example is Hessle, East Yorkshire and Hessle, West Yorkshire. The first is West of Hull and the second near Wakefield. There could be other similar names in Yorkshire. Would geo coding recognise the differences?

Would geo coding also recognise Sheffield, West Yorkshire or Sheffield, South Yorkshire (as it is today due to revised admin boundary changes). I prefer to stick to the original boundaries which in reality are still there butnot as admin boundaries.

Victor



Mike Tate
 

I am not sure about the FH Map Window geocoding but my Map Life Facts plugin removes North, South, East, West & Riding from Yorkshire as it usually geocodes more reliably in Google Maps. However, if there are multiple similar place names then they may need manually correcting.

Don’t forget that you can also help the geocoder by entering the modern place name in the Standardized field while keeping the original historic name in the main Place name field.

Mike Tate

 

From: family-historian@groups.io <family-historian@groups.io> On Behalf Of Victor Markham via groups.io
Sent: 06 January 2021 15:30
To: family-historian@groups.io
Subject: Re: [family-historian] Editing Places in FH7

 

I would like to say one thing about this when it comes to places in Yorkshire. Always add East, North or West to the Yorkshire county name. I have no idea what happens with geo coding or even the revised boundaries which now includes South Yorkshire. Here are some examples are Scalby, North Yorkshire. There is Scalby, East Yorkshire. The first os North of Scarborough and the second next to Gilberdkye, West of Hull. Another example is Hessle, East Yorkshire and Hessle, West Yorkshire. The first is West of Hull and the second near Wakefield. There could be other similar names in Yorkshire. Would geo coding recognise the differences?

Would geo coding also recognise Sheffield, West Yorkshire or Sheffield, South Yorkshire (as it is today due to revised admin boundary changes). I prefer to stick to the original boundaries which in reality are still there butnot as admin boundaries.

Victor

On 06/01/2021 3:00 pm, Lorna Craig via groups.io wrote:

Mike is correct, of course, but he is thinking of performing the merge in the standard way which can be used for any record type, by selecting the records to be emerged in the Records window then using Edit>Merge/Compare Records.  On the other hand I was thinking of Using Tools>Work with Data>Places, where you can select the records to be merged and then click the Merge button.  In that case you only get to choose one whole record for the final version, and you cannot ‘pick and choose’ which parts are retained.  So if you do it that way the final record will have whatever geocoding was in the record you selected for the final version, even if it had none and one of the other records did have geocoding.

 

Lorna

From: Mike Tate
Sent: 06 January 2021 14:18
To: family-historian@groups.io
Subject: Re: [family-historian] Editing Places in FH7

 

The principles of merging any type of record are fundamentally the same, but depend on several factors.

 

If a particular field is allowed multiple instances, such as Notes or linked Media, then the Merge keeps all instances from both records.

 

If a particular field is only allowed one instance, such as Lat/Long geocoding, then the Merge applies some simple rules.

When only one of the two records has a value in that field, or the value in both records is the same, then that value is kept in the merged record.

It is only when both records have a different value in that field that a decision is needed.

Whichever record is chosen as the final or preferred record then its field value is kept by default, but that can be reversed in the Merge Record dialogue.

 

So when Lorna says for the final merged record the geocoding in that record will remain unchanged is not strictly correct.

If the preferred final record has no geocoding, but the other record does, then that other geocoding will be used by default, but can be manually overridden.

 

Mike Tate

 

From: family-historian@groups.io <family-historian@groups.io> On Behalf Of Lorna Craig via groups.io
Sent: 06 January 2021 13:50
To: family-historian@groups.io
Subject: Re: [family-historian] Editing Places in FH7

 

When you merge two Place records you choose which one is to be the  final merged record, and the geocoding in that record will remain unchanged.   When you edit the name of a record the geocoding remains unchanged.  If you then want to refresh the automatic geocoding, select the record(s) in the Records window and click Map>Map Location of Selected Place Records (or use Tools>Work with Data> Places, select them there then click View in Map>View in Map Window.)   Then, in the Map Window toolbar use Map>Geocoding>Refresh Geocoding.

 

By the way, in order to avoid accidentally refreshing the geocoding for a Place you have previously geocoded manually, it is recommended that you use Tools>Preferences>Map Window and set Mark Auto-geocodes as Tentative if...  to Always, and tick Block Refresh for Non-tentative Geocodes. 

 

Lorna

....I just want to check that if I edit or merge places does the geocoding for latitude etc adjust automatically or is there something I need to do to "recode" the list? I only ask because the conversation above shows me that the mapping function is perhaps more complicated than I might have thought?
regards
John

 

 


Adrian Bruce
 

On Wed, 6 Jan 2021 at 16:00, Lorna Craig via groups.io
<l.m.craig=ntlworld.com@groups.io> wrote:

The mapping function uses modern place/county names, so when you record a place with its historic name it is advisable to use the Standardized field in the Place record to include the modern name. ...
This is particularly useful if, like me, you insist that there was no
such country as Australia before 1 January 1901 and terminate such
place-names with the appropriate colony-name. Originally I didn't have
the Standardized value set, didn't check the geo-coding (not sure
which geocoding mechanism I was using) and eventually discovered that
my (Ozzie) places ending in "Victoria" had geocoded to match Victoria
in British Columbia, Canada. Err - not quite where I wanted them to
map to!

Adrian


johnfirr@...
 

Thanks all.
A lot to take in. This thread is definitely going in the "useful for later reference file".
regards
John Firr