ldproxy

Features - GML

specstableimplcandidate

Kodierung von Features als GML.

Umfang

Bei einem WFS-Feature-Provider werden die Features als GML vom WFS abgerufen und in die Antwort umgeschrieben. Im Falle von Features ist das Wurzelelement sf:FeatureCollection.

Bei einem SQL-Feature-Provider werden die Features auf der Grundlage des Provider-Schemas auf GML-Objekt- und Eigenschaftselemente abgebildet. Es gibt eine Reihe von Konfigurationsoptionen, um zu steuern, wie die Merkmale auf XML abgebildet werden.

Alle Konfigurationsoptionen dieses Bausteins mit Ausnahme von "gmlSfLevel" sind nur für Collections mit einem SQL-Feature-Provider anwendbar. Für Collections mit einem WFS-Feature-Provider werden alle anderen Konfigurationsoptionen ignoriert.

Die folgenden Beschreibungen gelten alle nur für Collections mit einem SQL-Feature-Provider:

  • Die Feature-Eigenschaft mit der Rolle ID im Provider-Schema wird auf das Attribut gml:id
    des Features abgebildet. Diese Eigenschaften müssen eine direkte Eigenschaft des Featuretyps
    sein. Wenn gmlIdPrefix gesetzt ist, wird das Präfix jedem gml:id-Wert vorangestellt,
    um gültige XML-IDs zu gewährleisten. Wenn appendTemporalSuffixToGmlId: true gesetzt ist
    und der datetime-Parameter der Anfrage ein Intervall ist, wird der Wert der primären
    zeitlichen Eigenschaft im Format yyyyMMddTHHmmssX an die gml:id angehängt.
  • Wenn gmlIdentifier konfiguriert ist, wird ein gml:identifier-Element als erstes
    Kindelement jedes Features ausgegeben, mit dem konfigurierten codeSpace-Attribut und
    der Feature-ID (optional eingesetzt in valueTemplate) als Textinhalt.
  • Geometrieeigenschaften werden je nach Geometrietyp auf GML-3.2-Elemente abgebildet:
    Point wird auf gml:Point (mit gml:pos) abgebildet; MultiPoint auf
    gml:MultiPoint; LineString auf gml:LineString (mit gml:posList); CircularString
    auf gml:Curve mit einem gml:Arc-Segment (drei Kontrollpunkte) oder
    gml:ArcString-Segment (mehr als drei Kontrollpunkte); CompoundCurve auf gml:Curve
    mit mehreren Segmenten; MultiLineString und MultiCurve auf gml:MultiCurve;
    Polygon und CurvePolygon auf gml:Polygon mit gml:LinearRing-Ringen;
    MultiPolygon und MultiSurface auf gml:MultiSurface; PolyhedralSurface auf
    gml:Solid (wenn geschlossen) oder gml:PolyhedralSurface (wenn offen); und
    GeometryCollection auf gml:MultiGeometry.
    Mit useSurfaceAndCurve: true werden folgende alternative Kodierungen verwendet:
    einfache Linienzüge als gml:Curve mit einem gml:LineStringSegment; einfache Polygone
    (und CurvePolygon) als gml:Surface mit einem gml:PolygonPatch; CompoundCurves als
    gml:CompositeCurve; und alle Ringe innerhalb von Polygonen als gml:Ring mit einem
    oder mehreren gml:LineStringSegment-Curve-Membern statt gml:LinearRing. Das Attribut
    gml:id wird den Geometrieelementen nicht hinzugefügt, sofern nicht
    gmlIdOnGeometries: true gesetzt ist. Das Attribut srsName wird in jeder Geometrie
    gesetzt; mit srsNameStyle: TEMPLATE wird der Wert aus srsNameMappings übernommen
    statt der OGC-URI-Form. Mit srsDimension: true wird zusätzlich ein
    srsDimension-Attribut bei pos und posList hinzugefügt.
  • Eigenschaften, die OBJECTs mit dem Objekttyp Link sind, werden auf einen
    gml:Reference-Wert mit den Attributen xlink:href und xlink:title abgebildet, falls
    gesetzt. Für Feature-Referenz-Eigenschaften (mit refType deklariert) kann
    featureRefTemplate xlink:href zu einem URN-Bezeichner umschreiben (z.B.
    urn:adv:oid:{{value}}).
  • Eigenschaften, die OBJECTs mit dem Objekttyp Measure sind, werden auf einen
    gml:MeasureType-Wert abgebildet. Das Objekt muss die Eigenschaften value und uom
    haben, die beide in den Daten vorhanden sein müssen.
  • Eigenschaften, die FLOAT- oder INTEGER-Werte mit einer unit-Eigenschaft im
    Provider-Schema sind, werden ebenfalls auf einen gml:MeasureType-Wert abgebildet.
    Der Wert von unit wird auf das Attribut uom abgebildet. Mit uomStyle: TEMPLATE
    wird die Einheit über uomMappings aufgelöst.
  • Eigenschaften, die in codelistProperties aufgeführt sind, werden als leere
    XML-Elemente mit xlink:href (aus codelistUriTemplate aufgebaut) und xlink:title
    (das Codelist-Label, ersatzweise der Rohwert) kodiert, statt den rohen Wert als
    Elementtext zu schreiben.
  • Jedes Eigenschaftselement erhält den Namen der Eigenschaft aus dem Feature-Schema; mit
    useAlias: true werden Eigenschaften, die einen alias deklarieren, unter diesem Alias
    kodiert. Das Element wird im Namensraum seines übergeordneten Objekttyps platziert, wie
    in objectTypeNamespaces deklariert. Ein explizit angegebenes prefix:name im Schema
    oder eine rename-Transformation hat Vorrang vor dem geerbten Namensraum und dem Alias.
  • Eigenschaften, die in valueWrap aufgeführt sind, haben ihren skalaren Wert in ein oder
    mehrere geschachtelte XML-Elemente eingebettet, die in der Konfiguration deklariert sind
    (von außen nach innen); der Wert steht innerhalb des innersten Wrappers. Dies ist
    nützlich für Anwendungsschemata, die atomare Werte in Wrappertypen einbetten.

