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.

Nachdem der erste kleine Spaziergang durch den Wienburgpark erfolgreich aufgezeichnet war, mit etwas Mühe dem GPS-Gerät entlockt und in eine shp-Datei mittels gpx2shp verwandelt war, wollte ich doch nun den wirren Linien und Punkten ein wenig Boden geben und lud mir zu dem Zwecke gleich mal ein ETM+ Satellitenbild¹ herunter.

Eine GrassGIS-Location für Münster mit UTM (32U) für das Satellitenbild angelegt und noch eine für die GPS-Daten in LatLong; rasch die Daten importiert und dann mittels v.proj alles zu der UTM-Zone konvertiert.

Eine leichte Abweichung hatte ich erwartet, aber etliche Kilometer in Nordost- bzw. Südwestrichtung kamen mir dann doch seltsam vor. Dann wäre der Spaziergang nämlich in der Nähe der Rieselfelder anstatt im Park verlaufen. Eine Überprüfung ergab eine Überraschung. Die GPS Daten waren trotz der Konvertierung GPS->gpx-Datei->shp-Datei (zumindest die Punkte der Spur ('Track' im GPS-Jargon) ließen sich nicht via gps-babel importieren, das Modul v.in.gpsbabel brach ab.) konsistent und zeigten völlig korrekte UTM-Werte an, wenn ich der UTM-Berechnung des Gerätes trauen darf.

Vermutlich war die als 'orthorectified' deklarierte ETM+-Datei unsauber georeferenziert worden. Das ist vergleichsweise ärgerlich, denn Rasterdaten zu georeferenzieren ist mit GrassGIS freundlich formuliert: 'mühsam'.

Quelle für das zugrunde liegende Satellitenbild ist: Global Land Cover Facility, http://www.landcover.org. Erstellt mit GrassGIS 6.2.1 & QuantumGIS 0.8.1

Und hier schließlich die Route in rot und die einzelnen Messpunkte in grün bis leicht bräunlich, je nach Höhe über NN.

_________________________

Heute ist es eingetroffen, mein neues Spielzeug. Ein GPS-Handgerät. Gleich nach dem Auspacken hastig zwei Batterien hineingetan und andächtig zugeschaut, wie die GPS-Satelliten vom Gerät erkannt wurden, bis es der Meinung war, daß es sich in Münster befinden muß. Erkennbar an den Koordinaten.

Bereits die ersten Tests zeigten, wie einfach sich die Daten via QuantumGIS auslesen lassen. Ich hatte befürchtet zunächst mit gpsbabel die Kommandozeile quälen zu müssen.

Ein kleiner Bummel durch die Stadt zeigte recht bald die Grenzen des Empfangs auf, in den Gassen und Straßen und am Prinzipalmarkt unter den Arkaden, brach der Empfang zeitweilig zusammen, dennoch konnte ich bereits einigermaßen die Route erkennen, leider reichte es nicht für kontinuierliche und halbwegs verwendbare Höhenwerte aus.

Dummerweise stürzte QGIS auch noch reproduzierbar ab, wenn man versuchte die Daten anhand der verschiedenen Felder unterschiedlich darzustellen. Auch ein shape-export wurde nicht ermöglicht, ich denke da ist noch etwas zu tun im GPS-PlugIn. Nichtsdestotrotz ist es ein sehr angenehmer Weg die Daten schnell einzulesen und direkt zu betrachten.

Auch ein erster Test mit GrassGIS lief sehr vielversprechend, wenn auch wie QGIS nur unter Verwendung von gpsbabel im Hintergrund, gpstrans als GPS-Datenimporteur verweigerte die Zusammenarbeit wegen Formatproblemen wie es aussah. Schade, daß es keinen ebuild von gpstrans gibt, so mußte ich für den Test doch tatsächlich seit langem mal wieder ein Programm per Hand installieren, was sich aber auf das Herunterladen, entpacken, make && sudo make install reduzierte. Sehr einfach, in der jetzigen Form leider auch sehr überflüssig.

