* Changing place names

[RogerF]

It seems to me that the whole business of renaming a place is more complex than it ought to be. For a start, I couldn't find anything about it in the Help. Then, the only method I could discover to achieve this is to find an Individual record using the old place name, modify that record to use the new place name, and then merge the other old place names into the new name. If this indeed is the only method, then it's cumbersome and non-intuitive. If there's a better method, then it's well-hidden. I think that there ought to be a one-step way of doing this.

Background: I had used "Carnarvon, CAE" as the location for several census and BMDs. When trying to map this, I found that a better name would have been "Caernarfon, CAE". Making that change was much harder than it should have been.

[LornaCraig]

To edit a Place name, use Tools>Work with Data>Places. Select the Place name from the list and click Edit on the Right hand side. In View/Edit Place details you then need to double-click the name field or click the box with 3 dots at the end of the name field to open the Edit Place Name dialog. (You cannot edit the name direct in the place name field without opening this dialog, because it needs to check that another Place record does not already exist with exactly the same name. Unlike other types of record, no two Place records can have exactly the same name.)

Alternatively, open the Place record Property box from the Records window, and click in the name field there to open the Edit Place Name dialog.

See this entry in the Help files:

[tatewise]

If you need to make more complex Place name changes, such as replacing Carnarvon with Caernarfon in multiple different Place records, then use the Search and Replace Plugin.

Its Help & Advice has a Usage Examples page with specfic help on this topic.

[RogerF]

Lorna:
Thanks for your detailed reply. I somehow never need to use Tools>Work with Data, so for me that's not an intuitive place to look for assistance. And on your other answer, I've not come across anywhere else in FH where a field isn't editable in situ, but is after clicking on the three dots. Maybe I've just lead a sheltered life [...].

Mike:
Yes, of course S & R is another approach. It just isn't the right one for the circumstance I'm describing.

Either way, the Help seems to me to be deficient in this area.

[AdrianBruce]

Coming at it from a different angle - isn't this a case for going to the Place Record (v6 on only) and entering a "Standardized" value of "Caernarfon, CAE" against the "Carnarvon, CAE" references?

Caveat 1 - I've not done this myself yet, so I'm just suggesting this from the help file.
Caveat 2 - The efficacy of this exact method will depend on which method you do your mapping from.

My logic for suggesting this is that I get keen on applying contemporary names and the Victorians called the place "Carnarvon". Not to mention that it wasn't always in Caernarfonshire - however that's spelt!

[Gowermick]

I've come to this post a bit late, and can only agree with Original Poster, Roger! Use and editing of placenames needs some serious work doing on it.

Being new to FH, I was going through the process of Geocoding all the places in my tree. When I came across a typo in one of the places, but when I tried to correct it, via the proerty box, the placename field was greyed out and was uneditable. I then went to the one person linked to the place, and corrected the place entry there. (Finding this person was not simple, but this can be left for another day)

So far so good, the corrected place was now listed in the list of places. However, the mis-spelt name was there too, now showing no links associated. Thinking this was a leftover from the Marker set, I deleted the set and re-marked them. The mis-spelt place was still there - but where did it come from? It was no longer linked to any individual, so why does 'mapping places' show it, and more importantly, why is there no means of deleting it!

Merging the place with another gets rid of the unwanted place, but is hardly intuitive and far from best practice!

[tatewise]

One of the easiest way to edit Place details is via the Places tab of the Records Window. (The equivalent tabs for other record types are also often a good option.)

To delete any record, select it and click the Delete key on the keyboard.
That is covered on Page 74 of Getting the Most From FH 5.

To edit a Place: name, click the [...] edit button to the right of the box.

To find the owning record linked to any record, first select the record, then use View > Record Links.

[Gowermick]

Mike,
Perhaps I'm being picky, but when you open a context window (by right clicking), one of the more common Windows standards is to have the 'Delete/Rename' function shown as an option, where this is appropriate. Surely when looking at a list of places, the same Delete/Rename could have been made available at the click of a button, or failing that, the Map Window should at least have a 'Delete' button available on toolbar! (If the 'Del' key works, it is a simple bit of programming to add Context Menu 'Delete' or a Delete toolbar button to mimic the 'Del' keypress)

Likewise when viewing place properties, the property box open with the placename highlighted, which usually indicates it is ready for editing. I would not have expected to have to click on the ... button to edit it, surely an unnecesary step. The same checks can be carried out on the modified name, whether it is edited in-situ or via the ... button!

Perhaps these are things that ought to addressed by Calico Pie as a possible feature request.

Do you know why the mis-spelt name still appears in the Map Places list, when it is no longer being used?

