What are the limits for the Geography tree in terms the number of of terminal names?
Does Specify 7 get very slow for merging names once you have >100K Geography names? We noticed this for Specify 6 and the Taxon tree, it may take 5 minutes to merge two names.
We are pondering the idea to move the locality names in the locality table to the GEO tree and to use in the localityName field a unique, formatted number as identifier.
The current concept of the locality name usage is not satisfying and causes constantly problems. The field localityName in table Locality is not required to be unique, despite it has the function of an identifier for its re-use. So, you can have numerous locality records with the same value of localityName, but differing in Lat/Long, altitudes, depths etc. This requires that all these fields must also be added to the combo-box queries and the table aggregation (which is not the case for the default version of Specify).
Our users often cannot understand why they must not modify but to clone an existing locality record if they wish to add depths or altitudes.
So basically, it would be preferable to have the same situation and usage for the Locality+Geography as for the Taxon and Storage tree.
Tree performance is dependent on the system that hosts Specify 7, so the more processing power and memory, the less time the tree action will take.
We have been working on a solution to the performance issues caused by trees with a large number of records in them. We have identified the major causes of the slowdown:
Full-name construction
Node numbering
These actions take a lot of resources as each time a tree action is taken (e.g. merging) these have to be done for the entire tree currently.
We have been developing several potential solutions that we anticipate will be available in the coming months. Once we have released our improved tree handling, the performance you are having in the Taxon tree should be significantly improved.
The performance issue seen in the Taxon tree on your system will likely be replicated in the Geography tree at this time.
If possible, I would advise waiting until we have released the tree improvements in Specify 7 to make sure that performance does not become a problem.
Has there been any progress on implementing these improvements? We have been encountering some very slow tree performance recently and will definitely be interested in any Specify updates you can make to address these issues.
We have made progress on making tree updates more efficient that will be released in the coming weeks (#3175).
This would make it so that only the children of the tree node being modified would be updated rather than updating the entire tree each time. This will not appear any different to the user, but it will improve performance when modifying items in the tree.