Meinungsmache: OSM + Urheberdaten

Ich bin derzeit dabei, einen Weg zu finden, wie ich aus den OSM Quelldaten (XML Files)
direkt auf fertige routingfähige IMG Daten komme.
Ohne diesen ganzen Hickhack mit Java, Splitter, mkgmap und hasse nich gesehen.

Ich habe gestern die ersten Codezeilen begonnen mit einem vernünftigen Parser für die XML Files ohne über XML-Bibliotheken gehen zu müssen.
Das ganze mache ich in Perl.
Der Parser ist weitgehend auch schon fertig und haut auf meinem Notebook etwa eine Million Zeilen XML-Rohfile pro Minute weg.

Jetzt müsste ich die Daten aber zwischenspeichern.
Ich bin ein Freund von Software out of the box. Das heisst, ich will keinen Umweg über MySQL oder andere Datenbanken gehen sondern ein eigenes, für solche Massendaten geeigneteres Dateiformat nutzen.

Ich will nachher maximal 3 Programme haben.
OSM BuildUp - um eine Datenbank aus .oms aufzubauen
OSM Update - um die Diff-Files aus .osm einpflegen zu können
OSM Map - um .img Dateien erstellen zu können

Ich habe schonmal vor ein paar Monaten mit der gesamten OSM Datenbank gespielt.
Das Hauptproblem ist der Speicherplatz.
OSM Gesamt hat etwa 110 GB
Wenn ich das ganze in ein akzeptables Dateiformat konvertiere, komme ich auf etwa 70GB.

Und jetzt meine grosse Frage:

In dem XML File sind zu jedem Wegpunkt die Daten des Urhebers angegeben.
Das heisst, in jeder einzelnen Zeile ist der Benutzername und die Benutzer-ID mit angegeben.
Im .img File kann man mit den Daten nichts anfangen, die stehen da auch gar nicht drin.

Ich würde die auch nicht speichern wollen, denn, wenn ich diese überflüssigen Daten rausschmeisse, komme ich netto auf ein Datenvolumen von rund 50GB.
Wenn ich diese Daten dann noch binär speicher, komme ich weiter runter auf ca. 10GB.

Nun sagen aber die ganzen Open Source Lizenzen aus, dass man den Urheber immer nennen muss.

Was tun? Lizenzbruch oder schnelles rechnen mit "wenig" Platzverbrauch?

Die Diskussion ist eröffnet

Was spricht gegen eine 10GB (Binär) Datendatei und zusätzlich eine 50GB Urheberdatei. Wenn man die Daten veröffentlicht, muss man auch gleichzeitig die Urheberinfos anbieten. Wer sich die Daten herunterladen will wird ja nicht gezwungen auch die Urheberinformationen ebenfalls herunterzuladen.

Das ist vielleicht vergleichbar mit Software. Wenn ich an einem GPL Programm herumbastle muss ich auch den Quellcode der Änderungen mit veröffentlichen. Ein Benutzer, der sich z.B. The Gimp herunterlädt darf dies getrost als Binärpaket tun ohne, dass er gezwungen wird sich den Quellcode gleich mit herunter zu laden.

Gruß, Rolf.

Kommt drauf an, solange du es für dich machst, ist es wurscht, wenn öffentlich ... ja, dann muß es wohl drin bleiben und in Falle von img wo es eh nicht drin ist, stellt sich die Frage nicht.

Im Zweifel, direkt bei OSM anfragen, die sollten ja auch Interesse dran haben, das dieser ganze Konvertierungs- und Aufbereitungsstrang einfacher wird, es fehlt einfach eine vernünftige Programmoberfläche, nicht nur zur Kartenausgabe sondern auch für die Eingabe der Daten, ich würde schon manchen Abschnitt gerne aktualisieren wollen ...

Erst mal Danke für ein solches Projekt, finde ich super.
Ich sehe das mit den Urhebern auch so wie rolf1327. Oder reicht es nicht einfach Openstreetmap.org zu nennen? Wenn ich eine Karte aufrufe stehen da doch auch nicht sämtliche Editoren drin.

