* Find and Replace Places

[RogerF]

This isn't a 6.1.1 issue -- it dates from 6.0 -- and forgive me if it has been discussed before. However...

I'm unhappy about the behaviour of Find and Replace where Place records are concerned. I have, for example, a Place record "London (Barnet), LND" which is referenced by four Individual records. I decide to globally change the Place to "London (Barnet), MDX". The four Individual records are changed; so far so good. But, a new Place record is created (with four links), the old Place record remains (with no links), and no data is transferred from the original "LND" Place record to the new "MDX" Place record. So basically the global change hasn't worked properly. This can't be right?

[tatewise]

@Roger: It is 'right' from one perspective. The replacements can be selectively confirmed, so FH does not initially know how many Place names will be replaced, and how many will remain unchanged. The replaced ones become linked to the new Place record (which may or may not already exist), while the unchanged ones remain linked to the old Place record. This is exactly what would happen if you went through manually changing the Place names one by one.

If you want to simply modify an existing Place name, then either use Tools > Work with Data > Places > Edit, or open the Place record itself via say the Records Window > Places tab and change it there. Both methods will retain all other record details.

Place names & Place records have unique properties because unlike other records they are linked by Name and not Record Id, so need careful handling.

This is one reason why the Find and Replace dialog need a Help page to explain such effects.

BTW: My Search and Replace Plugin has similar effects but its Help & Advice explains how to handle Place names.

[RogerF]

Yes, Mike, but it isn't intuitive. You shouldn't need to think "ah, Places names, bet that's a special case" when doing a Find & Replace. If FH has to create a new Place record, so be it, but surely it can clone that new record from the one it's replacing?

[tatewise]

I agree it is not intuitive.
But how can FH know that new Place record should be a clone of old Place record?
It may be a very different place, that should not borrow Lat/Long, Media, or Notes from old Place.

It is a consequence of the decision to link Place records by Name instead of Record Id.
The solutions hinge on whether you are making selective or global changes.

Perhaps the Find and Replace dialog should raise dire warnings of the consequences on Place records when its Places option remains ticked, and advise that other methods should be used for global changes?

[RogerF]

But how can FH know that new Place record should be a clone of old Place record?
It may be a very different place, that should not borrow Lat/Long, Media, or Notes from old Place.

FH can't know that a clone is required. But, it's a very reasonable assumption; if wrong, the user can change it. That's certainly a whole load better than creating a new record without borrowing Lat/Long, Media, or Notes from old Place.

[tatewise]

I have split this off from the New Pre-release: 6.1.1 (13233) thread.

Perhaps report the issues and options to Calico Pie via http://www.family-historian.co.uk/suppo ... t-overview + Contact Support.

Even with that clone method, the user still needs to be informed that has happened, otherwise they don't know to go and check the new record contents.

[AdrianBruce]

I have to say that this is probably a case of six of one and half-a-dozen of the other. If Find-And-Replace really were a total Find-And-Replace, then the original Place record would be (effectively) deleted and replaced by its clone with the new name. Yet we have had this discussion before - if I wrote the history of pre-Union of South Africa Cape Town against the "Cape Town, Cape Colony" record, intending to write the post-Union history against the "Cape Town, Cape Province, South Africa" record (or whatever the names are) then I really don't want that pre-Union history to appear against the post-Union place record. So I'd probably "correct" the situation by renaming the Place record back to the original - which would revert all occurrences of that place-name in the individual facts, etc, taking us back to where we started!

Now, that's not quite the situation here but it does illustrate that the question "What do you mean by Find-And-Replace?" doesn't have a single answer across everyone. Or, one person's intuition isn't necessarily another person's....

To be perhaps unhelpful because I'm just describing my personal behaviour, if I wanted to totally globally change "London (Barnet), LND" to "London (Barnet), MDX" (i.e. change the Place-Record as well), I'd change the name in the Place Record - that's one change, end-of-story.

Using Find-and-Replace, so far as I can see, doesn't actually touch the Place records - or at least, it never offered a confirmation to indicate that it was going anywhere near the Place records. The effect on the Place records, I suggest, derives solely from the routines to keep the Place-records straight with the individual and family records.

Right now, I can't decide what the intuitive behaviour should be. I only know this is a brain-ache of a problem that comes up whenever someone wants to amend the contents of a key somewhere. Does that apply to the (pointer) value on the data record and the value on the keyed record, or...????

[AdrianBruce]

