# Semantische Anforderungen

Die semantischen Anforderungen sind meistens auf Attributbasis. Daraus ergeben sich 3 Fehlerzustände für ein Attribut:

* **SE_ATTRIBUTE_WRONG_VALUE:** Wenn ein Attribut ein falschen Wert hat.
* **SE_ATTRIBUTE_MISSING:** Wenn ein Attribut fehlt, aber vorhanden sein sollte.
* **SE_ATTRIBUTE_INVALID:** Wenn ein Attribut vorhanden ist aber verboten ist.

!!! warning
	**SE_ATTRIBUTE_INVALID:** ist noch nicht in CityDoctor und der QualityADE umgesetzt ist aber geplant in einer neuen Version zu unterstützen.

## Schematron

In CityDoctor wurde das [XML Validierungssystem Schematron](https://de.wikipedia.org/wiki/Schematron) integriert um flexibel Attributprüfungen anzupassen und zu unterstützen. 

Hier ist ein Beispiel für eine Schematron Datei die CityDoctor integrieren kann:

### CityDoctor >= 3.13.0
``` xml
<?xml version="1.0" encoding="UTF-8"?>
<schema xmlns="http://purl.oclc.org/dsdl/schematron" queryBinding="xslt2">
    <ns prefix="gml" uri="http://www.opengis.net/gml"/>
    <ns prefix="bldg" uri="http://www.opengis.net/citygml/building/2.0"/>
    
    <pattern>
        <rule context="//*:Building">
            <assert test="count(descendant::*:lod1Solid) &gt; 0 or count(descendant::*:lod2Solid) &gt; 0 or count(descendant::*:lod3Solid) &gt; 0 or count(descendant::*:lod4Solid) &gt; 0"><value-of select="@gml:id | @id"/>||||SE_ATTRIBUTE_MISSING||any solid</assert>
        </rule>
        <rule context="//*:BuildingPart">
            <assert test="count(*:lod1Solid) = 1 or count(*:lod2Solid) = 1 or count(*:lod3Solid) = 1 or count(*:lod4Solid) = 1"><value-of select="ancestor::*:Building/@*:id"/>||<value-of select="@gml:id | @id"/>||SE_ATTRIBUTE_MISSING||any solid</assert>
        </rule>
    </pattern>
</schema> 

```


### CityDoctor < 3.13.0

``` xml
<?xml version="1.0" encoding="UTF-8"?>
<schema xmlns="http://purl.oclc.org/dsdl/schematron" queryBinding="xslt2">
    <ns prefix="gml" uri="http://www.opengis.net/gml"/>
    <ns prefix="bldg" uri="http://www.opengis.net/citygml/building/2.0"/>
    
    <pattern>
        <rule context="//*:Building">
            <assert test="count(descendant::*:lod1Solid) &gt; 0 or count(descendant::*:lod2Solid) &gt; 0 or count(descendant::*:lod3Solid) &gt; 0 or count(descendant::*:lod4Solid) &gt; 0"><value-of select="@gml:id | @id"/>||||SE_ATTRIBUTE_MISSING||any solid||false</assert>
        </rule>
        <rule context="//*:BuildingPart">
            <assert test="count(*:lod1Solid) = 1 or count(*:lod2Solid) = 1 or count(*:lod3Solid) = 1 or count(*:lod4Solid) = 1"><value-of select="ancestor::*:Building/@*:id"/>||<value-of select="@gml:id | @id"/>||SE_ATTRIBUTE_MISSING||any solid||false</assert>
        </rule>
    </pattern>
</schema> 
```

Diese Datei prüft, dass alle Buildings in sich selbst oder in einem ihrer Unterelementen ein Solid beliebigen LODSs vorhanden ist. Außerdem stellt die Datei sicher, dass jedes BuildingPart ein Solid enthält. Wenn dies nicht der Fall ist wird eine Fehlermeldung ausgegeben. Die Fehlermeldung ist dabei so formattiert, dass CityDoctor sie interpretieren und in das interne Datenmodell einbinden kann.

### Fehlerformat

Das Fehlerformat ist ein CSV-Format mit || als Trennzeichen

```
parent id||child id||error code||error type||is generic attribute
```
Die Fehlermeldung besteht aus den folgenden Teilen:

* Die `parent id` ist die gml id des obersten Elements z.B. Building oder Bridge. 
* Falls der Fehler in einem Unterelement aufgetreten ist so kann diese ID in dem Feld für die `child id` eingetragen werden.
* Im Feld `error type` ist einer der 3 Fehlertypen einzutragen: `SE_ATTRIBUTE_WRONG_VALUE, SE_ATTRIBUTE_MISSING, SE_ATTRIBUTE_INVALID`.

note
Nur in CityDoctor < 3.13.0:
* Um ein generisches Attribut mit dem Namen `measuredHeight` von dem nicht generischen Attribut zu unterscheiden ist im letzten Feld vorgesehen `true` einzutragen wenn es sich um ein generisches Attribut handelt ansonsten `false`.