Nachfolgend sind die uns bekannten Probleme in den einzelnen Versionen aufgeführt:

Deegree allgemein:

• keine Authentifizierung möglich
• sehr rudimentäre Oberfläche für Konfiguration und Datensatzmanagement

Deegree 2.2

• Das Language-Tag wird von Deegree umgewandelt, so dass die Sprache nicht als Unterknoten 'LanguageCode' sondern nur als Zeichenkette (gco:CharacterString) ausgegeben wird. Dies wird von einigen CSW's nicht interpretiert.
• Datumsangaben in Form des XML-Knotens 'Date' wandelt der Deegree automatisch in einen DateTime-Knoten um. Auch das machte bei anderen CSW's Probleme, auch wenn es standardkonform ist.
• Unterstützt bei GetRecord mit Filter noch kein 'PropertyIsNotEqualTo'

Deegree 2.4

• Der XML-Knoten 'Language' wird jetzt mit Untertag LanguageCode ausgegeben, wenn so importiert, was erst mal korrekt ist. Leider wird das Language-Kürzel nur als codeListValue-Wert ausgegeben aber nicht noch einmal wiederholt als Werte des LanguageCode-Tags (rot fehlt):
  
  <gmd:language>
<gmd:LanguageCode codeList="LanguageCode" codeListValue="ger">ger</gmd:LanguageCode>
</gmd:language> 
• das Problem mit den Datumsangaben (siehe Version 2.2) besteht weiterhin
• POST-Anfragen mit dem Befehl 'GetRecords' werden zwar mit einem UTF-8-kodierten Ergebnis-XML beantwortet, im Response-Header wird aber der Content-Header mit einem falschen Encoding rausgegeben:
  Content-Type: text/xml;charset=windows-1252 
richtig wäre: Content-Type: text/xml;charset=UTF-8
(scheint nur in der Version 2.4 aufzutreten)
  Das Problem kann von FiddlerScript ab 1.1.9 mit der Option forceResponseHeaderCharsetUtf8 korrigiert werden.

Deegree 3.0.4

• das Problem mit dem Language-Tag (siehe Version 2.4) besteht weiterhin

Um den Deegree trotzdem zu betreiben hatten wir die Lösung gefunden, Fiddler als ReverseProxy zwischenzuschalten (als Dienst installiert). Für diesen rüstet dann ein Skript die fehlenden Authentifizierung des CSW nach und korrigiert einige Probleme in den Anfragen und Antworten.