Ability to define aliases for feature attributes

[tdipisa]

Description

This issue is aimed to define a specific support in MS for providing aliases for features attributes. Doing that is obviously possible but it is necessarily to point out the following aspects that need to be considered involved constraints/requirements for this new feature:

1. The change cannot be done at Attribute Table level because we have to keep consistency across different tools that manage/visualize somehow the feature attributes: Visual Style Editor, Filter Layer tool, Identify tool etc. This means that aliases for feature attributes need to be controlled/centralized in Layers Settings

2. For transparency it is necessary to let the user always know the real attribute name in certain cases. Therefore, as it happen in QGIS for example, the real attribute name can appear in brackets (only inside a tooltip) when you move the mouse over the alias in the Attribute Table header

3. Since we are going to control aliases (we are not changing the real attribute name from MapStore), the real attribute name can be obviously used where needed (eg. OGC filters, SLDs, other OGC requests involving charts/widgets) in a transparent way. This means that from UI the user can see/select the alias name while the real name is used for final requests to the remote services

4. The following constrains anyway exist:

   • MapStore cannot have control on Identify formats other than application/json for which it is possible to intervene on the output programmatically to show the alias instead of the real attribute name
   • Inside the Code Style Editor (the style text area) the real attribute name need to be anyway used

5. From Layer Settings can be possible to set aliases to real attributes name through a kind of tabular view where a reload button allow to reload the Feature Type schema on demand (eg. if an attribute name is changed server side) so that the user can set again the alias when needed

6. What already implemented for widgets (Feature grid aliases and tooltips for columns #8559) can be maintained. The widget can inherit aliases defined at Layer Settings level giving the possibility to further change them at widget level.

7. Each map will have its own setting of aliases

Tasks

Beta Give feedback

1. Improve layer settings performances #9120
   Accepted C206-DEUTSCHE_BAHN-2023-SUPPORT enhancement +3
   
2. Implement language selector tool to use in fields editor #9122
   Accepted C206-DEUTSCHE_BAHN-2023-SUPPORT enhancement +3
   
3. Errors in console when selecting layer in TOC (Dev only) #9129
   Accepted C206-DEUTSCHE_BAHN-2023-SUPPORT bug +3
   
4. Implement the editor of fields with alias support #9127
   Accepted C206-DEUTSCHE_BAHN-2023-SUPPORT enhancement +3
   
5. Support for fields aliases in MapStore tools #9128
   6 of 6
   Accepted C206-DEUTSCHE_BAHN-2023-SUPPORT enhancement +3
   
6. Save fields in JSON of the Map (Export / Import + Online map) #9136
   Accepted C206-DEUTSCHE_BAHN-2023-SUPPORT enhancement +3
   
7. Update Documentation for alias #9146
   Accepted C206-DEUTSCHE_BAHN-2023-SUPPORT Documentation User Guide enhancement +5
   

Acceptance criteria

• Dedicated UI for managing aliases in Layer Settings (preliminary design needed)
• Import/export mechanism for each set of aliases per single layer (in the map import/Export)
• Enable support for aliases for the various tools
  • filter layer tool
  • get feature info (only properties output format)
  • visual style editor
  • attribute table
  • widgets
• Code review (@allyoucanmap), documentation (@ElenaGallo)

Other useful information

Mockup:

On tab open, if the list of fields is not defined yet, the application will load them from the data source (if available). A button allows to reload the fields at any time (for instance because of a change of schema). The old customization on fields will be preserved for the fields with the same name, on reload.

The "clear customizations" button allows to clear all customization and reload the fields from the data source.

The aliases can be defined in a deticated tab in layer settings. Each field has 3 fields:

• Name
• Alias
• Type

At the moment only "Alias" can be edited. The user can choose to edit simply the default alias value or to localize it in all the languages available. The alias can be localized by clicking on the flag button.

Future extension points:

• Extend this UI to local vector data, 3D data etc ...
• Near each line we can add an "edit" button that opens a form with more options for each field. For instance we can select:
  • A formatter (e.g. date formatting, time formatting, render as html )
  • An editor (e.g. number editor, selector from a list, with some constraints, like force selection)
  • A long description of the field and/or a tooltip to show on mouse hover wherever possible.

Work in progress

Work in progress for this feature here:
https://github.com/offtherailz/MapStore2/tree/9099

[offtherailz]

@tdipisa I updated the issue with the mockup. I already discussed this mockup with @allyoucanmap a little.
If you have any comment, please let me know.

note Import/export mechanism is not reported yet. I'd add 2 buttons in the toolbar, to import/export a JSON file. What do you think?

[tdipisa]

@offtherailz the above sounds good with the exception of the following one that is not requested:

Import/export mechanism is not reported yet. I'd add 2 buttons in the toolbar, to import/export a JSON file. What do you think?

The following AC is related to the management of the aliases when you import/export a map where they have been defined for some layer in TOC

Import/export mechanism for each set of aliases per single layer

Only one note on how the translations are managed:

• Predefined value should be the original attribute name as defined from the source
• The alias value visualized in the list should be the one in the current language (if defined)

I'm available for a call to further discuss if needed.

[offtherailz]

The following AC is related to the management of the aliases when you import/export a map where they have been defined for some layer in TOC

Ok, clear. So import and export buttons not needed anymore. Good. I'm going to update the text.

• Predefined value should be the original attribute name as defined from the source

This should be automatically managed by the tools that use this field. The name shown should be in cascade "Localized Alias" --> "Default Alias" --> "Original Name"

• The alias value visualized in the list should be the one in the current language (if defined)

Ok. I did a first draft of implementing this feature this way, but I found the final result a little unclear, so I did the mockup taking into account the easier approach of using default. I'll try to apply this change so I can show it to you and take a final decision.

[offtherailz]

Here a preview: As you can see if a translation in italian is present, the one in italian is shown, with the flag to identify it is the localized version.

As well as you edit, you change directly the one in italian.

It is not bad, but when you delete the italian translation, for consistency it should switch to default version (default is ""), that is a little unclear.

screencast-localhost_8081-2023.04.19-14_52_54.webm

What do you think is better @tdipisa @allyoucanmap ?

[tdipisa]

@offtherailz ok let's keep things simple separating concerns. Let's maintain translations separated to be used only inside tools using aliases according to the client locale and let's manage in settings list only the default as you have suggested before.