Ein weiterer Malus gegenüber dem Import mit QGIS ist, daß man zunächst eine Location anlegen muß, bevor man überhaupt Daten eimlesen konnte. Schließlich sind auch noch die einzelnen Feldbezeichner überraschenderweise unterschiedlich benannt. Was bei QGIS 'Elevation' ist, wurde von GrassGIS als 'Altitude' deklariert. Obwohl beide eigentlich mit gpsbabel den gleichen Datenimporteur verwenden sollten. Da stellte sich für mich die Frage, ob einer von beiden eine eigene und eben andere Bibliothek mitbringt.

Ich freue mich bereits darauf ein paar Spaziergänge aufzuzeichnen und hoffentlich als komplette Route einlesen zu können.

Die ersten Ergebnisse werde ich sicherlich hier veröffentlichen.

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 :)

Teil drei sollte sich eigentlich bereits vorgestern damit beschäftigen, wie das Hochladen von Daten (Wegpunkten, Routen, 'tracks') klappt. Es funktionierte wider Erwarten nur halbwegs. Ich vermutete zunächst etwas in der Bedienung von gpsbabel übersehen zu haben, weshalb immer nur ein Wegpunkt hochgeladen wurde, anstatt alle vorgegebenen auf einmal.

Aber das war es nicht, also mal die allzu bekannte Suchmaschine genutzt und siehe da: der Treiber für Garmin (garmin_gps) wird auf gpsbabel ein reibungsloses Funktionieren treffenderweise als "depressingly uncommon situation" beschrieben. Also blieb mir nur über die angebotenen Lösungswege auf Gentoo Linux anzuwenden

Als erstes nutze ich die Gelegenheit den unweise fest in den Kernel kompilierten Treiber zu entfernen, was mir die mühsamen Umwege erspart den Treiber davor zu bewahren überhaupt geladen zu werden. Ich halte es auch für die sauberere Lösung das Ding direkt zu entfernen, da es nachweislich nicht korrekt arbeitet.

Im wesentlichen reichte es dann unter:
/etc/udev/rules.d/ die Datei 51-garmin.rules anzulegen. In diese Datei kommt folgende Zeile:
SYSFS{idVendor}=="091e", SYSFS{idProduct}=="0003", GROUP="plugdev", MODE="660"

Nun konnte ich mittels QGIS eine neue .gpx-Datei anlegen und mit lustigen Wegpunkten befüllen. Auch Routen ließen sich problemlos erzeugen und als normaler Nutzer ohne root-Rechte mit folgendem Befehl auf das GPS-Gerät hochladen:
gpsbabel -r -i gpx -f test.gpx -o garmin -F "usb:"

Nun endlich kann ich in Vorbereitung für Hattuscha die wesentlichen Strukturen vorab auf das Gerät laden. Übrigens Routen und 'tracks' eignen sich hervorragend, um Gebäudeumrisse nach zuzeichnen.

Und wieder ein Problem gelöst :)

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.

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

Noch ein bisl Zeit investiert und schon sind zwei komplette Karten fertig und können begangen werden.

Die Rieselfelder sind vollständig und auch zwei Wintersonnwendfeiertage-Spaziergänge in Marl (wenn auch mit wenig Bildern) sind fertiggestellt.

Rieselfelder
Marl

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.

Nach und nach nimmt die weite Reise Gestalt an.

Der große Rucksack ist bereit beladen zu werden, das ThinkPad ackert sich durch die letzten Vorbereitungen, damit ich (hoffentlich) vor Ort in Bogazköy gleich mit dem GPS draufloslaufen kann.

Lange Listen warten darauf viele, viele kleine Häkchen zu bekommen, wenn die einzelnen Dinge Ihren Platz gefunden haben, oder zu erledigende Aufgaben Ihren Abschluß gefunden haben.

Mal schauen, wie oft ich Gelegenheit haben werde vor Ort ins Internet zu gehen und hier ein paar Nachrichten zu hinterlassen. Wenn ich dort überhaupt etwas zu berichten habe, oder darf - kann ja sein, daß es so wichtige Ergebnisse gibt, daß ich an dieser Stelle nicht freimütig alles veröffentlichen darf.

