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

Juchuu! - nach fleißigem Basteln freue ich mich Version 0.4b der gis-tools.py freizugeben. Mein besonderer Dank geht an Seth Arnold, der mir mit viel Geduld geholfen hat die eine oder andere Hürde zu überwinden.

Hinter den Kulissen hat sich einiges getan:

• wie bereits angekündigt, ist der Code nun deutlich modularisiert und unterteilt in Benutzerschnittstelle, Konvertierungsfunktionen und dem Syntaxanalysierer (habe ich doch direkt mal das Wort 'parser' mit ding nachgeschlagen - herrliches Wort!), der derzeit noch den Kleber zwischen den anderen Ebenen spielt, sowie eine Hilfe und ein Auxiliarmodul für allgemeine Berechnungen.
• für die Umwandlung von Längen- und Breitengraden zu UTM-Koordinaten sind die Möglichkeiten hinzugekommen zwischen
  • einer aus den Längengraden berechneten gemeinsamen UTM-Zone,
  • je Koordinatenpaar die optimale Zone zu berechnen und
  • eine vom Anwender vorgegebene Zone, die angegeben werden muß
  zu wählen.

Ein bisl Zeit und Energie braucht es noch, bis auch das Analysieren der Eingabedatei flexibler von statten gehen kann. Momentan geht die Überlegung dahin, die Datenstruktur aus einer Titelzeile herauszulesen, das wäre am einfachsten für den Anwender, würde aber wiederum erschweren, 'mal eben' was auszulesen. Aber auch da wird es eine Lösung geben.

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.

Wie immer habe ich vor dem Kauf von Geräten für den Rechner geschaut, wie es denn um die Linux-Unterstürzuung bestellt ist. So auch bei dem Digitalisiertablett Bamboo von Wacom. Ein höschst schlichtes und einfaches Gerät, da ich damit eigentlich nur digitalisierte Rasterkarten in QGIS oder GRASS GIS vektorisieren wollte. Also nicht einmal die Druckstärke spielt eine Rolle für mich.

stille Wasser gründen tief

Und nachdem es mich doch einige Nerven gekostet hat und es offiziell doch noch nicht unterstützt wird, möchte ich hier eine kleine Beschreibung bieten, wie es dann doch geklappt hat. Ich habe es bisher nur unter Gentoo Linux 2.6.23 x86 und linuxwacom-0.7.8-3 getestet. Im wesentlichen habe ich mich an das HowTo Wacom Tablet vom Gentoo Wiki gehalten. Was die allgemeine Intallation zunächst betraf. Hier ist insbesondere die Konfiguration von udev ausführlich erklärt, so daß ich das hier nicht weiter aufgreifen werde. Die zweite wichtige Quelle für mich war: Support-for-wacom-bamboo-one-with-device-id-0x0069.

Das Bamboo One ist anscheinend nicht im Kern Bestandteil der Bamboo-Serie, sondern vermutlich im Kern ein Volito 2. Nur schmückt es sich mit einer anderen id, nämlich der Nummer 0069.

Also für den Fall, daß
cat /proc/bus/usb/devices | grep -A5 056a | grep Driver | grep wacom kein Ergebnis wie dieses: I:* If#= 0 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=01 Prot=02 Driver=wacom liefert, aber der Treiber vom Kernel oder linuxwacom wie im HowTo beschrieben installiert ist, dann spricht einiges dafür, daß der Treiber das Bamboo One noch gar nicht erkennen kann.

Das liegt an der Produkt-Nr. 0069, was man mit folgender Zeile recht schnell überprüfen kann:
cat /proc/bus/input/devices | grep 056a, diese sollte folgendes ausgeben: I: Bus=0003 Vendor=056a Product=0069 Version=0200.

Ich habe an den Kernelquellen nicht herumgebastelt, sondern den linuxwacom-Treiber manipuliert, so daß er erstens die Produkt-Nummer 0069 erkennen kann und außerdem das Bamboo One als GRAPHIRE anspricht und die gleichen Eckkoordinaten erhält wie das größere Volito 2

Dazu habe ich die Datei src/2.6.19/wacom_wac.c im Verzeichnis des linuxwacom-Quellcodes angepasst. Welche Bereiche kann man am besten aus der oben genannten zweiten Quelle entnehmen: Support-for-wacom-bamboo-one-with-device-id-0x0069.

Danach wäre zwar der Treiber mit dem Gerät verbunden, aber das Mapping ist noch falsch und der Stylus tanzt wie verrückt; an ein Arbeiten ist so nicht zu denken.

