Gramps 6.0.8, Fedora Linux 44 under KDE Plasma Desktop
Some places appear duplicated in Places tab of NarrativeWeb, e.g.:
(look at Dingy-Saint-Clair and Doussard)
Duplicated entries point onto the same place description page (hash inside the link is the same when you hover over the name).
Duplication seems to happen randomly. It does not seem to be related to Enclosed by feature, not to Alternate Names (places in the screenshot have none). The number of duplications is itself a mystery. It is not correlated to the number of references
I tried to look at the code (gramps/gramps/plugins/webreport/place.py) to see how the list is generated but I gave up quickly as it requires deep knowledge of the Report class.
Perhaps @SNoiraud could give me some clue.
Another issue occurs with alternate names. I expect them to be listed, pointing onto the same description page. I don’t find them all. It is likely the reason is these alternate names are not referenced by events. But this is a bit confusing because a place is mainly known by its modern name and having only the used “outdated” name in the list can make it difficult to find requested data.
The place list is created in narrativeweb.py. You have the _add_place method which creates the place list.
are you sure you have no duplicates ?
I confirm there are no duplicates in Places list view of Gramps. I also checked directly in the DB with an SQLite “sniffer”.
Isee there are two dicts related to places:
obj_dict[Place][…] indexed by place_handle, thus guaranteeing unicity, providing a list of “properties”obj_dict[PlaceName][…] indexed with the current name + grampsId, registering all names with a link to an item in the previous dict
But I am confused by the presence of event in the stored list. What is the role of this element? When a place is met several times (which is expected), event is overwritten and only the last seen is available.
The index is built by method placelistpage(…) in place.py by traversing obj_dict[PlaceName]. Each item is added as a list (p_name, [(handle, place_name)]).
Comments in addRecord(…) says that duplicates are allowed. Consequently, if there are, they come from obj_dict[PlaceName] and I don’t see how this is possible unless the computed p_name is different. But if names are different, how can they be printed the same (I checked there are no spaces)? Duplicated names don’t use alternate spellings not language.
Any idea? Even like adding debugging print.
Can you send me a small example of your database reproducing the problem ?
I am trying to “extract” from my live database but it is really huge. Deleting people, leaving places untouched, causes errors “handle does not exist” when generating NarrativeWeb.
I tried another approach.
I added debugging prints in method _add_place to dump the access key into obj_dict[PlaceName]. This key is place_name+:+gramp_id.
place_name is the expansion of the “enclosed by” structure.
In the debugging output, I get as many different place_names as duplications in the report, i.e. the “expansions” must be used somewhere to be listed. This means duplication is not systematic; it must be referenced to be listed. However, in the places list, only the first component of the expansion is shown (hamlet, village/town, etc.) is shown, giving the illusion of duplicates.
So, unless the access key mentioned above is filtered (ignore second+ components), nothing can be done. Grouping on the handle would do it but alternate names would be lost.
I attach the beginning of the sorted debugging dump for your information.
Should it be considered as a bug?
sorted.txt.pdf (132.8 KB)
Remove extension .pdf from filename. It is a plain text file but I had to cheat on the Discourse engine to upload it.
If I remember correctly, in 5.1, I needed to show all places and alternate names depending on date. I think this is why we have events attached to the place in the tables.
I don’t see any problems with the attached file.
I have understood how the issue appears. I’ll prepare a test tree tomorrow (1 person, 1 place, 2 events). You can then study how to cope with it.