Konformitätsklassen

Im Allgemeinen implementiert Features GML alle Anforderungen der Konformitätsklassen Geography Markup Language (GML), Simple Features Profile, Level 0 und Geography Markup Language (GML), Simple Features Profile, Level 2 aus OGC API - Features - Part 1: Core 1.0open in new window. Die Konformität hängt jedoch von der Konformität des GML-Anwendungsschemas mit dem GML Simple Features Standard ab. Da das GML-Anwendungsschema nicht von ldproxy kontrolliert wird, muss die Einstufung der Konformität als Teil der Konfiguration deklariert werden.

Für SQL-Feature-Provider kann außerdem ein anderes Root-Element als sf:FeatureCollection für die Features-Ressource konfiguriert werden. In diesem Fall kann die API nicht konform zu einer der GML-Konformitätsklassen von OGC API Features sein.

Konfiguration

Standardmäßig erhält jedes GML-Eigenschaftselement den Eigenschaftsnamen aus dem Feature-Schema. Das Element liegt im Namensraum seines übergeordneten Objekttyps (deklariert über objectTypeNamespaces); ist für den übergeordneten Objekttyp kein Namensraum-Mapping definiert, verbleibt das Element im Standard-Namensraum. Ein anderer Name oder ein expliziter Namensraum kann mit der Transformation rename festgelegt werden, die Vorrang vor dem geerbten Namensraum hat.

Wenn der CRUD-Baustein aktiviert ist, werden die für die GML-Ausgabe wirksamen Optionen beim Decodieren von GML-POST/PUT-Anfrage-Bodies symmetrisch berücksichtigt: applicationNamespaces, defaultNamespace, objectTypeNamespaces, useAlias, gmlIdPrefix, srsNameMappings, uomMappings, codelistProperties, codelistUriTemplate, featureRefTemplate, valueWrap, xmlAttributes, variableObjectElementNames, featureCollectionElementName, featureMemberElementName. Die übrigen Optionen wirken sich ausschließlich auf die Ausgabe aus \u2014 schemaLocations (XSD-Referenzen), srsNameStyle, uomStyle, gmlIdentifier, appendTemporalSuffixToGmlId, gmlSfLevel, useSurfaceAndCurve, defaultProfiles \u2014 entweder weil sie Formatierungsentscheidungen des Encoders ohne Eingabe-Pendant steuern oder weil der Decoder bei jeder äquivalenten Eingabeform permissiv ist.