Thanks

Mike

[AdrianBruce]

... It was no longer linked to any individual, so why does 'mapping places' show it ...

Reading this, I got interested (sometimes not a good idea!) and checked my Places tab in the Records window, to see if I had any unused Places (just alt-click the Links column to put the lowest numbers at the top).

Indeed, I did have a Place in there (Dysart, Fife) and no clue on screen why it was unused. However, just doing a general search of all text in all records reminded me that I had recently updated the birthplace for my G-GF's (allegedly wicked) stepmother. I'd altered her birthplace from Dysart to Gallatown, a village in the parish of Dysart.

Now, my immediate reaction was like Gowermick's, to ask why it still existed as a place, in the Place-tab, even though no person or family used it. Surely it should be auto-deleted? Except another few seconds' thought made me ask - what if I'd put notes in the Dysart record on the Place tab? I'd be a bit annoyed if that held the only text that Gallatown was in Dysart parish and it got deleted just because no-one used it as a Place in a fact.

So clearly auto-deletion of a Place if it's not used in a fact isn't a good idea - but neither is leaving unused stuff around like a fossil. I wonder if a message along the lines of "Dysart is no longer used as a Place - do you wish to delete it?" might help? I'm not wholly convinced as it could disrupt my thought flow which, especially in the case of a revamp of data, like here, is likely to get involved and should not be interrupted.

Could there be (and this is a bigger job) a scratch pad of messages about anomalies, etc., to be read and discarded or fixed at leisure?

[tatewise]

The auto-deletion of unused Place records was the initial implementation in FH V6 Beta testing, but for exactly the reasons Adrian gives that was changed. In fact no records are deleted just because they have no links, with the one exception of empty Family records with no parent/child links.

My Plugin Show Project Statistics probably covers most anomalies, which can be fixed as and when necessary, but does not currently report records with no links, although that could quite easily be added.

In the Records Window and elsewhere, when a record is selected, there is the Edit > X Delete command (the Del key is just a shortcut).

I think the reasoning behind the way the Place field is edited is to be consistent in all its contexts.
As you found, changing the Place field directly in the Individual Property Box creates a new Place record.
To change the name in the Place record itself requires the use of the [...] button.

However, I agree there should be the X Delete command in the Map Window, and possibly some improvement to the way Place names are changed. I think Calico Pie are damned if they do and damned if they don't. If every time you edit a Place field, there is a popup asking if you want to create a new Place record or edit the existing Place record, then many users will complain about the extra clicks needed. Whereas the current design requires you to know the two methods of editing the field or using the [...] button, which catches out newcomers.

Report the Map Window missing record Edit > X Delete command directly to support@family-historian.co.uk

[AdrianBruce]

... To change the name in the Place record itself requires the use of the [...] button.

However, I agree there should be ... possibly some improvement to the way Place names are changed. ...

Yes, it's a bit odd. If you start with the Places tab in the Records window, then bring up the Property Window for a Place record, you need, as you say, to use the [...] button to edit the name. But it's the only Property Window to require such usage. (There is an optional more... button for an individual's name but it's not obligatory.) And of course, all you get after pressing the [...] button for the place name is a box that looks identical to the one you can't edit!

Oddity part 2 is that you can get to all the Place data via Tools / Work with data / Places... Now, I can see why the Place List window is different from the Places tab, because it's got a load of tool buttons. But when you view / edit a place from the Place List window, you get a facility that does the same job as the Property Window for a Place record - but it's a different window. Strikes me that Calico could save themselves a bit of future maintenance work by using the same window.

[tatewise]

The reason the Place field is different from every other type of linked record is that they are the only records linked by Name and NOT by Record Id. You can change the Name/Title of other records without affecting the link, because you cannot easily edit the Record Id. With Place fields it is necessary to know whether you want to change its Place Name or create a new Place Record.

The Place List dialogue is very similar to the Places tab Property Box and exhibits exactly the same greyed-out Place field behaviour with the [...] edit button. As I said, the Place field in the Place record is designed to work in the same way as the Place field in say Facts, but since you cannot create a new record from an existing Place recod its name is greyed-out in that context.

What the Place List dialogue does lack is an All tab, sometimes needed to sort out UDF, etc, and a Notes tab to handle multiple instances of local Notes.

[AdrianBruce]

Thank you Mike - even though I'd looked at the GEDCOM for ordinary facts in v.6, I'd never made the step to realising that the link to a Place record (or its Primary Key) is the literal name. Now you've said that, much of the Place name behaviour becomes obvious to me (which doesn't mean it should be obvious to anyone else - it just happens to now be a mental model I already have).