Probably far too late to be thinking about this. But it occurs to me that there is an assumption in the original post that a find and replace of a location name is providing an alternative name for the same place. Whereas it might be a totally different place.

For instance, one sort of a find and replace is same-place-different-name, as per the original post. Another might be different-place - such as discovering a bunch of guys didn't die on a battle field but in a PoW camp miles away. The defaults and dialogues need to tease out which case it is. Not trivial. Especially when you consider that many FH users never go near the place records, relying on the automatic updates.

[DavidNewton]

This isn't a 6.1.1 issue -- it dates from 6.0 -- and forgive me if it has been discussed before. However...

I'm unhappy about the behaviour of Find and Replace where Place records are concerned. I have, for example, a Place record "London (Barnet), LND" which is referenced by four Individual records. I decide to globally change the Place to "London (Barnet), MDX". The four Individual records are changed; so far so good. But, a new Place record is created (with four links), the old Place record remains (with no links), and no data is transferred from the original "LND" Place record to the new "MDX" Place record. So basically the global change hasn't worked properly. This can't be right?

Although not intuitive if we are talking about an individual change such as that in your example the next step I would take would be to merge the two place records which allows you to select which pieces of data should remain in the final record.

David

[AdrianBruce]

... the next step I would take would be to merge the two place records ...

Hmm. Not sure that's particularly intuitive! (Though I don't think you're claiming it is!)

It's not intuitive because the intuition, I suggest, is that one record for the place should cover all the "names" for that place over history. Thus the record for Widnes should include the dated names "Widnes, Lancashire", "Widnes, Cheshire", and "Widnes, Halton District". Though there's no way I'm suggesting that's what the software should do. Apart from anything, what would a report show for someone who live all their life in Widnes from 1930 to 2015 and therefore covered all 3 names in one residence event? Ouch.

For me, the intuitive way to change a place-name is to make one change, which is to the place-name record. And if I wanted to change just some (like backdating some, but not all, "Cape Province, South Africa" references to "Cape Colony") then I'd start from Tools / Work with Data / Places". I'd go for that because the place-name is a key and specialist tools always work better on keys than the basic text editing of Find & Replace.

Please understand I'm not claiming this is the only intuitive way to do it. I'm saying this (a) to illustrate that designing solutions isn't easy and (b) in the hope that someone might find my ideas useful.

[RogerF]

I was perhaps over-specific in my original message. "London (Barnet), LND" was just one example of about 100 Place names changes I was attempting -- the actual Find & Replace was "), LND" to "), MDX". 100 Place names was why I didn't simply edit the Place record -- I was aiming for a short-cut. And the issue with Merging the two records afterwards is that one has the correct name, while the other has the correct Lat/Long, so each Merge requires a Retain and a Discard to bring the right pieces together -- far too much of a faff for 100 Merges.

As for Tools > Work with Data > Places... sorry, that just isn't on my radar (as I remember saying to Lorna when she suggested it as a solution to another Places issue many months ago). As I suggested earlier, intuitively, Find & Replace (or the Search & Replace plugin) are the tools that I have at hand.

[tatewise]

But changing the name in the Place record is the shortcut.

In the same way as changing the name of an Individual or Source or Media record.

Unfortunately, the analogy is not perfect because Place records are keyed by Name rather than Rec Id, and it relies on the knowledge that Place records exist.

[AdrianBruce]

... the actual Find & Replace was "), LND" to "), MDX". ....

Oh. That is rather different! Ironically, if you'd just used Notepad++ or similar, you would have, I'm sure, have got the desired result.

Explaining rather than excusing, because Place-records are designed to reflect what's in the data automatically, I believe that the first event record that got changed from LND to MDX would have created the MDX record. Hence, once you'd finished doing the individuals and families and the Find & Replace came to look at the Place records, altering the LND place to MDX would have resulted in a duplication. So I suspect that the Find & Replace is coded to never edit the keys of Place records. Which it ought to warn about.... Somehow...

[davidm_uk]

I think it's very subjective.

If for example I wanted to correct the spelling of a "place" (I use "place" because it's actually a set of place fields), the natural and obvious (for me) way to do it is via Tools > Work with Data > Places... because I can just change it once. Why would I want to find all the different entries for it in the gedcom.

If I wanted to change the "place" for only a particular set of facts, for example the same village name exists in two different counties and I'd got some individuals in the wrong place, or I wanted to show Barnet as either Middlesex or Hertfordshire depending on the date for the fact, then that's a whole different ballgame.