Sie zeigen eine alte Version dieser Seite an. Zeigen Sie die aktuelle Version an.

Unterschiede anzeigen Seitenhistorie anzeigen

« Vorherige Version anzeigen Version 14 Nächste Version anzeigen »

Im Rahmen der regelmäßigen Fortschreibung der Dokumente der GDI-DE, hat der AK Geodienste ein allgemeines Profil für Darstellungsdienste erarbeitet, welches das bisherige WMS-DE-Profil aus dem Jahr 2006 ersetzen soll:

Vorgaben der GDI-DE zur Bereitstellung von Darstellungsdiensten

Die Einhaltung der Vorgaben dieses Profils soll die einheitlichen Nutzbarkeit (Interoperabilität) aller Darstellungsdienste innerhalb der GDI-DE gewährleisten.

Im Sommer 2017 gab es bereits einen GDI-DE-internen Review-Prozess, in dessen Verlauf über 480 Kommentare und Anregungen eingegangen sind. Diese wurden in den letzten Monaten durch den AK gesichtet, bewertet und ggf. ins Dokument übernommen.

Aufgrund der umfangreichen Rückmeldungen wurde entschieden einen weiteren, öffentlichen Review-Prozess durchzuführen.

Sie haben die Möglichkeit Ihre Kommentare und Anregungen bis zum 31.01.2018, unter Nutzung der beigefügten Kommentierungstabelle, an das Funktionspostfach der Koordinierungsstelle GDI-DE zu senden (mail@gdi-de.org).

Wenn Sie direkte thematische Fragen haben oder Abklärungsbedarf sehen, können Sie sich auch direkt an die Leitung des AK Geodienste (Herrn Retterath, armin.retterath@vermkv.rlp.de) wenden.

