Feature #19

Transforming a name into a geographical name

Added by Thorsten Reitz over 2 years ago. Updated over 2 years ago.

Status:Closed Start date:09/15/2009
Priority:Normal Due date:01/15/2010
Assignee:Anna Pitaev % Done:

100%

Category:-
Target version:2.0-M1 Estimated time:25.00 hours

Description

This Feature was requested by Dominique Laurent, IGN France:

All INSPIRE themes have adopted the data type "geographical name" to express the toponyms. This data type is rather complicated as it includes several attributes:
- spelling which is itself a data type composed of (text, script and transliteration)
- language
- nativeness (endonym/exonym)
- nameStatus
- sourceOfName
- pronunciation which is itself a data type composed of 2 attributes (pronunciationSoundsLike, pronunciationIPA).
- grammatical gender
- grammatical number.

So, in the target schema, the data type is quite complicate, whereas in most existing data (source schema), only the name it self ("text" of "spelling") is known. Some other attributes may possibly filled by adding default value, such as the language, the nativeness (generally endonym) and possibly the script (the characterset used in the spelling).
All other attributes should generally receive an empty value with reasonForNilValue being set at "Unpopulated".

A function encapsulating all steps to transform an ordinary toponym into the INSPIRE data type "geographical name" would be very user-friendly.

  • The user selects in the source schema the attribute "name/toponym" of a given feature type.
  • The user selects in the target schema the corresponding attribute of the corresponding feature type.
  • The user selects the function " Name to Geographical Name".
  • This function opens a window containing all attributes of data type geographical name:
  • - the attribute "spelling" is automatically filled by the source attribute
  • - for the other attributes, the function proposes the possible values of the INSPIRE code list (if any) + the "unpopulated" possibility.

Note: a fitting Transformer needs to be developed within the CST project if this cannot be done using Augmentation Transformers for default values and the rename transformer.

History

Updated by Thorsten Reitz over 2 years ago

  • Target version set to Milestone 5 (RC1)

Updated by Thorsten Reitz over 2 years ago

  • Target version changed from Milestone 5 (RC1) to 1.0
  • % Done changed from 0 to 30
  • Estimated time changed from 2.50 to 5.00

Updated by Thorsten Reitz over 2 years ago

  • Due date set to 01/15/2010
  • Assignee changed from Thorsten Reitz to Anna Pitaev
  • Target version changed from 1.0 to 2.0-M1

Updated by Anna Pitaev over 2 years ago

  • Status changed from New to Assigned

Updated by Thorsten Reitz over 2 years ago

  • % Done changed from 30 to 80

Open Point: Confirmation that the generated OML is OK, afterwards the ticket can be closed.

Updated by Thorsten Reitz over 2 years ago

  • Status changed from Assigned to Closed
  • % Done changed from 80 to 100
  • Estimated time changed from 5.00 to 25.00

From the side of HALE, this ticket can be considered closed; it should be noted that there is still a serialisation issue in commons for the nested composed properties that this function requires, and that in cst, the corresponding function is also not finished.

Also available in: Atom PDF