Features - GML
specstableimplcandidateKodierung 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
IDim Provider-Schema wird auf das Attributgml:id
des Features abgebildet. Diese Eigenschaften müssen eine direkte Eigenschaft des Featuretyps
sein. WenngmlIdPrefixgesetzt ist, wird das Präfix jedemgml:id-Wert vorangestellt,
um gültige XML-IDs zu gewährleisten. Bei versionierten Collections verwendet GML
standardmäßig das Profilversions-as-features-unique-ids, sodass eine Antwort, die
mehrere Versionen eines Features enthalten kann, eindeutigegml:id-Werte trägt (das
Kompositum aus kanonischer Id und Intervallbeginn der Version). - Wenn
gmlIdentifierkonfiguriert ist, wird eingml:identifier-Element als erstes
Kindelement jedes Features ausgegeben, mit dem konfiguriertencodeSpace-Attribut und
der Feature-ID (optional eingesetzt invalueTemplate) als Textinhalt. - Geometrieeigenschaften werden je nach Geometrietyp auf GML-3.2-Elemente abgebildet:
Pointwird aufgml:Point(mitgml:pos) abgebildet;MultiPointaufgml:MultiPoint;LineStringaufgml:LineString(mitgml:posList);CircularString
aufgml:Curvemit einemgml:Arc-Segment (drei Kontrollpunkte) odergml:ArcString-Segment (mehr als drei Kontrollpunkte);CompoundCurveaufgml:Curve
mit mehreren Segmenten;MultiLineStringundMultiCurveaufgml:MultiCurve;PolygonundCurvePolygonaufgml:Polygonmitgml:LinearRing-Ringen;MultiPolygonundMultiSurfaceaufgml:MultiSurface;PolyhedralSurfaceaufgml:Solid(wenn geschlossen) odergml:PolyhedralSurface(wenn offen); undGeometryCollectionaufgml:MultiGeometry.
MituseSurfaceAndCurve: truewerden folgende alternative Kodierungen verwendet:
einfache Linienzüge alsgml:Curvemit einemgml:LineStringSegment; einfache Polygone
(undCurvePolygon) alsgml:Surfacemit einemgml:PolygonPatch; CompoundCurves alsgml:CompositeCurve; und alle Ringe innerhalb von Polygonen alsgml:Ringmit einem
oder mehrerengml:LineStringSegment-Curve-Membern stattgml:LinearRing. Das Attributgml:idwird den Geometrieelementen nicht hinzugefügt, sofern nichtgmlIdOnGeometries: truegesetzt ist. Das AttributsrsNamewird in jeder Geometrie
gesetzt; mitsrsNameStyle: TEMPLATEwird der Wert aussrsNameMappingsübernommen
statt der OGC-URI-Form. MitsrsDimension: truewird zusätzlich einsrsDimension-Attribut beiposundposListhinzugefügt. - Eigenschaften, die
OBJECTs mit dem ObjekttypLinksind, werden auf einengml:Reference-Wert mit den Attributenxlink:hrefundxlink:titleabgebildet, falls
gesetzt. Für Feature-Referenz-Eigenschaften (mitrefTypedeklariert) kannfeatureRefTemplatexlink:hrefzu einem URN-Bezeichner umschreiben (z.B.urn:adv:oid:{{value}}). - Eigenschaften, die
OBJECTs mit dem ObjekttypMeasuresind, werden auf einengml:MeasureType-Wert abgebildet. Das Objekt muss die Eigenschaftenvalueunduom
haben, die beide in den Daten vorhanden sein müssen. - Eigenschaften, die
FLOAT- oderINTEGER-Werte mit einerunit-Eigenschaft im
Provider-Schema sind, werden ebenfalls auf einengml:MeasureType-Wert abgebildet.
Der Wert vonunitwird auf das Attributuomabgebildet. MituomStyle: TEMPLATE
wird die Einheit überuomMappingsaufgelöst. - Eigenschaften, die in
codelistPropertiesaufgeführt sind, werden als leere
XML-Elemente mitxlink:href(auscodelistUriTemplateaufgebaut) undxlink: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: truewerden Eigenschaften, die einenaliasdeklarieren, unter diesem Alias
kodiert. Das Element wird im Namensraum seines übergeordneten Objekttyps platziert, wie
inobjectTypeNamespacesdeklariert. Ein explizit angegebenesprefix:nameim Schema
oder einerename-Transformation hat Vorrang vor dem geerbten Namensraum und dem Alias. - Eigenschaften, die in
xmlPathsaufgeführt sind, werden als die vollständige, in der
Konfiguration deklarierte Kette von XML-Elementen kodiert (von außen nach innen); der
Wert steht innerhalb des innersten Elements. Aufeinanderfolgende Eigenschaften, deren
Ketten mit denselben Elementen beginnen, werden innerhalb einer Instanz der geteilten
Wrapper-Elemente kodiert. Dies ist nützlich für Anwendungsschemata, die atomare Werte in
Wrappertypen einbetten, sowie um flache Eigenschaften als geschachtelte Strukturen zu
kodieren.
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.0. 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, uomMappings, codelistProperties, codelistUriTemplate, featureRefTemplate, xmlPaths, xmlAttributes, variableObjectElementNames, featureCollectionElementName, featureMemberElementName. Die übrigen Optionen wirken sich ausschließlich auf die Ausgabe aus - schemaLocations (XSD-Referenzen), srsNameStyle, uomStyle, gmlIdentifier, gmlSfLevel, useSurfaceAndCurve, defaultProfiles - entweder weil sie Formatierungsentscheidungen des Encoders ohne Eingabe-Pendant steuern oder weil der Decoder bei jeder äquivalenten Eingabeform permissiv ist. codeListUriTemplateIso19139 wirkt sich ebenfalls nur auf die Ausgabe aus, ebenso Attribute und eingefügte leere Elemente in xmlPaths-Ketten - beim Einlesen wird ein leeres Element innerhalb einer Kette übersprungen und ein xsi:type-Attribut auf einem Wert-Element verworfen.
Optionen
| Name | Default | Beschreibung | Typ | Seit |
|---|---|---|---|---|
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.0 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 |
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 |
xsdCatalog | {} | Lokale XSD-Dateien, die die entfernten Schema-URLs aus schemaLocations und aus xsi:schemaLocation-Imports während der XML-Schema-Validierung eingehender wfs:Transaction-Anfragen ersetzen. Jeder Schlüssel ist die entfernte URL exakt so, wie sie sonst geladen würde; der Wert ist ein Pfad relativ zum Ressourcenspeicher xsdCatalog (also Dateien unter <data-dir>/resources/xsdCatalog/). Nicht aufgeführte entfernte URLs werden weiterhin über das Netzwerk geladen. Diese Option ist nützlich, wenn die JVM, in der ldproxy läuft, das Schema-Repository nicht erreichen kann (zum Beispiel hinter einem Proxy oder bei der Validierung gegen unveröffentlichte Schema-Entwürfe). | object | v4.8 |
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 |
objectTypeSuffixedProperties | [] | Einige Eigenschaften mit Objektreferenzen werden in GML mit einem Elementnamen kodiert, der den referenzierten Objekttyp an den Eigenschaftsnamen anhängt, zum Beispiel gehoertZuBauwerk_AX_Turm statt gehoertZuBauwerk. Hier werden die betroffenen Eigenschaften aufgelistet, angegeben über ihre Property-Id. Bei der Kodierung erhält der Elementname ein _{objectType}-Suffix, wobei {objectType} der Objekttyp der Collection ist, auf die die Referenz verweist; bei der Dekodierung wird ein Elementname mit einem solchen Suffix wieder auf die Eigenschaft abgebildet. | array | v4.8 |
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 gml:Polygon als gml:Surface mit genau einem gml:PolygonPatch kodiert, und einfache Linienzüge statt als gml:LineString als gml:Curve mit genau einem gml:LineStringSegment. Alle Ringe werden als gml:Ring mit genau einem gml:LineStringSegment als Curve-Member statt als gml:LinearRing kodiert. Diese Option ist nützlich, wenn das Ziel-GML-Anwendungsschema diese Geometrietypen erfordert. | boolean | v4.8 |
forceCompositeCurve | false | Wenn aktiviert, wird eine Kurvengeometrie immer als gml:CompositeCurve kodiert (mit einem gml:curveMember je Kurvenkomponente), auch wenn die Geometrie nur eine einzige Komponente hat. Dies ist nützlich, wenn das Ziel-GML-Anwendungsschema gml:CompositeCurve für die Geometrie einer Objektart erfordert. Diese Option wird je Collection auf den betroffenen Objektarten gesetzt. Sie ist nur zusammen mit useSurfaceAndCurve wirksam. | boolean | v4.8 |
defaultProfiles | {"rel": "rel-as-link", "val": "val-as-code", "versions": "versions-as-features-unique-ids"} | 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, "val-as-code" für Eigenschaften mit codierten Werten sowie "versions-as-features-unique-ids" für versionierte Collections, da eine Antwort mit mehreren Versionen eines Features eindeutige gml:id-Werte erfordert (die Id jeder Version wird zu einem Kompositum aus kanonischer Id und Intervallbeginn der Version umgeschrieben; das Element gml:identifier trägt weiterhin die kanonische Id). 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 srsName-Attribut von Geometrien gerendert wird. OGC (Standard) erzeugt die OGC-URI-Form (z.B. http://www.opengis.net/def/crs/EPSG/0/25832). TEMPLATE sucht das CRS in den additionalCrs-Einträgen des CRS-Bausteins und verwendet die deklarierte alternativeUri; CRS ohne eine solche fallen auf die OGC-Form zurück. | string | v4.8 |
uomStyle | RAW | Steuert, wie das uom-Attribut bei Measure-Eigenschaften gerendert wird. RAW (Standard) schreibt den Einheitenwert aus dem Provider-Schema unverändert. TEMPLATE sucht die Einheit in uomMappings und verwendet den zugeordneten Wert; Einheiten ohne Mapping fallen auf den Rohwert zurück. | string | v4.8 |
uomMappings | [] | Mapping-Liste für uomStyle: TEMPLATE. Jeder Eintrag bindet einen Einheiten-String an einen festen uom-Wert. Nützlich für Anwendungsschemata, die Nicht-UCUM-Bezeichner verlangen (z.B. AdV: urn:adv:uom:m). | array | v4.8 |
featureRefTemplate | null | URI/URN-Template für xlink:href von Feature-Referenz-Eigenschaften (d.h. Properties mit refType). Der Platzhalter {{value}} wird durch die referenzierte Feature-ID (das Segment nach /items/ in der Original-URL) ersetzt. Standardwert null belässt die Original-URL. Nützlich für Anwendungsschemata, die URN-Referenzen verlangen (z.B. AdV: urn:adv:oid:{{value}}). Wirkt nicht auf Links in generischen Link-Objekten. | string | v4.8 |
gmlIdentifier | null | Wenn gesetzt, wird ein gml:identifier-Kindelement als erstes Kind jedes Features mit dem konfigurierten codeSpace-Attribut ausgegeben. Der Textinhalt des Elements ist die rohe Feature-ID aus dem Provider, optional eingesetzt in valueTemplate (wobei {{value}} durch die rohe ID ersetzt wird). Nützlich für Anwendungsschemata, die gml:identifier verlangen (z.B. AdV NAS). | object | v4.8 |
codelistUriTemplate | null | URI-Template zum Aufbau des xlink:href für Eigenschaften mit Codelist-Werten. Das Template darf die Platzhalter {{codelistId}} (ersetzt durch die Codelist-ID aus codelistProperties) und {{value}} (ersetzt durch den rohen Eigenschaftswert) enthalten. Wenn zusammen mit codelistProperties gesetzt, wird die betroffene Eigenschaft als leeres Element <prop xlink:href="..." xlink:title="..."/> kodiert, wobei xlink:title das Codelist-Label aus der aufgelösten Codelist ist (Fallback ist der rohe Wert, wenn kein Label gefunden wird). | string | v4.8 |
codelistProperties | {} | Bildet Eigenschaftspfade (entsprechend FeatureSchema#getFullPathAsString()) auf eine Codelist-ID ab. Hier aufgeführte Eigenschaften werden als xlink-Elemente mittels 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.8 |
xmlPaths | {} | Bildet Eigenschaftspfade (Eigenschafts-IDs; entsprechend FeatureSchema#getFullPathAsString() zum Kodierungszeitpunkt, d.h. nach eventuellen rename-Transformationen) auf die vollständige Kette von XML-Elementen ab (von außen nach innen), die die Eigenschaft repräsentiert. Das erste Element ersetzt das Eigenschaftselement (Name bzw. Alias der Eigenschaft werden für eine abgebildete Eigenschaft nicht verwendet), das innerste Element enthält den Wert; eine flache Eigenschaft kann so als beliebig geschachtelte Struktur kodiert werden. Jedes Segment ist ein Elementname, optional gefolgt von konstanten Attributen als [Attribut=Wert]-Prädikate (z.B. gco:Record[xsi:type=gml:doubleList]; der Wert kann in Anführungszeichen stehen) und/oder einem abschließenden /. Ein Segment mit abschließendem / umschließt nicht den Rest der Kette; stattdessen wird an dieser Stelle ein leeres Element mit den angegebenen Attributen geschrieben - z.B. das obligatorische valueUnit-Kind eines ISO-19139-DQ_QuantitativeResult, das dem value-Element vorangeht; das innerste Segment darf kein abschließendes / tragen. Element- und Attributnamen können Namespace-Präfixe tragen, sofern das Präfix in applicationNamespaces deklariert oder ein Standard-Präfix (xsi, xlink) ist; Namen ohne Präfix verwenden den Standard-Namespace. Aufeinanderfolgende Eigenschaften, deren Ketten mit denselben Segmenten beginnen, teilen sich diese Wrapper-Elemente: Die geteilten Elemente werden einmal geöffnet und bleiben offen, so dass zwei Eigenschaften mit den Ketten [lebenszeitintervall, AA_Lebenszeitintervall, beginnt] und [lebenszeitintervall, AA_Lebenszeitintervall, endet] innerhalb eines einzigen AA_Lebenszeitintervall-Objekts kodiert werden, in der Reihenfolge des Provider-Schemas. Die geteilten Elemente werden geschlossen, sobald eine nicht abgebildete Eigenschaft, eine Eigenschaft mit einem anderen Kettenanfang, eine Objekt- oder Array-Grenze, eine Geometrie oder das Ende des Features folgt. Bei einer Eigenschaft mit mehreren Werten wird die vollständige Kette für jeden Wert wiederholt. Auch eine Objekt-Eigenschaft kann abgebildet werden: Ihre Kette ersetzt sowohl das Eigenschaftselement als auch das Objektelement, das innerste Element enthält die Eigenschaften des Objekts, deren eigene Ketten relativ dazu sind. Bei einem Array von Objekten markiert ein vorangestelltes * an einem Segment, ab wo sich die Kette wiederholt: Die Segmente davor umschließen das gesamte Array und werden einmal geschrieben, die Segmente ab dem markierten für jedes Element erneut. Ohne Markierung wiederholt sich die gesamte Kette. | object | v4.8 |
codeListUriTemplateIso19139 | null | URI-Template für Codelist-Werte, die gemäß ISO 19139 kodiert werden. Das Template kann den Platzhalter {{codelistId}} enthalten, der durch die Codelist-ID ersetzt wird. Wenn gesetzt, wird eine Eigenschaft, die über die codelist-Constraint im Provider-Schema auf eine Codelist verweist und über xmlPaths auf eine Kette abgebildet ist, deren innerstes Element den lokalen Namen der Codelist-ID trägt, als ISO-19139-Codelist-Wert kodiert: Das einschließende Element erhält ein codeList-Attribut, das aus diesem Template gebildet wird, sowie ein codeListValue-Attribut mit dem Wert (der zugleich der Textinhalt des Elements ist). Der Standardwert null deaktiviert diese Kodierung. | string | v4.8 |
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: CRS
additionalCrs:
- code: 25832
forceAxisOrder: NONE
alternativeUri: 'urn:adv:crs:ETRS89_UTM32'
- code: 25833
forceAxisOrder: NONE
alternativeUri: 'urn:adv:crs:ETRS89_UTM33'
- code: 4326
forceAxisOrder: NONE
alternativeUri: 'urn:adv:crs:WGS84_Lat-Lon'
- code: 4326
forceAxisOrder: LON_LAT
alternativeUri: 'urn:adv:crs:WGS84_Lon-Lat'
- 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}}'
srsNameStyle: TEMPLATE
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:
anl: AX_Anlassart
codeListUriTemplateIso19139: 'https://schemas.isotc211.org/19139/resources/codelists/gmxCodelists.xml/gmxCodelists.xml#{{codelistId}}'
objectTypeNamespaces:
LI_Lineage: gmd
LI_ProcessStep: gmd
LI_Source: gmd
xmlPaths:
daq.dpl.prs.des:
- gmd:description
- AX_LI_ProcessStep_Punktort_Description
daq.dpl.prs.dat:
- gmd:dateTime
- gco:DateTime
daq.dpl.prs.src.des:
- gmd:description
- AX_Datenerhebung_Punktort
q2d.gwt:
- genauigkeitswert
- gmd:DQ_RelativeInternalPositionalAccuracy
- gmd:result
- gmd:DQ_QuantitativeResult
- gmd:valueUnit[xlink:href=urn:adv:uom:m]/
- gmd:value
- gco:Record[xsi:type=gml:doubleList]