Toponymy autocomplete

Manuel Gozalbes

We have observed that the toponym autocomplete displays information differently depending on the thesaurus from which the values originate.
Entries from the Official Toponymy thesauri are presented in a clear and consistent format, with the information displayed on separate lines in the following order:
Term
Parents
Model
However, entries from the tchi1, tooponymy1, and htoponymy thesauri are displayed in a different order, which makes them more difficult to read:
Parents
Model
Term
The screenshot illustrates an example from the Production Place field in TCH1, where the same term is displayed differently depending on whether it comes from ES1 or TCHI1. This inconsistency is confusing for users.

This issue affects all autocomplete fields that display toponym values. It would be beneficial to standardize the presentation so that entries from all toponymy thesauri are always displayed in the same order:

Term | Parents | Model

Thank you in advance

Alex

The tch555 is one of the most intricate relation components. It targets all toponymy thesauruses and Immovables and Memory graves.

This issue arises due to the varying types of target sections. In most components, parents are represented as the second column. However, in this case, parents are associated with different target and model sections. Consequently, the original configuration, which involved adding some information about the main term to disambiguate the terms, resulted in multiple entries with different information.

The base configuration was as follows:

Term hierarchy25	information ddinfo	Model hierarchy27
Jalance	El valle de Cofrentes-Ayora, Valencia, Comunidad Valenciana, Spain	Municipio

However, in this particular scenario, the second target failed to reset the previous configuration, leading to the following outcome:

Term hierarchy25	Information ddinfo	Model hierarchy27	Second Term tchi15	tchi13	Third Term dmm493	dmm483
	Valencia, Comunitat Valenciana, Places		Jalance

Why? Because the model component in the first schema is placed at the third position, and it's a standard component. Consequently, any other component is placed after the model in the columns. Therefore, tchi15 and dmm493 were placed after hierarchy27 in the request_config.

"choose": {
        "ddo_map": [
          {
            "tipo": "hierarchy25",
            "parent": "self",
            "section_tipo": "self",
            "value_with_parents": true
          },
          {
            "tipo": "hierarchy27",
            "parent": "self",
            "section_tipo": "self"
          },
          {
            "tipo": "tchi15",
            "parent": "self",
            "section_tipo": "tchi1",
             "value_with_parents": true
          },
          {
            "tipo": "tchi13",
            "parent": "self",
            "section_tipo": "tchi1"
          },
          {
            "tipo": "dmm493",
            "parent": "self",
            "section_tipo": "dmm480",
             "value_with_parents": true
          },
          {
            "tipo": "dmm483",
            "parent": "self",
            "section_tipo": "dmm480"
          }
        ],
        "sqo_config": {
          "limit": 30
        },
        "fields_separator": " | "
      }

Every component with value_with_parents creates its own ddinfo column, but the position is always the same, the second column.

The definition is correct, request_config define what components needs to calculate the parents and works properly. But, a more intelligent re-positon is needed to re-order the columns. And require a more flexible code. We fixed into the version 6.9.3 of the code. So, update your installation to obtain it.

Note: This situation is complex, so please let us know if the new configuration works or if it has any issues. We will test it, but it's impossible to test all possible combinations.

Best