Voting beendet: Tagging von Lichtquellen als man_made=lamp

Oh je. Das klingt ja drastisch. Gilt sauteuer nicht eher für die Energiekosten? Darum wollen die Berliner die doch abschaffen. Eine Verkabelung ist sowieso nötig (nein, bitte nicht die Erdkabel in OSM mappen …). Soweit ich gehört habe kann man das Lampendesign unter Denkmalschutz stellen, aber nicht das Leuchtmittel darin. Gas verbraucht sicher mehr als Glühbirnen. Und die Leuchtkraft von 75 Watt Glühbirnen habe ich bei der letzten Aldi-Aktion durch 11 Watt LED ausgetauscht. Das rechnet sich. Ich war selbst erstaunt wie hell die doch sind, im Vergleich zu den LED-funzeln früherer Tage.

So, Schluß mit off-topic für heute …

Es würde seinen Zweck erfüllen denke ich. Nach nochmaligem Überlegen hätte ich die “Ausrichtung der Lampe” aber eher als direction (ohne Präfix) bezeichnet, weil es der Bedeutung dieses generischen Schlüssels bei anderen Objekten doch sehr ähnlich ist.

Ich bestehe nicht unbedingt auf dieser Deutung, aber mich würde deine Auffassung interessieren. Hat der generische direction-Schlüssel bei Lampen gar keine Bedeutung?

Sehe ich eigentlich auch so, allerdings ist an einem Laternenmast relativ häufig auch noch ein weiteres Objekt, dass direction=* erhalten könnte (Uhren, Kameras, …). Darum ist ein eigener Schlüssel dafür vielleicht nicht so schlecht.

Nahmd,

Zum Glück kann man die Düsseldorfer Gaslaternen käuflich erwerben. Da haben wir gleich zugeschlagen. :sunglasses:

Gruß Wolf

Hallo Wolf

Schööön!

Edbert (EvanE)

Ja, das stimmt schon. Ich sehe hier nur ein wenig Verwechslungsgefahr. Wenn ich “direction” einfach wörtlich nehme und mich nach der “Richtung” der Lampe frage, denke ich spontan daran, in welche Richtung das Licht scheint. Das ist aber wieder eine ganz andere Eigenschaft. (Deshalb habe ich diese Eigenschaft auch lamp:direction genannt, weil sie eigentlich zusammen mit lamp:tilt eine Richtung im Raum angibt.)

Ich denke, es ist etwas schwierig. Den generischen direction-Schlüssel würde ich gefühlsmäßig bei Objekten benutzen, die eine generische Richtung haben. Das trifft sicher auf Höhleneingänge, Wegweiser und viele Aussichtspunkte zu (wobei letztere auch einen 360°-Blick oder mehrer Blickrichtungen haben können). Bei einer Lampe wüsste ich spontan nicht, was ich als deren generische Richtung bezeichnen würde. Ja, die Richtung des Mastes passt schon irgendwie, klingt für mich aber nicht sehr generisch. Vor allem, wenn man dann auch noch einen T-förmigen Mast mit Lampen an beiden Seiten hat… Hier müsste man dann z.B. direction=N;S taggen und so den direction-Schlüssel um Mehrfachwerte erweitern, die mit lamp:count gekoppelt sind. So eine Erweiterung fände ich in einem lamp: Unterschlüssel besser aufgehoben.

Die Strahlrichtung ist ja normalerweise ein Raumrichtung, also mit 2 polaren Koordinaten Azimut und Elevation.
Warum nicht einfach fürs Licht
lamp:light_direction=90,0
bedeutet 90°=Ost und 0°=Horizontal
oder
lamp:light_direction=*,0
rundherum (Sternchen) horizontal

Sogar ranges sind denkbar
lamp:light_direction=[0 90],[-90 0]
also Winkelbereich Nord bis Ost, horizontal bis unten.

So wäre es am einfachsten für die 3D-Software zu verarbeiten.

Vergesse aber nicht den Aufwand beim Taggen: bei einer krummen Straße müsste man die ganzen Winkel
ausrechnen oder mit dem Kompass jeden einzelnen Mast besuchen.

