Regeln für Teilnehmer:
Ich bin mit den Regeln einverstanden

Übersicht:

Favoritenliste:

Favourite Pages

There are currently no pages on your favourites list. You can add pages to this list by selecting Favourite from the Tools menu on the page you're viewing.
Child pages
  • Vorgaben Darstellungsdienste - 2017

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

              
Identifikator

Kapitel,

Abschnitt

(z.B. 2.1)

Paragraph,

Graphik,

Tabelle

(z.B. Tabelle 1)

Typ des

Kommentars

(redaktionell (r),

technisch (t),

grundsätzlich (g))

KommentarÄnderungsvorschlagOrganisationDatumAnmerkungen AK Geodienste
14.2.1.2Anforderung 10gDie Anforderung, wie eine Verlinkung eines Dienst-Metadatensatzes im Capabilities-Dokument zu erfolgen hat sollte nicht auf eine Empfehlung (Handlungsempfehlung) referenzieren.Besser: Nochmals explizit in Anforerungsdok. Benennen, da HE und Profil unterschiedliche Verbinflichkeiten haben.AK Metadaten / GDI-BW09.01.18

Leider gibt es kein verbindlicheres Dokument, dass diese Vorgehensweise regelt.

 

23Es wäre sinnvoll und für die Realisierer sehr hilfreich, wenn zu den Anforderungen und Empfehlungen ein dementsprechendes GetCap-Beispieldokument bereitgestellt wird (vgl. https://ims.geoportal.de/git/tree/AK-Metadaten.git/version1.2.0/konventionen!beispiel_xml).gDie Anforderungen/Empfehlungen sind leider nicht vollständig mit Beispielen erläutert, einen Gesamtüberblick im Anhang als eine GetCap-Datei ist nicht vorhanden.GetCap-Beispieldokument im Github bereitstellen.AK Metadaten / GDI-BW09.01.18Wird nachgeholt. Beispiele werden in github eingestellt.
34.2.2.Anforderug 12tAnforderung ist aus technischer Sicht nicht korrekt. Wird ein Dienst/Layer ausserhalb seines definierten Maßstabsbereiches angefragt, liefert dieser kein Bild. Dieses muss also noch nicht einmal transparent sein. Der Dienst reagiert technisch mit der "Auslieferung" von keinen Bildern, da bei korrekter Anfrage auch keine "Exception"-Logik kommt.entweder Anforderung 12 streichen, da nicht sinnvoll oder den Text umformulieren. "Leere Bilder" durch "keine Bilder" ersetzen.LVermGeo SH - Kst. GDI-SH19.01.18 
44.3.1.2.Anforderung 18gCopyrightvermerke sollten im digitalen Zeitalter insbesondere auf Bilddateien/-informationen möglich sein. Zumal die Metadatenanbindung in Clientsoftware und damit die Garantie, dass jeder Nutzer die Nutzungsrechte an einem Dienst liest, nicht immer gegeben ist. Hierbei ist darauf zu achten, dass Copyrightvermerke kurz und prägnant gehalten werden.Anforderung 18 als Empfehlung definieren:"Das ausgelieferte Kartenbild sollte frei von Informationen sein, die darauf abzielen Rechte zu sichern oder die bereitstellende Institution zu dokumentieren (z. B. Logos, Copyright-Symbole, Nutzungsbedingungen). Diese sind in den zugehörigen Metadaten zu dokumentieren."LVermGeo SH - Kst. GDI-SH19.01.18Anforderung wird zu Empfehlung und es kommt der Hinweis dazu, dass hier noch eine Entscheidung des AK Metadaten aussteht.
54.3.1.3.Anforderung 19tEine Mindestauflösung lässt sich nicht über die Parameter "MaxWidth" /"MaxHeight" angeben. Der Dienst wäre an dieser Stelle auf max 3000x3000 Pixel begrenzt und würde bei größeren Anfragen kein Bild liefern. Deshalb sollte der Satz umformuliert werden, um den Bedeutungen der Parameter gerecht zu werden. Ob in dem Zuge eine generelle Begrezung des WMS sinnvoll ist, in Anbetracht dessen das Endgeräte stetig bessere Auflösungen darstellen können, sollte hinterfragt werden.Anforderung 19 ändern: Auflösung des WMS Profils der AdV übernehmen. (max. 1200 x 1200 Pixel). Zudem sollte der Satz umformuliert werden. "Darstellungsdienste auf Basis einer WMS Schnittstelle sollten in der Lage sein, Bilder bis zu einer Größe von 1200x1200 Pixel ausliefern zu
können."
LVermGeo SH - Kst. GDI-SH19.01.18Über Vorgabe wurde schon im September abschliessend abschließend durch Mehrheitsbeaschluss Mehrheitsbeschluss entschieden. Formulierung wurde leicht angepasst.
64.4.2.ganzes KapitelgIn Anbetracht dessen, dass die bisherigen Caches vorwiegend in den Zoomstufen des WebAtlasDE-TileMatrixSet, welches von Google abgeleitet wurde, gerechnet wurden, sollten diese auch als Anforderung definiert werden. Zusätzlich sollte das TileMatrixSet gdi_de_25832 als Empfehlung angegeben werden. Eine Empfelung als alleinige Definition sagt nichts über die Mindestanforderungen für ein WMTS aus.TileMatrixSet des WebatlasDE als Anforderung ergänzen. TileMatrixSet gdi_de:25832 als Empfelung zusätzlich beibehalten.LVermGeo SH - Kst. GDI-SH19.01.18Über Festlegung wurde im September per Mehrheitsbeschluss abschliessend abschließend entschieden.
74.2.1Tabelle 1gDie Nutzbarkeit der Dienste muss dringend verbessert werden (bessere Auffindbarkeit). Grundsätzlich würde ich eine Mindestanzahl von Keywords als verpflichtend ansehen.Keywords als verplichtenden Parameter kennzeichnen.LVermGeo SH - Kst. GDI-SH19.01.18Unzureichende Festlegung welche keywords angegeben werden sollen. Vorschlag wird verworfen.
84.2.2Tabelle 2tname für WMS 1.1.1/WMS 1.3.0 sollte verpflichtend markiert werden (grau), sonst technisch nicht ansprechbarname für WMS 1.1.1/WMS 1.3.0 als verpflichtend markierenLVermGeo SH - Kst. GDI-SH19.01.18Zurückstellen – Bedeutung der Problematik ist dem AK klar.
94.3.3Abschnitt 1r"eigene Dienste zu
aufzusetzen und diese"
das Wort "zu" streichenLVermGeo SH - Kst. GDI-SH19.01.18 
101Inhaltsverzeichnisr4.1 Grundsätzlichdas ist kein Name einer Überschrift, entwerder "Allgemeine Angaben" oder "Grundsätzliche Angaben"LGB25.01.2018 
113Hinweise zum DokumentrATS dienen als
Grundlage für die Entwicklung automatisierter Überprüfungen zu Vorgaben aus diesem Dokument,
durch die Testsuite der GDI-DE.
ATS dienen als
Grundlage für die Entwicklung automatisierter Überprüfungen zu Vorgaben aus diesem Dokument, welche durch die Testsuite der GDI-DE durchgeführt werden.
LGB25.01.2018 
122AnwendungsbereichtDie Anforderungen und Empfehlungen bauen auf den internationalen Standards und Normen des
OGC sowie den ISO-Normen auf.
Die Anforderungen und Empfehlungen bauen auf den internationalen Standards und Normen des W3C, des
OGC sowie den ISO-Normen auf.
LGB25.01.2018 
134.1ÜberschriftrBesser Substantiv als Adjektiv als Überschrift verwendenGrundsätze statt Grundsätzlich schreibenLGB25.01.2018siehe 10
144.1.2Persistenz / IdentitätrService Oriented ArchitecureService Oriented ArchitectureLGB25.01.2018 
154.2Metadaten (in Capabilities und ISO Dokumenten)rZusätzlich zu den Metadaten in den Capabilities-Dokumenten des Dienstes, ist ein ISO 19139
Dokument zu erstellen und im Internet zu publizieren.
Zusätzlich zu den Metadaten in den Capabilities-Dokumenten des Dienstes, ist ein ISO 19139
Dokument zu erstellen und im Internet zu publizieren. (Komma weg)
LGB25.01.2018 
164.2Absatz 2rSatzbauZusätzlich zu den Metadaten ist in den Capabilities-Dokumenten des Dienstes, ein ISO...LGB25.01.2018Der Sinn wurde hier wahrscheinlich falsch verstanden.
174.2.1Service Level Metadatenrbeinhalten bedingt vor zuhaltende Informationenvorzuhaltende wird zusammen geschriebenLGB25.01.2018 
184.2.2Content Level Metadaten im Capabilities -Dokumentrbeinhalten bedingt vor zuhaltende Informationenvorzuhaltende wird zusammen geschriebenLGB25.01.2018 
194.2.2Content Level Metadaten im Capabilities -DokumentrDaten-Dienste KopplungDaten-Dienste-Kopplung (Bindestrich zwischen Dienste und Kopplung)LGB25.01.2018 
204.2.2Content Level Metadaten im Capabilities -Dokumentru.a.u. a. (mit Leerzeichen)LGB25.01.2018 
214.2.2Content Level Metadaten im Capabilities -DokumenttAnforderung 13: Bei "Zoom to Layer" müssen Geometrien (ggf. generalisiert) sichtbar sein.Anforderung 13: Die angegebene <BoundingBox> muss der minimalen umfassenden
Begrenzung der bereitgestellten Daten entsprechen und die Geometrien der Daten bei maximaler Ausdehnung darstellen (ggf. generalisiert).
LGB25.01.2018Formulierung klarer gefasst.
224.2.2Absatz zwischen Anforderung 12 und 13teine BoundingBox begrenzt einen geographischen Bereichgeometrisch mit geographisch ersetzenLGB25.01.2018 
234.3.1.3Text und AnforderungtText und Anforderung 19 wiedersprechen sich, denn ein Bild mit 3000x3000 Pixel ist groß.Bitte großes Bild (z.B. durch Pixelangabe) definieren.LGB25.01.2018 
244.3.2Sachdatenr,t, FrageEs ist nicht vermerkt, ob die Unterstützung von GetFeatureInfo freiwillig oder verpflichtend ist. Evtl. Unterkapitel?GetFeatureInfo muss unterstützt werden.LGB25.01.2018Erläuternden Text hinzugefügt.
254.3.2.1FormateFrageWarum nicht auch text/plain unterstützen?Anforderung 20: Für die Operation GetFeatureInfo sind zumindest der MIME-Type
text/html und text/plain als valides Rückgabeformat zu unterstützen.
LGB25.01.2018Das Format text/plain wird nicht grundsätzlich ausgeschlossen. Vorteile einer Verpflichtung sind dem AK nicht klar.
264.3.3Styles / LegendenrIn diesem Fall wird empfohlen, eigene Dienste zu
aufzusetzen und diese mittels einfacher Authentifizierungsverfahren den jeweiligen Gruppen
zugänglich zu machen.
In diesem Fall wird empfohlen, eigene Dienste zu
aufzusetzen und diese mittels einfacher Authentifizierungsverfahren den jeweiligen Gruppen zugänglich zu machen. ("zu" muss weg)
LGB25.01.2018siehe 9
274.3.3Absatz zwischen Empfehlung 14 und 15r Das Anzeigen von Legenden zu dem dargestellten Inhalt..LGB25.01.2018 
284.4.1WMSr,t, FrageFür die Brandenburger wäre eine Unterstützung von EPSG:25833 zumindest als Ergänzung zu Empfehlung 19 hilfreich! Technisch stellt dies ohnehin (auch im Falle einer Anforderung) keine Hürde dar…Empfehlung 19: WMS sollen Anfragen auch für folgende
Koordinatenreferenzsysteme unterstützen: EPSG:25833, EPSG:3857 und EPSG:3035.
LGB25.01.2018Dem Änderungswunsch wurde entsprochen.
294.4.2WMTSrMit Hilfe
des well-known sclae set kann ein Client entscheiden ob ein WMTS eingesetzt werden kann oder
nicht.
Mit Hilfe
des well-known scale set kann ein Client entscheiden, ob ein WMTS eingesetzt werden kann oder
nicht. (das Wort "scale" und ein Komma nach "entscheiden")
LGB25.01.2018 
304.9Absicherungr7 Hier ist darauf hinzuweisen, dass die HTTP-BASIC Authentication Nutzername und Passwort im Klartext im HTTP
header überträgt und daher nur über eine sichere https-Verbindung genutzt werden sollte.
Groß- und Kleinschreibung nicht mischen. HTTP und https, header oder HeaderLGB25.01.2018Nach eingehender Recherche ist HTTP Header und HTTPS-Verbindung die gebräuchliche deutsche Bezeichnung. Die Schreibweise wurde angepasst.
315.11WMTS (TileMatrixSet - 4.4.2)gVor diesem Hintergrund hat sich der AK zur Festlegung des unter Empfehlung 20: augeführten
well-known scale set mit der Bezeichnung gdi_de_25832 entschlossen.
Vor diesem Hintergrund hat sich der AK zur Festlegung des unter Empfehlung 20: augeführten
well-known scale set mit der Bezeichnung gdi_de_25832 entschlossen.
Empfehlung 20 ist ein Link, aber auf den ersten Blick nicht ersichtlich.
LGB25.01.2018Referenzen werden im Rahmen der Schlussredaktion umformatiert.
325.14Verwendung von CORS Headern (4.8)r(z. B. Session-Cookies oder HTTP-Authentifizierungsdaten)HTTP (TTP ist kursiv)LGB25.01.2018 
335.3Persistenz / Identität (4.1.2)rUm die dauerhafte Referenzierbarkeit von URLs zu gewährleisten, kann es sinnvoll sein diese von
einem zentralen HTTP-Proxy ausliefern zu lassen.
Komma nach "sein"LGB25.01.2018 
345.3Persistenz / Identität (4.1.2)rZieht einer der verteilten Server um, wird die updateSequence der Dokumente geändert und die
angeschlossenen Systeme (bzw. Nutzer) sind prinzipiell in der Lage die Änderungen
nachzuvollziehen.
Komma nach "Lage"LGB25.01.2018 
355.3Persistenz / Identität (4.1.2)r(wie sie INSPIRE fordert)(wie von INSPIRE gefordert) - "sie" ist zu personalisiertLGB25.01.2018 
36Anforderung 1 rDie Vorgabe ist an sich in Ordnung - allerdings sollte zum besseren Verständnis vielleicht besser auf eine technische Sicht (und nicht auf die verwendete logische Sicht) abgestellt werden.Wird ein Datensatz als Dienst bereitgestellt, so muss mindestens die OGC WMS-Schnittstelle angeboten werden.Geobasis NRW26.01.18 
37Anforderung 8 gDie Festlegung ist zu überarbeiten, denn es kann auch mehrere gmd:otherconstraints/gmx:anchor-Elemente geben, die sich auf gmd:accessConstraints bzw. gmd:useConstraints beziehen. In diesem Fall müsste klargestellt werden, wie die Abbildung in nur EIN Freitextfeld erfolgen soll.

Weiterhin ist die unveränderte Wiedergabe des Inhalts des gmx:Anchor-Elements nur wenig nutzerfreundlich (Beispiel: "xlink:href="http://inspire.ec.europa.eu/metadata-codelist/ ConditionsApplyingToAccessAndUse/noConditionsApply"> No conditions apply to access and use"). Clienten werten dies auch noch nicht aus. Man sollte sich auf lesbaren Freitext beschränken.
Das Fees-Element aus dem Capabilities-Dokument muss mindestens die Nutzungsbedingungen aufführen.

[Regelung gem. Entwurf AdV-OWS-Basisprofil Version 1.0.0 mit Stand vom 19.10.2017 Anforderung 16]
Geobasis NRW26.01.18Hinweis auf Metadatenkonventionendokument eingefügt.
38Anforderung 9 gDie Festlegung ist zu überarbeiten, denn es kann auch mehrere gmd:otherconstraints/gmx:anchor-Elemente geben, die sich auf gmd:accessConstraints bzw. gmd:useConstraints beziehen. In diesem Fall müsste klargestellt werden, wie die Abbildung in nur EIN Freitextfeld erfolgen soll.

Weiterhin ist die unveränderte Wiedergabe des Inhalts des gmx:Anchor-Elements nur wenig nutzerfreundlich (Beispiel: "xlink:href="http://inspire.ec.europa.eu/metadata-codelist/ ConditionsApplyingToAccessAndUse/noConditionsApply"> No conditions apply to access and use"). Clienten werten dies auch noch nicht aus. Man sollte sich auf lesbaren Freitext beschränken.
Sofern Zugriffseinschränkungen existieren, sind diese als Freitext in dem accessConstraints-Element aus dem Capabilities-Dokument anzugeben.

[Regelung gem. Entwurf AdV-OWS-Basisprofil Version 1.0.0 mit Stand vom 19.10.2017 Anforderung 17]
Geobasis NRW26.01.18Lässt sich ohne Weiteres nicht lösen. Referenz auf Metadatenkonventionendokument eingefügt.
39Anforderung 11, Tabelle 2 g, t(a) Damit die Layer eines WMS angesprochen werden können, sind die name-Elemente zwingend erforderlich. Insofern sollten name-Elemente nicht nur optional sein (gleichwohl der OGC-Standard dies zulässt)

(b) Forderung nach metadataURL steht im Konflikt mit Anforderung 14, nach der nicht zwangsweise Metadatensätze existieren müssen.
(a) Das name-Element sollte verpflichtend gefordert werden

(b) metadataURL sollte bedingt verpflichtend sein (fett und unterstrichten)
Geobasis NRW 

(a) wurde schon erläutert – Nummer nachtragen

(b) wurde in Tabelle angepasst

40Empfehlung 20 gEs handelt sich zwar nur um eine Empfehlung - dennoch sollte nicht von dem weit verbreiteten und auch von INSPIRE (TG view service 5.2.7 Interoperability: TileMatrixSet) und in der AdV (AdV-Profil zum WMTS Version 1.0.0) standardisierten Google-TileMatrixSet (Quasi-Standard) abgewichen werden: darunter leidet die Interoperabilität!
Die Begründung, dass gerade Maßstäbe erforderlich/gewünscht sind, kommt aus der alten analogen Welt. In der digitalen Welt benötigt man keine geraden Maßstäbe mehr. Der Druck gerader Maßstäbe ist von dem verwendeten TileMatrixSet ebenfalls unabhängig.
Empfehlung oder Anforderung für das - auch von der INSPIRE/AdV vorgegebene - Google TMSGeobasis NRW Begründung angepasst
41Anforderung 21 g, t(a) Es sollte klargestellt werden, dass sich die Anforderung nur auf Layer bezieht, die queryable sind.

(b) Die technische Realisierung dieser Anforderung ist vermutlich nicht unproblematisch und nur durch besondere Implementierung zu lösen.

(c) Die Verwendung eines class-Attributes bringt nur etwas, wenn auch der Client den Response auswerten kann. Wenn, dann sollte zusätzlich ein Klartext gefordert werden, der über den Fehler Auskunft gibt. Allerdings gilt ohnehin (b), so dass grundsätzlich auf eine solch proprietäre Lösung verzichtet werden sollte.
(a) Klarstellung in der Anforderung

besser:
(b und c) Anforderung vollständig entfallen lassen
Geobasis NRW26.01.18

(a) erledigt – siehe Punkt weiter oben

(b) erläutert

(c) ist Sache des Diensteanbieters und wird nicht verhindert

42Anforderung 26 g, tDie OGC Specifikation sieht vor, "A WMTS Server SHOULD support KVP and/or RESTful." A WMTS client SHOULD support both KVP and RESTful." Wenn ein konformer Klient ohnehin KVP und REST unterstützen muss, gibt es keinen Grund das KVP-Binding als verpflichtend zu definieren. Die REST-Unterstützung ist eindeutig zu bevorzugen. Nr. 11.5 der OGC Spezifikation hebt die Vorteile des REST-Bindings im Hinblick auf das Cachen explizit hervor.
Das REST-Binding im WTMS vereint alle Vorteile und ist auch der Hauptgrund warum es überhaupt diesen OGC Standard gibt: Serverseitiges sowie Clientseitiges cachen wird hiermit erst vollumfänglich möglich. Der einfache Betrieb ist ein weiteres Argument. REST – WMTS können ohne komplexe Serversoftware betrieben werden, beim KVP-Binding sieht das anders aus. Weit verbreitete Konzepte der Lastverteilung und Cache-Lösungen aus dem normalen „nicht-GIS-Umfeld“ können ohne Integrationsaufwand eingesetzt werden. (-> Vereinheitlichung IT-Betrieb -> Verfügbarkeit -> Kosten)
Ein WMTS muss KVP und/oder RESTful unterstützen.Geobasis NRW26.01.18Erledigt – da ist wohl ein Fehler bei der Übertragung passiert.
434.1.13. Absatzr…die meisten Server die neuere WMS Version 1.3.0 [ISO 19115:2003],……die meisten Server die neuere WMS Version 1.3.0 [ISO 19115:2003],…GeoSN26.01.208 
444.1.2Empfehlung 2rFormulierung im ganzen SatzDer UPDATESEQUENCE Parameter der GetCapabilities Operation sollte unterstützt werden.GeoSN26.01.208 
454.1.3Empfehlung 4gSo kurz wie möglich bedeutet auch, dass die Layernamen durchnummeriert werden können was z.B. der ArcGIS-Server standardmäßig durchführt. Das führt hinsichtlich der Erläuterungen bei 4.1.2 Persistenz / Identität zu Problemen.
Insofern sollten eindeutige Kurznamen, welche auch beim Wechsel der Reihenfolge oder Ergänzen einzelner Layer nicht geändert werden und stabil bleiben, genutzt werden.
Die Länge der Zeichenkette des Layernamen bzw. -identifikators sollen möglichst zwischen 5 und 20 Zeichen betragen. Ein durchnummerieren der Layer ist nicht zulässig.GeoSN26.01.208Soweit dem AK bekannt, können auch in ArcGIS bei Bedarf statische Layernamen definiert werden. Die genaue Festlegung der Länge der Zeichenkette wird als sinnvoll angesehen.
464.1.4Empfehlung 5gEs werden keine Angaben zu Kapazität und Performance abgegeben. INSPIRE macht hier entsprechende Vorgaben.Die Dienste sollten den INSPIRE Qualitätskriterien hinsichtlich Verfügbarkeit, Kapazität und Performance entsprechen.GeoSN26.01.208Da Kapazität und Performance stark von der Art der Daten und den zwischengeschalteten Transformationen abhängt, nimmt der AK Abstand von diesbezüglichen Festlegungen. Außerdem geht es im vorliegenden Dokument nicht nur im INSPIRE Dienste.
474.1.4Empfehlung 5tBei dem Qualitätsparameter Verfügbarkeit kommt es öfters zur Frage inkl. oder exkl. Wartungsfenster, gleichermaßen wo gemessen wird am Server oder an externen Client.
Das BKG selbst führt einen Nachweis über bekannte Ausfälle. Das sollte man ebenfalls empfehlen.
Erläuterungen, wie Verfügbarkeit definiert ist, ggf. als Fußnote ergänzen.
Liste der bekannten Ausfälle im Sinne eines Monitorings, als Empfehlung ergänzen.
GeoSN26.01.208

Ein Hinweis auf die maximale Ausfallzeit ist eingefügt.

Das Dokument macht keine Empfehlungen für den Betrieb einer Diensteinfrastruktur sondern formuliert nur die für eine interoperable Bereitstellung erforderlichen Vorgaben.

484.2.1Abschnitt nach Anforderung 7r… beinhalten bedingt vor zuhaltende Informationen …... beinhalten bedingt vorzuhaltende Informationen …GeoSN26.01.208siehe 17
494.2.1Tabelle 1
Country
r/gmd:MD_Metadata/ggmd:identificationInfo/srv:SV_ServiceIdentification/gmd:pointOfContact/gmd:CI_ResponsibleParty/gmd:contactInfo/gmd:CI_Contact/gmd:address/gmd:CI_Address/gmd:country/gco:CharacterStringgmd:MD_Metadata/gmd:identificationInfo/srv:SV_ServiceIdentification/gmd:pointOfContact/gmd:CI_ResponsibleParty/gmd:contactInfo/gmd:CI_Contact/gmd:address/gmd:CI_Address/gmd:country/gco:CharacterStringGeoSN26.01.208 
504.2.1Tabelle 1
Fees
g/gmd:MD_Metadata/gmd:identificationInfo/srv:SV_ServiceIdentification/gmd:resourceConstraints/gmd:MD_LegalConstraints/gmd:useConstraintsnach Konventionendokument 3.2 wird fees im XPATH /gmd:MD_Metadata/gmd:identificationInfo/srv:SV_ServiceIdentification/gmd:resourceConstraints/gmd:MD_LegalConstraints/gmd:useLimitation/gco:CharacterString eingetragenGeoSN26.01.208 
514.2.1Tabelle 1
AccessConstraints
g/gmd:MD_Metadata/gmd:identificationInfo/srv:SV_ServiceIdentification/gmd:resourceConstraints/gmd:MD_LegalConstraints/gmd:accessConstraintsder erste Xpath wäre /gmd:MD_Metadata/gmd:identificationInfo/srv:SV_ServiceIdentification/gmd:resourceConstraints/gmd:MD_LegalConstraints/gmd:accessConstraints/gmd:MD_RestrictionCode/@codeList

der zweite Xpath wäre z.Z. /gmd:MD_Metadata/gmd:identificationInfo/srv:SV_ServiceIdentification/gmd:resourceConstraints/gmd:MD_LegalConstraints/gmd:otherConstraints/gco:CharacterString

Die Realisierung durch Anchor-Elemente wird noch nicht von allen MDK unterstützt.
GeoSN26.01.208Anpassung der XPATH ist erfolgt, dabei wird in Kauf genommen, dass noch nicht alle Metadaten an die neuen Vorgaben von INSPIRE angepasst wurden.
524.2.1Tabelle 1
OnlineResource
ghier verpflichtendAuch nach Komventionendokument des AK Metadaten nicht verpflichtend.GeoSN26.01.208 
534.2.1Tabelle 1
KeywordList
r/gmd:MD_Metadata/gmd:identificationInfo/srv:SV_ServiceIdentification/gmd:descriptiveKeywords/gmd:MD_Keywords/gmd:MD_keyword/gco:CharacterString/gmd:MD_Metadata/gmd:identificationInfo/srv:SV_ServiceIdentification/gmd:descriptiveKeywords/gmd:MD_Keywords/gmd:keyword/gco:CharacterStringGeoSN26.01.208 
544.2.1Tabelle 1
AdressType
tleerist hier evtl. die Rolle gemeint? z.B.
/gmd:MD_Metadata/gmd:identificationInfo/srv:SV_ServiceIdentification/gmd:pointOfContact/gmd:CI_ResponsibleParty/gmd:role/gmd:CI_RoleCode
GeoSN26.01.208Nach Überprüfung gibt es kein ISO19115 Äquivalent zu diesem Element. Beispiel: ‚postal‘ für postalische Adresse.
554.2.1.1Stefan Röthig: @MD-Verantwortliche: Bitte techn. Hintergrund evaluieren/erläutern, z.B. + konkreter Inhalt des gmx:Anchor + verpflichtend bzw. Kardinalität + Ist immer ein lesbarer Text enthalten Anforderung 8
Anforderung 9
tDie Forderung ist unverständlich:
gmx:Anchor umfasst sowohl ein Link-Attribut als auch "freien" Text. Was von beidem soll in die Capabilities-Elemente von Darstellungsdiensten übernommen werden?
Weiterhin kann es mehrere otherConstraints-Elemente geben:
+ sollen dann alle übernommen werden?
+ wie sind diese zu verketten?
+ wie erfolgt an dieser Stelle der Umgang mit Fremdsprachen?
Festlegung des AdV-OWS-Basisprofils verwenden (derzeit läuft Beschlussfassung)GeoSN / AdV26.01.208Angepasst
564.2.1.2Anforderung 10r/gIn der vorangegangenen Version wurde noch ein Hinweis (wenngleich auch nur als Fußnote) für die erforderliche (ggf. manuelle) INSPIRE-Schemaerweiterung angeführt. Warum entfällt diese jetzt?Hinweis wieder aufnehmen, da er zur Beachtung finanzieller Mehraufwände bei der Umsetzung erforderlich ist!GeoSN26.01.208Dieser Hinweis wurde im letzten Review auf Wunsch anderer Stellen entfernt, da er redundant zu den Vorgaben in den Handlungsempfehlungen zu den INSPIRE View Services war und diese hier nur referenziert werden.
574.2.2TabelletDer Parameter dimension ist lt. OGC-Standard optional. Wenn GDI-DE diesen verpflichtet setzt, muss auch erläutert werden, welche Werte zulässig sind und welche nicht. OGC setzt diesen Parameter bewusst optional, da es sich um die Beschreibung einer 3. Dimension handelt (bspw. Höhe, Zeit, Temperatur). Bekanntermaßen fallen nur wenige Geodatendienste darunter. Eine klare Vorgabe für die Überführung 2-dimensionaler Daten in die 3. Dimension wäre also hilfreich. GeoSN26.01.208Die Angaben zu Dimension haben nur dann zu erfolgen, wenn sie auch anwendbar sind. Die Elemente sind als bedingt verpflichtend gekennzeichnet.
584.2.2Anforderung 12tWas soll zurückgeliefert werden, wenn das angefragte Bildformat keine Transparenz unterstützt? GeoSN26.01.208 
594.2.2Empfehlung 7g Diese Empfehlung gilt nur für INSPIRE-Geodatendienste - dies sollte hier auch entsprechend vermerkt werden.GeoSN26.01.208Die Empfehlung gilt für alle Dienste – Beispiel wurde angepasst.
604.2.2Anforderung 13gFormulierung ist missverständlich: Die BBOX zu groß anzugeben (z.B. weltweit) ist ebenfalls nicht sinnvoll und vermutlich auch nicht gemeint. Bitte ein Beispiel ergänzen, z.B. Datensatz eines Bundeslandes gibt BBOX der Außengrenzen des Bundeslandes wieder.
Ergänzend ist es ggf. problematisch, wenn zwar eine Flächendeckung vorgesehen, aber nicht generell vorhanden ist (z.B. Standorte Landesbehörden), welche nicht zwingend bis an die Landesgrenze reichen.
Formulierung prüfen, ggf. Beispiel ergänzen.GeoSN26.01.208Nach Meinung des AK ist die Anforderung ausreichend und klar beschrieben.
614.2.3Empfehlung 9rJe nach Dokumententyp ist im <Format> Tag …Je nach Dokumententyp sollte im <Format> Tag ...GeoSN26.01.208 
624.2.3Anforderung 16tDie strikte Forderung nach einem Verweis auf ein ISO19139 Dokument innerhalb der OnlineResource, kann missverstanden werden.
Es sollte generell eine Element MetadatenURL vorhanden sein, welches auf ein ISO19139 Dokument referenziert. Es kann aber zusätzlich auch eine MetadatenURL vom Typ HTML, welche nicht auf ein ISO19139 Dokument verweisen, verwendet werden.
Das xlink:href Attribut mindestens eines <OnlineResource> Elements verweist auf ein valides ISO19139 Dokument oder auf eine GetRecordById Response eines Katalogdienstes.GeoSN26.01.208 
634.2.3Anforderung 16tFrage: Wenn bei einem Layer verschiedene Datensätze aggregiert wurden und einzelne Metadatensatzbeschreibungen vorliegen, wird pro MDS eine MetadatenURL angelegt ? Der Client muss also ggf. pro Dienstelayer, mehrere Metadatenlinks anbieten. GeoSN26.01.208Formulierung wurde angepasst.
644.2.3Anforderung 16gDa viele Clients vorhandene HTML Ausgaben der ISO19139 Dokumente verwenden, sollten Ergänzend zu den URL's der XML Dokumente auch URL's zu der HTML Variante angegeben werden.Empfehlung ergänzen (nach Nr. 8): Für jede MetadatenURL mit OnlineResource auf ein ISO19139 Dokument soll ein korrespondierende MetdatenURL vom Typ HTML angegeben werden.GeoSN26.01.208Der erhöhte Aufwand bei der Bereitstellung von HTML Repräsentationen für die Datenbereitsteller ist vom AK nicht abschätzbar. Ein Mehrwert wird nicht gesehen.
654.2.3Empfehlung 9tPrüfen, ob die Angaben (für alle WMS Versionen) dem Standard entsprechen. Üblicherweise erfolgt die Angabe mit text/xml und text/html. GeoSN26.01.208Wurde geprüft, es handelt sich um eine Empfehlung die die Interoperabilität verbessern soll und diese geht über die Festlegungen der Spezifikationen hinaus.
664.3.1.2Anforderung 18r… die darauf abzielen Rechte zu sichern ...… die darauf abzielen, Rechte zu sichern ...GeoSN26.01.208 
674.3.1.3Anforderung 19tINSPIRE definiert das konkreter: Grafikformat ohne Transparenz, mit 800*600 Pixeln in max. 5 Sekunden. Eine ähnliche genaue Formulierung sollte auch für die maximale Bildgröße angegeben werden: Ist z.B. eine Bereitstellung in 60 Sekunden OK.? GeoSN26.01.208Hinweis an dieser Stelle falsch, da es hier nicht um Leistungsanforderungen geht.
684.3.1.3Anforderung 19tAnforderung erweitern bzw. neue ergänzen hinsichtlich Eintrag in den Capabilities. Muss dann dort auch zwingend 3000 Pixel enthalten sein, oder die maximal abrufbaren Bildgrößen z.B. 6000 Pixel, wenngleich bei einigen Konstellationen z.B. PNG32 mit Transparenz ein Timeout der Infrastruktur (ggf. nicht des Webservers) greift.Erläuterungen ggf. im Kapitel 5 ergänzen.GeoSN26.01.208Kommentierung unklar. Wir abgewiesen.
694.3.2.1Empfehlung 12r… sollte für die Operation GetFeatureInfo zusätzlich
application/vnd.ogc.gml (WMS 1.1.1) und application/vnd.ogc.gml/3.1.1
bzw. application/gml+xml; version=3.1 (WMS 1.3.0) als Rückgabeformat
unterstützt werden.
… sollten für die Operation GetFeatureInfo zusätzlich
application/vnd.ogc.gml (WMS 1.1.1) und application/vnd.ogc.gml/3.1.1
bzw. application/gml+xml; version=3.1 (WMS 1.3.0) als Rückgabeformate
unterstützt werden.
GeoSN26.01.208 
704.3.2.1Empfehlung 12tDie Nutzer der Geodatendienste in Sachsen, insbesondere aus dem E-Government-Bereich, haben sich als native Formate TXT und XML gewünscht.Format TXT und XML ergänzen.GeoSN26.01.208Es ist jedem unbenommen weitere Formate zu implementieren.
714.3.2.2Anforderung 21tDie ursprüngliche Forderung (s. u.) bleibt bestehen: Es ist nicht nachvollziehbar, warum in der GDI-DE in allen BL Mehraufwände erzeugt werden, wenn sich die Client-Unterstützung dafür maximal auf einen individuell entwickelten/angepassten Client beschränkt.
Eine nachvollziehbare Begründung für diese Vorgabe wurde bisher nicht geliefert.
EntfernenGeoSN26.01.208 
724.3.2.2Anforderung 21t/gWas soll das body-Tag konkret bewirken? Wenn ein anderer Inhalt in der zurückgelieferten HTML-Seite ausgegeben werden soll, müsste dieser auch beschrieben werden. Zudem müssten Client-Implementierungen eine einheitliche CSS-Definition verwenden.Klarstellung, dass die Umsetzung dieser Forderung finanzielle Mehraufwände nach sich zieht, ggf. in Empfehlung ändernGeoSN26.01.208Es geht nur darum, dass jeder Nutzer die Möglichkeit erhält leere Rückgaben als solche zu erkennen.
734.3.2.3Anforderung 22tEs wird nicht beachtet, dass oftmals über die Sachdatenabfrage auf Webclients von externen Fachinformationssystemen referenziert wird. Die Anforderung ist im Sinne der Barrierefreiheit global und damit auch für FIS gültig. Dazu passt aber nicht die Empfehlung 13, welche nicht mehr zeitgemäß wäre.Empfehlung 13 streichen.GeoSN26.01.208Die interoperable Nutzung von Diensten in verschiedensten Webanwendungen wird durch die Verwendung von aktivem Content verhindert. Webanwendungen dürfen meist keinen externen Javascript Code ausführen. Die Empfehlung bleibt so bestehen.
744.4.1Anforderung 23gErster Absatz zweiter Satz: Auf welche Quelle bezieht sich das?
Siehe Architektur der GDI-DE – Technik V 3.3.0 vom 01.08.2016: Seite 39, Standards für Projektionen: Maßstäbe > 1:500.000 (amtliches Bezugssytem der AdV): ETRS89/UTM zone 32 N (EPSG:25832) und ETRS89/UTM zone 33 N (EPSG:25833)
siehe Link in Spalte H
WMS müssen Anfragen zumindest für folgende
Koordinatenreferenzsysteme unterstützen: EPSG:25832, EPSG:25833 und EPSG:4326.
GeoSN26.01.208Die bewährte Festlegung wurde aus dem alten WMS-DE Profil von 2006 übernommen.
754.4.1Anforderung 24gIst entbehrlich, da es sich um eine INSPIRE-Anforderung handelt und nur für diese gelten soll.Anforderung in Anforderung 23 einfügen oder in Empfehlung 19 einfügen oder streichenGeoSN26.01.208Von INSPIRE gibt es keine Vorgabe eines einheitlichen CRS für alle bereitzustellenden Dienste. Hier gehen wir aus Gründen der Interoperabilität über die Anforderungen von INSPIRE hinaus.
764.4.2Tabelle 3tDie BoundingBox stimmt nicht mit den AdV-Vorgaben zu WMTS-Diensten überein.Die BoundinBox soll mit den Werten in Anhang 5 des AdV-Profil zum WMTS abgeglichen werden.GeoSN26.01.208Richtig, es handelt sich hier auch nur um eine Empfehlung. Siehe Erläuterungen.
774.4.2Tabelle 4tDas Kachelset für WMTS stimmt nicht mit dem in Zusammenarbeit mit dem BKG von der AdV festgelegten Kachelset überein.Entsprechend der AdV-Vorgaben korrigierenGeoSN26.01.208Richtig, es handelt sich hir auch nur um eine Empfehlung. Siehe Erläuterungen.
784.4.2Empfehlung 20gZu WMTS fehlt grundsätzlich eine Aussage, welche CRS unterstützt werden müssen. Hierzu eine Festlegung zu treffen, hat weitreichendere Konsequenzen als bei WMS, ist aber für die Interoperabilität erforderlich.Sachsen wird keinen WMTS mit Unterstützung EPSG: 25832 erzeugenGeoSN26.01.208Wegen der weitreichenden Konsequenzen werden vom AK keine Festlegungen diesbezüglich getroffen.
794.5Anforderung 25gWiderspricht der Vorgabe, dass die Dimension-Angabe in den Capabilities verpflichtend ist. Demnach müssen WMS-Dienste immer mehrdimensionale Angaben implementieren, nicht nur in den in der Anforderung genannten Fällen.Bezug: Anmerkung zu Tabelle 2 in 4.2.2: Angabe zu dimensionGeoSN26.01.208Wiederholung
804.7Gliederungr4.7 Festlegungen…
4.8 Verwendung…
Zwei Gliederungen???GeoSN26.01.208 
814.81. AbsatzrDie Bildquellen werden dabei i.d.R. direkt vom Browser des jeweiligen Nutzers angefragt (verteilte
Architektur auf Basis von HTTP ).
--> Leerzeichen vor schließender Klammer entfernen
Die Bildquellen werden dabei i.d.R. direkt vom Browser des jeweiligen Nutzers angefragt (verteilte
Architektur auf Basis von HTTP).
GeoSN26.01.208 
824.9Anforderung 27gEine Regelung zur Absicherung und den verwendeten Verfahren halten wir in diesem Dokument für entbehrlich. Eine Forderung, RFC2617 - HTTPAuthentication verwenden zu müssen, halten wir für falsch.EntfernenGeoSN26.01.208

Meinung wird vom AK so nicht geteilt.

 

834.9Anforderung 22gDie Absicherung richtet sich nach dem Schutzbedarf der Geodaten. Die verpflichtende Vorgabe eines eher unsicheren Verfahrens ist nicht sinnvoll.Anforderung 22 maximal als Empfehlung abgeben, besser streichen.GeoSN26.01.208Es sollen ja nicht alle Dienste geschützt werden. Es geht hier um die standardisierte Übertragung der Authentifizierungsinformationen und nicht um deren Absicherung. Hierzu muss https eingesetzt werden.
845.0Erläuterungeng Wozu dieses Kapitel? Ist für die Vorgaben nicht relevant und soll entfernt werden (Begründungen für Festlegungen aus dem "Kerndokument" entfernen).GeoSN26.01.208

Meinung wird vom AK so nicht geteilt.

 

855.3 gWas sollen die Beispiele aussagen. In beiden Capabilities werden die gleichen URL's bei den Operationen verwendet. Das erläuterte Vorgehen ist nachvollziehbar, allerdings werten aktuell nicht alle Clients den Inhalt der Capabilities entsprechend aus. Es wird teilweise davon ausgegangen, dass die URL der GetCapabilities Abfrage gleichermaßen für GetMap usw. verwendet wird.
Die Umsetzung durch jeden Diensteanbieter scheint ebenfalls nicht sinnvoll. Die Verwendung einer zentralen Registry wurde doch vorgestellt und sollte ausreichen.
Text umformulieren, Zielstellung erläutern.GeoSN26.01.208Die Unzulänglichkeiten der Clients liegen nicht im Fokus des Dokumentes. Die Einrichtung von persistenten URIs ist keine Anforderung, sondern nur eine Empfehlung, wenn sie auch für die Funktionsfähigkeit einer GDI unabdingbar  ist.
865.6 rmöglichst Beispiel(e) ergänzen 1417.410714 entspricht 1:1500 GeoSN26.01.2018Scheinbar wird hier eine Tabelle gefordert, die die Umrechnung von Maßstabszahlen bezüglich verschiedener dpi Vorgaben ermöglicht (90,714 → 96 unterschiedliche Interpretation ESRI/OGC) . Eine solche Aussage kann nicht Bestandteil eines zentralen Vorgabendokumentes sein, sondern muss je nach verwendeter Software eigenständig ermittelt werden.
875.3letzter Absatz "Ein zusätzlicher Vorteil…"gSchlussfolgerung/ Vorteil ist nicht nachvollziehbarbitte verdeutlichenKst. GDI-HH26.01.208Erklärung innerhalb der Tabelle nachliefern!
885.4erster Absatz, Satz 2 "Die techn. Handlungsempfehlunegn…"rFormatierung "Limitations on Public Access" falschändern in kursivKst. GDI-HH26.01.208 
895.5dritter Absatz, Satz 2 "Dieses Element soll…."rgemeint ist vermutlich "welches bereits für Zugriffsbeschränkungen verwendet wird"ändern in "Zugriffsbeschränkungen"Kst. GDI-HH26.01.208 
904.1.4.Empfehlung 5:redaktionellEmpfehlung 5: Die Dienste sollten eine Verfügbarkeit von mindestens 99% gewährleisten.

Für das Verständnis des Lesers erscheint es angebracht die Bedeutung von 99% Verfügbarkeit in Zeiteinheiten darzustellen. Für kritische Dienste ist eine Verfügbarkeit von 99% nicht ausreichend. Eine Verfügbarkeit von 99% entspricht einem Ausfall von 7,3h im Monat oder 87,6h bzw. 3,65 Tage im Jahr.
Empfehlung 5: Die Dienste sollten eine Verfügbarkeit von mindestens 99% gewährleisten. (Hinweis: Dies entspricht einer maximalen Ausfallzeit von im Schnitt 7,3h im Monat)ZGeoBw29.01.18 
914.1.5. redaktionellDie Inhalte von Textfeldern in der Antwort auf die GetCapabilities Anfrage werden grundsätzlich in
deutscher Sprache veröffentlicht. Sollen weitere Sprachen bereitgestellt werden, ist der den von
INSPIRE vorgesehene, zusätzliche Language Parameter zu nutzen.
Die Inhalte von Textfeldern in der Antwort auf die GetCapabilities Anfrage werden grundsätzlich in
deutscher Sprache veröffentlicht. Sollen weitere Sprachen bereitgestellt werden, ist der von
INSPIRE vorgesehene, zusätzliche Language Parameter zu nutzen.
ZGeoBw29.01.18siehe 111
924.3.3. redaktionellIn diesem Fall wird empfohlen, eigene Dienste zu
aufzusetzen und diese mittels einfacher Authentifizierungsverfahren den jeweiligen Gruppen
zugänglich zu machen.
In diesem Fall wird empfohlen, eigene Dienste
aufzusetzen und diese mittels einfacher Authentifizierungsverfahren den jeweiligen Gruppen
zugänglich zu machen.
ZGeoBw29.01.18siehe 9
934.3.3.Empfehlung 15:redaktionellBei der Bereitstellung von Grafiken über das <LegendURL>- Element im Layer Style soll vermieden werden, die Layer-Titel in die Ausgabegrafik zu rendern.
Was bedeutet diese Empfehlung konkret?
Keine textuelle Beschreibung im Image oder Verwendung von "Name" gegenüber "Title"?
 ZGeoBw29.01.18Es soll vermieden werden, dass sich die Referenzierung des jeweiligen Layers in der Legendendarstellung widerspiegelt. Die Zuordnung wird grundsätzlich vom Client verwaltet.
944.1.21. Zeile in Abschnitt 4.1.2, Seite 7redaktionellSchreibfehlerArchitectureBGR29.01.18siehe 14
954.1.52. Zeile in Abschnitt 4.1.5, Seite 9redaktionellSchreibfehlerIm Satz "den" streichenBGR29.01.18siehe 111
964.2.16. Zeile in Abschnitt 4.2.1, Seite 10redaktionellSchreibfehlerschreibe "vorzuhalten" in einem WortBGR29.01.18siehe 17
974.3.3Text nach Empfehlung 14, Seite 17redaktionellSchreibfehlerschreibe "Inhalten" (Plural), Komma ist überflüssigBGR29.01.18siehe 27
985.111. Satz auf S. 31redaktionellSchreibfehlerschreibe aufgeführten statt augeführten. Der vorhergehende Doppelpunkt kann entfallen.BGR29.01.18: wird automatisch gesetzt – muss noch kontrolliert werden – Endredaktion
99Gesamt redaktionelldoppelte LeerzeichenDas Dokument könnte nach doppelten Leerzeichen im Text durchsucht werden, die häufiger auftreten.BGR29.01.18 
1004.1.4Empfehlung 5g/tFür die Leistungsfähigkeit eines Dienstes sind neben der Verfügbarkeit weitere Parameter von Bedeutung:
- Antwortzeit
- Kapazität
- ….
Genauer zu spezifitieren ist, worauf sich die 99 % Verfügbarkeit (Ausfall, geplante Wartungsfenster, ...) beziehen.
Die Dokumentation (Monitoring) ist zu beschreiben.
Spezifizieren oder weglassenLandesamt für Geoinformation und Landesvermessung Niedersachsen (LGLN) - Landesvermessung und Geobasisinformation - Landesbetrieb -30.01.18siehe 46, 67, 68
1014.1.6 rDie Anforderung, Unicode zu verwenden, ist ohnehin eine Pflichtanforderung für die öffentliche Verwaltung. Sie resultiert aus einer Entscheidung des IT-Planungsrates: https://www.it-planungsrat.de/SharedDocs/Entscheidungen/DE/2014/Entscheidung_2014_04.html?nn=6844478 UTF-8 stellt also lediglich eine Präzisierung des inzwischen geforderten dar.Auf die Entscheidung 2014/04 des IT-Planungsrates verweisen, um den Gesamtzusammenhang darzustellen.GDI-NI30.01.18Diese Forderung war schon Bestandteil des Profils aus dem Jahr 2006 und hat eigentlich nichts mit dem IT-Planungsrat zu tun.
1024.3.1.2Anforderung 18gRechtliche Vorgaben erfordern die Darstellung von Copyright Vermerken.
Die Anforderung kann so nicht erfüllt werden.
Als Empfehlung formulierenLandesamt für Geoinformation und Landesvermessung Niedersachsen (LGLN) - Landesvermessung und Geobasisinformation - Landesbetrieb -30.01.18siehe 4
1034.4.2Empfehlung 20, Tabelle 3, Tabelle 4gNeben dem Well-known-scale-set gdi_de_25832 soll auch die für den WebatlasDE verwendete TileMatrixSet empfohlen werden.
Der WebatlasDE TileMatrixSet wurde in Anlehnung an Google-Vorgaben spezifiziert.
Hintergrund: Nutzer/Clients werden nicht ausschließlich mit amtlichen Daten arbeiten sondern auch Daten der Wirtschaft verwenden und kombinieren. Durch die starke Marktdurchdringung von Google ist davon auszugehen, dass die Festlegungen von Google hier Anwendung finden.
TileMatrixSet des WebatlasDE ergänzen.Landesamt für Geoinformation und Landesvermessung Niedersachsen (LGLN) - Landesvermessung und Geobasisinformation - Landesbetrieb -30.01.18siehe 6, 40, 76, 77, 78
1044.6.1Letzter SatzrUm das Risiko für Fehlfunktionen sowie die Flexibilität der Nutzung zu erhöhen, sollten alle Serverkomponenten neben HTTP GET auch HTTP POST unterstützen.
Es fehlt … zu minimieren ….
Um das Risiko für Fehlfunktionen zu minimieren sowie die Flexibilität der Nutzung zu erhöhen, sollten alle Serverkomponenten neben HTTP GET auch HTTP POST unterstützen.Landesamt für Geoinformation und Landesvermessung Niedersachsen (LGLN) - Landesvermessung und Geobasisinformation - Landesbetrieb -30.01.18 
1054.9Anforderung 27gDie besondere Schutzwürdigkeit von Daten erlaubt gegebenenfalls kein Standardverfahren zur Authentifizierung.
Hier sind weitergehende Sicherungs-Mechanismen erforderlich.
Zur Absicherung von Darstellungsdiensten muss grundsätzlich das Standardverfahren zur Authentifizierung von HTTP (RFC2617 - HTTPAuthentication) angeboten werden.
Weitere Fußnote:
Zum Schutz von Daten sind gegebenenfalls weitergehende Maßnahmen erforderlich.
Landesamt für Geoinformation und Landesvermessung Niedersachsen (LGLN) - Landesvermessung und Geobasisinformation - Landesbetrieb -30.01.18Weitere Schutzmechanismen werden nicht eingeschränkt. Der Hinweis auf die Nutzung von https ist vorhanden. Siehe auch 82, 83
1061.Anforderungen / S. 4rGliederung Nr. 4.1.3, 4.2.3, 4.7, 5.2 falsch und Zeilenumbruch 4.7Anpassung erforderlichLVermGeo LSA31.01.18Schlussredaktion
1071 Einleitung3. Absatzgfür die Referenz zum Klammerausdruck "SOA Prinzip" und den Verweis (Fußnote) sollte nicht "nur" auf Wikipedia, sondern zumindest auch auf das in der Architektur der GDI-DE existierende Grundsatzdokument "Technik" (S. 15) und auf SAGA (S. 19, 22) verwiesen werden (ggf. via neu erstelltem Shortlinks)in Fußnote 1 ergänzen:

Architektur der GDI-DE - Technik: http://www.geoportal.de/DE/GDI-DE/Arbeitskreise/Architektur/architektur.html?lang=de
(http://t1p.de/Architektur)

SAGA-Modul Technische Spezifikationen: https://www.cio.bund.de/Web/DE/Architekturen-und-Standards/SAGA/SAGA%205-aktuelle%20Version/saga_5_aktuelle_version_node.html;jsessionid=DD7A01B022B158A0FB1E1B147E7B09F1.1_cid350
(http://t1p.de/SAGA)
MLV
Sachsen-Anhalt
31.01.18 
1082Satz 4gWiderspruch
Wenn eine nahtlose Integration angestrebt wird, müssen auch die Anforderungen der INSPIRE-Durchführungsbestimmungen für GDI-DE WMS greifen (zum Beispiel die 99 % Verfügbarkeit).
Satz daher umformulieren: Um die Integration von INSPIRE und GDI-DE zu gewährleisten, werden hier keine Anforderungen und Empfehlungen getroffen, die einer INSPIRE-Konformität entgegenstehen.LVermGeo LSA31.01.18Der AK sieht keinen Änderungsbedarf.
1094.1.1Empfehlung 1gim Grundsatzdokument "Architektur der GDI-DE - Technik, S. 49" wird WMS Version 1.1.1 klassifiziert in "GDI-DE-auslaufend", hier aber neben WMS 1.3.0 zu Unterstützung empfohlen
Widerspruch?
bitte prüfen
bei Beibehalt wäre dies ggf. im Technik-Dokument nachführen (@AK Arch)
MLV
Sachsen-Anhalt
31.01.18Richtig. Arbeitsauftrag für AK Architektur.
1104.1.4Satz 1 und Empfehlung 5r"Verfügbarkeit von 99% für die Netzdienste"
"Verfügbarkeit von mindestens 99%"
es ist üblich, die Schreibweise der Verfügbarkeit von Netzdiensten um den Klammerausdruck zu "Tag und Stunde" zu ergänzen (s. bspw. "Architektur der GDI-DE - Technik" S. 54)
Duktus vereinheitlichen, mit:
"… Verfügbarkeit von 99 % (7*24) für die Netzdienste ..."
"… Verfügbarkeit von mindestens 99 % (7*24) ..."
MLV
Sachsen-Anhalt
31.01.18 
1114.1.5Absatz 1r"…werden, ist der den von INSPIRE…" korrigierenin "…werden, ist der von INSPIRE…"LVermGeo LSA31.01.18 
1124.1.6Anforderung 6g"Zeichenkodierung von textbasierten Rückgabewerten"
Ist der beschreibende Bezug zur Unterstützung zur Unicode-Zeichenkodierung herzustellen ("Lateinische Zeichen in UNICODE", Entscheidung 2014/04, Beschluss 13. Sitzung IT-PLR, ggf. Teilmenge)?
bitte prüfenMLV
Sachsen-Anhalt
31.01.18siehe 101
1134.2.1Tabelle 1tBeispiel aus Medatenkonventionen (WMS Capabilities Dokument): hier fehlt das Element ContactPosition.Bitte Prüfen und ergänzen.LVermGeo LSA31.01.18 
1144.2.3Empfehlung 9gEmpfehlung ist wie eine Anforderung formuliert.Bitte umformulieren: "Je nach Dokumententyp sollte im ... angegeben werden."LVermGeo LSA31.01.18siehe 61
1154.9Anforderung 27gneben Authentifizierung von HTTP RFC2617 werden im Grundsatzdokument "Architektur der GDI-DE - Technik, ab S. 62" drei weitere Spezifikationen mit RFC2616, RFC2817 und RFC2818 als "GDI-DE-grundlegend" klassifiziert ("Für diese Absicherung müssen Geodatendienste ... unterstützen.")bitte prüfenMLV
Sachsen-Anhalt
31.01.18Diese Technologien sind Bestandteil der Vorgaben zu den Diensten. Prüfauftrag an AK Architektur zur Fortschreibung des Technik Teils.
1165.4Absatz 1r"Limitations on Public Acces" kursiv schreiben, siehe nächster Absatz und "Conditions for Access and Use""Limitations on Public Acces", "Conditions for Access and Use"...Vereinheitlichung der SchreibweiseLVermGeo LSA31.01.18siehe 88
1175.4Beispiel Dienst-MetadatensatztXML-Tags gmd:MD_Restriction Code und gmd: otherConstraints korrigieren<gmd:resourceConstraints>
<gmd:MD_LegalConstraints>
<gmd:useConstraints>
<gmd:MD_RestrictionCode codeList="http://standards.iso.org/iso/19139/
resourEs gelten keine Bedingungen für die
Nutzung.ces/gmxCodelists.xml#MD_RestrictionCode"
codeListValue="otherRestrictions" />
</gmd:useConstraints>
<gmd:otherCEs gelten keine Bedingungen für die Nutzung.onstraints>
<gmx:Anchor xlink:href="http://inspire.ec.europa.eu/
metadata-codelist/ConditionsApplyingToAccessAndUse/noConditionsApply">
Es gelten keine Bedingungen für die Nutzung.
</gmx:Anchor>
</gmd:otherConstraints>
LVermGeo LSA31.01.18 
1185.4Beispiel Capabilities-DokumenttText an das Beispiel Dienst-Metadatensatz anpassen (oder umgekehrt). "Es existiert keine Beschränkung"

Fees (= useConstraints) sind die Angaben zu
Nutzungseinschränkungen/Nutzungsbedingungen und
AccessConstraints sind Angaben zu
Einschränkungen (siehe Tabelle unter 4.2.1)
<Fees>
Es gelten keine Bedingungen für die Nutzung.
</Fees>
<AccessConstraints>
Es existiert keine Beschränkung.
</AccessConstraints>
LVermGeo LSA  
1195.8Absatz 1 und
Abbildung 2 Bezeichnung
rverschiedene Bezeichnungen für gleichen SachverhaltVereinheitlichung:
Copyright Vermerke oder Copyright Signaturen
LVermGeo LSA  
1206.5"GDI-DE Vorgaben" (S. 35)gbei Umsetzung Kommentar 2 (1. Einleitung, 3. Absatz) Referenz zum "Technik-Dokument" ergänzen
(ggf. via neu erstelltem Shortlinks)
Architektur der GDI-DE -
Technik: http://t1p.de/Architektur

?
SAGA-Modul Technische Spezifikationen:
http://t1p.de/SAGA
?
MLV
Sachsen-Anhalt
31.01.18 
1214.2.2
Empfehlung 6
BildschirmauflösungtAdV und OGC-Angaben für WMS und WMTS gehen i.d.R. von 96 dpi und nicht von 90,714 dpi aus.96 dpi übernehmenKontaktstelle GDI-HE31.01.18Diese Aussage konnte nicht verifiziert werden. Nach dem referenzierten Dokumenten der OGC wird von 0.28mm ausgegangen, was einem dpi Wert von 90.714 entspricht.
1224.3.1.2
Anforderung 18
Copyright-Vermerkgtechnisch umsetzbar, aber es existieren Verwaltungsvorgaben, die die Darstellung des Copyright im Bild vorschreiben.Prüfergebnisse aus der Anfrage des AK Architektur vom 05.12.2017 einarbeitenKontaktstelle GDI-HE31.01.18siehe 4
1234.3.1.3
Anforderung 19
mindest BildgrößegDie Mindestpixelzahl von 3000x3000 ist technisch umsetzbar, aber es existieren tlw.Verwaltungsvorgaben zu zurückliefernden Bildgrößen.
Die AdV sieht beispielsweise Mindestgrößen von 1200x1200 Pixel vor.
als Empfehlung aussprechenKontaktstelle GDI-HE31.01.18siehe 5
1244.3.2.2
Anforderung 21
leere HTML SeitetMit GetFeatureInfo Abfragen, die kein Ergebnis erzielen, wird technisch in Abhängigkeit der Implementierung unterschiedlich umgegangen. Die Anforderung erscheint zu restriktiv ausgerichtet.als Empfehlung aussprechenKontaktstelle GDI-HE31.01.18siehe 41, 71
1254.4.2
Empfehlung 20
Tabelle 4: Well-known-scale-set gdi_de_25832 - ZoomstufentDie Festlegungen entsprechen nicht dem beschlossenen AdV-WMTS-Profil_V_1.0.0 (11.03.2014) bzw. zur Abstimmung V_2.0.0 (01.02.2016) A4 zu INSPIRE-Tile Matrix Set nach OGC-, INSPIRE-, AdV-Angaben.Werte an OGC-, INSPIRE-, AdV-Vorgaben anpassenKontaktstelle GDI-HE31.01.18siehe 6, 40, 76, 77, 78
126alleKopfzeilerDie Kopfzeile ist wie ein normaler Textabschnitt formatiert. Bei Texten die über mehrere Seiten irritiert die KopfzeileFormatierung ändern (Schriftart kleiner, Farbe: grau, etc) LDBV05.02.18 
127alleAbsätzerAbkürzungen, die aus mehreren Wörtern bestehen, werden im Dokument unterschiedlich wiedergegeben - mal zusammengeschrieben (z.B.) und mal getrennt (z. B.) geschrieben.Einheitliche Schreibweise verwenden, wobei aus mehreren Wörtern bestehende Abkürzungen auch getrennt abgekürzt werden (z. B.; i. d. R.) LDBV05.02.18 
128alleFußnotenreinheitliche Vorgehensweise zum Verweis auf Erläuterungen durch Fußnoten. Fußnote 3 verweist auf ausführliche Erläuterungenalle Verweise auf zusätzliche Erläuterungen durch Fußnoten kennzeichen LDBV05.02.18 
129Inhalts-verzeich-nis rFormatierungsfehler: Vor dem Inhaltverzeichnis steht "1. Anforderungen"Löschen des 1 Eintrages LDBV05.02.18 
1303Absatz 2, Satz 2rAusdrucksfehler: „… Überprüfung zu Vorgaben aus diesem Dokument, ...“Ändern zu: „… Überprüfung von Vorgaben aus diesem Dokument, ...“ LDBV05.02.18 
1313Absatz 3rRechtschreibfehler: „… Bezeichnungen von XML-Elementen, - Attributwerte und Code in eigener ...“Ändern zu: "… Bezeichnungen von XML-Elementen, -Attributwerten und Codes in eigener ...“ LDBV05.02.18 
1324.1.1Fußnote 3rFormatierung der Fußnote, Abstand zwischen Fußnote und Text zu geringFormatierung der Fußnote anpassen LDBV05.02.18 
1334.1.2Absatz 3, Satz 1rDie Schreibweise <Name>/<ows:Identifier> suggeriert eine Pfadangabe. Stattdessen sind hier vermutlich zwei verschiedene Elemente gemeint, die bei WMS bzw. WMTS existieren.Ändern zu: "… mit dem <Name> bzw. <ows:Identifier> Element ..." LDBV05.02.18 
1344.1.2Absatz 3rAus Formulierung geht nicht deutlich hervor, was gemeint ist.Änderung der Formulierung des Absatzes gemäß http://www.geoportal.rlp.de/mediawiki/index.php/Vorgaben_der_GDI-DE_zur_Bereitstellung_von_Darstellungsdiensten#Persistenz.2FIdentit.C3.A4t:
"Die eindeutige Referenzierung des Datensatzes (Layers) erfolgt dabei durch eine Kombination der URL des Servers mit dem <name> bzw. <identifier> Element des jeweiligen Layers. Dienst-URL und <name> bzw. <identifier> von Layern sollen nach Veröffentlichung eines Dienstes nicht mehr verändert werden."
 LDBV05.02.18 
1354.1.3Anforderung 4rRechtschreibfehler: "Layernamen, bzw. -identifikatoren…" --> Komma gehört da nicht hinÄndern zu: "Layernamen bzw. -identifikatoren…" LDBV05.02.18 
1364.1.3 tEs sollte eine Zusätzliche Festlegung zu Layernamen getroffen werden, damit gleichlautende Layer von Dienstanbieter aus unterschiedlichen Bundesländern unterscheidbar sind. Layernamen sollten daher grundsätzlich mit dem Kürzel des Bundeslandes anfangen. z. B. by_dopAufnahme einer weiteren Anforderung: "Laynamen bzw. -identifikatioren müssen mit dem Kürzel des Bundeslandes beginnen." LDBV05.02.18 Kann nicht Bestandteil eines allgemeinen Profils sein. Diese Regelungen sollten von den jeweils fachlich zuständigen Stellen aufgestellt werden.
1374.1.6Anforderung 6rAusdrucksfehler: „… Antworten auf GetCapabilities, GetFeatureInfo Requests sowie Service Exceptions, …"Ändern zu: „… Antworten auf GetCapabilities und GetFeatureInfo-Requests sowie Service Exceptions, …" LDBV05.02.18 
1384.2.3KapitelgKommentar wurde im ersten Review weder berücksichtigt noch bewertet, daher erneute Meldung:
Bei der Daten-Dienste-Kopplung fehlt eine Aussage, wie diese bei WMTS zu realisieren ist.
Das ganze Kapitel ist um Erläuterungen, Anforderungen und Empfehlungen für WMTS-Darstellungsdienste zu ergänzen. LDBV05.02.18 
1394.2.3Absatz 3tDie Aussagen zum Namensraum und dessen Muster entsprechen nicht der derzeit gültigen Konvention zur Bildung von Namensräumen in der GDI-DE (s. https://wiki.gdi-de.org/pages/viewpage.action?pageId=60981269). Festgelegt ist hier lediglich das Muster https://registry.gdi-de.org/id/de."&Bund-/Länderkürzel&"/". Die eventuelle Festlegung von Unternamensräumen ist aktuell Ländersache. Ggf. auf dem GDI-DE Ansprechpartner-Workshop im März 2018 getroffene, weitere Festlegungen müssen hier berücksichtigt werden. Die Verwendung eines Behördenkürzels wird in BY nicht als sinnvoll erachtet, da nicht persistent.Ändern in "... einem für alle Namensräume einheitlich definierten Präfix https://registry.gdi-de.
org/id/de. und einem Bund- bzw. Länderkürzel zusammen. Zusätzlich können Unternamensräume (z.B. Behördenkürzel) registriert werden. Beispiel: https://registry.gdi-de.org/id/de.rp.vermkv/2b009ae4-aa3eff21-
870b-49846d9561b2"
 LDBV05.02.18 
1404.2.3Absatz 3rDas Muster des Namensraumes ist in der jetzigen Form schwer lesbar.Einfügen eines Zeilenumbruchs nach „… wird nach folgendem Muster gebildet:“ LDBV05.02.18 
1414.2.3letzter Absatz, Satz 2rRechtschreibfehler --> Leerzeichen vorm Punkt des SatzendesLeerzeichen entfernen LDBV05.02.18 
1424.3.1.2Anforderung 18gKommentar wurde im ersten Review weder berücksichtigt noch bewertet, daher erneute Meldung:
Es muss im Ermessen des Datenanbieters bleiben, eine Copyright-Einblendung standardmäßig vorzusehen. Das ergibt sich aus den Rechten des Datenanbieters nach Art. 13 und 14 RL INSPIRE.
Es wird vorgeschlagen, Anforderung 18 zu streichen. Sofern sich die Anforderung 18 aus einer Rechtsquelle ergeben sollte, ist diese anzugeben. LDBV05.02.18siehe 4
1434.3.1.3Absatz 1, Satz 1rKomma fehlt: "… in der Regel einer Beschränkung um beispielsweise…"Ändern zu: "… in der Regel einer Beschränkung, um beispielsweise…" LDBV05.02.18 
1444.3.2.1Empfehlung 12rKommata zu viel bei "… Verbreitung, sowie … Formates, sollte… --> kein eingeschobener TeilsatzKommata entfernen LDBV05.02.18 
1454.3.3Absatz 1, Satz 3rungünstiger Satzbau: „Nicht sinnvoll ist es, ...“Ändern zu : „Es ist nicht sinnvoll, ...“ LDBV05.02.18 
1464.3.3Absatz 1, letzter SatzrWort zu viel: "…, eigene Dienste zu aufzusetzen…""zu" streichen: "…, eigene Dienste aufzusetzen…" LDBV05.02.18siehe 9
1474.4.1Absatz 2, Satz 2r2 Punkte am Satzendevorderen Punkt streichen LDBV05.02.18 
1484.4.1Anforderungen 23 und 24tKommentar wurde im ersten Review weder berücksichtigt noch bewertet, daher erneute Meldung:
EPSG:4258 ist im Dok. „Architektur der GDI-DE – Technik“, V. 3.3.0 nicht nur als INSPIRE-, sondern auch als GDI-DE-grundlegend eingestuft und damit für alle Dienste in der GDI-DE verpflichtend. Die Vorgaben aus dem Technik-Dokument müssen von allen Profilen eingehalten werden.
Aufnahme von EPSG:4258 in Anforderung 23 und Löschung von Anforderung 24. LDBV05.02.18 Problem erkannt – wird als Prüfauftrag an den AK Architektur weitergeleitet.
1494.4.2Absatz 1, letzter Satzrfehlendes Komma: „… kann ein Client entscheiden ob ein...“ändern zu: „… kann ein Client entscheiden, ob ein...“ LDBV05.02.18siehe 29
1504.4.2KapitelgKommentar wurde im ersten Review weder berücksichtigt noch bewertet, daher erneute Meldung:
Für die GDI ist es fatal, wenn unterschiedliche Gremien (AdV, GDI-DE) in Deutschland unterschiedliche Kachelsätze für ein Koordinatenreferenzsystem (EPSG:25832) eines WMTS definieren, die nicht miteinander kompatibel sind. Dies widerspricht dem Interoperabilitätsgedanken einer GDI. Zudem wird die Beratungsarbeit beim Kunden erschwert.
Zusammenarbeit aller Gremien, um einen gemeinsamen Deutschlandweit gültigen Kachelsatz festzulegen. LDBV05.02.18siehe 6, 31, 40, 76, 77, 78
1514.4.2TabelletKommentar wurde im ersten Review weder berücksichtigt noch bewertet, daher erneute Meldung:
Für gewöhnlich wird beim WMTS die Pixelgröße und die Maßstabszahl immer verdoppelt. In dieser Tabelle werden ganze Maßstabszahlen (…, 1000, 2500, 5000, …) festgelegt, die keine Verdopplung mitbringen können. Ein harmonischer Eindruck bei zoomen könnte beeinträchtigt werden.
Kachelsatz in Abstimmung mit anderen in Deutschland tätigen Gremien überarbeiten. LDBV05.02.18siehe 6, 31, 40, 76, 77, 78
1524.6.2Anforderung 26gKommentar wurde im ersten Review weder berücksichtigt noch bewertet, daher erneute Meldung:
Die restriktive Vorgabe zur verpflichtenden Unterstützung der KVP Variante ist nicht nachvollziehbar, da in Nr. 5.13 die Vorteile von RESTful genannt werden. Zudem unterstützt RESTful das HTTP-Caching besser.
Ändern zu: „Ein WMTS muss entweder die KVP- oder die REST-Variante unterstützen.“ LDBV05.02.18siehe 42
1534.7Abschnitt 4.8 / 4.9rFalsche Formatierung der Überschriften 4.8 und 4.94.8 und 4.9 ändern zu 4.7.1 und 4.7.2 LDBV05.02.18siehe 80
1544.8 (4.7.1)Absatz 1, Satz 3rLeerzeichen zu viel am Satzende: „… auf Basis von HTTP ).“Ändern zu: “...auf Basis von HTTP)“ LDBV05.02.18

siehe 81

1555.2Absatz 1, letzter Satzrfalsche Schriftgröße bei "EPSG:4326"Schriftgröße anpassen LDBV05.02.18 
1565.3Absatz 1, Satz 1rKomma fehlt: "… kann es sinnvoll sein diese von…"Komma fehlt: "… kann es sinnvoll sein, diese von…" LDBV05.02.18siehe 33
1575.3Absatz 1, Satz 2rRechtschreibfehler: "Nach Außen…"ändern zu: "Nach außen…" LDBV05.02.18 
1585.3Absatz 2, Satz 1rKomma zu viel: "… Registry, sowie…"Komma entfernen LDBV05.02.18 
1595.4Absatz 1, letzter Satz, letzter TermrFormatierung überprüfen bei "Conditions for Access and Use"ggf. Formatierung anpassen LDBV05.02.18siehe 88
1605.4Beispiel Dienst-MetadatensatzrFormatierungen für Hyperlinks überprüfen: Der erste Link unterstreicht freie Flächen, der 2., 3. und 4. Link wird nicht vollständig unterstichenLink richtig formatieren oder Hyperlinks entfernen LDBV05.02.18 
1615.12Absatz 3rSatzbau: "… erlauben eine interoperable Nutzung solcher Datenquellen, durch die Verwendung des WMS …"Ändern zu : „… erlauben durch die Verwendung des WMS Dimension Parameters eine interoperable Nutzung solcher Datenquellen.“ LDBV05.02.18 
1625.14Absatz 1, Sätze 3 und 4rfalsche Schriftgröße bei "Access-Control-Allow-*" und "Access-Control-Allow-Origin"Schriftgröße anpassen LDBV05.02.18Wirkt nur größer – ist eigentlich die Standardgröße 12pt