Optionen

NameDefaultBeschreibungTypSeit
buildingBlock
Immer GML.
string
v2.0
enabled
false
Soll der Baustein aktiviert werden?
boolean
v2.0
transformations
{}
Property-Transformationen erfolgen bei der Aufbereitung der Daten für die Rückgabe über die API. Die Datenhaltung selbst bleibt unverändert. Alle Filterausdrücke (siehe queryables in Features) wirken unabhängig von etwaigen Transformationen bei der Ausgabe und müssen auf der Basis der Werte in der Datenhaltung formuliert sein - die Transformationen sind i.A. nicht umkehrbar und eine Berücksichtigung der inversen Transformationen bei Filterausdrücken wäre kompliziert und nur unvollständig möglich. Insofern sollten Eigenschaften, die queryable sein sollen, möglichst bereits in der Datenquelle transformiert sein. Eine Ausnahme sind typischerweise Transformationen in der HTML-Ausgabe, wo direkte Lesbarkeit i.d.R. wichtiger ist als die Filtermöglichkeit.
object
v2.0
useAlias
false
Wenn true, werden Eigenschaften des Feature-Schemas, für die ein alias angegeben ist, unter dem Alias anstelle des Schemanamens kodiert. Hilfreich für Anwendungsschemata, in denen jede Eigenschaft sowohl einen kurzen technischen Namen als auch einen längeren eingängigen Namen hat (z.B. AdV-NAS: arf / artDerFlurstuecksgrenze). Eine explizite rename-Transformation für eine Eigenschaft hat weiterhin Vorrang vor dem Alias. Die Option wirkt nur auf die Feature-Kodierung; Queryables, Sortables und andere Schema-Ableitungen verwenden immer die Schemanamen.
boolean
v2.0
gmlVersion
GML32
Bestimmt die zu verwendende GML-Version: GML32 für GML 3.2, GML31 für GML 3.1 und GML21 für GML 2.1.
string
v3.3
gmlSfLevel
null
Der Standardwert null erklärt, dass die GML-Unterstützung nicht alle Anforderungen der Konformitätsklassen Geography Markup Language (GML), Simple Features Profile, Level 0 oder der Geography Markup Language (GML), Simple Features Profile, Level 2 aus OGC API - Features - Part 1: Core 1.0open in new window erfüllt. Wenn der Wert auf 0, 1 oder 2 gesetzt wird, wird die Konformität in der Conformance Declaration Ressource angegeben. Wenn für eine Sammlung von einem SQL-Feature-Provider ein anderes Root-Element als sf:FeatureCollection in featureCollectionElementName konfiguriert ist, wird der Wert ignoriert und es wird keine Konformität zu einer GML-Konformitätsklasse erklärt.
number
v3.3
conformance
string
v2.0
applicationNamespaces
{}
Jedes XML-Element hat einen XML-Namensraum und jedes XML-Attribut kann einen XML-Namensraum haben. Um die Lesbarkeit der XML-Dokumente zu verbessern, wird für jeden Namespace ein Namespace-Präfix deklariert. Gängige Namespaces und Präfixe sind vordefiniert, diese sind: gml (GML 3.2), xlink (XLink), xml (XML), sf (OGC API Features Core 1.0, Core-SF), wfs (WFS 2.0), und xsi (XML Schema Information). Weitere Namespaces, die in den Daten verwendet werden (deklariert in GML-Anwendungsschemata und importierten Schemata), werden mit ihren Präfixen konfiguriert. Da Feature-Daten immer Elemente in anwendungsschemaspezifischen Namespaces verwenden, muss dieser Konfigurationsparameter immer angegeben werden.
object
v3.3
defaultNamespace
null
Mit diesem Konfigurationsparameter kann ein Standard-Namespace angegeben werden, der für XML-Elemente verwendet wird, wenn kein anderer Namespace angegeben ist. Der Wert ist der Namespace-Präfix. Es muss entweder ein vordefiniertes Präfix oder ein in applicationNamespaces deklariertes Präfix sein. Dieser Namespace wird als Standard-Namespace des XML-Dokuments deklariert.
string
v3.3
schemaLocations
null
Wenn ein Anwendungsnamensraum in das Attribut xsi:schemaLocation des Root-Elements aufgenommen werden soll, müssen die Dokument-URIs angegeben werden. Außerdem wird die Schema-URL des Namespaces des Root-Elements hinzugefügt, falls bekannt. Für die vordefinierten Namespaces (gml, sf und wfs) wird die kanonische Schema-URL im OGC-Schema-Repository verwendet, sofern keine andere Schema-URL für den Namespace konfiguriert ist. Beachten Sie, dass der Namespace des Root-Elements im Attribut xsi:schemaLocation deklariert werden muss, um den XML-Schema-Validierungsanforderungen zu entsprechen, auch wenn der Namespace von einem anderen Schema importiert wird.
object
v3.3
objectTypeNamespaces
{}
Alle Objekt/Datentyp-Instanzen werden durch ein GML-Objektelement dargestellt. Im Provider-Schema muss für jedes OBJEKT in der Eigenschaft objectType ein Name angegeben werden, auch für den Feature-Typ selbst. Standardmäßig wird dieser Name für den unqualifizierten Namen des GML-Objektelements verwendet. Wenn das GML-Objektelement nicht im Standard-Namensraum liegt, spezifiziert dieser Konfigurationsparameter den Namensraumpräfix zu einem Objekttyp. Der zugeordnete Präfix wird auch auf die Eigenschaftselemente angewendet, die dieser Objekttyp deklariert (seine Kindelemente im Schema-Baum). Das entspricht der XML-Schema- Konvention elementFormDefault="qualified": ein Eigenschaftselement liegt im Ziel-Namensraum des komplexen Typs, der es deklariert. Eigenschaftsnamen (bzw. ihre Aliase) sollten daher im Provider-Schema ohne Präfix angegeben werden; der Namensraum wird automatisch aus dem Mapping des übergeordneten Objekttyps ergänzt. Ein explizit angegebenes prefix:name im Schema-Namen oder Alias hat weiterhin Vorrang.
object
v3.3
variableObjectElementNames
{}
Es kann auch Fälle geben, insbesondere wenn im zugrunde liegenden Anwendungsschema Vererbung verwendet wird, in denen mehrere Objekttypen in derselben Tabelle geführt werden, mit einem Attribut, das den Namen des Merkmals/Objekttyps angibt. Dieser Konfigurationsparameter bietet die Möglichkeit, diese Eigenschaften zu identifizieren und die Werte auf qualifizierte Namen für das GML-Objektelement abzubilden. Im Beispiel ist _type die Feature-Eigenschaft mit drei verschiedenen Werten, die auf den qualifizierten Elementnamen abgebildet werden.
object
v3.3
featureCollectionElementName
sf:FeatureCollection
Es werden verschiedene Feature-Collection-Elemente verwendet und manchmal werden zusätzliche Elemente in GML-Anwendungsschemata definiert. Der Standard ist sf:FeatureCollection, wie von OGC API Features spezifiziert. Dieser Konfigurationsparameter bietet die Möglichkeit, dass ein anderes Feature-Collection-Element in der Rückgabe verwendet wird.
string
v3.3
featureMemberElementName
sf:featureMember
Das in featureCollectionElementNamereferenzierte Feature-Collection-Element hat ein untergeordnetes Eigenschaftselement, das wiederum jedes Feature enthält. Der Standardwert ist sf:featureMember, wie von OGC API Features definiert. Dieser Konfigurationsparameter bietet die Möglichkeit, den Elementnamen für das konfigurierte Feature-Collection-Element zu spezifizieren.
string
v3.3
supportsStandardResponseParameters
false
Das Feature-Collection-Element, auf das in featureCollectionElementName verwiesen wird, kann die WFS-2.0-Standardantwortparameter (timeStamp, numberMatched, numberReturned) unterstützen. Dieser Konfigurationsparameter steuert, ob die Attribute als XML-Attribute in das Feature-Collection-Element aufgenommen werden.
boolean
v3.3
xmlAttributes
[]
Eigenschaften werden standardmäßig als XML-Kindelement (GML-Eigenschaftselement) des XML-Elements dargestellt, das das Objekt repräsentiert (GML-Objektelement). Alternativ kann die Eigenschaft auch als XML-Attribut des übergeordneten GML-Objektelements dargestellt werden. Dies ist nur für Eigenschaften vom Typ STRING, FLOAT, INTEGER oder BOOLEAN möglich.
array
v3.3
gmlIdPrefix
null
Die Feature-Eigenschaft mit der Rolle ID im Provider-Schema wird auf das Attribut gml:id des Merkmals abgebildet. Diese Eigenschaften müssen eine direkte Eigenschaft des Feature-Typs sein. Wenn die Werte die Regel für XML-IDs verletzen, z. B. wenn sie mit einer Ziffer beginnen können, kann dieser Konfigurationsparameter verwendet werden, um ein konsistentes Präfix hinzuzufügen, um alle Werte auf gültige XML-IDs abzubilden.
string
v3.3
gmlIdOnGeometries
false
Diese Option fügt ein gml:id-Attribut zu allen GML-Geometrieelementen hinzu. Das id-Attribut war in GML 3.2 bis 2016 verpflichtend, ältere Kopien des GML-Schemas können das Attribut noch benötigen. Diese Option ermöglicht es, Instanzen zu erstellen, die für solche Schemas gültig sind.
boolean
v4.0
srsDimension
false
Diese Option fügt ein srsDimension-Attribut bei allen posList und pos-Elementen hinzu. Einige GML-Reader erwarten diese Information, insbesondere für 3D-Koordinaten.
boolean
v4.6
useSurfaceAndCurve
false
Wenn aktiviert, werden einfache Polygone statt als {@code gml:Polygon} als {@code gml:Surface} mit genau einem {@code gml:PolygonPatch} kodiert, und einfache Linienzüge statt als {@code gml:LineString} als {@code gml:Curve} mit genau einem {@code gml:LineStringSegment}. Alle Ringe werden als {@code gml:Ring} mit genau einem {@code gml:LineStringSegment} als Curve-Member statt als {@code gml:LinearRing} kodiert. Diese Option ist nützlich, wenn das Ziel-GML-Anwendungsschema diese Geometrietypen erfordert.
boolean
v4.8
defaultProfiles
{"rel": "rel-as-link", "val": "val-as-code"}
Spezifiziert den Standardwert des Profile-Parameters für Features. Der Wert ist ein Objekt, bei dem der Schlüssel die ID eines Profilsatzes ist und der Wert das Standardprofil für den Profilsatz. Diese Vorgaben haben Vorrang vor den im Features-Baustein angegebenen Standardprofilen. Für GML sind die folgenden Standardprofile gesetzt: "rel-as-link" für Feature-Beziehungen und "val-as-code" für Eigenschaften mit codierten Werten. Ein Ändern dieser Profile führt wahrscheinlich zu einer GML-Kodierung, die nicht gegen das GML-Anwendungsschema valide ist, das typischerweise keine Variationen der Kodierung unterstützt.
object
v4.2
srsNameStyle
OGC
Steuert, wie das {@code srsName}-Attribut von Geometrien gerendert wird. {@code OGC} (Standard) erzeugt die OGC-URI-Form (z.B. {@code http://www.opengis.net/def/crs/EPSG/0/25832open in new window}). {@code TEMPLATE} sucht das CRS in {@code srsNameMappings} und verwendet den zugeordneten Wert; CRS ohne Mapping fallen auf die {@code OGC}-Form zurück.
string
v4.9
srsNameMappings
[]
Mapping-Liste für {@code srsNameStyle: TEMPLATE}. Jeder Eintrag bindet ein CRS an einen festen {@code srsName}-Wert. Nützlich für Anwendungsschemata, die Nicht-OGC-URIs verlangen (z.B. AdV: {@code urn:adv:crs:ETRS89_UTM32}).
array
v4.9
uomStyle
RAW
Steuert, wie das {@code uom}-Attribut bei Measure-Eigenschaften gerendert wird. {@code RAW} (Standard) schreibt den Einheitenwert aus dem Provider-Schema unverändert. {@code TEMPLATE} sucht die Einheit in {@code uomMappings} und verwendet den zugeordneten Wert; Einheiten ohne Mapping fallen auf den Rohwert zurück.
string
v4.9
uomMappings
[]
Mapping-Liste für {@code uomStyle: TEMPLATE}. Jeder Eintrag bindet einen Einheiten-String an einen festen {@code uom}-Wert. Nützlich für Anwendungsschemata, die Nicht-UCUM-Bezeichner verlangen (z.B. AdV: {@code urn:adv:uom:m}).
array
v4.9
featureRefTemplate
null
URI/URN-Template für {@code xlink:href} von Feature-Referenz-Eigenschaften (d.h. Properties mit {@code refType}). Der Platzhalter {@code } wird durch die referenzierte Feature-ID (das Segment nach {@code /items/} in der Original-URL) ersetzt. Standardwert {@code null} belässt die Original-URL. Nützlich für Anwendungsschemata, die URN-Referenzen verlangen (z.B. AdV: {@code urn:adv:oid:}). Wirkt nicht auf Links in generischen {@code Link}-Objekten.
string
v4.9
gmlIdentifier
null
Wenn gesetzt, wird ein {@code gml:identifier}-Kindelement als erstes Kind jedes Features mit dem konfigurierten {@code codeSpace}-Attribut ausgegeben. Der Textinhalt des Elements ist die rohe Feature-ID aus dem Provider, optional eingesetzt in {@code valueTemplate} (wobei {@code } durch die rohe ID ersetzt wird). Nützlich für Anwendungsschemata, die {@code gml:identifier} verlangen (z.B. AdV NAS).
object
v4.9
appendTemporalSuffixToGmlId
false
Wenn {@code true} und der {@code datetime}-Parameter der Anfrage ein Intervall ist (enthält {@code /}), wird die {@code gml:id} jedes Features um den Wert der primären zeitlichen Eigenschaft formatiert als {@code yyyyMMddTHHmmssX} ergänzt. Quelle ist die Eigenschaft mit Rolle {@code PRIMARY_INSTANT}, ersatzweise {@code PRIMARY_INTERVAL_START}. Nützlich für Anwendungsschemata, die je Feature-Version eine eindeutige {@code gml:id} verlangen (z.B. AdV NAS Zeitreihen-Anfragen). Wirkt nicht auf {@code gml:identifier}.
boolean
v4.9
codelistUriTemplate
null
URI-Template zum Aufbau des {@code xlink:href} für Eigenschaften mit Codelist-Werten. Das Template darf die Platzhalter {@code } (ersetzt durch die Codelist-ID aus {@code codelistProperties}) und {@code } (ersetzt durch den rohen Eigenschaftswert) enthalten. Wenn zusammen mit {@code codelistProperties} gesetzt, wird die betroffene Eigenschaft als leeres Element {@code } kodiert, wobei {@code xlink:title} das Codelist-Label aus der aufgelösten Codelist ist (Fallback ist der rohe Wert, wenn kein Label gefunden wird).
string
v4.9
codelistProperties
{}
Bildet Eigenschaftspfade (entsprechend {@code FeatureSchema#getFullPathAsString()}) auf eine Codelist-ID ab. Hier aufgeführte Eigenschaften werden als xlink-Elemente mittels {@code codelistUriTemplate} kodiert anstatt den rohen Wert als Elementtext zu schreiben. Auf Building-Block-Ebene (API) definierte Einträge gelten für alle Collections; Einträge auf Collection-Ebene werden ergänzt.
object
v4.9
valueWrap
{}
Bildet Eigenschaftspfade (entsprechend {@code FeatureSchema#getFullPathAsString()} zum Kodierungszeitpunkt, d.h. nach eventuellen {@code rename}-Transformationen) auf eine Liste von XML-Elementnamen ab (von außen nach innen), die den skalaren Wert einschließen. Bei einem Treffer wird der Inhalt des Eigenschaftselements als {@code } statt als reiner Wert kodiert. Elementnamen können Namespace-Präfixe tragen (z.B. {@code gco:DateTime}), sofern das Präfix in {@code applicationNamespaces} deklariert ist.
object
v4.9

Dieses Modul benötigt bzw. unterstützt keine zusätzlichen Konfigurationsdateien.

Beispiele

Das folgende Beispiel zeigt eine grundlegende Deklaration von Namespaces und deren Schema-Speicherorten, die Konfiguration eines gml:id-Präfixes zur Gewährleistung der XML-ID-Kompatibilität sowie spezifische Konfigurationsoptionen für eine Objektart.


- buildingBlock: GML
 enabled: true
 applicationNamespaces:
   ns1: http://www.example.com/ns/ns1/1.0
   ns2: http://www.example.com/ns/ns2/1.0
 defaultNamespace: ns1
 schemaLocations:
   ns1: '{{serviceUrl}}/resources/ns1.xsd'
   ns2: '{{serviceUrl}}/resources/ns2.xsd'
 gmlIdPrefix: '_'
collections:
 some_type:
   ...
   api:
   - buildingBlock: GML
     xmlAttributes:
       - someAtt
     transformations:
       someOtherAtt:
         rename: 'ns2:someOtherAtt'

Das folgende Beispiel kombiniert alle Optionen, die üblicherweise benötigt werden, um Daten gemäß dem AdV-GeoInfoDok-/AFIS-ALKIS-ATKIS-NAS-Anwendungsschema bereitzustellen. Jede Option ist einzeln aktivierbar und auch für andere GML-Anwendungsschemata nutzbar.

Die Option useAlias: true bewirkt, dass jede Eigenschaft des Feature-Schemas, für die ein alias angegeben ist (siehe das alias-Feld im Provider-Schema), unter ihrem Alias anstelle des Attributcodes aus drei Zeichen kodiert wird, sofern der Code im Provider-Schema verwendet wird. Dies ist die bevorzugte Methode, um NAS-Daten mit den mnemotechnischen Eigenschaftsnamen (z.B. anlass statt anl) bereitzustellen, ohne eine umfangreiche rename-Transformationsliste pro Eigenschaft pflegen zu müssen.


- buildingBlock: GML
 enabled: true
 useAlias: true
 useSurfaceAndCurve: true
 applicationNamespaces:
   aaa: 'http://www.adv-online.de/namespaces/adv/gid/7.1'
 defaultNamespace: aaa
 schemaLocations:
   aaa: 'https://repository.gdi-de.org/schemas/adv/nas/7.1/aaa.xsd'
 featureRefTemplate: 'urn:adv:oid:{{value}}'
 gmlIdentifier:
   codeSpace: 'http://www.adv-online.de/'
   valueTemplate: 'urn:adv:oid:{{value}}'
 appendTemporalSuffixToGmlId: true
 srsNameStyle: TEMPLATE
 srsNameMappings:
   - crs:
       code: 25832
       forceAxisOrder: NONE
     value: 'urn:adv:crs:ETRS89_UTM32'
   - crs:
       code: 25833
       forceAxisOrder: NONE
     value: 'urn:adv:crs:ETRS89_UTM33'
   - crs:
       code: 4326
       forceAxisOrder: NONE
     value: 'urn:adv:crs:WGS84_Lat-Lon'
   - crs:
       code: 4326
       forceAxisOrder: LON_LAT
     value: 'urn:adv:crs:WGS84_Lon-Lat'
 uomStyle: TEMPLATE
 uomMappings:
   - uom: 'm'
     value: 'urn:adv:uom:m'
   - uom: 'grad'
     value: 'urn:adv:uom:grad'
 codelistUriTemplate: 'https://registry.gdi-de.org/codelist/de.adv-online.gid/{{codelistId}}/{{value}}'
 codelistProperties:
   anlass: AX_Anlassart
 objectTypeNamespaces:
   LI_Lineage: gmd
   LI_ProcessStep: gmd
   LI_Source: gmd
 valueWrap:
   lebenszeitintervall:
     - AA_Lebenszeitintervall
     - beginnt
   qualitaetsangaben.herkunft.processStep.description:
     - AX_LI_ProcessStep_Punktort_Description
   qualitaetsangaben.herkunft.processStep.dateTime:
     - gco:DateTime
   qualitaetsangaben.herkunft.processStep.source.description:
     - AX_Datenerhebung_Punktort
ImpressumDatenschutzerklärung