Also muß man nun in Ergänzung zu den Angaben von Frederik M.J. Vestre noch in der oben erwähnten wacom_wac.c-Datei die Auflistung ändern, leicht zu finden wenn man nach "Bamboo" sucht. Ich habe hier die Bamboo-Zeile auskommentiert und dafür eine neue für das Bamboo One eingefügt. Vermutlich kann man die Kommentierung auch entfernen.
{ "Wacom PenPartner2", 8, 3250, 2320, 255, 63, GRAPHIRE },
/*{ "Wacom Bamboo", 9, 14760, 9225, 511, 63, WACOM_MO },*/
{ "Wacom Bamboo One", 8, 5104, 3712, 511, 63, GRAPHIRE },
Das ganze mit folgendem Befehl übersetzen lassen:
./configure --prefix=/usr/ --enable-wacomdrv --enable-wacdump --enable-xsetwacom --enable-dlloader --enable-wacom --enable-tabletdev --enable-input --enable-mousedev --enable-evdev && make && sudo make install
und danach den im Verzeichnis unter src/2.6.19/wacom.ko erstellten Treiber anstelle des vom Kernel bereitgestellten Treibers einfügen, man sollte die dort vorhandene Datei gegebenenfalls sichern.
cp wacom.ko /lib/modules/2.6.23-gentoo/kernel/drivers/input/tablet/wacom.ko
Hier muß der Pfad an die eigene Installation angepasst werden.

Ich wünsche viel Erfolg :)

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.

Wer kennt das nicht, wenn ein oder zwei Papiertaschen hervorgeholt werden und es heißt 'Ihr müßt Euch unbedingt noch die Bilder von [irgendeinem familiären Großereignis] ansehen.' - Widerstand zwecklos. Nach dem 33. Bild mit lachenden Gesichtern und der Erläuterung der Verwandschaftsgrade und letzter Neuigkeiten zu jedem Portrait ...

Nun steht es auch mir mal wieder bevor aus tausenden Digitalphotos das herauszusuchen, was interessant ist und das ganze ansehnlich zu verpacken. Und da ich den sogenannten 'Ken-Burns-effect' (Photos zu bewegen, um aus den stehenden Motiven doch bewegte zu machen.) recht gerne mag suchte ich nun nach so einem Programm und fand schließlich cinelerra. Ein Videoschnittprogramm mit einer bisweilen ungewöhlichen Bedienung. Neben der Bewegung von Bildern bietet es noch zig Überblendeffekte, die Möglichkeit Musik / Ton zu hinterlegen und mehrere Bilder parallel darzustellen usw. usf.

Der Aufwand ist natürlich ungleich größer, aber mit ein wenig Spieltrieb kann man der Langeweile trockener Diashows entfliehen, gezielt Akzente durch Bewegung setzen - beispielsweise Panoramaaufnahmen durchlaufen lassen - mit einer passenden Geräuschkulisse die Atmsophäre in den Aufnahmen wiedergeben.

Bin gespannt, wie es bei den 'Opfern' ankommt :)

Zur Zeit arbeite ich so oft es die Umstände erlauben daran die gis-tools.py zu erweitern und vor allem in Richtung Grass GIS auszurichten. Es sind zwei neue, recht spezielle Werkzeuge zum Massenimport in Grass GIS mit Georektifizierung bzw. Referenzierung hinzugekommen. Besonders arealizer.py könnte man gut eigenen Zwecken anpassen, um viele Graustufenrasterkarten in einem Rutsch einzulesen.

Da das Modul m.cogo (Distanz & Winkel in kartesiche Koordinaten umwandeln) von Grass GIS nicht so ganz meinen Bedürfnissen entspricht, werde ich mich mal daran versuchen eine Alternative aus dem p2c.py zu entwickeln.

Momentan ist alles eine Baustelle und ich schwanke noch, ob ich die vorhandenen Funktionen der SWIG-API für Python verwenden soll. Leider sind meines Wissens bisher nur die image und general Bereiche in der SWIG-API integriert, so daß man noch nicht alles darüber erledigen kann.

Die Überlegung QGIS-PlugIns zu erstellen habe ich erstmal auf Eis gelegt, ich hoffe später bei Bedarf die Werkzeuge indirekt über die GrassToolBox innerhalb von QGIS zugänglich machen zu können.

--- Nachtrag ---
Die Arbeit geht gut voran und ich werde eine Weile die SWIG-API Möglichkeiten einsetzen, aber parallel immer eine Alternative als fallback-Lösung einsetzen, ohne daß der Nutzer es überhaupt bemerken sollte. Dies machte mir am meisten Sinn, so Stück für Stück die Teile die mit Grass GIS zusammenarbeiten sollen auf die API umzustellen ohne die Möglichkeit zu verlieren die einzelnen Funktionen außerhalb von GrassGIS einsetzen zu können. Hinzu kommt, daß die Verwendung von Grass GIS 6.3-cvs bei mir derzeit mehr als instabil läuft, und für die produktive Datenverabeitung dann doch eine stabile Funktion bevorzugt wird.