Ah, sorry, ich hab ne wichtige Info vergessen.
Die Software soll -wenn sie denn mal fertig wird- released werden.
Jetzt lädt Mr.X die runter, zieht sich die OSM Datenbank und baut sich mittels meiner Software die komprimierte Datenbank auf.

Mr.X hat dann ja gar nicht erst die Urheberdaten.
Wobei ich das Extrafile einen sehr interessanten Ansatz finde, den ich so noch gar nicht betrachtet habe.
Das könnte man ja wiederum einfach als XML ausgeben, weil damit nicht gearbeitet wird, man wohl aber lizenztechnisch im reinen ist.

Was hält dich davon ab, die Lizenzbedingung auch in deine binäre Datei aufzunehmen?

Mag wohl erst mal keiner so sehen. Aber wenn du sie an den Anfang stellst mit jedem Texteditor lesbar und vielleicht eine API Funktion dafür zur Verfügung stellst, dann sollten doch alle zufrieden sein. Die paar Kilobyte machen sicher nicht den Braten fett.

KDB

Um die Lizenzbedingungen geht's doch gar nicht. Die haben in der Tat wenige Kilobytes (wenn überhaupt).

Es geht darum wer-wann-was bearbeitet hat.

stoerti schrieb:

Ich habe gestern die ersten Codezeilen begonnen mit einem vernünftigen Parser für die XML Files ohne über XML-Bibliotheken gehen zu müssen.
Das ganze mache ich in Perl.
Der Parser ist weitgehend auch schon fertig und haut auf meinem Notebook etwa eine Million Zeilen XML-Rohfile pro Minute weg.

Zum Vergrößern anklicken....

Warum Perl? Warum nicht eine grundlegende Sprache wie C oder C++ und eine Bibliothek, die sich überall einbetten lässt. Egal ob es später Java, Perl, Python, C# oder was auch immer sein soll. Das würde wirklich was gegenüber mkgmap bringen. Und Perl ist bestimmt nicht ideal für die Bitpfrimelei die es braucht um eine IMG Datei zu erstellen.

Zur Lizenzfrage: Hast Du dir schon mal angesehen wie es vom OSM Projekt selber gehandhabt wird? Alle Kartenderivate aus den OSM Rohdaten werden unter Nennung der Creative Commons Attribution Share Alike 2.0 License veröffentlicht. Und dafür bietet das Garmin TDB/IMG Format auch die nötigen Felder. Keiner verlangt, dass jeder einzelne, der zu OSM beigetragen hat, genannt wird.

Ich glaube Du solltest wirklich erstmal mit den Leuten sprechen, die das alles schon gemacht haben. Die sind froh wenn jemand hilft. Und sie könne Dir auch sagen wie es geht und was noch fehlt. Das Thema ist deutlich komplexer als es sich auf den ersten Blick darstellt.

Oliver

Ich habe früher oftmals versucht, mich in bestehende Projekte einzubringen und habe immer aufgegeben als die Diskussion so los ging:

Warum Perl? Warum nicht eine grundlegende Sprache wie C oder C++ und eine Bibliothek, die sich überall einbetten lässt. Egal ob es später Java, Perl, Python, C# oder was auch immer sein soll. Das würde wirklich was gegenüber mkgmap bringen. Und Perl ist bestimmt nicht ideal für die Bitpfrimelei die es braucht um eine IMG Datei zu erstellen.

Zum Vergrößern anklicken....

Perl nehme ich, weil ich Perl geil finde, weil ich seit 20 Jahren mit Perl arbeite, weil Perl für Massendatenverarbeitung entwickelt wurde, weil Perl geil ist, weil Perl kult ist, weil Perl für jede erdenkliche Plattform verfügbar ist.
Und ich nehme Perl, weil ich es so will.

