Leider fehlt mir jede Erinnerung, wo genau ich zum ersten mal von Spagetthi-Code gelesen habe. Vermutlich im Linux Magazin oder in der c't. Vor ein paar Tagen stieß ich dann auf eine nicht zu 100% ernsthaft gemeinte Erläuterung, was denn Spaghetti Code sei. Die weniger bekannten Alternativen Lasagna-Code (Blockhafter aber strukturierter Code, schwer zu pflegen) und Ravioli-Code (die Idealform, kleine Pakete, die miteinander in Beziehung stehen aber unabhängig sind in der Pflege).

Dies führte mich zu der Überlegung, wo denn die gis-tools.py einzuordnen wären. Ich kam recht schnell dazu, daß es sich um eine Unterart der Lasagne handeln muß, den Cannelloni (Bild auf Wikipedia). Längliche Rohren von in etwa 2cm Durchmesser, die man dann nebeneinander legt ansonsten aber ähnlich wie Lasagne mit lekkerem Inhalt befüllt.

Genau so war der Code bisher. Drei riesige Pakete, an beiden Seiten offen, an sich leicht zu warten, da sich quasi alles innerhalb der Röhren abspielte, aber man ahnt es schon, fast immer die gleiche Soße drin.

Zu Ravioli habe ich schon immer eine besondere Beziehung gehabt. Als ganz kleiner Junge fiel es mir schwer mir diesen seltsamen Namen 'Ravioli' zu merken, das waren eindeutig zu viele Vokale auf einmal für eine bis dahin von Fremdsprachen unbefleckte Zunge. Aber es gab da etwas viel besseres. Und zwar habe ich einen kleinen Schlumpf, der auf einem roten Kissen sitzt, den habe ich immer noch! Und dieses Kissen war in Form und Größe genauso beschaffen wie die Ravioli, und damit waren das für mich keine Ravioli mehr, sondern Schlumpfkissen, die rote Farbe besorgte ja die lekkere Soße.

Ich werde also Kissencode schlumpfen. Freue mich schon auf die Kissenschlacht, und Schlaubys erhobenen Zeigefinger.

Nun mußte ich mich also entscheiden unter welche Art von Lizenz soll ich meine Software stellen.

Gar nicht so einfach, zum einen soll es eine übliche Lizenz sein, eigentlich wäre mir die, die ich auch für dieses Blog allgemein verwende am liebsten. Dummerweise wird das aber nicht empfohlen von den Leuten bei Creative Commons - schade eigentlich, ich finde es wäre doch ein leichtes die Lizenz auch auf OpenSource Software auszudehnen.

Sei's drum. - Also entschied ich mich wenigstens äußerlich der CC-Lizenz nahe zu bleiben und nahm deren Angebot dankbar an, die GPL über das CC-Emblem dafür einzubinden.

Mich wunderte zwar, daß da überall noch was von GPL 2 stand, hatte ich doch eigentlich gedacht die frisch gebackene GPL 3 zu verwenden.

Also stieß mich hier das Schicksal doch deutlich darauf mir doch mal etwas genauer die Unterschiede anzusehen, bzw. Artikel darüber zu lesen - ich lese gerne, aber juristischen Kauderwelsch zu verdauen fällt bei mir nicht mehr unter das Lesevergnügen.

Da haben mich dann doch ein paar Dinge erstaunt. Vor allem aber folgendes: so würde mich die GPL 3 nach deutschem Recht schlechter stellen. Ich wäre auch noch verpflichtet Lizenzverletzer in einer Frist zu kontaktieren und ich müßte den Lizenzvertrag quasi manuell kündigen, ja wozu mache ich mir denn hier die Mühe eine Lizenz zu wählen, doch um genau so einen Unfug zu vermeiden.

Nicht, daß ich glaube ich würde jemals eine Lizenzüberschreitung zu ahnden haben, dafür ist mein Kram dann doch zu simpel und sicherlich auch nicht einzigartig.

Das meiste betrifft mich glülicherweise gar nicht, da ich ja keine Hardware erstelle und auch kein DRM verwenden werde.

Also habe ich mich erstmal dazu entschieden es auf die GPL 2 zu beschränken, ändern kann ich es später ja immer noch.

Ach ja, nebenher habe ich für die gis-tools.py noch eine Dokumentation erstellt und eine TODO Liste angefangen. Nur das Changelog habe ich noch vergessen

Manchmal hat man Glück. Das Thema Längen- und Breitengrade in UTM (Universal Transverse Mercator) umzuwandeln hat wohl aufgrund seiner enormen Komplexität des öfteren Interessierte veranlasst entsprechende Fragen zu stellen und glücklicherweise höchst fundierte Antworten zu bekommen.

So war es relativ einfach, die hinter der Konvertierung stehende Formel in die gis-tools.py einzubinden. Ein bischen Feinschliff und einige zusätzliche Features möchte ich noch einbinden, um auch große Reihen von Koordinaten elegant umzuwandeln. Version 0.4 wird also schon bald folgen.

Manchmal muß man sehr alte archæologischen Vermessungen in moderne GIS einlesen. Das einfachste Vermessungsverfahren bevor es Laser-Tachymeter gab, war Distanz und Winkel.

Leider bieten die Opensource GIS-Programme GrassGIS und QuantumGIS keine Möglichkeit Polarkoordinaten einzulesen. Für GrassGIS ist zwar das Add-On Modul m.cogo vorhanden, welches aber derart aufwendige Vorformatierung erfordert, daß man es schneller in einer Tabellenkalkulation selber umgerechnet hat.

Also war eines meiner ersten Projekte mit Python die Umwandlung von Polarkoordinaten zu kartesischen Koordinaten.

