DB für OSM Vergleich auch unter ODBl? (Gebäudeumrisse aus OSM und Amt)

Hallo zusammen,
hier beim Katasteramt Rostock überlegen wir derzeit, wie wir auch OSM Gebäude auf der Offenen Regionalkarte M-V (ORKA) nutzen können. Der Hintergrund ist, dass die Einmessung aus versch. Gründen immer hinterherhinkt und einige neue Stadtteile derzeit “nackt” sind, was öfters für Irritationen sorgt. Allerdings sind wir unsicher, wie dabei mit Lizenz umgegangen werden muss. Auch innerhalb der OSM-Community scheint es dazu unterschiedliche Meinungen zu geben, weshalb wir nochmal in einem größerem Rahmen fragen möchten, bevor wir die License WG mit sowas belegen.

Details:
Die ORKa kombiniert die Vorteile von amtlichen Daten mit OSM und soll bei landesweiter Abdeckung eine freie Nutzung ermöglichen. Dazu werden bereits jetzt Daten aus OSM (insb. Straßennetz und POIs) mit amtl. Daten (insb. Gebäudeumrisse, Hausnummern, Flächennutzung, …) in einer Karte kombiniert und die zugrundeliegenden Daten sowohl aktuell, als auch mit einer guten Abdeckung vorhanden sind.

Nun soll an Stellen wo noch keine amtl. Gebäudeumrisse vorhanden sind, nach Möglichkeit mit den bereits** in OSM vorhandenen Häusern** ergänzt werden. Auf Datenebene kann dazu ein Filter genutzt werden, der für bewohnte Gebäude ermittelt, ob diese bereits durch amtl. Umrisse zu großen Teilen abgedeckt ist. Nur diejenigen Objekte, die nicht abgedeckt sind, verbleiben und werden auf der Karte angedeutet. Also vereinfacht gesagt X = OSM_buildings - GOV_buildings

Denn leider können wir aufgrund der vielen beteiligten Kommunen und auch aufgrund der Vorgaben vom Land nicht einfach die amtlichen Gebäudeumrisse freigeben :frowning: Deshalb fragen wir uns, ob es nicht einen Weg gibt, dass wir auch ohne Veröffentlichung der amtlichen Umrisse (als Orginal GOV) zu einer Lösung kommen können? Da das Ergebnis X ja nur OSM Daten beeinhaltet, stört es nicht die unter ODBl zu halten (ODBl §4.4.b) und zu veröffentlichen, aber für die amtl. Daten geht das definitiv derzeit nicht. Wir haben uns mal durch die Lizenzen gelesen und mit einigen aus der Community geredet.

Argumente, die aus unserer Sicht dafür sprechen, dass man bei so einem Vorhaben die amtl. Ausgangsdaten nicht unter ODBl veröffentlichen muss:

  • OSM-Daten bleiben getrennt von amtl. Daten, es ist nur eine Sammeldatenbank (usecase 4)

  • (andernfalls würde es reichen lediglich den Algorithmus oder die Differen zur öffentlichen OSM DB zu beschreiben (FAQ 3b))

  • OSM-Daten werden lediglich “ausgeknippst”, es ist ein “triviales” matching (FAQ 3d)

  • die DB selbst wird als solche nicht öffentlich zugänglich gemacht (wie bei anderen QA Analysen färbt die Lizenz auch nicht auf den Ursprungsbestand bzw. die temporären Datenbestände ab).

Allerdings spricht wohl auch einiges dafür, dass wir die amtl. Daten eigentlich auch unter die ODBl stellen müssten:

  • es entsteht bereits beim Filtern eine abgeleitete DB, da OSM angefasst wird und nur durch die amtl. Gebäudedaten ein gleiches Resultat erhalten werden kann (FAQ 3b, Use case 3)

  • alle gemergten Layer einer Karte müssen auch zugänglich gemacht werden (Guidelines do-examples)

Kurzum, trotz der ganzen Informationen ist das für uns ganz schön schwierig einzuschätzen, ob unser Vorhaben umsetzbar ist. Wir würden uns deshalb sehr über Hilfe bei der fundierten Beurteilung freuen, damit wir da nichts falsch machen :slight_smile:

Nicht das hier ein falscher Eindruck rüberkommt, wir wollen niemanden “übervorteilen”. Ganz im Gegenteil, hoffen wir nicht nur, dass so die Akzeptanz von OSM im amtlichen Umfeld größer wird, sondern auch, dass OSM verbessert werden kann. Gerne stellen wir dafür eine (umgekehrte) Ansicht zu Verfügung, wo noch Wohngebäude in OSM fehlen. Diese können dann (wie bisher auch) im Gegenzug von ORKa “abgepaust” werden.

Update: ORKa-Links ergänzt

Ich würde euren Hausjuristen fragen, auch wenn ich verstehe wie ungerne man sowas macht :wink:

Aber Hut ab für euer Engagement im Bereich OSM!

Hallo Matthias,

solche Fragen gehören eigentlich nicht hier ins Forum, sondern per Mail an den Herausgeber der Daten, die OSMF, genauer deren Legal Working Group: legal-questions@osmfoundation.org

OSM ist als Projekt dazu da, für die Öffnung von Datenbeständen zu sorgen. Das hat in manchen Bundesländern schon ganz gut funktioniert. Leider ist es in unsere Welt dazu nötig, dass man dafür Daumenschrauben anlegt. Der Share-Alike ist eine. Wer in der OSM-Welt mitspielen will und unsere Daten nutzen will, muss sich unseren Regeln unterwerfen. Ihr lest das vielleicht ungern, aber so ist OSM halt.

In eurem Fall geht es um regional Cuts, also die Festlegung, dass man in einem Gebiet die eine Datenquelle und in einem anderen Gebiet OSM-Daten verwendet. Dazu gibt es eine Community-Guideline, das ist aber nur eine Meinung, wie man die ODbL interpretieren könnte. Bezahlt doch einen Anwalt, wenn es euch so wichtig ist. Wenn ihr etwas Gutes tun wollt, veröffentlicht ihr (mit dessen Einverständnis) sein “Gutachten”.

Ich hoffe mal, dass Simon Poole sich hier auch noch äußern wird.

Viele Grüße

Michael

Ich schließe mich zwar der Meinung von Nakaner an. Möchte aber kurz meine Einschätzung abgeben: Wichtig ist, ob ihr den Dienst nur intern verwenden wollt oder auch nach außen (ggf. andere Ämter?) treten wollt. Intern könnt ihr im Endeffekt machen, was ihr wollt. Sobald aber nur ein Ausdruck veröffentlicht wird (an einen Dritten verschickt usw.), greifen die entsprechenden Paragraphen.

Was nicht-intern allerdings überhaupt nicht geht, ist das Mischen gleicher Feature-Typen, ohne den Rückfluss der anderen Elemente an OpenStreetMap. Ihr könnt also nicht einen Teil Gebäude aus eurer Karte neuen und die Lücken dann mit OSM auffüllen. Dann müsstet ihr euren Gebäude-Bestand unter ODbL freigeben. Was aber geht: ihr lasst eure Gebäude komplett weg und nehmt nur unsere. Wie gesagt, das bezieht sich nur auf eine nicht-interne Nutzung. Intern geht alles.

Kurzer Nachtrag: Irgendwie taucht der “Vergleich” aus der Überschrift nicht mehr im Text auf. Ein Vergleich ist natürlich auch immer möglich, es gibt - glaube ich - aber eine Guideline die beschreibt, dass man nicht “fehlt in OSM” dranschreiben darf.

Die Gebäude aus OSM ungefiltert als extra Layer nehmen, sollte doch gehen. Macht natürlich nur als Slippy Map Sinn, weil dann der Nutzer die unterschiedlichen Layer an- und abschalten kann.

Ich finde es traurig bis witzig, wenn jemand fragt, ob er dieses oder jenes machen darf als Antwort bekommt: frag einen Anwalt. Ja wissen wir als Rechteinhaber nicht, wie wir die von uns gestellten Regeln in einem konkreten Fall anwenden wollen? Ein Anwalt kann raten, wie ein Prozess ausgehen könnte. Aber die viel interessantere Frage, ob wir gegen eine bestimmte Nutzung klagen würden kann er nicht beantworten. Dies ist allerdings das was einen Nutzer wirklich interessiert.

Das Problem ist recht komplex. “Wir” als Mapper sind ja - wenn es überhaupt eine Schöpfungshöhe gibt - nur (Mit-)Urheber einiger kleinen Elemente in der Datenbank und haben einfache (???) Nutzungsrechte an jemand anderen abgetreten (den Herausgeber der Datenbank). “Wir” sind also von vorne bis hinten die falschen Ansprechpartner und wenn jemand von uns sagt “das geht so” und der Herausgeber der Datenbank das aber nicht so sieht, ist die Hölle am Brennen.

