GML-specific simplifications

[heidivanparys]

There should be a section where already identified GML-specific simplications can be documented, to be used when an alternative encoding that is GML, but not the default encoding, is developed.

An example is given in section 4.5.2 Encoding of GeographicalName as string with language information in: 2016.1 Fitness for purpose Annex III - Danish comments.

<name xml:lang="da-DK">København</name>

More info about the contents of xm:lang: https://en.wikipedia.org/wiki/IETF_language_tag

[thorsten-reitz]

Hi @heidivanparys ,

given the current structure of the document I would add that as a model transformation rule which defines an alternate, simple representation of the name following your suggestion. Would this be OK?

In the Danish Comments document, there is an gmlxbt:LanguageStringType in GML 3.3 that might be used. I am unsure if we can use GML 3.3 elements in INSPIRE GML though. However there are is also LocalisedCharacterString from ISO 19115. It has a locale attribute that serves a similiar purpose like xml:lang.

Do you think it would make sense to actually add one more additional encoding to define a simplified GML encoding?

[heidivanparys]

The simplification basically consists of:

1. Model transformation rule for GeographicalName
   1. where spelling.text is kept and its multiplicity changed to 1
   2. where language is kept, its multiplicity changed to 0..1 (xml:lang attribute on gmlxbt:LanguageStringType is optional) and the voidable stereotype is removed
   3. its other properties are discarded.
2. Another encoding than the default one is used: GeographicalName is encoded as gmlxbt:LanguageStringType

With the default encoding, a GML application schema would contain

<element maxOccurs="unbounded" name="name" type="gn:GeographicalNamePropertyType">

and something similar to

<complexType name="GeographicalNameType">
    <sequence>
        <element minOccurs="0" name="language" type="string" />
        <element name="spellingText" type="string" />
    </sequence>
</complexType>

With the alternative encoding, a GML application schema would contain

<element maxOccurs="unbounded" name="name" type="gmlxbt:LanguageStringType">

Regarding GML 3.3: GML 3.3 shall be used according to D2.7: Guidelines for the encoding of spatial data, Version 3.3:

Yes, I think it would make sense to actually add one more additionals encodings to define a simplified GML encoding? We could discuss that at the next online meeting?

[thorsten-reitz]

@michellutz I did not take this up for the work on the GeoJSON rule, as it seemed out of scope to me. With respect to the GeoJSON encoding, it achieves the same as the current approach, albeit in a slightly more general way. I would consider this as a possible enhancement for future development.