Um Doppelmeldungen zu vermeiden, werden die Anregungen bei Eingang direkt in die folgende Tabelle eingestellt:

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ÄnderungsvorschlagOrganisationDatum
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 Metadaten2018-01-09
14.2.1.2Anforderung 10g

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 Metadaten2018-01-09
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-SH2018-01-19
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-SH2018-01-19
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-SH2018-01-19
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-SH2018-01-19
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-SH2018-01-19
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 markieren LVermGeo SH - Kst. GDI-SH2018-01-19
94.3.3Abschnitt 1r"eigene Dienste zu
aufzusetzen und diese"		das Wort "zu" streichen LVermGeo SH - Kst. GDI-SH2018-01-19
10 5.3letzter Absatz "Ein zusätzlicher Vorteil…"gSchlussfolgerung/ Vorteil ist nicht nachvollziehbarbitte verdeutlichenKst. GDI-HH2018-01-26
11 5.4erster Absatz, Satz 2 "Die techn. Handlungsempfehlunegn…"rFormatierung "Limitations on Public Access" falschändern in kursivKst. GDI-HH2018-01-26
12 5.5dritter Absatz, Satz 2 "Dieses Element soll…."rgemeint ist vermutlich "welches bereits für Zugriffsbeschränkungen verwendet wird"ändern in "Zugriffsbeschränkungen"Kst. GDI-HH2018-01-26
131Inhaltsverzeichnisr4.1 Grundsätzlichdas ist kein Name einer Überschrift, entwerder "Allgemeine Angaben" oder "Grundsätzliche Angaben"LGB – Kontaktstelle BB2018-01-25
143Hinweise 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.		LGB – Kontaktstelle BB2018-01-25
152AnwendungsbereichtDie 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 – Kontaktstelle BB2018-01-25
164.1ÜberschriftrBesser Substantiv als Adjektiv als Überschrift verwendenGrundsätze statt Grundsätzlich schreibenLGB – Kontaktstelle BB2018-01-25
174.1.2Persistenz / IdentitätrService Oriented ArchitecureService Oriented ArchitectureLGB – Kontaktstelle BB2018-01-25
184.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)		LGB – Kontaktstelle BB2018-01-25
194.2Absatz 2rSatzbauZusätzlich zu den Metadaten ist in den Capabilities-Dokumenten des Dienstes, ein ISO...LGB – Kontaktstelle BB2018-01-25
204.2.1Service Level Metadatenrbeinhalten bedingt vor zuhaltende Informationenvorzuhaltende wird zusammen geschriebenLGB – Kontaktstelle BB2018-01-25
214.2.2Content Level Metadaten im Capabilities -Dokumentrbeinhalten bedingt vor zuhaltende Informationenvorzuhaltende wird zusammen geschriebenLGB – Kontaktstelle BB2018-01-25
224.2.2Content Level Metadaten im Capabilities -DokumentrDaten-Dienste KopplungDaten-Dienste-Kopplung (Bindestrich zwischen Dienste und Kopplung)LGB – Kontaktstelle BB2018-01-25
234.2.2Content Level Metadaten im Capabilities -Dokumentru.a.u. a. (mit Leerzeichen)LGB – Kontaktstelle BB2018-01-25
244.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).		LGB – Kontaktstelle BB2018-01-25
254.2.2Absatz zwischen Anforderung 12 und 13teine BoundingBox begrenzt einen geographischen Bereichgeometrisch mit geographisch ersetzenLGB – Kontaktstelle BB2018-01-25
264.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.LGB – Kontaktstelle BB2018-01-25
274.3.2Sachdatenr,t, FrageEs ist nicht vermerkt, ob die Unterstützung von GetFeatureInfo freiwillig oder verpflichtend ist. Evtl. Unterkapitel?GetFeatureInfo muss unterstützt werden.LGB – Kontaktstelle BB2018-01-25
284.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.		LGB – Kontaktstelle BB2018-01-25
294.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)		LGB – Kontaktstelle BB2018-01-25
304.3.3Absatz zwischen Empfehlung 14 und 15r Das Anzeigen von Legenden zu dem dargestellten Inhalt..LGB – Kontaktstelle BB2018-01-25
314.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.		LGB – Kontaktstelle BB2018-01-25
324.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")		LGB – Kontaktstelle BB2018-01-25
334.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 HeaderLGB – Kontaktstelle BB2018-01-25
345.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.		LGB – Kontaktstelle BB2018-01-25
355.14Verwendung von CORS Headern (4.8)r(z. B. Session-Cookies oder HTTP-Authentifizierungsdaten)HTTP (TTP ist kursiv)LGB – Kontaktstelle BB2018-01-25
365.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"LGB – Kontaktstelle BB2018-01-25
375.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"LGB – Kontaktstelle BB2018-01-25
385.3Persistenz / Identität (4.1.2)r(wie sie INSPIRE fordert)(wie von INSPIRE gefordert) - "sie" ist zu personalisiertLGB – Kontaktstelle BB2018-01-25
394.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],…GeoSN2018-01-26
404.1.2Empfehlung 2rFormulierung im ganzen SatzDer UPDATESEQUENCE Parameter der GetCapabilities Operation sollte unterstützt werden.GeoSN2018-01-26
414.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.GeoSN2018-01-26
424.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.GeoSN2018-01-26
434.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.		GeoSN2018-01-26
444.2.1Abschnitt nach Anforderung 7r… beinhalten bedingt vor zuhaltende Informationen …... beinhalten bedingt vorzuhaltende Informationen …GeoSN2018-01-26
454.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:CharacterStringGeoSN2018-01-26
464.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 eingetragenGeoSN2018-01-26
474.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.		GeoSN2018-01-26
484.2.1Tabelle 1
OnlineResource		ghier verpflichtendAuch nach Komventionendokument des AK Metadaten nicht verpflichtend.GeoSN2018-01-26
494.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:CharacterStringGeoSN2018-01-26
504.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		GeoSN2018-01-26
514.2.1.1Anforderung 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 / AdV2018-01-26
524.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!GeoSN2018-01-26
534.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. GeoSN2018-01-26
544.2.2Anforderung 12tWas soll zurückgeliefert werden, wenn das angefragte Bildformat keine Transparenz unterstützt? GeoSN2018-01-26
554.2.2Empfehlung 7g Diese Empfehlung gilt nur für INSPIRE-Geodatendienste - dies sollte hier auch entsprechend vermerkt werden.GeoSN2018-01-26
564.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.GeoSN2018-01-26
574.2.3Empfehlung 9rJe nach Dokumententyp ist im <Format> Tag …Je nach Dokumententyp sollte im <Format> Tag ...GeoSN2018-01-26
584.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.GeoSN2018-01-26
594.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. GeoSN2018-01-26
604.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.GeoSN2018-01-26
614.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. GeoSN2018-01-26
624.3.1.2Anforderung 18r… die darauf abzielen Rechte zu sichern ...… die darauf abzielen, Rechte zu sichern ...GeoSN2018-01-26
634.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.? GeoSN2018-01-26
644.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.GeoSN2018-01-26
654.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.		GeoSN2018-01-26
664.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.GeoSN2018-01-26
674.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.		EntfernenGeoSN2018-01-26
684.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 ändernGeoSN2018-01-26
694.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.GeoSN2018-01-26
704.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.		GeoSN2018-01-26
714.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 streichenGeoSN2018-01-26
724.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.GeoSN2018-01-26
734.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 korrigierenGeoSN2018-01-26
744.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 erzeugenGeoSN2018-01-26
754.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 dimensionGeoSN2018-01-26
764.7Gliederungr4.7 Festlegungen…
4.8 Verwendung…		Zwei Gliederungen???GeoSN2018-01-26
774.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).		GeoSN2018-01-26
784.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.EntfernenGeoSN2018-01-26
794.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.GeoSN2018-01-26
805.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).GeoSN2018-01-26
815.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.GeoSN2018-01-26
825.6 rmöglichst Beispiel(e) ergänzen 1417.410714 entspricht 1:1500 GeoSN2018-01-26
83Kapitel 4.1.1Anforderung 1rDie 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 NRW2018-01-26
84Kapitel 4.2.1.1Anforderung 8gDie 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 NRW2018-01-26
85Kapitel 4.2.1.1Anforderung 9gDie 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 NRW2018-01-26
86Kapitel 4.2.2Anforderung 11, Tabelle 2g, 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 NRW2018-01-26
87Kapitel 4.4.2Empfehlung 20gEs 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 
88Kapitel 4.3.2.2Anforderung 21g, 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 NRW2018-01-26
89Kapitel 4.6.2Anforderung 26g, 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 NRW2018-01-26






  • Keine Stichwörter