Um gewisse Dinge nicht immer neu schreiben zu müssen, habe ich also das ganze Ding modularisiert und es ist der zweite Part (mein erstes Spielzeug war die Umwandlung von Grad zu Dezimalgrad) meiner kleinen gis-tools in Python. Da ich kein Skript gefunden hatte für diese Messreihenumwandlung möchte ich nun auch meinen kleinen Beitrag leisten und es an die Allgemeinheit zurückgeben. Es ist zwar noch in einem sehr unausgereiftem Stadium (simple Datei mit ASCII öffnen, auslesen, umwandeln und in einer neuen Datei speichern), aber vielleicht nützlich für den einen oder anderen mit ähnlichen Daten.

Bisher sind noch etliche Einschränkungen vorhanden:

• kein Unicode!
• der Parser ist auf 'Punktname, Distanz, Winkel, zusätzliche Bemerkung' beschränkt und erlaubt keine Abweichungen
• Der Initialpunkt wird grundsätzlich mit den Koordinaten 0;0 angenommmen
• keine GUI
• einfache Genauigkeit

Auf lange Sicht möchte ich das ganze als Plug-In(-Sammlung) für QGIS gestalten, da hier ohnehin gerade die Weichen für Python-Skripte gestellt werden und mit Qt mein bevorzugtes GUI-Toolkit zum Zuge kommt.

Die jeweils aktuelle Version findest Du unter Projekte.

Heute habe ich in der Werbepause von Papillon zwei Episoden aus der neuen Hornbach TV-Werbung gesehen. Köstlich! Endlich mal wieder Werbung, die sich nicht so ernst nimmt und Spaß macht.

Leider mit Flash, aber dennoch zum Genießen für alle TV-Abstinenzler: www.schnickundschnack.de.

Ach ja, bitte nicht denken, ich würde von dem Baumarkt bezahlt, seit Blixa Bargelds Lesung ist man da hoffentlich unverdächtig.

Es gibt sie noch, die Programme, die man am besten in einer DOSe laufen läßt. Zum Beispiel WordPerfect 5.1, welches es zwar auch für Unix gibt, wovon ich aber leider keine Lizenz besitze.

Ich weiß noch wie ich um das Jahr 2000 herum verzweifelt versucht habe mit einem Font diverse Sonderzeichen in MS-Word einzugeben, persische, arabische und türkische Ortsnamen in einem Text können ein echtes Problem darstellen.

Hätte ich damals bereits WordPerfect 5.1 gehabt, wäre das alles kein Problem gewesen. Auch das Setzen von Spalten, Fußnoten, Seitenformatierung läuft wesentlich stabiler ab als unter so manchem Textbearbeitungsprogramm heute.

Aber das coolste was ich dort kennengelernt habe, ist daß es bereits Anfang der 90er überhaupt kein Problem war ein universell lesbares und layoutgetreues Dateiformat zu verwenden. Ich meine nicht das proprietäre Dateiformat von WordPerfect selber, sondern die PostScript-Ausgabe, die zum Lieferumfang gehört. Für wohl 95% aller Fälle reicht das für die gleichen Zwecke aus, wie heute der in OpenOffice, MS-Office und den vielen anderen Office-Suiten reichlich beworbene und als grandiose Innovation erachetete direkte PDF-Export.

Manchmal ist WYSIWYG ein wahrer Segen, aber nach einer Weile gewöhnt man sich wieder daran nicht gleich zusehen, wie es aussieht, sondern die Vorstellungskraft reicht vollkommen aus. Und wenn man es dennoch mal braucht gibt es eine schnelle Druckvorschau, die im Zweifelsfall einen schnellen Überblick verschafft. Im Prinzip ist das Schreiben auf WordPerfect sehr ähnlich wie HTML im Texteditor zu verfassen. Insbesondere wenn man sich die Steuerzeichen (also den Code der hinter dem ganzen Text steht) parallel darstellen läßt. Man sieht sofort, wo anstelle einer Einrückung der Tabulator mißbraucht wurde oder ähnliche Probleme. [Fett]und dieser Abschnitt wird fett[fett]: ist das nicht herrlich einfach? Genau deswegen gibt es ja auch Befürworter für OpenOffice diese Darstellung einführen zu wollen, wie dieses Macro für die 1.x Serie von OOo.

Fast jeder HTML-Editor hat dieses Feature, und wenn man bedenkt, daß es zum guten Ton auch in OfficeSuiten gehört bei HTML den 'Code' offen zu legen, warum nicht auch für normale Texte.

Übrigens ist dieser Modus so beliebt und auch die DOS-Oberfläche mit weißer Schrift auf blauem Grund (glücklicherweise kann man sich das anpassen ;) ), daß selbst in der jüngsten Version Office X3 von Corel dieser Modus einstellbar ist.

Für weitgehende Microsoft Abstinenzler wie mich gibt es aber auch noch eine andere Lösung, nämlich OpenDOS in einer Virtual Machine. Es äuft grandios schnell, nur die Maus zickt bisweilen herum, aber die braucht man sowieso kaum, da man sehr schnell mit Tastaturkürzeln arbeitet. Und dann noch schnell ein mount -t msdos /var/lib/vmware/Virtual\ Machines/floppy.img /mnt/floppy/ -o loop und schon kann man auf die Diskette aka Laufwerk A: gespeichertes Lesen und auch schreiben. Übrigens, wer WP 5.1 noch einsetzt hat oft auch noch Disketten. Darüberhinaus kann man damit noch auf Rechnern arbeiten, die im zweistelligen MHz-Bereich getaktet sind.