“Such dir einen Anwalt” ist also der richtige Weg, die bislang nicht verbindliche ODbL zu übersetzen und so zu interpretieren, dass sie im Einklang mit den Guidelines des Herausgebers stehen. Über einige Teile der Datenbankschutzrichtlinie bzw. dessen Umsetzung in Landes- (in unserem Sinne Bundes-) Recht wurde bislang überhaupt noch nicht geurteilt, weil keine Verfahren dazu zustande gekommen sind. Das hast du ja vortrefflich mit dem Verb “raten” beschrieben.

Klar ist “such dir einen Anwalt” die einzig sichere Lösung. Da sieht man mal, dass unsere Lizenzierung viel zu kompliziert ist.

@Gormo Naja die Rechtswissenschaften decken ja ein breites Feld ab und unsere Rechtsabteilung hat leider niemanden, der mit der Lizenzierung von Geodaten und gerade neueren Lizenzmodellen (copyleft) wirklich vertraut ist.

@Nakaner Wie schon geschrieben werden wir auf jeden Fall die legal-WG kontzaktieren. Vorher wollten wir aber erstmal schauen, ob wir evtl. Sachen völlig falsch verstanden haben bzw. ob ihr evtl. Fälle wisst, wo ein ähnliches Problem gelöst wurde. Das macht es schließlich auch für die WG einfacher das Ganze einzuordnen :slight_smile: Das mit den regional cuts ist aber noch mal ein sehr guter Hinweis, danke!

@TobWen Der Dienst soll definitiv frei zugänglich und (“offen”) nachnutzbar sein. Vergleich habe ich nur in die Überschrift, damit es klarer wird, dass nicht um ein Mischen auf Datenebene geht. Woraus leitest du denn das “Mischen”-Verbot von gleichen Features auf der Karte ab? Kannst du das bitte noch erläutern?

@SammysHP Die ORKa wird auch zum Druck angeboten und ist eine Basemap für verschiedene Dienste. Wenn dann müssten die Layer auf Rasterebene also schon verbunden werden.

@hfst Naja ist halt alles nicht einfach :slight_smile:

Wenn die Daten für den Benutzer nicht mehr als zwei Datensätze zu erkennen sind (unterschiedliche Objekttypen, verschiedene Layer), wird es mit der Lizenz schwierig. Wird wohl nicht funktionieren.

Also abgrenzen wollen wir die natürlich (s.o. “auf der Karte angedeutet”), auch damit es keine Irritationen bzgl. der Präzision gibt und damit unsere Vermesser nicht sauer sind :wink: Denkbar wäre vielleicht ein Stil, der auf osm.org derzeit für Baustellen genutzt wird, oder sowas.

Glaube nicht, dass das ausreicht.

Man kann es auch anderherum sehen:

Bei uns gibt es ein paar Beteiligte mehr und es klappt.

Nein, die Lösung Anwalt ist nicht sicher, denn im Falle eines Prozesses ist das Gericht nicht an das Gutachten eines Anwalts gebunden. Eine gute Rechtssicherheit bekommt man wenn der Rechteinhaber sagt: Passt so.
Und wenn er das nicht kann oder will würde ich das Thema nur im höchsten Notfall weiterverfolgen.

Wir haben dann mal die OSMF kontaktiert und sind gespannt :slight_smile:

Mischen/Überlagern
Es gibt dieses Verbot nicht explizit. Aber wie hier bereits angedeutet, gibt es eigentlich nur die Möglichkeit alle Gebäudeumrisse aus OSM darzustellen oder zu filtern. In dem Moment wo ihr beginnt das auszufiltern, was ihr bereits selber habt, müsst ihr die Daten logischerweise miteinander verknüpfen und das wäre wieder unzulässsig. Ich denke daher kommt diese Aussage.

PS Es wäre aber vielleicht möglich OSM Daten viel gröber zu filtern. Also Wohngiebt 1 mit OSM Wohngebiet 2 aus euren Daten. Dann bräuchte man “nur” die Wohngebiete zu veröffentlichen mit einer Vorschrift, wie man dann die OSM Daten entsprechend filtert. Das würde natürlich das einzelne Neue Haus im Bestand nicht abdecken, aber das wäre sicher verzichtbar.

