Übersicht:
Favoritenliste:
Favoritenseiten
| Ihre Favoritenliste enthält derzeit keine Seiten. Sie fügen dieser Liste Seiten hinzu, indem Sie im Menü Extras der angezeigten Seite Favorit selektieren. |
Seitenhistorie
...
| 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 | Änderungsvorschlag | Organisation | Datum | Anmerkungen AK Geodienste |
|---|---|---|---|---|---|---|---|---|
| 1 | 4.2.1.2 | Anforderung 10 | g | Die 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-BW | 09.01.18 | Leider gibt es kein verbindlicheres Dokument, dass diese Vorgehensweise regelt.
|
| 2 | 3 | Es 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). | g | Die 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-BW | 09.01.18 | Wird nachgeholt. Beispiele werden in github eingestellt. |
| 3 | 4.2.2. | Anforderug 12 | t | Anforderung 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-SH | 19.01.18 | |
| 4 | 4.3.1.2. | Anforderung 18 | g | Copyrightvermerke 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-SH | 19.01.18 | Anforderung wird zu Empfehlung und es kommt der Hinweis dazu, dass hier noch eine Entscheidung des AK Metadaten aussteht. |
| 5 | 4.3.1.3. | Anforderung 19 | t | Eine 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-SH | 19.01.18 | Über Vorgabe wurde schon im September abschliessend abschließend durch Mehrheitsbeaschluss Mehrheitsbeschluss entschieden. Formulierung wurde leicht angepasst. |
| 6 | 4.4.2. | ganzes Kapitel | g | In 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-SH | 19.01.18 | Über Festlegung wurde im September per Mehrheitsbeschluss abschliessend abschließend entschieden. |
| 7 | 4.2.1 | Tabelle 1 | g | Die 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-SH | 19.01.18 | Unzureichende Festlegung welche keywords angegeben werden sollen. Vorschlag wird verworfen. |
| 8 | 4.2.2 | Tabelle 2 | t | name für WMS 1.1.1/WMS 1.3.0 sollte verpflichtend markiert werden (grau), sonst technisch nicht ansprechbar | name für WMS 1.1.1/WMS 1.3.0 als verpflichtend markieren | LVermGeo SH - Kst. GDI-SH | 19.01.18 | Zurückstellen – Bedeutung der Problematik ist dem AK klar. |
| 9 | 4.3.3 | Abschnitt 1 | r | "eigene Dienste zu aufzusetzen und diese" | das Wort "zu" streichen | LVermGeo SH - Kst. GDI-SH | 19.01.18 | |
| 10 | 1 | Inhaltsverzeichnis | r | 4.1 Grundsätzlich | das ist kein Name einer Überschrift, entwerder "Allgemeine Angaben" oder "Grundsätzliche Angaben" | LGB | 25.01.2018 | |
| 11 | 3 | Hinweise zum Dokument | r | ATS 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. | LGB | 25.01.2018 | |
| 12 | 2 | Anwendungsbereich | t | Die 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. | LGB | 25.01.2018 | |
| 13 | 4.1 | Überschrift | r | Besser Substantiv als Adjektiv als Überschrift verwenden | Grundsätze statt Grundsätzlich schreiben | LGB | 25.01.2018 | siehe 10 |
| 14 | 4.1.2 | Persistenz / Identität | r | Service Oriented Architecure | Service Oriented Architecture | LGB | 25.01.2018 | |
| 15 | 4.2 | Metadaten (in Capabilities und ISO Dokumenten) | r | Zusä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) | LGB | 25.01.2018 | |
| 16 | 4.2 | Absatz 2 | r | Satzbau | Zusätzlich zu den Metadaten ist in den Capabilities-Dokumenten des Dienstes, ein ISO... | LGB | 25.01.2018 | Der Sinn wurde hier wahrscheinlich falsch verstanden. |
| 17 | 4.2.1 | Service Level Metadaten | r | beinhalten bedingt vor zuhaltende Informationen | vorzuhaltende wird zusammen geschrieben | LGB | 25.01.2018 | |
| 18 | 4.2.2 | Content Level Metadaten im Capabilities -Dokument | r | beinhalten bedingt vor zuhaltende Informationen | vorzuhaltende wird zusammen geschrieben | LGB | 25.01.2018 | |
| 19 | 4.2.2 | Content Level Metadaten im Capabilities -Dokument | r | Daten-Dienste Kopplung | Daten-Dienste-Kopplung (Bindestrich zwischen Dienste und Kopplung) | LGB | 25.01.2018 | |
| 20 | 4.2.2 | Content Level Metadaten im Capabilities -Dokument | r | u.a. | u. a. (mit Leerzeichen) | LGB | 25.01.2018 | |
| 21 | 4.2.2 | Content Level Metadaten im Capabilities -Dokument | t | Anforderung 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). | LGB | 25.01.2018 | Formulierung klarer gefasst. |
| 22 | 4.2.2 | Absatz zwischen Anforderung 12 und 13 | t | eine BoundingBox begrenzt einen geographischen Bereich | geometrisch mit geographisch ersetzen | LGB | 25.01.2018 | |
| 23 | 4.3.1.3 | Text und Anforderung | t | Text und Anforderung 19 wiedersprechen sich, denn ein Bild mit 3000x3000 Pixel ist groß. | Bitte großes Bild (z.B. durch Pixelangabe) definieren. | LGB | 25.01.2018 | |
| 24 | 4.3.2 | Sachdaten | r,t, Frage | Es ist nicht vermerkt, ob die Unterstützung von GetFeatureInfo freiwillig oder verpflichtend ist. Evtl. Unterkapitel? | GetFeatureInfo muss unterstützt werden. | LGB | 25.01.2018 | Erläuternden Text hinzugefügt. |
| 25 | 4.3.2.1 | Formate | Frage | Warum 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. | LGB | 25.01.2018 | Das Format text/plain wird nicht grundsätzlich ausgeschlossen. Vorteile einer Verpflichtung sind dem AK nicht klar. |
| 26 | 4.3.3 | Styles / Legenden | r | In 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) | LGB | 25.01.2018 | siehe 9 |
| 27 | 4.3.3 | Absatz zwischen Empfehlung 14 und 15 | r | Das Anzeigen von Legenden zu dem dargestellten Inhalt.. | LGB | 25.01.2018 | ||
| 28 | 4.4.1 | WMS | r,t, Frage | Fü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. | LGB | 25.01.2018 | Dem Änderungswunsch wurde entsprochen. |
| 29 | 4.4.2 | WMTS | r | Mit 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") | LGB | 25.01.2018 | |
| 30 | 4.9 | Absicherung | r | 7 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 Header | LGB | 25.01.2018 | Nach eingehender Recherche ist HTTP Header und HTTPS-Verbindung die gebräuchliche deutsche Bezeichnung. Die Schreibweise wurde angepasst. |
| 31 | 5.11 | WMTS (TileMatrixSet - 4.4.2) | g | 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. | 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. | LGB | 25.01.2018 | Referenzen werden im Rahmen der Schlussredaktion umformatiert. |
| 32 | 5.14 | Verwendung von CORS Headern (4.8) | r | (z. B. Session-Cookies oder HTTP-Authentifizierungsdaten) | HTTP (TTP ist kursiv) | LGB | 25.01.2018 | |
| 33 | 5.3 | Persistenz / Identität (4.1.2) | r | Um die dauerhafte Referenzierbarkeit von URLs zu gewährleisten, kann es sinnvoll sein diese von einem zentralen HTTP-Proxy ausliefern zu lassen. | Komma nach "sein" | LGB | 25.01.2018 | |
| 34 | 5.3 | Persistenz / Identität (4.1.2) | r | Zieht 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" | LGB | 25.01.2018 | |
| 35 | 5.3 | Persistenz / Identität (4.1.2) | r | (wie sie INSPIRE fordert) | (wie von INSPIRE gefordert) - "sie" ist zu personalisiert | LGB | 25.01.2018 | |
| 36 | Anforderung 1 | r | Die 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 NRW | 26.01.18 | ||
| 37 | Anforderung 8 | g | Die 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 NRW | 26.01.18 | Hinweis auf Metadatenkonventionendokument eingefügt. | |
| 38 | Anforderung 9 | g | Die 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 NRW | 26.01.18 | Lässt sich ohne Weiteres nicht lösen. Referenz auf Metadatenkonventionendokument eingefügt. | |
| 39 | Anforderung 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 | ||
| 40 | Empfehlung 20 | g | Es 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 TMS | Geobasis NRW | Begründung angepasst | ||
| 41 | Anforderung 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 NRW | 26.01.18 | (a) erledigt – siehe Punkt weiter oben (b) erläutert (c) ist Sache des Diensteanbieters und wird nicht verhindert | |
| 42 | Anforderung 26 | g, t | Die 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 NRW | 26.01.18 | Erledigt – da ist wohl ein Fehler bei der Übertragung passiert. | |
| 43 | 4.1.1 | 3. Absatz | r | …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],… | GeoSN | 26.01.208 | |
| 44 | 4.1.2 | Empfehlung 2 | r | Formulierung im ganzen Satz | Der UPDATESEQUENCE Parameter der GetCapabilities Operation sollte unterstützt werden. | GeoSN | 26.01.208 | |
| 45 | 4.1.3 | Empfehlung 4 | g | So 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. | GeoSN | 26.01.208 | Soweit 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. |
| 46 | 4.1.4 | Empfehlung 5 | g | Es 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. | GeoSN | 26.01.208 | Da 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. |
| 47 | 4.1.4 | Empfehlung 5 | t | Bei 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. | GeoSN | 26.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. |
| 48 | 4.2.1 | Abschnitt nach Anforderung 7 | r | … beinhalten bedingt vor zuhaltende Informationen … | ... beinhalten bedingt vorzuhaltende Informationen … | GeoSN | 26.01.208 | siehe 17 |
| 49 | 4.2.1 | Tabelle 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:CharacterString | gmd: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:CharacterString | GeoSN | 26.01.208 | |
| 50 | 4.2.1 | Tabelle 1 Fees | g | /gmd:MD_Metadata/gmd:identificationInfo/srv:SV_ServiceIdentification/gmd:resourceConstraints/gmd:MD_LegalConstraints/gmd:useConstraints | nach Konventionendokument 3.2 wird fees im XPATH /gmd:MD_Metadata/gmd:identificationInfo/srv:SV_ServiceIdentification/gmd:resourceConstraints/gmd:MD_LegalConstraints/gmd:useLimitation/gco:CharacterString eingetragen | GeoSN | 26.01.208 | |
| 51 | 4.2.1 | Tabelle 1 AccessConstraints | g | /gmd:MD_Metadata/gmd:identificationInfo/srv:SV_ServiceIdentification/gmd:resourceConstraints/gmd:MD_LegalConstraints/gmd:accessConstraints | der 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. | GeoSN | 26.01.208 | Anpassung der XPATH ist erfolgt, dabei wird in Kauf genommen, dass noch nicht alle Metadaten an die neuen Vorgaben von INSPIRE angepasst wurden. |
| 52 | 4.2.1 | Tabelle 1 OnlineResource | g | hier verpflichtend | Auch nach Komventionendokument des AK Metadaten nicht verpflichtend. | GeoSN | 26.01.208 | |
| 53 | 4.2.1 | Tabelle 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:CharacterString | GeoSN | 26.01.208 | |
| 54 | 4.2.1 | Tabelle 1 AdressType | t | leer | ist 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 | GeoSN | 26.01.208 | Nach Überprüfung gibt es kein ISO19115 Äquivalent zu diesem Element. Beispiel: ‚postal‘ für postalische Adresse. |
| 55 | 4.2.1.1 | Stefan 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 | t | Die 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 / AdV | 26.01.208 | Angepasst |
| 56 | 4.2.1.2 | Anforderung 10 | r/g | In 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! | GeoSN | 26.01.208 | Dieser 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. |
| 57 | 4.2.2 | Tabelle | t | Der 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. | GeoSN | 26.01.208 | Die Angaben zu Dimension haben nur dann zu erfolgen, wenn sie auch anwendbar sind. Die Elemente sind als bedingt verpflichtend gekennzeichnet. | |
| 58 | 4.2.2 | Anforderung 12 | t | Was soll zurückgeliefert werden, wenn das angefragte Bildformat keine Transparenz unterstützt? | GeoSN | 26.01.208 | ||
| 59 | 4.2.2 | Empfehlung 7 | g | Diese Empfehlung gilt nur für INSPIRE-Geodatendienste - dies sollte hier auch entsprechend vermerkt werden. | GeoSN | 26.01.208 | Die Empfehlung gilt für alle Dienste – Beispiel wurde angepasst. | |
| 60 | 4.2.2 | Anforderung 13 | g | Formulierung 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. | GeoSN | 26.01.208 | Nach Meinung des AK ist die Anforderung ausreichend und klar beschrieben. |
| 61 | 4.2.3 | Empfehlung 9 | r | Je nach Dokumententyp ist im <Format> Tag … | Je nach Dokumententyp sollte im <Format> Tag ... | GeoSN | 26.01.208 | |
| 62 | 4.2.3 | Anforderung 16 | t | Die 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. | GeoSN | 26.01.208 | |
| 63 | 4.2.3 | Anforderung 16 | t | Frage: 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. | GeoSN | 26.01.208 | Formulierung wurde angepasst. | |
| 64 | 4.2.3 | Anforderung 16 | g | Da 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. | GeoSN | 26.01.208 | Der 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. |
| 65 | 4.2.3 | Empfehlung 9 | t | Prüfen, ob die Angaben (für alle WMS Versionen) dem Standard entsprechen. Üblicherweise erfolgt die Angabe mit text/xml und text/html. | GeoSN | 26.01.208 | Wurde geprüft, es handelt sich um eine Empfehlung die die Interoperabilität verbessern soll und diese geht über die Festlegungen der Spezifikationen hinaus. | |
| 66 | 4.3.1.2 | Anforderung 18 | r | … die darauf abzielen Rechte zu sichern ... | … die darauf abzielen, Rechte zu sichern ... | GeoSN | 26.01.208 | |
| 67 | 4.3.1.3 | Anforderung 19 | t | INSPIRE 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.? | GeoSN | 26.01.208 | Hinweis an dieser Stelle falsch, da es hier nicht um Leistungsanforderungen geht. | |
| 68 | 4.3.1.3 | Anforderung 19 | t | Anforderung 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. | GeoSN | 26.01.208 | Kommentierung unklar. Wir abgewiesen. |
| 69 | 4.3.2.1 | Empfehlung 12 | r | … 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. | GeoSN | 26.01.208 | |
| 70 | 4.3.2.1 | Empfehlung 12 | t | Die 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. | GeoSN | 26.01.208 | Es ist jedem unbenommen weitere Formate zu implementieren. |
| 71 | 4.3.2.2 | Anforderung 21 | t | Die 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. | Entfernen | GeoSN | 26.01.208 | |
| 72 | 4.3.2.2 | Anforderung 21 | t/g | Was 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 ändern | GeoSN | 26.01.208 | Es geht nur darum, dass jeder Nutzer die Möglichkeit erhält leere Rückgaben als solche zu erkennen. |
| 73 | 4.3.2.3 | Anforderung 22 | t | Es 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. | GeoSN | 26.01.208 | Die 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. |
| 74 | 4.4.1 | Anforderung 23 | g | Erster 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. | GeoSN | 26.01.208 | Die bewährte Festlegung wurde aus dem alten WMS-DE Profil von 2006 übernommen. |
| 75 | 4.4.1 | Anforderung 24 | g | Ist 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 streichen | GeoSN | 26.01.208 | Von 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. |
| 76 | 4.4.2 | Tabelle 3 | t | Die 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. | GeoSN | 26.01.208 | Richtig, es handelt sich hier auch nur um eine Empfehlung. Siehe Erläuterungen. |
| 77 | 4.4.2 | Tabelle 4 | t | Das Kachelset für WMTS stimmt nicht mit dem in Zusammenarbeit mit dem BKG von der AdV festgelegten Kachelset überein. | Entsprechend der AdV-Vorgaben korrigieren | GeoSN | 26.01.208 | Richtig, es handelt sich hir auch nur um eine Empfehlung. Siehe Erläuterungen. |
| 78 | 4.4.2 | Empfehlung 20 | g | Zu 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 erzeugen | GeoSN | 26.01.208 | Wegen der weitreichenden Konsequenzen werden vom AK keine Festlegungen diesbezüglich getroffen. |
| 79 | 4.5 | Anforderung 25 | g | Widerspricht 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 dimension | GeoSN | 26.01.208 | Wiederholung |
| 80 | 4.7 | Gliederung | r | 4.7 Festlegungen… 4.8 Verwendung… | Zwei Gliederungen??? | GeoSN | 26.01.208 | |
| 81 | 4.8 | 1. Absatz | r | Die 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). | GeoSN | 26.01.208 | |
| 82 | 4.9 | Anforderung 27 | g | Eine 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. | Entfernen | GeoSN | 26.01.208 | Meinung wird vom AK so nicht geteilt.
|
| 83 | 4.9 | Anforderung 22 | g | Die 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. | GeoSN | 26.01.208 | Es 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. |
| 84 | 5.0 | Erläuterungen | g | Wozu dieses Kapitel? Ist für die Vorgaben nicht relevant und soll entfernt werden (Begründungen für Festlegungen aus dem "Kerndokument" entfernen). | GeoSN | 26.01.208 | Meinung wird vom AK so nicht geteilt.
| |
| 85 | 5.3 | g | Was 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. | GeoSN | 26.01.208 | Die 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. | |
| 86 | 5.6 | r | möglichst Beispiel(e) ergänzen 1417.410714 entspricht 1:1500 | GeoSN | 26.01.2018 | Scheinbar 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. | ||
| 87 | 5.3 | letzter Absatz "Ein zusätzlicher Vorteil…" | g | Schlussfolgerung/ Vorteil ist nicht nachvollziehbar | bitte verdeutlichen | Kst. GDI-HH | 26.01.208 | Erklärung innerhalb der Tabelle nachliefern! |
| 88 | 5.4 | erster Absatz, Satz 2 "Die techn. Handlungsempfehlunegn…" | r | Formatierung "Limitations on Public Access" falsch | ändern in kursiv | Kst. GDI-HH | 26.01.208 | |
| 89 | 5.5 | dritter Absatz, Satz 2 "Dieses Element soll…." | r | gemeint ist vermutlich "welches bereits für Zugriffsbeschränkungen verwendet wird" | ändern in "Zugriffsbeschränkungen" | Kst. GDI-HH | 26.01.208 | |
| 90 | 4.1.4. | Empfehlung 5: | redaktionell | Empfehlung 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) | ZGeoBw | 29.01.18 | |
| 91 | 4.1.5. | redaktionell | 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 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. | ZGeoBw | 29.01.18 | siehe 111 | |
| 92 | 4.3.3. | redaktionell | In 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. | ZGeoBw | 29.01.18 | siehe 9 | |
| 93 | 4.3.3. | Empfehlung 15: | redaktionell | Bei 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"? | ZGeoBw | 29.01.18 | Es soll vermieden werden, dass sich die Referenzierung des jeweiligen Layers in der Legendendarstellung widerspiegelt. Die Zuordnung wird grundsätzlich vom Client verwaltet. | |
| 94 | 4.1.2 | 1. Zeile in Abschnitt 4.1.2, Seite 7 | redaktionell | Schreibfehler | Architecture | BGR | 29.01.18 | siehe 14 |
| 95 | 4.1.5 | 2. Zeile in Abschnitt 4.1.5, Seite 9 | redaktionell | Schreibfehler | Im Satz "den" streichen | BGR | 29.01.18 | siehe 111 |
| 96 | 4.2.1 | 6. Zeile in Abschnitt 4.2.1, Seite 10 | redaktionell | Schreibfehler | schreibe "vorzuhalten" in einem Wort | BGR | 29.01.18 | siehe 17 |
| 97 | 4.3.3 | Text nach Empfehlung 14, Seite 17 | redaktionell | Schreibfehler | schreibe "Inhalten" (Plural), Komma ist überflüssig | BGR | 29.01.18 | siehe 27 |
| 98 | 5.11 | 1. Satz auf S. 31 | redaktionell | Schreibfehler | schreibe aufgeführten statt augeführten. Der vorhergehende Doppelpunkt kann entfallen. | BGR | 29.01.18 | : wird automatisch gesetzt – muss noch kontrolliert werden – Endredaktion |
| 99 | Gesamt | redaktionell | doppelte Leerzeichen | Das Dokument könnte nach doppelten Leerzeichen im Text durchsucht werden, die häufiger auftreten. | BGR | 29.01.18 | ||
| 100 | 4.1.4 | Empfehlung 5 | g/t | Fü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 weglassen | Landesamt für Geoinformation und Landesvermessung Niedersachsen (LGLN) - Landesvermessung und Geobasisinformation - Landesbetrieb - | 30.01.18 | siehe 46, 67, 68 |
| 101 | 4.1.6 | r | Die 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-NI | 30.01.18 | Diese Forderung war schon Bestandteil des Profils aus dem Jahr 2006 und hat eigentlich nichts mit dem IT-Planungsrat zu tun. | |
| 102 | 4.3.1.2 | Anforderung 18 | g | Rechtliche Vorgaben erfordern die Darstellung von Copyright Vermerken. Die Anforderung kann so nicht erfüllt werden. | Als Empfehlung formulieren | Landesamt für Geoinformation und Landesvermessung Niedersachsen (LGLN) - Landesvermessung und Geobasisinformation - Landesbetrieb - | 30.01.18 | siehe 4 |
| 103 | 4.4.2 | Empfehlung 20, Tabelle 3, Tabelle 4 | g | Neben 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.18 | siehe 6, 40, 76, 77, 78 |
| 104 | 4.6.1 | Letzter Satz | r | Um 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 | |
| 105 | 4.9 | Anforderung 27 | g | Die 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.18 | Weitere Schutzmechanismen werden nicht eingeschränkt. Der Hinweis auf die Nutzung von https ist vorhanden. Siehe auch 82, 83 |
| 106 | 1. | Anforderungen / S. 4 | r | Gliederung Nr. 4.1.3, 4.2.3, 4.7, 5.2 falsch und Zeilenumbruch 4.7 | Anpassung erforderlich | LVermGeo LSA | 31.01.18 | Schlussredaktion |
| 107 | 1 Einleitung | 3. Absatz | g | fü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 | |
| 108 | 2 | Satz 4 | g | Widerspruch 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 LSA | 31.01.18 | Der AK sieht keinen Änderungsbedarf. |
| 109 | 4.1.1 | Empfehlung 1 | g | im 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.18 | Richtig. Arbeitsauftrag für AK Architektur. |
| 110 | 4.1.4 | Satz 1 und Empfehlung 5 | r | "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 | |
| 111 | 4.1.5 | Absatz 1 | r | "…werden, ist der den von INSPIRE…" korrigieren | in "…werden, ist der von INSPIRE…" | LVermGeo LSA | 31.01.18 | |
| 112 | 4.1.6 | Anforderung 6 | g | "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üfen | MLV Sachsen-Anhalt | 31.01.18 | siehe 101 |
| 113 | 4.2.1 | Tabelle 1 | t | Beispiel aus Medatenkonventionen (WMS Capabilities Dokument): hier fehlt das Element ContactPosition. | Bitte Prüfen und ergänzen. | LVermGeo LSA | 31.01.18 | |
| 114 | 4.2.3 | Empfehlung 9 | g | Empfehlung ist wie eine Anforderung formuliert. | Bitte umformulieren: "Je nach Dokumententyp sollte im ... angegeben werden." | LVermGeo LSA | 31.01.18 | siehe 61 |
| 115 | 4.9 | Anforderung 27 | g | neben 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üfen | MLV Sachsen-Anhalt | 31.01.18 | Diese Technologien sind Bestandteil der Vorgaben zu den Diensten. Prüfauftrag an AK Architektur zur Fortschreibung des Technik Teils. |
| 116 | 5.4 | Absatz 1 | r | "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 Schreibweise | LVermGeo LSA | 31.01.18 | siehe 88 |
| 117 | 5.4 | Beispiel Dienst-Metadatensatz | t | XML-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 LSA | 31.01.18 | |
| 118 | 5.4 | Beispiel Capabilities-Dokument | t | Text 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 | ||
| 119 | 5.8 | Absatz 1 und Abbildung 2 Bezeichnung | r | verschiedene Bezeichnungen für gleichen Sachverhalt | Vereinheitlichung: Copyright Vermerke oder Copyright Signaturen | LVermGeo LSA | ||
| 120 | 6.5 | "GDI-DE Vorgaben" (S. 35) | g | bei 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 | |
| 121 | 4.2.2 Empfehlung 6 | Bildschirmauflösung | t | AdV und OGC-Angaben für WMS und WMTS gehen i.d.R. von 96 dpi und nicht von 90,714 dpi aus. | 96 dpi übernehmen | Kontaktstelle GDI-HE | 31.01.18 | Diese Aussage konnte nicht verifiziert werden. Nach dem referenzierten Dokumenten der OGC wird von 0.28mm ausgegangen, was einem dpi Wert von 90.714 entspricht. |
| 122 | 4.3.1.2 Anforderung 18 | Copyright-Vermerk | g | technisch 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 einarbeiten | Kontaktstelle GDI-HE | 31.01.18 | siehe 4 |
| 123 | 4.3.1.3 Anforderung 19 | mindest Bildgröße | g | Die 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 aussprechen | Kontaktstelle GDI-HE | 31.01.18 | siehe 5 |
| 124 | 4.3.2.2 Anforderung 21 | leere HTML Seite | t | Mit GetFeatureInfo Abfragen, die kein Ergebnis erzielen, wird technisch in Abhängigkeit der Implementierung unterschiedlich umgegangen. Die Anforderung erscheint zu restriktiv ausgerichtet. | als Empfehlung aussprechen | Kontaktstelle GDI-HE | 31.01.18 | siehe 41, 71 |
| 125 | 4.4.2 Empfehlung 20 | Tabelle 4: Well-known-scale-set gdi_de_25832 - Zoomstufen | t | Die 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 anpassen | Kontaktstelle GDI-HE | 31.01.18 | siehe 6, 40, 76, 77, 78 |
| 126 | alle | Kopfzeile | r | Die Kopfzeile ist wie ein normaler Textabschnitt formatiert. Bei Texten die über mehrere Seiten irritiert die Kopfzeile | Formatierung ändern (Schriftart kleiner, Farbe: grau, etc) | LDBV | 05.02.18 | |
| 127 | alle | Absätze | r | Abkü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.) | LDBV | 05.02.18 | |
| 128 | alle | Fußnoten | r | einheitliche Vorgehensweise zum Verweis auf Erläuterungen durch Fußnoten. Fußnote 3 verweist auf ausführliche Erläuterungen | alle Verweise auf zusätzliche Erläuterungen durch Fußnoten kennzeichen | LDBV | 05.02.18 | |
| 129 | Inhalts-verzeich-nis | r | Formatierungsfehler: Vor dem Inhaltverzeichnis steht "1. Anforderungen" | Löschen des 1 Eintrages | LDBV | 05.02.18 | ||
| 130 | 3 | Absatz 2, Satz 2 | r | Ausdrucksfehler: „… Überprüfung zu Vorgaben aus diesem Dokument, ...“ | Ändern zu: „… Überprüfung von Vorgaben aus diesem Dokument, ...“ | LDBV | 05.02.18 | |
| 131 | 3 | Absatz 3 | r | Rechtschreibfehler: „… Bezeichnungen von XML-Elementen, - Attributwerte und Code in eigener ...“ | Ändern zu: "… Bezeichnungen von XML-Elementen, -Attributwerten und Codes in eigener ...“ | LDBV | 05.02.18 | |
| 132 | 4.1.1 | Fußnote 3 | r | Formatierung der Fußnote, Abstand zwischen Fußnote und Text zu gering | Formatierung der Fußnote anpassen | LDBV | 05.02.18 | |
| 133 | 4.1.2 | Absatz 3, Satz 1 | r | Die 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 ..." | LDBV | 05.02.18 | |
| 134 | 4.1.2 | Absatz 3 | r | Aus 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." | LDBV | 05.02.18 | |
| 135 | 4.1.3 | Anforderung 4 | r | Rechtschreibfehler: "Layernamen, bzw. -identifikatoren…" --> Komma gehört da nicht hin | Ändern zu: "Layernamen bzw. -identifikatoren…" | LDBV | 05.02.18 | |
| 136 | 4.1.3 | t | Es 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_dop | Aufnahme einer weiteren Anforderung: "Laynamen bzw. -identifikatioren müssen mit dem Kürzel des Bundeslandes beginnen." | LDBV | 05.02.18 | Kann nicht Bestandteil eines allgemeinen Profils sein. Diese Regelungen sollten von den jeweils fachlich zuständigen Stellen aufgestellt werden. | |
| 137 | 4.1.6 | Anforderung 6 | r | Ausdrucksfehler: „… Antworten auf GetCapabilities, GetFeatureInfo Requests sowie Service Exceptions, …" | Ändern zu: „… Antworten auf GetCapabilities und GetFeatureInfo-Requests sowie Service Exceptions, …" | LDBV | 05.02.18 | |
| 138 | 4.2.3 | Kapitel | g | Kommentar 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. | LDBV | 05.02.18 | |
| 139 | 4.2.3 | Absatz 3 | t | Die 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" | LDBV | 05.02.18 | |
| 140 | 4.2.3 | Absatz 3 | r | Das Muster des Namensraumes ist in der jetzigen Form schwer lesbar. | Einfügen eines Zeilenumbruchs nach „… wird nach folgendem Muster gebildet:“ | LDBV | 05.02.18 | |
| 141 | 4.2.3 | letzter Absatz, Satz 2 | r | Rechtschreibfehler --> Leerzeichen vorm Punkt des Satzendes | Leerzeichen entfernen | LDBV | 05.02.18 | |
| 142 | 4.3.1.2 | Anforderung 18 | g | Kommentar 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. | LDBV | 05.02.18 | siehe 4 |
| 143 | 4.3.1.3 | Absatz 1, Satz 1 | r | Komma fehlt: "… in der Regel einer Beschränkung um beispielsweise…" | Ändern zu: "… in der Regel einer Beschränkung, um beispielsweise…" | LDBV | 05.02.18 | |
| 144 | 4.3.2.1 | Empfehlung 12 | r | Kommata zu viel bei "… Verbreitung, sowie … Formates, sollte… --> kein eingeschobener Teilsatz | Kommata entfernen | LDBV | 05.02.18 | |
| 145 | 4.3.3 | Absatz 1, Satz 3 | r | ungünstiger Satzbau: „Nicht sinnvoll ist es, ...“ | Ändern zu : „Es ist nicht sinnvoll, ...“ | LDBV | 05.02.18 | |
| 146 | 4.3.3 | Absatz 1, letzter Satz | r | Wort zu viel: "…, eigene Dienste zu aufzusetzen…" | "zu" streichen: "…, eigene Dienste aufzusetzen…" | LDBV | 05.02.18 | siehe 9 |
| 147 | 4.4.1 | Absatz 2, Satz 2 | r | 2 Punkte am Satzende | vorderen Punkt streichen | LDBV | 05.02.18 | |
| 148 | 4.4.1 | Anforderungen 23 und 24 | t | Kommentar 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. | LDBV | 05.02.18 | Problem erkannt – wird als Prüfauftrag an den AK Architektur weitergeleitet. |
| 149 | 4.4.2 | Absatz 1, letzter Satz | r | fehlendes Komma: „… kann ein Client entscheiden ob ein...“ | ändern zu: „… kann ein Client entscheiden, ob ein...“ | LDBV | 05.02.18 | siehe 29 |
| 150 | 4.4.2 | Kapitel | g | Kommentar 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. | LDBV | 05.02.18 | siehe 6, 31, 40, 76, 77, 78 |
| 151 | 4.4.2 | Tabelle | t | Kommentar 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. | LDBV | 05.02.18 | siehe 6, 31, 40, 76, 77, 78 |
| 152 | 4.6.2 | Anforderung 26 | g | Kommentar 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.“ | LDBV | 05.02.18 | siehe 42 |
| 153 | 4.7 | Abschnitt 4.8 / 4.9 | r | Falsche Formatierung der Überschriften 4.8 und 4.9 | 4.8 und 4.9 ändern zu 4.7.1 und 4.7.2 | LDBV | 05.02.18 | siehe 80 |
| 154 | 4.8 (4.7.1) | Absatz 1, Satz 3 | r | Leerzeichen zu viel am Satzende: „… auf Basis von HTTP ).“ | Ändern zu: “...auf Basis von HTTP)“ | LDBV | 05.02.18 | siehe 81 |
| 155 | 5.2 | Absatz 1, letzter Satz | r | falsche Schriftgröße bei "EPSG:4326" | Schriftgröße anpassen | LDBV | 05.02.18 | |
| 156 | 5.3 | Absatz 1, Satz 1 | r | Komma fehlt: "… kann es sinnvoll sein diese von…" | Komma fehlt: "… kann es sinnvoll sein, diese von…" | LDBV | 05.02.18 | siehe 33 |
| 157 | 5.3 | Absatz 1, Satz 2 | r | Rechtschreibfehler: "Nach Außen…" | ändern zu: "Nach außen…" | LDBV | 05.02.18 | |
| 158 | 5.3 | Absatz 2, Satz 1 | r | Komma zu viel: "… Registry, sowie…" | Komma entfernen | LDBV | 05.02.18 | |
| 159 | 5.4 | Absatz 1, letzter Satz, letzter Term | r | Formatierung überprüfen bei "Conditions for Access and Use" | ggf. Formatierung anpassen | LDBV | 05.02.18 | siehe 88 |
| 160 | 5.4 | Beispiel Dienst-Metadatensatz | r | Formatierungen für Hyperlinks überprüfen: Der erste Link unterstreicht freie Flächen, der 2., 3. und 4. Link wird nicht vollständig unterstichen | Link richtig formatieren oder Hyperlinks entfernen | LDBV | 05.02.18 | |
| 161 | 5.12 | Absatz 3 | r | Satzbau: "… 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.“ | LDBV | 05.02.18 | |
| 162 | 5.14 | Absatz 1, Sätze 3 und 4 | r | falsche Schriftgröße bei "Access-Control-Allow-*" und "Access-Control-Allow-Origin" | Schriftgröße anpassen | LDBV | 05.02.18 | Wirkt nur größer – ist eigentlich die Standardgröße 12pt |
Überblick
Inhalte
Aktivität