Nur um mal ein Beispiel zu bringen, wie schnell Perl ist.
Ich habe heute um 1700 Uhr einen Testimport gestartet, Germany.osm mit 6.6GB Rohdaten.
Aufgrund eines Fehlers hat er mir zu jedem Datensatz einen Overhead von einigen KB mit auf die Platte geschrieben und hat damit die Datenmenge massiv vermehrt.
Um 2200 Uhr war die Platte vollgeschrieben mit über 200GB.
Die Javakrücken bringen es nichtmal fertig, nen vernünftigen Datenimport ohne immensen Speicherplatzverbrauch hinzukriegen.
Der Rechner hatte zu keiner Zeit eine Systemload über 0.9 und der Speicherplatzverbrauch im RAM lag zu keiner Zeit über 500kB

Und deswegen nehme ich Perl.
Und wer lieber eine Lib aus C/C++ haben will, der soll sich die eben programmieren.

Noch n Nachtrag: C# ist doch Wintendo oder? Seitdem M$ bei meinen Programmen eine Warnmeldung ausgibt, dass die nicht M$ zertifiziert sind und man besser die Sofware nicht installiert, weil sie grundsätzlich böse ist, habe ich jegliche Softwareentwicklungen für Wintendo grundlegend eingestellt.
Ich werde - so lange M$ Softwareentwickler dazu nötigen will, viel Geld zu bezahlen, damit sie Software für Wintendo entwickeln - nie wieder etwas unter einem M$ Betriebssystem programmieren.
Wer auf Windows steht, der soll gucken, wie er an seine Software kommt - ich mache bei diesem Riesenbeschiss nicht mit.

stoerti schrieb:

Ich habe früher oftmals versucht, mich in bestehende Projekte einzubringen und habe immer aufgegeben als die Diskussion so los ging:
....

Zum Vergrößern anklicken....

Das wundert mich nach diesem Beitrag überhaupt nicht. Na dann, viel Spaß auf deiner persönlichen Wallfahrt. Ich hoffe der Weg wird nicht zu einsam und steinig.

viel Erfolg.

Oliver

Das lass mal mein Problem sein

Wenn ich etwas entwickle und es dann verschenke, wenn es fertig ist, dann erwarte ich, dass ich nicht daran kritisiert werde, wie ich es gemacht habe und das es anders viel besser ist.

Manche Leute scheinen gar nicht zu merken, wie arrogant sie eigentlich sind

Warum muss es eigentlich immer diese Grundsatzdiskussionen über die Programmiersprache geben. Ich freue mich, wenn jemand sich die Arbeit macht und ein Tool entwickelt von dem ich partiziperen kann. Da versuche ich nicht ihn davon zu Überzeugen, dass das Programm in Brainfuck viel besser aussehen würde. Wenn ich der Meinung bin es in Assembler oder FischelBasik besser machen zu können, dann mache ich es oder lasse es bleiben.

Just my 2 cent,
Rolf.

Ja, das haben viele leider nicht begriffen.
Und ich will nicht wissen, wieviele Open Source Projekte genau daran schon gestorben sind.

stoerti schrieb:

Ich habe früher oftmals versucht, mich in bestehende Projekte einzubringen und habe immer aufgegeben als die Diskussion so los ging:
[..Programmiersprachen/Betriebsystem-Evangelismus..]

Zum Vergrößern anklicken....

Ich glaube, wir sind alle alt genug, um solche Kindereien schlicht zu ignorieren. Wer nicht über das eigentliche Problem diskutieren will, sondern lieber sein Steckenpferd reiten möchte, der kann's gern tun... woanders!

Zu den Urheberrechtsfragen: Ich gehe davon aus, dass eine Attributierung wie an den bei osm.org gezeigten Karten (CC-BY-SA/2.0 Openstreetmap and Constributors, link zum Lizenztext) ausreichend ist.
Siehe z.B. Attributierung beim Schadstoffregister des Bundesumweltamtes oder Obamas Change-Website.

-jha- schrieb:

stoerti schrieb:

Ich habe früher oftmals versucht, mich in bestehende Projekte einzubringen und habe immer aufgegeben als die Diskussion so los ging:
[..Programmiersprachen/Betriebsystem-Evangelismus..]

Zum Vergrößern anklicken....

Ich glaube, wir sind alle alt genug, um solche Kindereien schlicht zu ignorieren. Wer nicht über das eigentliche Problem diskutieren will, sondern lieber sein Steckenpferd reiten möchte, der kann's gern tun... woanders!

Zum Vergrößern anklicken....

Stimmt. Diskutieren wir über das eigentliche Problem. Nachdem die Lizenzerwähnung ausreichend geklärt scheint, möchte ich , da wir ja schon in illuster Runde sind, etwas OT werden und einfach mal aus dem Nähkästchen meiner "Fanpost" berichten.

Dort schwappt alle Monate mal der Feature Request rein, ob man denn nicht so on-the-fly aus der OSM Datenbasis Karten für das Garmin bauen und als IMG übertragen kann. Die Benutzer stellen sich das ganz einfach vor: Bereich auf der OSM Tile Map auswälen, ok drücken, vor der Sanduhr meditieren und bing! Fertig ist es. Solches Ansinnen muss ich leider jedes mal enttäuschen, da das Einbinden von mkgmap mit dem ganzen Javazeugs nichts für schwache Nerven ist. Geschweige denn für Benutzer die eigentlich nur ein graphisches Installationsprogramm bedienen wollen/können. Eine Bibliothek, gegen die man fest binden kann und die man auch als Binary anbieten kann, wäre hier ein echter Durchbruch. Der Bedarf scheint zu existieren.

Aber wie gesagt das ist OT. Wenn das hier jemand ernsthaft diskutieren will, möchte ich einen Moderator bitten es zu verschieben. Ansonsten freuen wir und alle auf Stoertis neues Tool, das hoffentlich die Kartenerstellung revolutioniert. mkgmap hat in der Tat genügend Schwachstellen, die gefixed werden sollten.

Grüße

Oliver

Bereich auf der OSM Tile Map auswälen, ok drücken, vor der Sanduhr meditieren und bing! Fertig ist es.

Zum Vergrößern anklicken....

Sowas habe ich ja vor. So im grossen und ganzen halt.

Eine Bibliothek, gegen die man fest binden kann und die man auch als Binary anbieten kann, wäre hier ein echter Durchbruch.

Zum Vergrößern anklicken....

Das wiederum ist etwas schwierig, denn es ist ja nicht damit getan, aus einer bestehenden Datenbasis mal eben ein paar Karten zu erzeugen.
Ich erhebe den Anspruch darauf, dass meine Datenbasis wenigstens wochenaktuell ist.
Das heisst, ich muss eine Datenbasis vorhalten und die Diffs einspielen.
Dazu möchte ich aber gerne auch noch bestimmen, welche POIs ich gerne in meinen Karten hätte.
Da sollte man dann bedenken, dass man immer in mehreren GB Daten rumwurschtelt.

Aber wie gesagt das ist OT

Zum Vergrößern anklicken....

Egal. Das Threadthema ist beantwortet, lass uns OT werden, solange es sachdienlich ist.

Ich habe bisher das Osmosis weitgehend neu programmiert, also nicht umfänglich aber der osm Import in eine MySQL Datenbank, mit der ich aktuell experimentiere, klappt soweit.
Ich habe dafür Belgien benutzt mit 241MB. Der komplette Datenimport dauert rund 3 Minuten.
Die Maschine ist ein Doppel-CPU system mit 4GB Ram, wobei das Perlscript nur auf einer CPU lief, die MySQL DB auf beiden.
Der maximale Speicherverbrauch des Perlscripts im RAM lag bei 3MB.
Dafür benutze ich keine XML Libs, sondern mache das ausschliesslich mit regexp.

Wenn Import/Export und Diff-Import fertig sind, mach ich da mal n Package draus, weil selbst das mit bestehenden Tools nicht wirklich gut funktioniert.

