Qualitätssicherung mit Vektortiles
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 68 | |
| Author | ||
| License | CC Attribution 3.0 Germany: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/30498 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
| |
| Keywords |
1
2
3
6
7
11
15
24
26
28
29
30
31
36
37
39
49
52
53
54
57
58
59
60
61
62
65
67
68
00:00
Direction (geometry)Vector graphicsDatabaseLecture/Conference
00:54
View (database)INGA <Programm>Pell's equationPHPSQLOpen sourceParallel programming modelSoftwareCoordinate systemPhysical quantityState of matterListe <Informatik>DatabaseGebiet <Mathematik>MittelungsverfahrenContent (media)Service (economics)SurfaceLevel (video gaming)UpdateVector graphicsSoftwareDatabaseParallel programming modelHauptspeicherProgramming languagePlane (geometry)ZeitraumPolygonFile viewerVECTOR <Programm>RoutingC++Total S.A.ComputerComputer animation
07:35
Network topologyRaw image formatNetwork topologyForestContent (media)Normal (geometry)GeometryGeometryObject (grammar)Scale (map)Liste <Informatik>Interface (chemistry)Sound effectSoftwareFile formatAbbildung <Physik>BootingNoten <Programm>PDF <Dateiformat>Wind waveRandFluxNewton's law of universal gravitationDiagram
14:16
RoutingRollbewegungLinieValidationPolygonVector graphicsCelestial sphereObject (grammar)Gebiet <Mathematik>Abzweigung <Strömungsmechanik>Router (computing)Spring (hydrology)RollbewegungGeometryRoutingSoftware developerValidationLinieEuclidean vectorLösung <Mathematik>StatistikerCoroutineDatabaseLink (knot theory)Noten <Programm>Diagram
20:57
World Wide WebGeometryUpdateDatabaseImplementationCalculationCollisionGebiet <Mathematik>LinieRoute of administrationVector graphicsGeometryFile viewerGenerating functionMeeting/Interview
Transcript: German(auto-generated)
00:07
Die vorhergehende Referentin hat schon so ein bisschen an einer Stelle den Finger in die Wunde gelegt, als sie den Wegweise so erwähnt hat, der bei den Daten dann in die falsche Richtung deutet. Das hat nicht unbedingt jetzt was mit Qualitätsmängeln zu tun,
00:26
aber Qualitätssicherung ist bei OpenStreetMap natürlich das A und O. Die Datenbasis ist mittlerweile gut. Jetzt geht es natürlich auch immer darum, wie man den Standard hält oder verbessert.
00:40
Und da freue ich mich auf den Vortrag von Michael. Hallo. Ja, die Qualitätssicherung bei OSM lässt manchmal zu wünschen übrig. Und darum geht es in meinem Vortrag, wie man die mit Hilfe von Vectortals verbessern könnte. Ich möchte zuerst kurz vorstellen, was der Status quo ist bei Qualitätssicherung.
01:01
Die drei großen Qualitätssicherungsdienste und deren gemeinsames Problem, wie Vectortals eine Lösung sein könnten, wie häufig sich Daten in OSM überhaupt ändern, welches Format man für Qualitätssicherungszwecke verwenden könnte und dann noch zur Größe der Teils und Einschwerpunkt des Vortrags für sein Inhalt der Teils, wie man da mit Relationen umgeht.
01:28
Bislang gibt es zur Qualitätssicherung in OpenStreetMap drei große Dienste. Das ist zum einen der OpenStreetMap Inspector, der nicht nur Qualitätssicherungstool ist, sondern auch noch so eine Sammlung an Spezialkarten.
01:40
Hier sieht man jetzt ein Areas View mit kaputten Flächen und vor allem Multipolygone, aber auch einfache Ways. Es gibt den Dienst Keep Right und es gibt den französischen Dienst Osmose. Osmose ist von den drei in der jüngste und hat auch das modernste UI.
02:05
Die anderen beiden werden etwas lieblos behandelt. Die drei kann man vergleichen nach einigen Kriterien. Das wichtigste Kriterium eigentlich ist, wie häufig werden die Daten in diesen Diensten aktualisiert.
02:20
Und es fällt auf, es gibt keinen Dienst, der stündliche Updates hat. Alle haben tägliche Updates, Keep Right schafft sogar bloß einen wöchentlichen Rhythmus. Um überhaupt diesen Rhythmus zu halten, wenden einige der Dienste auch Partitionierungstechniken ansprechend, dass sie die Welt in kleinere Teile aufteilen, um beim Prozessieren der einen Teil weniger Arbeitsspeicher und andere Ressourcen zu benötigen.
02:46
Der OSMI macht das gar nicht. Der rechnet in den meisten Fällen immer die Welt als Ganzes durch. Keep Right teilt die Welt in glaube ich 64 Rechtecke auf, die etwa gleich groß sind von der Datenmenge.
03:02
Und Osmose nutzt die länderextraktete Geofabrik. Der OSMI ist meines Erachtens nach der einzige von den drei, der Parallelisierung einsetzt. Beim OSMI werden verschiedene Views, also die einzelnen Themen parallel berechnet auf verschiedenen Computern.
03:25
Die anderen parallelisieren nicht. Der OSMI kann auch dritte Datenquellen einbinden. Der Aerojas View wird gar nicht von der Geofabrik berechnet und der Routing View wurde gar nicht von der Geofabrik programmiert.
03:43
Da lassen wir nur das Programm laufen. Der OSMI setzt überwiegend C++ ein, aber die externen Teile verwenden auch gerne andere Programmiersprachen, unter anderem Java für den Routing View. Keep Right setzt auf PHP und die eigentliche Federsuche erfolgt in einer Datenbank und Osmose setzt auf Python und eine Datenbank.
04:08
Keep Right und Osmose setzen als Datenbankschema Osmosis ein. Der OSMI ist im weiten Teil nicht open source und die anderen beiden sind es.
04:21
Das große Problem ist, das habe ich jetzt schon angedeutet, sie erhalten sich nicht an die Regel Don't Repeat Yourself. Sie rechnen jeden Tag oder jede Woche den gesamten Planet durch, dabei ändert sich ein Open Street Map innerhalb einer Woche oder eines Tages gar nicht so viel. Deshalb denke ich in Vector Tiles eine gute Lösung dafür.
04:44
Warum sollte man Tiles nehmen und nicht ein anderes Partitionierungsschema? Tiles sind jetzt ein etabliertes Schema zur Partitionierung. Es gibt schon Software dafür und wenn man doch noch Software dafür schreiben muss, kann man das Software auch anderweitig wiederverwenden.
05:01
Man ist dann zwar gezwungen die Webmarkerprojektion zu verwenden, die gewisse nicht zu vernachlässigen Nachteile hat. Unter anderem kann man nicht die ganze Welt damit abbilden. Aber da es in den polnahen Gebieten wenig Daten gibt, ist dieser Nachteil meiner Meinung nach zu verschmerzen.
05:26
Ich habe in meiner Masterarbeit analysiert, wie häufig auch Open Street Map Daten sich ändern. Ich habe mir eigentlich, um Vector Tiles erzeugen zu können, in dem Format, das ich haben möchte, mir einen eigenen Datenbank-Importer geschrieben.
05:41
Der kann auch DIVs anwenden und sogenannte Expire-Listen schreiben, wie es auch OSM2P und SQL macht. Also Listen, welche Teile neu gerendert werden müssten, wenn es eine Rendering-Datenbank wäre. Die Listen sehen aus, wie hier auf der linken Seite dargestellt. Diese Listen kann man auch in Shapefiles konvertieren. Dazu habe ich ein Programm geschrieben namens Expires to SAP.
06:06
Und wenn man die mit einigen SQL-Abfragen noch zusammenfasst, kommt dann so schöne Bildchen wie dieses hier raus. Das hier sind die Änderungen in Open Street Map von Ende August bis Anfang Oktober letzten Jahres. Ich habe alle stündlichen DIVs aus diesem Zeitraum importiert.
06:27
Alle Gebiete, die blau sind, haben wenig Änderungen erfahren. Und wenn man genauer hinschaut, es gibt ein paar wenige Teils auf Zoom-Stufe 12, die in diesen fünf Wochen keine Änderungen erfahren haben. Das ist ein Gebiet im südwestlichen Brandenburg. Okay, dort ist auch Tote Hose, muss ich sagen.
06:48
Potsdam ist echt lebendig dagegen. Das ist orange, das ist unter dem E von Berlin. Aber weite Teile wurden maximal in zehn Stunden dieses gesamten Zeitraums aktualisiert.
07:05
Das heißt, wenn man täglich die Daten neu prozessiert, hätte man sie etwa 20-30 Mal zu oft prozessiert. Es gibt auch ein paar Hotspots, das sind die Stadtzentren von Berlin und Hamburg. Vermutlich waren das die vielen Maps.me-Mapper.
07:25
Das sieht auch im anderen Teil Südwestdeutschland ähnlich aus. Dort fällt noch eins auf. Wenn man Relationen berücksichtigt, dann treten Bahnstrecken hervor, nicht die Autobahnen. Das liegt daran, dass es in Deutschland eine aktive Eisenbahn-Mapper-Community gibt.
07:43
Und wenn die irgendwo einen Way aufteilt und er wird von fünf ICE-Linien benutzt, dann werden all diese fünf Relationen expired und die sind meistens etwas länger. Die gehen von Basel bis Berlin oder von Amsterdam bis weiß Gott wohin. Folgliche Weise expired dann das gesamte Rheintal.
08:04
In Frankreich sieht man den Effekt auch aber nicht so schlimm. In den USA machen Relationen gar nichts aus, aber dort sieht man, dass dort auch Mapping-mäßig wirklich nichts los ist, bis auf die zwei großen Städte in Kalifornien. An der Ostküste sieht es ähnlich aus.
08:22
Ich habe jetzt nur diesen etwas größeren Ausstieg aus Kalifornien genommen. Wenn man Relationen weglässt, kommt man zu einem, meiner Meinung nach, realistischeren Ergebnis. Im ländlichen Raum treten Lücken hervor und die Bahnstrecken verschwinden ganz.
08:41
Die Bahnstrecken waren sonst etwa einmal täglich expired worden. Das Ganze noch einmal für Frankreich und Südwestdeutschland. Jetzt treten wirklich Städte hervor. Und in den USA würde es sich jetzt richtig lohnen, Vektorteils einzusetzen.
09:04
Zum Vektorteilformat. Die bisherigen, die meisten gebräuchlichen Vektorteilformate sind für den Zweck, denke ich, nicht geeignet. Es sind Formate, die für das Rendering gedacht sind. Diese enthalten die Geometrie direkt als Koordinatenliste. Und keine Ways mit ihren Referenzen auf die Node-IDs.
09:26
Für einige Qualitätssicherungszwecke braucht man jedoch die Topologie, sprich, welcher Way referenziert welchen Node, gerade wenn man Routingfehler finden möchte. Es gibt von Mapbox schon sogenannte QA-Teils.
09:41
Dabei handelt es sich um GeoJSON. GeoJSON enthält keine Topologie. Außerdem enthalten diese QA-Teils auch keine Relationen. Ich habe dann die naheliegende Lösung genommen und mich für ganz normales OSM PBF entschieden. Dann kann man auch schon bestehende Software, die OSM-Daten einlesen kann und darin Fehler sucht, weiterverwenden.
10:08
Es stellen sich jetzt noch zwei Fragen. Wie groß sollen diese Teils sein? Und welche Inhalte sollen in den Teils enthalten sein? Die Größe der Teils sollte sich nach den Daten richten.
10:26
Wenn ich relativ lange Geometrien habe, dann ist es keine gute Idee sehr kleine Teils zu wählen, weil man dann die Geometrie mehrfach prozessiert, weil sie in jedem Teil vollständig enthalten ist.
10:42
Vorausgesetzt, sie ist vollständig enthalten. Warum sie das sein sollte, gleich, gleich. Deshalb sollte teils so groß sein, dass die meisten Objekte, die in ihnen liegen, auch nicht aus dem Teil herausragen.
11:00
Objekte mit großer Ausdehnung sind in der OSM typischerweise Grenzrelationen, die auch mal um halben Globus reichen können. Fließgewässer, die nicht verdohlt sind, also keine kleinen Bäche, sondern eher größere Flüsse, die können auch kilometerlang sein. Wälder und Seen, größere Seen.
11:23
Objekte mit typischerweise kleiner Ausdehnung sind als Notes gemapte Points of Interest und Gebäude. Und wenn in einer Gegengebäude gemapt sind, dann sind auch diese verantwortlich für die große Datenmenge.
11:40
Deshalb ist es eine gute Annäherung, einfach zu untersuchen, wie viele Notes ein Teil hat und daran zu entscheiden, ob man es noch weiter aufteilen sollte oder ob man es bei dieser Größe belässt. Die Annäherung, Notes pro Teil zu verwenden, als Maßstab für die Teilgröße,
12:01
die Größe kompensiert auch den Fehler der Mercator-Abbildung. In polennahen Gegenden, wo ein Teil nur noch eine geringere Fläche auf der Erdoberfläche abdeckt, werden die Teils von Natur aus dann wieder größer, sodass dieser Fehler ausgeglichen wird.
12:23
Die Größe von Teils kann man mit dem Programm Dense Teils aus der Sammlung Osmium Contrib ausrechnen. Ich habe es in meiner Masterarbeit für jede gewünschte Zumstufe einmal laufen lassen. Das ist nicht die effizienteste Lösung. Man könnte das Programm auch noch umschreiben, dass es mehrere Zumstufen auf einmal berechnet.
12:44
Dazu hat mir aber dann die Zeit gefehlt. Für die Zumstufe 10 sieht die Ausgabe dann etwa so aus. Zuerst die Zumstufe 10, dann X-Koordinat und Y-Koordinat des Teils und dann die Anzahl der Notes im Teil.
13:04
Diese Listen habe ich alphabetisch sortiert und dann mit einem Pilsen-Skript zusammengeführt. Das hat insgesamt 45 bis 60 Minuten gedauert. Der Großteil der Zeit ging für Dense Teils drauf. Das Sortieren selbst und das Zusammenführen hat noch drei Minuten gedauert.
13:23
Das Resultat ist dann das hier. Der Schwellwert war hier 5000 Notes pro Teil maximal. Wenn das Teil mehr als 5000 Notes hat, wird das aufgeteilt. Die größte Zumstufe ist die Zumstufe 16 und die kleinste war die Zumstufe 8.
13:42
Man sieht auf dem Wattenmeer draußen, wo es wenig Daten gibt, gibt es schnell sehr große Teils. Nun zum Inhalt der Teils. Was soll in den Teils enthalten sein? Es stellt sich die Frage, wer ist vollständig enthalten sein?
14:03
Ich kann eins sagen, mit unvollständigen Ways kann man nicht arbeiten. Man braucht zumindest nicht nur die Notes, die im Teil selbst liegen, sondern auch noch einen Teil der Notes, die außerhalb des Teils liegen.
14:20
Wenn ich nämlich nicht weiß, wo sich die Notes, die der Way referenziert, aber außerhalb des Teils liegen, befinden, weiß ich nicht, ob der Way von hier hier lang geht oder hier lang geht. Das ist relevant, wenn ich sicher überschneidend überkreuzende Linien finden möchte und nicht weiß, wo sich das letzte Segment befindet, das die Teilgrenze kreuzt.
14:47
Das heißt, man braucht zumindest diese Note und wenn man zu faul ist zum Programmieren, schreibt man diese Note mit noch ins Vektor-Teil.
15:02
Mit Vektor-Teils sind prüfbar zum einen Tagging-Fehler, weil die Tags der Objekte, die in einem Vektor-Teil enthalten sind, sind im Vektor-Teil enthalten. Was nicht geht, ist die Suche nach exotischen Tags, die auf globalen Statistiken beruht. Dazu braucht man Hilfslösungen wie eine Datenbank, in der man alle aktuell vorhandenen Tags speichert.
15:24
Sprich, man bräuchte eine Art Tag-Info noch im Backend. Man kann mit Vektor-Teils Geometrie-Fehler in Ways prüfen, also Selbstüberschneidungen oder ob Notes doppelt referenziert werden. Und man kann auch einfache Routing-Prüfungen machen, zum Beispiel ob es unverbundene Ways gibt, die nahe beieinander sind.
15:46
Nicht prüfbar sind Routing-Inseln, Routing-Quellen und Senken. Gerade letztere sind nicht zuverlässig prüfbar. Man kann einige entdecken, aber nicht alle.
16:04
Die Teils sollten natürlich auch Relationen enthalten. Und da stellt sich die Frage, sollen diese Relationen vollständig sein? Vollständige Relationen sind keine gute Idee, weil dann enthalten die Teils an vielen Bahnstrecken meistens die Gleise von Halbdeutschland.
16:23
Weil die wegen besagten Eisenbahnrelationen. Man kann auch, wenn nicht alle Mitglieder der Relation im Teil enthalten sind, Multipolygone prüfen, ob sie gültig sind. Vorausgesetzt, die Rollen sind vergeben für die Mitglieder, das heißt ob es Auto oder Intervay sind.
16:47
Man kann bei Grenzrelationen prüfen, ob die Polygone gültig sind. Und man kann Lücken in ÖPNV-Relationen finden, die dem neueren Schema folgen. Nur mit vollständigen Relationen kann man die Hierarchie von Atemgrenzen prüfen, ob es Lücken in
17:05
Routenrelationen gibt, die dem alten Schema folgen und ob die Reihenfolge in ÖPNV-Routenrelationen korrekt ist. Wenn man hier zum Beispiel ein Multipolygon hat mit zwei Ringen und diese beiden Ringe überschneiden sich,
17:22
was kein gültiges Polygon ergibt und diese Überschneidung befindet sich im Teil, dann findet man diese auch. Weil beide Ways im Teil enthalten sind und somit man diese Überschneidung finden kann. Die gepunkteten Linien sind nicht im Teil enthalten und fehlen also auch im Vektorteil.
17:47
Man kann auch Fehler finden, wenn sich zwei Ringe überlappen, was auch kein gültiges Polygon ergibt. Denn wenn der Fehler im Teil liegt, dann sind auch die verursachenden Objekte im Vektorteil enthalten.
18:06
Man kann auch Lücken in Ringen finden, dadurch dass man einfach von einem unvollständigen Multipolygon, einem solchen Vektorteil versucht Ringe zusammenzusetzen. Und wenn ein Ringende sich im Gebiet des Teils befindet, dann ist dort eine Lücke.
18:33
Wie ich schon vorher sagte, die Hierarchie von Grenzrelationen kann man nicht prüfen. In diesem Fall, den ich hier zeige, könnte man sie prüfen, weil hier die Grenzrelation B die Grenzrelation A kreuzt.
18:49
Das eine mal zweigt sie zur rechten Seite ab, das andere mal zur linken. Aber wenn das gemeinsame Stück aus dem Teil heraus ragt, ist das nicht offensichtlich.
19:04
Es fehlt der Kontext, denn im Vektorteil ist der V3,5 und V3,6 nicht enthalten. Sodass ich nur sagen kann, ja das sieht ja gültig aus. Und wenn ich hier das nächste Teil betrachte, dann sieht das auch gültig aus. Was soll da kaputt sein?
19:27
Zur Validierung von Ruten. Klassische Ruten in OSM müssen nicht geordnet sein und müssen keine lückenlosen Linien ergeben. Und da sie keine lückenlosen Linien ergeben müssen, kann ich auch keine Lücken suchen.
19:43
Abzweige sind auch erlaubt. Bei ÖPNV-Ruten, die dem neueren Schema folgen, muss die Mitgliedegeliste geordnet sein und Haltestellen müssen sich am Anfang befinden. Und die Linie muss eine lückenlose Linie ergeben.
20:03
Deshalb kann ich bei unvollständigen Relationen Lücken suchen mit dem gleichen Verfahren, das man auch für Multipolygone verwendet. Die Reihenfolge kann man da aber nicht überprüfen, weil man nicht weiß, was die Anfangs- und Endhaltestelle ist.
20:25
Wir haben nochmal grafisch gezeigt. Das Grau ist jetzt das Teil, das ich habe. Ich weiß also die Geometrie von 10 und 21. Ich weiß aber nicht die Geometrie von 20, 13 und 14.
20:48
Und damit möchte ich für eure Aufmerksamkeit danken. Vielen Dank für den spannenden Vortrag. Gibt es Fragen?
21:05
Ist das denn jetzt implementiert oder ist das jetzt nur eine Idee oder was ist der Startstatus? Es ist in Teilen implementiert und in Teilen eine Idee. Also implementiert ist der Datenbank-Importer und ist die Erzeugung der Vektor teils.
21:27
Kurze Bemerkung zu den Polarregionen. Das Problem ist nicht in erster Linie der Bereich, der außerhalb der Merkatorkarte ist, sondern dass in den polnahen Gebieten relativ weit nach Süden und Norden reichen, hat zum Merkatorchen reichend,
21:40
die Anzeige in den Qualitätssicherungstools viel zu spät beim reinen Zoom erfolgt. Und man deshalb den... Also bei uns ist der Vektor ganz deutlich sichtbar, zum Beispiel im Area View. Das ist praktisch nicht nutzbar, weil man viel zu weit reinzoomen muss, bis überhaupt was auftaucht. Weil die niedrigste Zoomstufe, auf der die Sachen gerendert werden, zu hoch ist.
22:01
Okay. Danke. Ist vielleicht eher eine Verständnisfrage. Also der Vortrag hat sich nochmal im Verständnis in zwei Teile gegliedert.
22:22
Das eine ist, der Vorschlag in teils quasi eine Aktualisierung durchzuführen, weil das effizienter ist, wie wenn man jedes Mal die ganze Welt durchprozessiert. Das ist ja, sag ich mal, eine Anwendung, die sich an die Leute richtet, die quasi intensiv oder halt viel Open-Street-Map-Daten nutzen.
22:44
Oder, sag ich mal, für diejenigen, die diese Open-Street-Map-Datenbank aufbauen. Das war mir nicht so ganz klar. Und der zweite Teil, hab ich so verstanden, ist eigentlich, dass man das auch nutzen will, also jetzt quasi diese Partitionierung, um nachher eine topologische Prüfung zu machen von diesen Geometrien.
23:04
Und was mir da irgendwie gefehlt hat, ist, also dieses Tool würde, so wie du das vorgestellt hast, im Prinzip fehlende oder, sag ich mal, Fehler finden. Aber die Korrektur würde ja dann hinterher immer noch von jemandem gemacht werden müssen. Ja, die Korrektur wird weiterhin manuell gemacht.
23:21
Weil wir bei Open-Street-Map dem automatischen Editieren eher kritisch gegenüberstehen.
23:42
Also, wie du beschrieben hast, das Aufteilen macht natürlich Sinn, wenn danach man weniger Arbeit machen muss. Aber das Aufteilen selber kostet ja auch Arbeit. Das heißt, wenn ich jetzt direkt auf dem Planeten arbeite und jeden Tag diesen Update mache, wie die Tools, die du vorgestellt hast, das machen,
24:01
die haben natürlich den Vorteil, dass sie diese Aufteilung nicht machen müssen, dass sie sich nicht merken müssen, was ist in welchem Teil, welches Teil muss geupdatet werden, keine Datenbank führen müssen, die das alles hat. Und das macht diese Tools natürlich einfacher und schneller. Jetzt ist die Frage, mit deiner Erfahrung, mit der Implementierung, gewinnen wir so viel dadurch, nachher, dass wir diesen extra Aufwand mit dieser Aufteilung machen?
24:26
Also, durch die Aufteilung gewinnen wir dazu am Ende so viel, dass es sich lohnt, diese Aufteilung zu machen. Also, dass es sich lohnt, diese Datenbank zu führen und den Teil expired durchzuführen und all diese Sachen. Also, die Frage wäre letztlich, wie schnell kriegen wir denn die Updates dahin?
24:43
Und was ist der Aufwand, den man jetzt rechentechnisch machen muss? Was für einen Rechner braucht man dafür, für diese Datenbank oder sowas? Also, für die Datenbank braucht man einen Rechner, der mit einem OSMTPQ SQL importierten Planet umgehen kann.
25:00
Was ja schon ein bisschen was ist. Ja, das darf keine schwache Maschine sein. Ob dieser Teil mit einer Datenbank gemacht wird oder ob man die Vector-Teils direkt aus dem Planet erzeugt, darüber kann man noch diskutieren. Das muss nicht der Weisheit letzter Schluss sein, was ich da gemacht habe.