Wenn zum Thema “Vermischen von Daten” eine Klärung herbei geführt werden sollte, so wäre ich an dem Ergebnis auch recht interessiert. In einem anderen Thread habe ich dazu diese Auffassung vertreten:

Entscheidend ist meines Erachtens diese Passage aus der ODbL:

4.6 Access to Derivative Databases. If You Publicly Use a Derivative Database or a Produced Work from a Derivative Database, You must also offer to recipients of the Derivative Database or Produced Work a copy in a machine readable form of:

a. The entire Derivative Database; or

b. A file containing all of the alterations made to the Database or the method of making the alterations to the Database (such as an algorithm), including any additional Contents, that make up all the differences between the Database and the Derivative Database.

The Derivative Database (under a.) or alteration file (under b.) must be available at no more than a reasonable production cost for physical distributions and free of charge if distributed over the internet.

Durch diese Passage werden die OSM-Daten (meiner Meinung nach) auch für kommerzielle Projekte nutzbar. Bei einer Vermischung der OSM-Daten mit privaten Daten (z.B. einer Kunden-DB) muß man die Struktur der Daten, die Art der Datenvermischung und das Ergebnis veröffentlichen, NICHT jedoch die Daten selbst.

Das Grundproblem bei allen Fragestellungen bzgl. der Auslegung der Lizenzbedingungen ist, daß die Bedingungen von Juristen für Juristen erarbeitet wurden. Bei allen Interpretationen die durch Laien erfolgen, sollte man sehr vorsichtig sein … entsprechend auch bei meiner vorstehenden Bewertung. Aber vielleicht kann der Herausgeber der Lizenzbedingungen hier Klarheit schaffen.

Gruß Klaus

@toc-rox: Das habe ich dir doch in deinem Thread zu den Druckdaten schon mit den Community-Guidelines genau beschrieben.

a: die gesamte (neue) abgeleitete Datenbank ODER
b: alle Elemente, die neu dazu gekomemn sind ODER die Methode einschließlich des zusätzliches Inhalts

Du musst nichts interpretieren. Die OSMF hat als Herausgeber und Lizenzinhaber unserer Daten einen Interpretationshinweis veröffentlicht. Ich erkläre es aber nochmal an deren Beispiel:

In deinem OSM-Datensatz sind 12 Restaurants, du hast eine Liste, in denen noch 8 weitere sind. Dann kannst du:
a) die 8 Restaurants aus deiner Liste nehmen und mit den 12 von OSM mischen, musst die 8 aber OSM spenden (auf Anfrage natürlich),
b) alle OSM-Restaurants rauswerfen und deine Acht plus eine andere Quelle nehmen oder
c) nur die 12 OSM-Restaurants nehmen oder
d) gar keine Restaurants anzeigen.

Es geht immer nur um gleiche Feature-Types (so nennen die es). Auch dürfen die Daten nicht interagieren. Wenn du deine zusätzlichen Restaurants so ausrichtest, dass sie auf OSM-Daten passen, musst du sie unter ODbL stellen. Wenn du Straßen anpasst, dass sie auf deine vorhandenen Wege passen (oder wenn sie OSM-Daten ergänzen), musst du sie unter ODbL stellen - auf Anfrage natürlich.

Das steht, wie gesagt, genau so in den Community-Guidelines und auf den Websites der OSMF sowie im Wiki (auch mit Übersetzung an verschiedenen stellen).

Aber TobWen, wenn wir nur gemeinsam rendern, vermischen wir die wie gesagt nicht auf DB Ebene, sondern nutzten die Daten zu gegenseitigen Tests. Wir reichern die OSM DB nicht an, sondern reduzieren sie lediglich :confused: (s.o.)

Wahrscheinlich hat @toc-rox Recht, wir sollten einfach mal auf die OSMF und deren Interpretation warten.

Moin,

auf welche Interpretation von

wollt Ihr (inkl. Klaus) denn noch warten?

Es steht doch wirklich eindeutig bereits da, dass es sowohl für die Datenbank wie auch ein aus verschiedenen Datenbanken gemischtes Werk gilt.
Sobald ihr - statt Layer zu verwenden - eine gemeinsame Kachel rendert, ist es doch ein Produced Work - da beißt die Maus keinen Faden mehr ab.

Gruß
Georg