We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Offene Standards und Freie Software - Zusammenspiel, Entwicklungen, Unterschiede

00:00

Formale Metadaten

Titel
Offene Standards und Freie Software - Zusammenspiel, Entwicklungen, Unterschiede
Serientitel
Anzahl der Teile
31
Autor
Lizenz
CC-Namensnennung 3.0 Unported:
Sie dürfen das Werk bzw. den Inhalt zu jedem legalen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen.
Identifikatoren
Herausgeber
Erscheinungsjahr
Sprache

Inhaltliche Metadaten

Fachgebiet
Genre
Abstract
Ähnlich wie die immer wiederkehrenden Fragen nach „Was ist Freie Software?“, „Was ist Open Source Software?“, „Was ist die OSGeo?“ gibt es immer wieder Fragen wie „Was ist das OGC?“, „Wie entsteht ein Standard?“, „Wie kann ich mich beim OGC einbringen?“. Daher ist der Vortrag als Grundlagenvortrag gedacht, der aber auch Ausblick auf aktuelle Entwicklungen im OGC gibt. Offene Standards bilden die Grundlage für viele Anwendungen in einer immer komplexer werdenden IT-Welt. Geodaten und daraus resultierende Geoinformationen finden immer mehr Anwendung und werden von immer mehr Nicht-Fachleuten genutzt. Ein standardisierter Zugriff und Interoperabilität zwischen verschiedenen Systemen und Plattformen ist eine wichtige Voraussetzung, um die große Menge Daten und Informationen sinnvoll zu nutzen und miteinander verknüpfen zu können. In der Geo-Branche sind die Standards des Open Geospatial Consortium (OGC) in Bereichen wie 3D-Anwendungen, dem „Internet der Dinge“, aber auch bei „klassische“ Geoportal-Anwendungen nicht mehr wegzudenken. Die zentrale Aufgabe des OGC ist die globale Entwicklung, Förderung und Harmonisierung von offenen Standards und Architekturen, die die Integration von raumbezogenen Daten und Diensten für Benutzeranwendungen ermöglichen und entsprechendes Marktpotenzial schaffen. Ähnlich wie die immer wiederkehrenden Fragen nach „Was ist Freie Software?“, „Was ist Open Source Software?“, „Was ist die OSGeo?“ gibt es immer wieder Fragen wie „Was ist das OGC?“, „Wie entsteht ein Standard?“, „Wie kann ich mich beim OGC einbringen?“. Daher beleuchtet dieser (als Grundlagenvortrag gedachte) Vortrag u.a. folgende Aspekte: Grundlagen des OGC: Was arbeitet das OGC und wie ist sie aufgebaut? Wer sind die Mitglieder? Was sind aktuelle Themen? Wie entsteht ein Standard? Vom Interoperability Program zum Standards Program (z.B. 3D Portrayal Interoperability Experiment) [1, 2, 3] Welche Rolle spielt Freie Software im OGC (Beispiele: OGC Referenzimplementationen, das OGC Compliance Program) Neuigkeiten aus den einzelnen Arbeitsgruppen, wie z.B. welche aktuellen Entwicklungen gibt es im Bereich Linked Data? Welche Arbeitsgruppen wurden in den vergangenen 12 Monaten in Leben gerufen?, Wie ist der Standard der Dinge der OGC Web Services Testbeds (OWS-9 und OWS-10). Ausblick auf Aktivitäten / Meetings in 2013/2014
APIPositionInternetGeometrieInformationFaktorisierungHaar-MaßOffene MengeWort <Informatik>Systems <München>EbeneSound <Multimedia>ChipkarteEckeVorlesung/Konferenz
Lift <Framework, Informatik>Uniformer RaumInformationReiheSeidelOpen SourceSoftwareGeodätische LinieMikroarchitekturLoginZahlenbereichZusammenhang <Mathematik>PerspektiveOffene MengeMomentenproblemVorlesung/Konferenz
SchwingungSpezialrechnerDECExt-FunktorMinimalgradGcc <Compiler>Open SourceGeoinformationGroße VereinheitlichungAnwendungssoftwareMengeGeometrieMomentenproblemEbeneGeodätische LinieTestbedSoftwareWeb-SeiteIntegriergerätPerspektiveARM <Computerarchitektur>InformationGruppoidZusammenhang <Mathematik>Vorlesung/Konferenz
Web logProgramminspektionSchwebungOpen SourceMailing-ListeTwitter <Softwareplattform>InformationSound <Multimedia>SenderVorlesung/Konferenz
Transkript: Deutsch(automatisch erzeugt)
Ja, ich habe jetzt die schwere Aufgabe nach Ahnhoff nicht gehabt. Ja, Martina Farkas ist mein Name und ich lebe mit dem Programm offene Standards und mit meiner Software, wie das zusammengespielt.
Und ich werde mich ein bisschen erläutern, warum wir offene Standards machen beim Cochisee, die Geospatial Consortium. Und ich habe auch gerade noch was geschrieben, was bei der Ahnhoff noch eingegangen ist auf Interoperabilität. Und wer hat sich in den letzten Wochen mit dem Thema Geo-Services-Rest-API beschäftigt?
Ich bin sehr gespannt auf deinen Vortrag. Ja, also ich mache mal eine kurze
Einführung und werde dann ein paar Worte zur Zusammenarbeit zwischen OGC und der OSGEO erklären. Und ein paar Neuigkeiten aus dem OGC berichten. Weil der Ton nicht funktioniert, ich kann das Video nicht so gut... Ich kann das Video nicht so gut nachmachen wie der Ahnhoff. Wenn Sie Zeit haben und so grundsätzlich schauen wollen, was macht das OGC,
wir haben einen YouTube-Channel, da kann man sich ein bisschen durchklicken. Das sind sehr nette Sachen dabei, von ganz allgemeinen Einführungen bis ganz speziell zum Thema Hydrologie und OGC-Standards.
Es geht um Interoperabilität und es geht um Standards bei OGC. Und unser Gründer, der David Schell, der hat mal gesagt, Interoperability seems to be about the integration of information.
Ein ganz wichtiger Aspekt, da kann man nichts gegen sagen. What it's really about is the coordination of organizational behavior. Und ich glaube, das ist ein ganz wichtiger Aspekt, dass es nicht nur um die technische Interoperabilität geht, sondern auch semantische Interoperabilität und Veranstaltungen wie die FOSCIS, die tragen dazu bei, dass die Leute sich treffen,
dass sie miteinander reden und man vielleicht auch auf Fehleinschätzungen, Fehlwahrnehmungen aufmerksam gemacht wird, die dann helfen, eine bessere Lösung zu finden. Ich habe mal hier, das ist von dem European Interoperability Framework,
die haben die unterschiedlichen Ebenen von Interoperabilität definiert. Wir wollen ja oft Daten und Informationen über Grenzen hinweg austauschen. Das kann man auf Landes-, also auf Staatenebene schauen.
Es gibt hier zwischen Deutschland und der Schweiz oder Deutschland, Schweiz, Österreich gibt es sehr schöne Projekte. Da verstehen wir alles, das macht Sinn, dass man da von Interoperabilität redet. Aber es gibt auch Interoperabilität in einem Land zwischen zwei verschiedenen Behörden, die auf denselben Daten zugreifen.
Das sind auch Grenzen. Es gibt auch innerhalb einer Behörde unterschiedliche Ämter. Und da reden wir auch von Interoperabilität. Und da sind so Sachen wie semantische Interoperabilität vielleicht wichtig.
Für mich, die ich nichts mit der Seefahrt zu tun habe, ist ein Leuchtturm dort auf Inverse, da kann man schöne Bilder machen. Man kann gucken, wie lange man das Licht braucht, bis sich das einmal gedreht hat. Vielleicht gibt es einen Standard für, ich weiß es nicht. Aber für einen Seemann, für einen Seefahrer ist das extrem wichtig.
Das hat eine ganz andere Bedeutung, eine ganz andere semantische Bedeutung. Organisatorische Interoperabilität habe ich gerade schon erläutert, wenn die Behörden zusammenarbeiten müssen. Oder wenn unterschiedliche Organisationen miteinander reden müssen.
Das brauchen wir auch, das ist wichtig, das darf man nie vergessen. Was wir hier überwiegend beachten oder worauf wir schauen, das ist überwiegend die technische Interoperabilität. Wichtiger Faktor für den Zugang zu verteilten Daten, wir reden ja immer mehr von Open Data, ist die Standardisierung.
Und wir definieren das als die allgemeingültige und gemeinsame Schnittstellen, die Interoperabilität ermöglichen.
Und ich habe jetzt gerade nochmal beim Armut-Disco erwähnt, das OGC versteht unter Interoperabilität folgendes. Und da bezieht sich das OGC auf ISO 2382-1, die Fähigkeit über verschiedene Systeme hinweg Daten und Informationen auszutauschen,
ohne dass der Endanwender vertiefte Kenntnisse über die Technologie dahinter haben muss. Also das ist ein ganz wichtiger Aspekt, wenn wir schauen, komme ich mir aus der Ecke der Programmierung, der Entwicklung von Standards oder wenigen Anwendern, das sind einfach auch Dinge, die Sie im Hinterkopf haben müssen.
Zum Thema Open Data hat das OGC keine spezielle Position, wir sagen grundsätzlich, egal welche Strategie Sie in den Unternehmen oder Ihrer Behörde, die Ihre Organisation verfolgen, das ist Ihr Ding, es ändern sicher auch Dinge. Arno hat es gesagt, was gestern Open Data ist, kann heute oder überhaupt was anderes sein und umgekehrt.
Aus unserer Sicht ist es einfach wichtig, dass man einen Rahmen schafft, und der ist eben durch offene Standards, dass Daten eben zugänglich gemacht werden können. Wenn man unsere Mitglieder fragt, also das OGC, wir sind eine Organisation, wir haben über 400 Mitglieder, 480 Mitglieder,
warum macht ihr denn mit beim OGC? Und für viele ist einfach, die haben Herausforderungen, weil die Interoperabilität nicht funktioniert, sie können Karten nicht übers Internet austauschen, oder sie können Daten nicht zur Verfügung stellen, deswegen sind sie OGC-Mitglieder geworden und machen mit an der Erarbeitung von Standards.
Und wir als Organisation ermöglichen eben diesen Konsensprozess und direkt schon, als das OGC vor 20 Jahren,
vor fast 20 Jahren gegründet wurde, haben wir gesagt, die Standards, die unsere Mitglieder entwickeln, sind offene Standards. Ein proprietäres Standard, der nicht von allen genutzt werden kann, weil er eben proprietär ist, da lohnt sich aus unserer Sicht die Arbeit nicht. Deswegen sind unsere Standards offene Standards, und wir haben eben Regierungen, Privatwirtschaft, NGOs, Universität und Forschung,
die arbeiten zusammen, um offene Standards für Geodaten und andere Mainstream-Informationstechnologien zu haben. Was bedeutet aus unserer Perspektive offen, und Sie sagen vielleicht alle ja, das wissen wir, aber ich möchte es trotzdem nochmal erwähnen,
die Standards des OGC sind frei und öffentlich verfügbar, sie erfordern keine Lizenzgebühren und sie sind anbieter- und dateneutral. Also, weil wir eben auch einen sehr blumen Strauß an Mitgliedern haben, die aus verschiedensten Firmen zusammensetzt und Behörden,
ist das Ziel, wir wollen keine spezielle Technologie unterstützen, sondern es soll eben anbieter- und dateneutral sein. Wir haben einen formalisierten Prozess, mitgliederbasierten Prozess, und was wir auch sehr wichtig erachten,
sind die Standards, die beim OGC, die OGC-Standards, die ermöglichen es eben nicht einem einzelnen Unternehmen, dass ein Standard kontrolliert wird.
Sehr häufig wird hier bei uns vielleicht nicht mehr, ich würde es aber trotzdem nochmal erwähnen, Open Standards und Open Source Software ist nicht das gleiche. Das eine ist Software und das andere ist Standard. Die OGC-Standards können von jedem Software implementiert werden, ganz egal, was das für eine Software ist.
Der Arnulf hat zusammen mit einem Kollegen von mir, Carl Reed, ein White Paper geschrieben und das lohnt sich sicherlich da mal rein zu lesen. Da geht es um, was ist Open Source Software und was sind offene Standards.
Wir hatten gehört, warum sollte man denn freie Software einsetzen. Ich habe jetzt hier, was ist denn der Nutzen und der Mehrwert von offenen Standards und zwar die offenen Standards beleben den Wettbewerb, auch international. Wenn
Sie in Architekturen sind, die eine Software nutzen, dann ist das prima. Aber jetzt kommen zum Beispiel, Sie haben eine neue Anforderung, eine neue Herausforderung und die Software, die Sie nutzen, die passt plötzlich nicht. Wenn Sie dann in Ihre Architektur schon auf offenes Standard setzen, haben
Sie plötzlich eine Vielzahl an Software zur Auswahl, die Sie nutzen können. Also ist es für die Anbieter von Software, kann es ganz interessant sein, wir implementieren offene Standards, weil dann wird sich unser Kundenkreis potenziell viel größer.
Offene Standards haben wir schon gehört. Fördern, Innovation sind auch häufig die Grundlage dafür. Beim OTC haben wir jetzt auch angefangen, erste Standards, den GitHub zu entwickeln, der Geopackages-Standard und das Thema wurde von der Open Source Community getriggert.
Und auch wenn wir eine alte Organisation sind, wir versuchen immer am Zahn der Zeit zu bleiben, wir entwickeln uns weiter. Das dauert vielleicht manchmal etwas länger, aber wir streben das an.
Ein weiterer Nutzen von offenen Standards, die verhindern ein Login in proprietary Architekturen. Ganz wichtig ist, das hat der Arne Fachin im Zusammenhang mit Open Data erwähnt, es ist wichtig, dass nicht nur die Techniker und die Softwareprogrammierer verstehen, warum offene Standards wichtig sind, sondern dass es auch die Entscheidegebenen versteht.
Wenn Sie eine Architektur haben oder wenn Sie Ihre Behörde oder Organisation auf offene Standards setzen, dann verhindern Sie ein Login in proprietary Architekturen, Sie sind viel flexibler bei der Auswahl der Software.
Und deswegen ist es wichtig, dass nicht nur die Techniker, dass wir nicht nur untereinander reden, ich bin keine Technikerin, aber dass die Informationen durch die komplette Behörde oder Organisation weiter verteilt werden.
Ja, was, kurzer Überblick zum OGC. Wir wurden 1994 gegründet, wir haben nächstes Jahr ein 20-jähriges Jubiläum, sind Not-for-profit-konsentbasiert und freiwillig. Also alle Aktivitäten im OGC passiert, wird von den Mitgliedern angetrieben. Im Moment sind
wir 480 Mitglieder, ein bisschen mehr als ein Drittel ist von der Interest Industry. Die großen, die Big Player und wir haben sehr viele kleine und mittlere Unternehmen und die haben alle, jedes Mitglied hat das gleiche Mitspracherecht im OGC.
Wir haben Behörden und öffentliche Verwaltungen sind Mitglieder im OGC und Wissenschaft und Forschung. Ich habe hier mal nur die Zahlen beigetan, wir haben 11 Mitglieder aus der Schweiz und einige, viele sind auch hier auf der Konferenz.
Wir haben 8 Mitglieder aus Österreich und wir sind 48 Mitglieder in Deutschland. Der größte Teil der OGC-Mitglieder kommt aus Europa, die folgt von Nordamerika und dann wird es etwas dünner. Aber wir haben in den letzten Jahren steigende Mitgliedezahlen, weil es immer mehr Anforderungen an Standards gibt und
auch die offenen Standards, auch die etablierten Standards werden auch weiterentwickelt, weil sich eben das ganze Umfeld weiterentwickelt. Wir sind bei OGC 23 Leute und im Moment haben wir mehr als 35 Standards.
Wir arbeiten sehr eng mit der ISO zusammen, speziell mit der Technik für Geoinformation und viele OGC-Standards sind auch ISO-Standards. Es gibt nicht nur Co-Branding, sondern es wird tatsächlich überlegt, wir
wollen jetzt einen Standard entwickeln, wo macht es Sinn, dass wir den entwickeln? Entwickeln wir den ISO TC211 in der Technik für Geoinformation oder machen wir das in der OGC-Arbeitsgruppe? Wenn Sie da Interesse haben und sagen, wir engagieren uns bei ISO und wollen als OGC reingucken, dann gibt es da Mechanismen, das einfach zu machen.
Wie erwähnt kann man die OGC-Standards im Software implementieren und auf unserer Webseite finden Sie ganz viele Software-Produkte, die die OGC-Standards implementieren.
Die große weltweite Nutzer- und Entwickler-Community war in Südamerika, da war auch eine Konferenz. Damals war mein Spanisch noch nicht sehr gut, aber WMS, WFS konnte ich verstehen und ich konnte mich auch mit einer Frau über ISO 19, 125 unterhalten.
Das dient dann auch und das zeigt einfach, dass wenn man über geodatene Infrastrukturen spricht, sind ISO und OGC-Standards einfach die Grundlage. Und ich erwähnte das gerade schon mit ISO, wir arbeiten eng mit vielen
anderen Standardisierungsorganisationen und Community-Organisationen zusammen, weil wir wollen nicht das Rad neu erfinden. Und wir wollen auch nicht, dass andere das Rad neu erfinden, sondern wenn man jetzt im Moment entdeckt, oder seit einigen Jahren entdeckt, viele Communities, Geo für sich und sagt, wow, das ist super und dann sagen wir doch, guck doch, was es schon
gibt, macht mit an eine Verbesserung von dem Standard oder an eine Änderung von dem Standard, anstatt etwas neu zu entwickeln. Und in dem Zusammenhang, also mit dem Kooperation mit anderen Organisationen, haben wir ein Memorandum of Understanding mit der OSGeo.
Das ist jetzt auf Englisch, weil es sind Zitate aus diesem Memorandum of Understanding. Die OSGeo hat schon dazu beigetragen, dass unser Prozess von OGC sich geöffnet hat.
Also wir haben jetzt einen offeneren Prozess, wir müssen natürlich auch schauen, beim OGC gibt es bestimmte Regeln, Policies und Procedures, aber die Kooperation und die Zusammenarbeit mit der OSGeo, die hat sich sehr positiv ausgewirkt.
Zum Beispiel gibt es beim OGC ein sogenanntes Compliance Test Programm und da hat die Open Source Community schon eine ganze Menge an Referenzimplementationen dazu beigetragen. Also wenn Sie mal schauen wollen, die meisten Referenzimplementationen für OGC Standards kommen aus der Open Source Community.
Ein wichtiger Aspekt ist, dass mit dem Working Place die OSGeo Community, es gibt da bei der OSGeo Community eine Standardsliste, da kommen neue Ideen, was für einen Standard man entwickeln kann oder wie sich ein Standard weiterentwickeln kann und das wird auch in das OGC eingebracht.
Ich glaube das MOU gibt es jetzt seit vier Jahren und das ist sehr gut. Kurzer Exkurs zur Arbeitsweise des OGC, ich hatte das schon erwähnt, wir arbeiten am Konsensprinzip. Systementwickler, Integratoren und Anwender einigen sich auf den Standard.
Also man hat die Anwenderseite gesagt, wir haben hier die Herausforderungen und man hat die Entwickler, die sagen, wir können das und das lösen und wenn die sich unterhalten, dann ist die Wahrscheinlichkeit, dass da was Gutes dabei rauskommt, relativ hoch. Wir haben einen formalisierten Standardisierungsprozess von Policies und Procedures, die immer
wieder etabliert werden und Standards eben nach dem Muster entwickelt werden. Und wir nutzen innovative Prozesse, um eben zu schauen, wenn eine Anwende in die Community kommt und sagt, der Standard ist gut, der gefällt mir, der würde es gerne für meine Community nutzen.
Dann haben wir die Möglichkeit, Testbeds oder Pilotprojekte zu machen und die nutzen dann den Standard und schauen, ob der zum Beispiel für die Hydrologie, die sind zum Beispiel sehr aktiv im Moment, die schauen, ob das passt. Und Ergebnisse von diesen Pilotprojekten, die fließen dann wieder zurück zu der entsprechenden Standardsarbeitsgruppe.
Wenn wir jetzt aber von Entwicklungen, von Standards sprechen, das ist nicht so ganz einfach. Da kommen verbreiten unterschiedliche Welten auf. Ich habe ja vorhin schon gesagt, es gibt unterschiedliche Level an Interoperabilität, reden wir überhaupt über das Gleiche.
Das sind alles Herausforderungen, denen wir uns stellen müssen. Und wenn man von Interoperabilität spricht, wo Geodaten und Geo-Services adressiert werden, dann hört sich das alles ganz leicht an. Aber ganz so einfach ist es dann doch nicht. Es ist wichtig, ein Verständnis für jemand anderen zu haben,
also nicht immer sich in den Vordergrund zu stellen, sondern auch andere anzuhören und möglichen im Dialog zu treten. Man braucht eine Kooperation. Wir müssen auf globaler Ebene miteinander kooperieren, wenn wir offene Standards haben wollen, die auch weltweit eingesetzt werden. Es ist ein Geben und ein Geben. Ich kann mich nicht hinsetzen, die Arme verschränken und warten, bis irgendjemand was macht.
Und wenn es dann doof ist und sagen, das ist ja ein Mist, das geht ja gar nicht, sondern ich beteilige mich an dem Prozess, ich mache mit. Und aus unserer Perspektive eben auch ein zertifizierter Prozess, der immer wieder wiederholt werden kann. Und das sind beim OTC die Policies und Procedures, die habe ich gerade schon erzählt.
Und jetzt komme ich so einige drauf warten, Neuigkeiten aus dem OTC. GeoServices REST API. Für die, die es nicht wissen, der Standard sollte im April verabschiedet werden und
kurz vor zwölf, also bevor es dann durchging, ging ein Aufschrei durch die komplette Community. Leute, die sie nie zu Wort gemeldet haben, haben plötzlich ganz vorne weg und haben konstruktive und nicht so konstruktive Weise viele Menschen, viele Organisationen beschimpft.
Ich wollte jetzt heute meinen Vortrag nutzen, mal darzustellen, wie entsteht so ein Standard. Sie können auch diesen Log von einer Kollegin, der erläutert das alles nochmal, da können Sie nachlesen, wie das funktioniert.
Also jetzt speziell, der GeoServices REST API Standard, der wurde vor zwei Jahren, kam die Idee auf, dass wir einen GeoServices REST API Standard im OTC definieren sollten. Und die Idee kam, wenn man so etwas machen, wenn man die Standard
entwickeln will oder definieren will, dann braucht man eine Arbeitsgruppe, eine Standards-Arbeitsgruppe. Dafür brauchen wir mindestens drei Mitglieder vom OTC, die eine Charta für diese Standards-Arbeitsgruppe entwickeln. Es wurde dann gemacht, dass diese Charta wurde dann an die Mitarbeiter, also an den OTC Staff geschickt.
Und wir haben da ein bisschen geschaut, dass das auch die Policies and Procedures berücksichtigt. Und dann wurde das dem ganzen allen Mitgliedern zum Durchlesen zur Verfügung gestellt. Die Mitarbeiter konnten dann Kommentare zurück schicken und dann konnten sie sagen, ja, das finde ich nicht so gut.
Und da musste man vielleicht noch ein bisschen was ändern. Und so wurde in ein paar Wochen, innerhalb ein paar Wochen, wurde eben diese Charta dann weiterentwickelt, bis es soweit war, dass man sagen konnte, okay, wir können jetzt eine Standards-Arbeitsgruppe entwickeln.
Das war dann im Juni 2011 und da gab es dann mittlerweile schon 16 OTC-Mitglieder, die sagten, wow, das ist spannend, da wollen wir mitmachen, weil dieser Standard, das brauchen wir wirklich.
Und diese Geoservices REST API, die Idee, die wurde von einer Firma ins OTC eingebracht. Dazu muss man jetzt sagen, wenn ein Mitglied einen Standard oder eine Idee eines Standards ins OTC einbringt, der außerhalb des OTC entwickelt wurde, dann gibt es diese Organisation, die alle Rechte an diesem Standard, an diesem Dokument, also die IPR Rules, gehen komplett ans OTC über.
Und so bleibt das, OTC heißt, alle Mitglieder haben dann, können dann gehen. Also die Firma oder das Unternehmen selber kann dann, hat ja nicht mehr den Finger drauf. Ganz wichtig.
Der Standard, wo das hat, also die SI hat diesen Standard eingebracht und hat quasi die Rechte an den Dokument abgegeben. Und ab da sind alle Mitglieder, alle Mitglieder, die über diese Standardarbeitsgruppe gearbeitet haben, konnten an diesem Standard umdrehen
und umschrauben und haben auch sehr viel Arbeit reingesteckt, haben den Standard entwickelt und viel Zeit in die Weiterentwicklung investiert. Es gab dann Ende letzten Jahres eine Public Retail Phase, also das sind mehrere
Wochen, da wird ein Candidate Standard, der wird dann veröffentlicht und alle, die Interesse haben, sind OTC-Mitglieder, sind nicht-OTC-Mitglieder, die können Kommentare zu diesem Candidate Standard schicken.
Diese Kommentare müssen von der Arbeitsgruppe berücksichtigt werden und in diesen Standard mit eingearbeitet werden. Der Candidate Standard wird in vielen Ländern veröffentlicht, aber nicht in Deutschland. Nein, das wird auf der OTC-Webseite veröffentlicht, das hat nichts mit der ISO zu tun. Genau, das ist der reine OTC-Prozess.
Die Kommentare, wie gesagt, die werden dann von der Arbeitsgruppe aufgenommen. Natürlich, wenn es völlig halblose Kommentare sind, dann macht das keinen Sinn. Aber die Arbeitsgruppe hat sich dann in Mühe gemacht, die Leute Feedback zu
geben und der Standard wurde dann auch durch diese Public Review Phase verbessert. Dann war es dann im April dieses Jahres, sollte dann der Standard beabschiedet werden, dann wurde dann dem OTC, dem Voting-Members beim OTC vorgelegt und plötzlich war Chaos da.
Also ich meine, anders kann man das nicht sagen. Es gab wieder sehr viele gute Kommentare, dass der Standard überhaupt nicht funktioniert und dass es eine Technologie bevorzugt. Also das Ende vom Beat, Sie können das alles nachlesen, das ist zum Teil sehr interessant und auch sehr interessant zu lesen.
Das Ende vom Beat war, dass die Arbeitsgruppe, und nicht es, die Arbeitsgruppe hat gesagt, wir ziehen den Candidate Standard zurück. Wir wollen jetzt nicht, dass der verabschiedet wird, weil wenn die komplette Community, wenn es
da so ein Aufschrei durch die Community geht, dann hat der Standard einfach auch keinen Rückhalt. Die OSGEO hatten oft oder einige Mitglieder der OSGEO oder Engagierten der OSGEO haben auf einem Brief geschrieben, es wurde in der Presse dargestellt ganz viel.
Also die Arbeitsgruppe, die Standards Arbeitsgruppe hat den Standard zurückgezogen, der ist aber immer noch da. Also wenn Sie jetzt sagen, ich war dabei und ich fand den Standard überhaupt nicht gut und ich will da was ändern und Sie sind Mitglied beim OTC, dann können Sie sich da bei der Arbeitsgruppe engagieren. Oder Sie spenden nicht an oder wenn Sie aus dem Open Source Bereich kommen, es gibt immer Möglichkeiten auch an der Arbeitsgruppe mitzumachen.
Und ich wollte jetzt einfach diesen Prozess darstellen. Wir haben eine öffentliche Review Phase, wo man eben auch als Nicht-Mitglied sich engagieren kann. Und was der ganze Prozess gezeigt hat, ist, dass die Community funktioniert. Es wäre schön, wenn so Dialoge einfach schon zeitnah stattfinden.
Und ich würde auf alle Fälle den Blog lesen, das ist sicherlich nochmal sehr spannend zu lesen, wie das funktioniert.
Ja, weil jetzt die Zeit abgelaufen ist, überspreche ich das, aber mein Vortrag steht zur Verfügung. Wenn Sie Interesse haben an diesem Interoperability-Programm, dass Sie einfach sagen, wir beschäftigen uns entweder mit data station in the cloud oder mobile security.
Die Data Quality Improvenance ist auch ein Thema, was man vielleicht sich auch überlegen muss. Dann gibt es die Möglichkeit, sich über das Interoperability-Programm zu engagieren oder umführen zu machen.
Ich habe jetzt nicht mehr so viel Zeit, deswegen ist das leider etwas kurz, aber ich bin die nächsten drei Tage noch da. Ja, also wenn da jemand Interesse hat, wir können das auch offline besprechen. Ja, aber wie hier auf der Veranstaltung sehr viel im 3D-Bereich, im City-GML, noch ein Hinweis auf eine Veranstaltung-Workshop an der TU München,
der auch mit den OGC-Standards und City-GML zu Ton hat, da können Sie sich auch engagieren. Wenn Sie sagen, ich will jetzt nicht Mitglied bei der OGC werden, aber ich würde gern mitmachen, dann ist diese Workshop sicherlich auch eine Möglichkeit im 3D-Bereich.
Ja, abschließend unsere Herausforderungen und Chancen. Ich glaube, ich habe diesen Geo-Services-Rest-API, das war eine sehr gute, wie sagt man, eine sehr gute Übung für unsere Community. Ich glaube, das hat auch gut funktioniert.
Es gibt bestimmt ein paar Wogen, die man glätten muss, aber hier heißt es Wogen, Wurter, Fallen, Späne. Das Wichtigste ist kommunizieren. Wenn Ihnen was nicht passt, sagen Sie es und am besten haben Sie noch vielleicht einen Urstand, wie man etwas anders machen kann. Und das gilt jetzt nicht nur für offene Standards, sondern generell auch in der OGC-Community.
Das ist immer einfach umzumeckern, aber konstruktiv dabei bei der Sache zu bleiben, ich glaube, das ist ein ganz wichtiger Aspekt. Erfahrungen austauschen auch gut, weil man dann wahrscheinlich auch Erfahrungen von anderen lernen kann.
Also wenn man miteinander redet oder erzählt, was man für Erfahrungen gemacht hat, profitiert man auch von. Die ganze Thematik Open Data, Open Standards, freie Software ist ein Modell, was man sich anschauen muss, vor allen Dingen in wirklich schwierigen Zeiten.
Stay tuned, wir haben einen Vlog, wir sind auf LinkedIn, wir sind auf Twitter. Und ich habe die OSGEO-Standards-Mailinglist auch noch aufgetragen. Also da diskutiert die OSGEO-Community, was man mit Standards machen kann oder wie das läuft.
Und OGC-Mitarbeiter und auch OGC-Mitglieder sind auch auf dieser Mailingliste. Das ist sicherlich eine gute Sache, wo man sich Informationen holen kann oder einfach informiert wird, was gerade passiert. Gut, dann danke ich wieder auf.