Ein vereinfachtes Modell wären Polarkoordinaten, deren Azimut nicht nach Nord zeigt, wie üblich,
sondern entlang der Straße ausgerichtet ist.
ein
lamp:ligh_direction=90s,0
mit “s” für “street aligned”. Taggt man alle Lampen so heißt es dann, 90° zur Straßenlinie, also rechtwinklig auf die Straße zu

Für die Mastform könnte man sich ähnliches ausdenken. Ist die Frage, ob man den wirklich so detailliert modellieren will.
Richtige 3D-Formen wie in Google Earth sind schon deutlich datenintensiver.
Dazu wäre es besser, von der Karte aus eine Referenz auf ein 3D-Modell zu verlinken.
Ich glaube Google Earth macht das auch so.
Für die 3D-Modelle haben sie sogar einen eigenen Editor (Google Sketchup).
Sieht sehr schön aus. Hatte ich auch mal für ein Bauwerk gemacht.
Sicher gibt es auch OpenSource-Alternativen dazu.
Man modelliert zunächst im lokalen Koordinatensystem und kann es dann
beliebig in der Google-Karte platzieren.

Genau diese beiden Winkel habe ich ja mit lamp:tilt und lamp:direction beschrieben.

Hatte ich verstanden. Für die Verarbeitung wäre es nur praktischer Azimut/Elevation in einem Tag zusammenzufassen.
“lamp:tilt” klingt etwas irreführend, eher nach Neigung der Lampe und nicht des Strahls. Die sind meist 90° auseinander.
Aber frag lieber mal einen “native speaker”. Wir Deutsche definieren gerne mal Dinge auf Englisch, die für die Briten oder
Amis dann total lustig klingen (siehe “Handy” … handy what? ist die Rückfrage).

Was hältst du eigentlich von einem “street aligned” Koordinatensystem?
Also z.B. etwas wie “90s” für 90° Azimut relativ zur Straßenlinie?
Dann müsste man sich meist überhaupt keine Gedanken mehr über die Ausrichtung einzelner Lampen machen,
vor allem bei kurvigen Straßenzügen. Bei absoluten Winkeln würde man bei N Nord anfangen,
bis E East und dazwischen NE Nordost oder steigende Winkel … ziemlich aufwendig.
Der Bezug zur Straßenlinie ändert sich i.d.R. aber nicht, sind eben meist 90° zur Straßenlinie ausgerichtet.
Oder 0° sieht man auch öfters (war das nicht auf den Belgischen Autobahnen so im Mittelstreifen?).

Azimut zählt man i.d.R. von 0° Nord zu 90° Ostwärts in positiver Richtung (also mit Uhrzeigersinn),
anders als die mathematische Polarkoordinate (x-Achse ist dort 0°).
Solaranlagenbetreiber normieren 0° in Südrichtung, hmm warum wohl das? Hatte ich zuvor noch nicht gesehen…

Und vergesse nicht eine Referenz (URI, ID etc.) auf ein 3D-Modell.
Das Rendering von Straßenlampen wird vermutlich nur in detailgetreuen 3D-Landschaften Sinn machen.
Darin würde man die schönen Gaslampen natürlich ausführlicher modellieren wollen als nur mit einem Strichmännchen.
Eine Lampe wird dann nur einmal als 3D-Modell hinterlegt und bei mehrfacher Nutzung referenziert.
Hast du schon in der OSM 3D-Community gefragt? Die haben sich da wohl schon Gedanken gemacht.

Nicht unbedingt - zwei Winkel aus zwei Tags auszulesen ist nicht schwieriger als einen Tag mittels Trennzeichen aufzuteilen, um daraus zwei Winkel auszulesen.

Kommt darauf an, was man als “Neigung der Lampe” ansieht. Zunächst einmal hat eine Lampe an sich kein vordefiniertes “oben” oder “unten”. Die einzige Richtungsabhängigkeit ist also durch die Lichtabstrahlung gegeben.

Der “tilt angle” bezeichnet genau den besagten Neigungswinkel - ansonsten hätte ich dieses Tag nicht vorgeschlagen.

Dafür braucht es dann aber 1. eine Relation, damit man weiß, relativ zu welcher Straße eine Laterne ausgerichtet ist, die an einer Kreuzung steht, und 2. muss der Auswerter bei gebogenen Straßen für jede Laterne wissen, zu welchem Punkt auf der Straße die Ausrichtung gehört. Davon halte ich daher wenig.

3D ist nicht Thema dieses Proposals.