(I just tried to guess how much code Calico would have needed to change if the Place Record link had been made into an arbitrary record-id like Individuals, etc., and getting the name from the Place Record. It doesn't bear thinking about!)

This may even explain the clunky behaviour of needing to press the [...] edit button to get to a box identical to the one you just left. If the [...] edit button is on a standard form for all record types, editing the place name in place would just alter the name on the record, i.e. the Place record, not throughout the GEDCOM file. Locking that one item on the Place record is probably the easiest way to get to a form designed to access the Place name wherever it is. Still clunky - I just find it easier to understand....

[tatewise]

Like you, I would have preferred Record Id links to Place records.

I think the reason Calico Pie did not use Record Id, is that it leaves Place names in the Place field in Facts, etc, so that when the GEDCOM is exported to another program the non-standard Place records can be ignored by that other program, but the GEDCOM Place names are still present.

[LornaCraig]

Like you, I would have preferred Record Id links to Place records.

I think a link based on Record ID would be very hazardous for the user, if it left open the possibility of having two Place records with exactly the same name. It would still be necessary to distinguish Place records by name rather than ID number.

If it were possible to have two Place records with identical names this could lead to different information being attached to the two records without the user realising it. Media might be attached to one record and a note added to the other. Neither would contain all the information about the place.

It is possible for two individuals to have the same name and date and place of birth. Therefore they can be distinguished by Record ID. But it is not possible for two places to have exactly the same name and coordinates, because then by definition they are the same place. As it says in the extract from the Help files that I attached to my post which is second in this thread, Place records are effectively identified by place name, so these must be unique.

[tatewise]

The same argument could be made for other record types such as Source, Repository, and Media.

Even two Individual records with the same Name can turn out actually be duplicates.

Conversely, tiny differences in a record Name will result in two records that the user may not notice (e.g. Westward Ho!, Devon and Westward Ho, Devon). So it is really up to the user to manage duplicates or near duplicates, although FH could be more pro-active, as many have requested, in alerting the user to duplicates of all types of record.

The auto-completion of Place (and Address) fields mitigates against accidental duplication of Place records whether linked by Name or Record Id.

[LornaCraig]

The auto-completion of Place (and Address) fields mitigates against accidental duplication of Place records whether linked by Name or Record Id.

I had thought about that. Auto-completion would mitigate against the creation of two identical Place names while entering data in a place field. But if there were already two existing records with identical names (for example, as a result of direct editing of a Place record to change its name) how would FH know which one to offer for auto-completion? Even if FH consistently offered the same one, the other would still exist and might have a note or media attached.

I agree that ultimately it is up to the user to manage duplicates, but FH does help do this for Place records under the existing system. It doesn't help decide whether two Places with very similar names should be the same, but it does prevent having two Places with identical names.

(I take your point that the same argument could be made for Source, Repository and Media records).

[tatewise]

Firstly, FH could easily prevent duplicate Place Name records exactly as it does now, but still use Record Id links. Presumably FH has a complete indexed list of Place Names in memory in order to provide auto-complete.

Alternatively, if duplicates were allowed, the auto-complete logic could detect them and popup a message to allow a choice and also alert the user to the duplicates. This is what I mean by FH being more pro-active in handling duplicates., which could be improved for all record types. After all it is only software ~ almost anything is possible!

[LornaCraig]

After all it is only software ~ almost anything is possible!

Agreed.

[craigmollekin]

I've just merged three Gedcoms which resulted in 15,000 place records. Trying to tidy up the redundant places was a nightmare as I couldn't see the wood for the trees for all the places with 0 records attached. I couldn't delete them but I merged them away. I selected all the zero entry places and then merged them into one record called 'DELETE'! Then I merged 'DELETE' into an insignificant place record. That's the only way I could get rid of them. Not perfect but the result is

[LornaCraig]

Craig,

Deleting Place records is no different from deleting records of any other type. To delete a single record, simply select it in the Records window and hit the delete key (or use Edit > X Delete). To delete multiple records, add them to a named list using Edit > Add to Named List, and then select the list and use Lists > Delete Named List Records to delete all the records in the list.

(However I admire your ingenious alternative!)

[craigmollekin]

Sadly, hitting the delete key does not work for me (or for the people posting before me?).

[davidm_uk]

For single Place records the Delete key (the one in the Insert/Home/PageUp etc cluster) works fine for me, but NOT the Del key on the numeric pad. Edit > X Delete also works ok.

[craigmollekin]

Ah.....I was pressing the delete key on the numeric pad

[davidm_uk]

Perhaps Calico Pie should change the Edit menu to show Delete rather than Del on the Edit Menu, to avoid any confusion.