Nebenbei habe mich noch ein wenig in digiKam eingearbeitet. Da ich noch keine Digitalcamera besitze, sondern nach wie vor der schrecklich teuren analogen Photographie treu geblieben bin (Diapositive haben immer noch eine unglaubliche Informationsdichte! - warum sind gute digitale Spiegelreflexcameras so teuer?) war für mich bisher wenig Bedarf dazu. Aber ich habe den Nutzen dann doch unterschätzt, meine vielen Rasterdaten kann ich damit viel besser überblicken, kommentieren und sortieren. Das hat mir die Arbeit an den Satellitenbildern sehr erleichtert.

Ich frage mich gerade, wieso man in Flugzeugen nur 20 kg Gepäck und 8 kg Handgepäck haben darf. Ich denke ich wiege weniger als der durchschnittliche deutsche Erwachsene, man könnte doch einfach die einzelnen Passagiere samt allen Gepäckes wiegen und das darf einen bestimmten Wert nicht überschreiten. Somit wären dicke Menschen angehalten den überdurchschnittlichen Kerosinverbrauch entweder durch reduziertes Gepäck zu kompensieren, oder eben zu bezahlen, während leichte Menschen, vielleicht etwas günstiger davonkämen. Solche Gdanken kommen, wenn man merkt, daß die ganze Ausrüstung und die mitzunehmende Kleidung (es ist zur Zeit ca. 30° C in der Region Ankara - zum Herbst hin wird es sich wohl empfindlich abkühlen) für 60 Tage doch einiges an Volumen und Gewicht bedeutet. Wenn es ganz eng wird, werde ich wohl auf ein bischen Fruchtgummi und Lakritz verzichten müssen. Oder meine Weste damit vollstopfen :).

Genug der wirren Gedanken - bis die Tage!

Endlich gibt es neue Photos, es hat sich in der letzten Zeit doch einiges angesammelt und ich habe kräftig aussortiert.

Googles Map / Earth Applikation hat mir nach ein bisl Einarbeitung ermöglicht endlich Bild und Ort zusammenzubringen. Erstmal als 'proof of concept' ein kleiner Auszug aus einer Radtour in die Münsteraner Rieselfelder zum Photographieren. Die GPS-Koordinaten sind aus der .gpx-Datei in eine Polylinie umgewandelt, und dann noch zum Testen einen Punkt herausgegriffen und zu einem Vorschaubild verlinkt.

Wie das ganze funktioniert kann man dann hier sehen: Rieselfelder.

Das Photo dort kann man immerhin schon anklicken ;) .

Wer schon immer mal einfach seine GPS-Daten auf einer GoogleMap veröffentlichen wollte, der wird mit gpx2gm.py das machen können.

Mich hat geärgert, daß es so mühsam ist seine GPS-Tracks zu veröffentlichen. Man muß Sie erst via gpsbabel einlesen und dann kann man das zwar mit einem webdienst umwandlen lassen in eine GoogleMap, aber da muß man dann jede Menge Handarbeit anlegen, bis die so aussieht, wie man das gerne hätte.

gpx2gm.py ist zwar noch lange nicht am Ziel meiner Wünsche, aber die wichtigste Fähigkeit beherrscht es ganz ordentlich.

gpx2gm.py

Das Programm liest eine gpx-Datei ein und wandelt alle Trackpunkte in eine GoogleMap-Polylinie um. Es unterscheidet noch nicht zwischen einzelnen Tracks innerhalb einer Datei, das kann man als Vorteil sehen, wenn man kleinere Unterbrechungen im Empfang hatte, oder als Nachteil , wenn das alles gar nicht zusammen betrachtet werden soll - das ist so eine Sache an der es noch zu arbeiten gilt.

Was es kann (für mittlere Breitengrade), ist aber das nötige Zoomlevel anhand der gewünschten Kartengröße in Pixeln zu wählen und so dafür Sorge zu tragen, daß man da kein lästiges rumprobieren hat.

Einzige Vorraussetzung ist, daß man die Tracks vom Gerät im XML Format als .gpx-Datei vorliegen hat.

Wer es ausprobieren möchte:
auf der Befehlszeile python gpx2gm.py pfad/zur/datei.gpx
eingeben.

In der Programm-Datei sind alle Variablen ausführlich kommentiert, so daß man sich einigermaßen schnell zurecht finden sollte. Für die Zukunft ist hier eine Vereinfachung angedacht. Bevor man aber eine solche Karte veröffentlichen kann, muß man sich von Google eine kostenlosen API-Key zuteilen lassen.