Ich meine generell finde ich es praktisch Richtungsvektoren (3D) oder az/el-Tupel (2D) vektoriell zu verarbeiten anstatt mit For-Loops durch die Elemente zu iterieren. Programmcode ist dann nur halb solang. Auch Ein/Ausgabe geht kürzer. Positionsvektoren macht man z.B. gerne als CSV-Strings (lon,lat,alt).

Ich hatte bei lamp:tilt zuerst die Lampe selbst im Kopf, also wenn die Röhre horizontal steht (0° tilt) oder die Lampe gerade (90° tilt). lamp:direction/tilt/orientation würde ich intuitiv immer auf das Objekt selbst beziehen. Deswegen “light_direction” fände ich eindeutiger.

Die Trennung direction und tilt in 2 Tags hat auch einen Vorteil: im Proposal hast du ja vorwiegend auf die direction verzichtet und nur tilt angegeben. Könnte man mit leeren CSV-Feldern im Koordinatenstring auch machen, sieht aber so in deiner Formatierung dann etwas eleganter aus. Stell das Proposal aber ruhig mal auf die internationale Liste zur Debatte. Es ist schließlich eine weltweite Definition für OSM. Nicht alles was wir im Wörterbuch so finden klingt auch für die native speakers so schön wie für uns. Elevation vs. Altitude für die Höhe war auch so ein Fall, laut Wörterbuch ginge beides, aber das Englische kennt da doch Nuancen drin. Die Definition soll schließlich dauerhaft in OSM verankert werden.

Stimmt, hatte ich nicht bedacht. Die Lampe ist ja ein Einzelobjekt ohne Straßenbindung. Ist das so kompliziert oder reicht eine kurze Referenz auf die (existierende) Straßenrelation? Zu 2. sehe ich den Nachteil nicht: Für den Mapper ist es praktisch, da alle Lamps nur noch dupliziert werden müssen. Der Renderer kennt den Winkel des nächsten Straßensegmentes und kann die Rotation direkt einsetzen. Kann vielleicht sein, dass an scharfen Kanten mal eine Lampe etwas schief steht, aber dafür würde man sich den Aufwand ersparen, hunderte von Einzelrichtungen separat zu taggen. Einfach nur die 4 Himmelsrichtungen würde ja auch zu schiefen Lampen führen, dann müsste man schon die Winkel stetig verändern. Für den Mapper viel zu viel Arbeit, für den Renderer später in Software nur eine Frage von Mikrosekunden, vollautomatisch. Oder, wie in deinen Beispielen, lässt man die Richtung eben ganz weg und denkt sich “die übliche Richtung” also zur Straße hin. Vermutlich hast du lamp:direction auch in erster Linie für Sonderfälle wie Flutlichter angedacht, nicht?

??? verstehe ich nicht. Ich dachte OSM-3D wäre so der Primärnutzer der Straßenlampen-Infos.
Dann sollte man die keys auch so auslegen, dass sie etwas damit anfangen können.
Ist hier im OSM-Germany Forum einer der 3D-Kartographen die so etwas benutzen würden?
Ich kenne deren Konzept nicht, aber so eine Modell-Referenz wäre für mich die logische Art,
mit 3D-Modellen umzugehen.

Oder gibt es 2D-Karten wo Straßenlampen Sinn machen? Ich meine jetzt nicht die reine Spielerei
nach dem Motto “hey, meine Karte hat auch Lampen, ätsch”, sondern irgendwas praktisch Sinnvolles.
Wenn ich auf dem Bürgersteig bin suche ich nicht in OSM nach der nächsten Laterne.
Lampen vom Typ Orientierungslicht auf Windkraftanlagen schon eher, wenn man eine Nachtwanderung
für die Pfadfinder auf OSM-Karten plant. Das passt gut in normale topografische Karten. Ist mir schon passiert,
dass in der Landschaft oder im Meer ein Haufen Rotlichter blinkt und man neugierig in der Karte nachschaut
was das sein könnte (Offshore-Windpark, Kurzwellen-Sendestation etc.)


Noch eine Tag-Idee:

Jetzt wo die LEDs aufkommen gibt man auch die Leuchtkraft bzw. den Lichtstrom in Lumen an.
lamp:power=11W für die Birnen klingt stark im Energiesparen, aber man denkt gleich an eine
schwache Funzel. Darum schreibt man dann lamp:flux=1200 Lumen auf die Packung, was dann
etwa 75 W Glühbirnen entsprechen würde.
lamp:power interessiert eigentlich nur den Eigentümer der Lampe, der die Energierechnung bezahlt.
Die Nutzleistung der Birne/Lampe drückt man besser in lamp:flux aus.

Ja, so kann man seiner Lieblingslaterne einen Brief schreiben.
Und Speicherplatz wird ja immer billiger, also kein Problem. :sunglasses:

Eine solche Objekt-Verlinkung würde alle Objekte betreffen. Ein 3D-Schema könnte also auf Strassenlaternen anwendbar sein, ein Strassenlaternen-Schema sollte jedoch nicht 3D-Tags für Bahnsteige definieren. Strassenlaternen können in einem 3D-Rendering auch mit dem hier vorgeschlagenen Schema schöner werden, ohne dass man dafür eine Objektverlinkung braucht (für die auch immer erst jemand ein Objekt erstellen müsste).

Richtig, das Modell-Verlinkungsschema sollte für alle OSM-Objekte einheitlich sein.
Wie wird das denn derzeit bei OSM-3D realisiert?
Mit dem aktuellen Tagging würde man halt nur sagen welche Kategorie von Lampe vorliegt
und die konkrete Form müsste dann generisch gerendert werden. Meistens will 3D aber mehr,
also konkrete Formen, Texturen etc.

Bei Google Sketchup würde man in so einem Falle erstmal den Typ “Düsseldorfer Gaslampe”
als 3D-Modell zeichnen, in einem lokalen Koordinatensystem. Das wird als XML gespeichert,
genauso wie Momumente, Gebäude, Türme etc.
Jedes Modell bekommt eine eindeutige ID, z.B. so etwas wie GUID, oder URI/URL zum Modell.
In der Karte stehen dann zu den Objekten jeweils die ID notiert,
z.B. als model_id=#ffaa7432 model_title=“Gaslampe Düsseldorf”
oder model_url=osmserver/models/gaslampe_d.xml

Würde man solche IDs dann nicht in den Namesraum der Lampe setzen?
lamp:model_id=
oder doch eine Stufe höher
model_id= ??

Ich versuche mir gerade vorzustellen, wie 3D für OSM funktioniert (Google Earth als Beispiel im Kopf).

Der Aufwand ist mir bewusst. Das wird man sicherlich nicht für jede 08-15-Lampe machen.
Andererseits sind die nicht so individuell wie einzelne Häuser. Wenn eine Stadt nur bei 3 Herstellern
eingekauft hat würden 3 Modelle reichen, die dann zigtausendfach referenziert wrden.
Und wenn der Modell-Link fehlt wird eben generisch gerendert.

Bedenkt bitte die Anwendung in 3D-Szenerien. Das ist vermutlich der einzige Fall wo die Straßenlampen
überhaupt Sinn machen.

Denkbare Anwendung: Autorennen-Computerspiel “Need for Speed in Munich Town”. Also mal so richig
in seiner Lieblingsstadt Rennen fahren ohne Konsequenzen fürchten zu müssen.
Die mir bekannten Autorennspiele kennen leider das reale Straßennetz nicht.

Nahmd,

mit einem vernünftigen Konzept “Ausrichtung” würden die Peitschenleuchten am Thewissenweg die Straße beleuchten und nicht das Ödland daneben. Also macht mal hinne!

Gruß Wolf

Vor allem schauen die Häuser so flach aus im Vergleich zur Lampenhöhe.

Oder müssen die erst noch gebaut werden? Ist das der Bebauungsplan?
http://www.youtube.com/watch?v=oyqvspyyM2Y

Dafür braucht man dann natürlich Code, der CSV-Strings verarbeiten kann.

Bei einer Lampe mit einer Röhre kann man das so interpretieren - bei anderen Lampenformen anders. Ich hatte hier gezielt nach einem Begriff gesucht, der allgemein einen Neigungswinkel bezeichnet.

Wie bereits weiter oben geschrieben, habe ich genau das versucht, konnte mich aber nicht bei der tagging-Liste anmelden und nicht posten. Daher hatte ich ja darum gebeten, dass jemand das Proposal dort postet.