Es gibt wohl drei Gruppen von Benutzern. Die einen verfügen über einen dicken Server und machen allerlei Tricks mit Typ Dateien und Zeugs (z.b. openmtbmap.org). Die haben auch kein Problem damit sich mit Perl, MySql und was weiß ich noch auseinander zu setzen.

Die anderen wollen einfach nur fix eine aktuelle Karte haben. Und dabei vielleicht noch bestimmte Dinge auswählen. Deren Bereitschaft für ein Tool auch noch Skriptsprache XYZ und Datenbank ABC zu installieren ist gering. Die meisten sind froh wenn sie eine Installation ohne Zwischenfragen und Probleme gebacken bekommen. Sie wollen aber zu Recht eine aktuelle Karte von ihrem Urlaubsziel, ohne auf das Wohlwollen der ersten Gruppe angewiesen zu sein.

Eine weiter Gruppe sind die Entwickler andere Projekte. Die könnten Dir helfen die zweite Gruppe zufrieden zu stellen. Nur machst Du es ihnen fast unmöglich, wenn Du eine Skriptsprache verwendest. Und auch die Wahl einer Datenbank mit Installation und Setup lässt mich zurück schrecken. Das kann ich einem Benutzer kaum vermitteln, dass er um ein Feature zu benützen erst noch eine Datenbank installieren muss. Ich bekomme das täglich mit. Meine eigene Software hat aus der Not heraus schon zu viele von diesen mystischen Kommandozeilenhacks drinnen, die oft zu Problemen führen. Und ich wünsche mir jedes mal eine Bibliothek zu haben.

Verstehe es deshalb nicht falsch, wenn Dir jemand von der anderen Seite sagt, dass er deine Entscheidungen nicht für besonders prickelnd hält. Das ist auch kein "Du musst", sondern nur ein ehrlicher Gedankenaustausch. Zu mindestens ehrlicher als das übliche Gebrüll: Mach mal, wir partizipieren dann nachher davon. Wobei in diesem Fall wohl eher gemeint war: Mach mal und wenn es was wird werden wir schon davon profitieren.

Aber jetzt arbeite Dich erstmal in die wundersame Welt der Garminformate ein. Dann kannst Du immer noch überlegen, ob Du dir das alles in Perl antun willst. Und ob eine generische Bibliothek nicht auch ihren Charme hätte.

Ich harre der IMG Dateien die da auf mich zukommen

Oliver

also perl ist überall verfügbar und genau dazu entwickelt worden, massendaten zu verarbeiten.

die MySQL Datenbank...damit bin ich auch noch nicht glücklich.
Ich will aber erstmal dahin kommen, dass ich osm importiere und hinten kommt .img raus.

Java ist noch viel kranker als irgendeine Scriptsprache - passendes Beispiel:

Installier Dir ein aktuelles FreeBSD und nehme dann ein Java-Tool Deiner Wahl aus dem OSM Projekt und versuche das zum laufen zu bringen.

Bisher verzichte ich bei den Perlscripts mit Ausnahme der DBI auf jegliche zusätzlichen Packages und ich versuche, dass das so bleibt.
Ein eigenes Datenformat kommt dann später.

stoerti schrieb:

Der maximale Speicherverbrauch des Perlscripts im RAM lag bei 3MB.
Dafür benutze ich keine XML Libs, sondern mache das ausschliesslich mit regexp.
Wenn Import/Export und Diff-Import fertig sind, mach ich da mal n Package draus, weil selbst das mit bestehenden Tools nicht wirklich gut funktioniert.

Zum Vergrößern anklicken....

Das klingt überaus lecker! Ich bin wirklich gespannt!
Und wenn's wirklich hart auf hart kommt, dann installiere ich lieber ein zweites Perl-Universum als dass ich mich von irgendwelchen JDKs niederringen lasse.

zweites Perl-Universum

Zum Vergrößern anklicken....

Wieso?
Eins reicht doch oder nicht?