Wenn eine solche Relation existiert, müsste man Lampen darin aufnehmen. Dafür müsste man aber entweder die eingemottete associatedStreet-Relation wieder rauskramen und modifizieren oder eine neue entwerfen.

Dafür muss er aber erst einmal das nächstgelegene Straßensegment bestimmen, und dafür muss er die Geometrie analysieren, was deutlich mehr Aufwand ist, als einen Wert auszulesen.

Letzteres ist als möglicher Wert für lamp:direction bereits vorgesehen.

In meinen Beispielen scheint die Lampe nach unten (lamp:tilt=-90), da braucht es keinen Azimutwinkel.

Nein. Das ist ein generelles Tag für Lampen mit Vorzugsrichtung.

Primärnutzer werden eher die Ersteller von Licht- oder Nachtkarten sein, die Lichtquellen auswerten oder rendern wollen. Natürlich gibt es auch eine 3D-Community, aber das ist eine völlig andere Fragestellung, denn:

Genau so ist es. Mein Lampen-Proposal und 3D sind orthogonale Themen. Natürlich sollte es für Lampen auch 3D-Modelle geben, aber diese Modelle sollten für alle Objekte gleich aufgebaut sein. Also braucht es auch ein Tag, das für alle Objekte gilt, und das hat in einem Proposal speziell für das Taggen von Lampen und deren Eigenschaften nichts zu sichen.

Und wenn man aus etwas Entfernung eine Ortschaft sieht, mit einer beleuchteten Straße mit 4 Laternen zwischen zwei Kreuzungen, kann man die auch auf einer solchen Karte finden.

Sowas kann man machen. Den zu messen dürfte nicht leicht sein, die wenigsten Mapper dürften ein Messgerät dafür haben. Möglicherweise kennen die Betreiber den Lichtstrom und man kann diesen Wert erfragen - sicher kennen sie aber die elektrische Leistung, die ist also leichter zu erfragen. Aber so ein Tag kann man aufnehmen.

In C/C++ sind das jeweils Einzeiler (sscanf,fprintf,format, …).
Plus Code für Extrawünsche wie * für rundherum oder für ranges.
Für die ganzen geometrischen Berechungen hat der typische Renderer auch gleich
die Matrix/Vektor-Libraries hinzugelinkt. Das schreibt sich dann alles ganz einfach,
z.B. Vektor-rotation y = A * x mit der Rotationsmatrix A.
In Java ähnlich, nur das elegante Overloading der math. Operatoren geht da nicht.

Hmm, scheint wohl komplizierter zu sein als ich dachte.

So etwas Ähnliches hatte ich mal programmiert (Track-Matching an spline-Muster).
War halb so wild. Interessant ist eben die elegante Beschreibung “0=längs” oder “90=quer” zur Fahrbahn.
Im Prinzip arbeitet der Renderer ähnlich, wenn er die Straßennamen entlang der Krümmung der Straße zeichnet.
Du kannst ja beide Systeme zulassen und den “Markt” (die Mapper) mit Füßen abstimmen lassen in welchem System
sie lieber arbeiten. Wenn das korrekt definiert wird (z.B. Suffix “s” für die street aligned Winkel zur Unterscheidung)
lässt sich das nachträglich umrechnen. Ich hatte mir das ohnehin nur als eine Alternative zum Absolutwinkel vorgestellt.

Aber unterschätze nicht den Aufwand. Wenn die Straße von Azimut 0 bis 10° eine Biegung macht und dazwischen stehen 30 Lampen müsste der Mapper den Winkel jeder Lampe um 10/30=0.3333°-Schritten erhöhen. Der Aufwand ist halt wesentlich höher als einfach nur pauschal für alle zu sagen, der Strahl steht quer zur Fahrbahn. Der Mapper hat sicher keine Lust zu rechnen. Der 3D-Renderer rechnet sowieso schon viel. Das wären dann nur noch peanuts für die Software (bei den CPU Gigaflops heutzutage).

Mit Nutzer meinte ich mehr die Leute, die diese Karten später betrachten und daraus einen Nutzen ziehen. Ich dachte nicht an die Kartenersteller. Deren Spieltrieb ist bekannt. Ich mag auch die Lichtkarten, Sat-Aufnahmen, von Europa, aber eher just for fun. Und muss immer an die Belgier denken wie viel Atomkraftwerke sie wohl brauchen um das ganze Land zu erleuchten. Komplett wurde die Autobahnbeleuchtung immer noch nicht abgeschaltet. Zuletzt irgendwo in der Nähe von Lüttich war es nachts auf der Autobahn noch sehr hell.

Das Objekt Lampe braucht dazu auf jeden Fall eine Referenz. Du willst die halt nicht in den lamp: namensraum schreiben, sondern eine Stufe höher, wenn ich das richtig verstehe. Kein Problem, hauptsache die Referenz ist da. Es ist natürlich gut, wenn lamp: auch unabhängig von einem 3D-Modell gut (generalisiert) beschrieben wird. Vielleicht gibt’s aber doch Querbeziehungen oder Seiteneffekte. Dazu müsste man die beiden Datenmodelle gut kennen.

Das ist aber gerade für die “Lichtkarte” wichtig, die dir vorschwebt. Die LED erzeugt die gleiche Lichtleistung wie eine Glühbirne mit 7-facher Leistung. Für die Lichtkarte zählt die elektrische Leistung also weniger. Genau genommen müsste darin auch die Reflektivität des Bodens und der Umgebung eingehen.

Der Mapper wird Lumen sowieso nicht messen können. Lumen ist nicht die Helligkeit “Lux”, sondern ein Maß für das gesamte Licht das die Lampe in verschiedene Richtungen verteilt. Ist am Mast ein Schild mit der Leistung drauf? Beim LED-Kauf steht zumindest auf der Verpackung Watt und Lumen drauf. Erst bei 1200 Lumen hat mich die LED zum Ersatz meiner alten Energiesparlampen bewogen. Es gibt auch viel schwächere Funzeln, z.B. um die 400 Lumen. Das hat sich mittlerweile gut entwickelt. Beim Beamer schaut auch jeder nur noch auf die Lumen-Zahl und nicht auf die Watts der Beamerbirne.

Der Kartenersteller nutzt die Daten für seine Karte und der Betrachter nutzt dann diese Karte. Natürlich hatte ich auch letztere in Sinn - Karten sind ja nicht als reine Kunst da, sondern um genutzt zu werden.

Jedes Objekt braucht eine Referenz, egal ob es nun eine Lampe oder eine Kirche ist. Das ist keine lampenspezifische Eigenschaft.

Die Lichtkarte schwebt mir nicht vor, sondern das ist ein Beispiel aus der Praxis, wie bereits heute lit=yes und highway=street_lamp ausgewertet wird. Das lässt sich durch ein erweitertes Lampenmapping noch ausbauen.

Eben das meine ich ja. Lux kann man ja noch mit einem Messgerät messen, aber für Lumen muss dann schon die ganze Lampe ins Labor.

Stimmt schon, die “Watt” kann man leichter prüfen (in dem Fall die Stadtwerke), bei Lumen muss man in der Praxis auf die Herstellerangaben vertrauen. Die reine Lux-Messung wäre sowieso keine sinnvolle Aussage, denn die Helligkeit hängt noch von der Strahlbreite/-form, Winkel und vom Abstand ab. Wenn man das kennt oder abschätzt könnte man die Lux-Messung auf Lumen entsprechend zurückrechnen. Von der elektrischen Leistung weiss man nicht wie viel jede Lampe in Wärme umsetzt (i.d.R. das meiste davon). Das einzige wirklich vernünftige Maß für die Lichtleistung einer Lampe ist Lumen.

http://de.wikipedia.org/wiki/Photometrie

Aber wie gesagt, heutzutage wird Lumen genauso wie Watt beim Verkauf der Leuchtmittel angegeben, zumindest bei LEDs.

Du hast ja auch einen Tag für die Strahlbreite.
Wenn es dann noch etwas wie “lamp:flux=10000lm” geben würde, könnte man die Helligkeit
für verschiedene Abstände abschätzen. Das Gesamtlicht Lumen reduziert um eine typische
Reflektivität von Straßenbelag wäre dann das was für eine Lichtkarte aufsummiert werden muss.
Mit den elektrischen Watt ginge das nicht so gut.
Naja, dafür müsste dann alles recht gut gemappt werden.
Wenn man die Lampenstärke nicht kennt könnte der Lichtkartenrenderer auch einfach einen “typischen Wert” einsetzen.