Wo liegt der Way?
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 | 107 | |
| Author | ||
| License | CC Attribution 4.0 International: 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/61118 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
| |
| Keywords |
7
12
19
20
24
30
33
34
44
65
72
74
76
79
80
84
87
91
00:00
GeometryData modelVersion <Informatik>Coordinate systemData typeMultiplicationHTMLEditorVersion <Informatik>DatabaseGeometryData modelPhysical quantityGeometryLevel (video gaming)EnergieReading (process)Link (knot theory)PositionSet (mathematics)Gebiet <Mathematik>MathematicsLength of staySun <Marke>Beobachter <Kybernetik>WEBLösung <Mathematik>MittelungsverfahrenInferenceSpur <Datentechnik>Noten <Programm>Mobile appRaw image formatDataflowTor <Netzwerk>Pattern languageData typeComputer animation
06:59
Version <Informatik>Data modelCoordinate systemData typeEditorGeometryMoving averageAPIKommunikationLanglebigkeitMetreVersion <Informatik>WebsiteGeometryDatabaseSoftwarePoint (geometry)LebensdauerNumberGeometryTimestampStrich <Typographie>StatistikerGebiet <Mathematik>Noten <Programm>BuildingTor <Netzwerk>DatabaseLöschen <Datenverarbeitung>Ad-hoc-NetzTriade
13:52
Data modelWebsiteLink (knot theory)GeometryData modelError messageEditorMathematicsWind wavePositionSoftware developerObject (grammar)Military operationWebsiteBlock (periodic table)Noten <Programm>Version <Informatik>MAPPERDatabaseSoftwareInformationLebensdauerGeometryQuantum stateTransmitterPhysical quantityFLOPSTOUR <Programm>Web pageAnbindung <Informatik>NintendoLecture/Conference
Transcript: German(auto-generated)
00:07
Herzlich willkommen zu unserem zweiten Vortrag in unserer Demo-Session. Ich möchte Sie erst einmal darauf hinweisen, wenn Sie Fragen haben,
00:22
dann können Sie die stellen in dieser Venueless-App. Dazu haben Sie einen Link bekommen. Vorgestern müsste eine Mail gekommen sein. Da finden Sie einen Link. Dann können Sie Ihre Fragen reinschreiben. Das können genauso die machen, die jetzt bloß über Video und zusehen. Die sammeln wir am Ende, um sie dann stellen zu können. Sie können auch dann voten, welche Frage Ihnen am wichtigsten ist.
00:43
Wir hören jetzt einen 15-Minuten-Vortrag von Dr. Roland Ulbricht. Wo liegt der Way? Bitte schön. Danke für die Gelegenheit, hier zu sprechen. Es geht jetzt um Fragen vom OSM-Datenmodell. Es wird relativ technisch, aber das stand ja in der Vortragsbeschreibung. Erstmal fangen wir noch mal sehr einfach an mit dem OSM-Datenmodell.
01:03
Es gibt die Nodes, es gibt die Ways und es gibt die Relationen. So weit, so einfach. Die Ways dienen dazu, Wege zu modellieren, aber sie haben keine Geometrie.
01:20
Auf der anderen Seite das, was wichtig ist, um als Community zusammenarbeiten zu können. Man kann die Versionen jedes einzelnen Ways nachvollziehen. Ich habe jetzt mal hier den Fußweg zum Eingang vom Gebäude genommen. Da gab es eine Version, eine alte, von vor zwölf Jahren.
01:40
Es gab eine alte Version von vor zwölf Jahren und es gibt eine zweite Version von etwa vor drei Jahren. Es gibt aber ein paar Probleme damit. Es ist grundsätzlich, wenn man auf der Hauptseite schaut, nicht möglich, die Geometrie für alte Way-Versionen anzuzeigen. Und auch, wenn man versucht, sich die Changesets anzuzeigen,
02:03
das ist ein bisschen, was dieser Chronik-Button einem eigentlich suggeriert, was gehen sollte, die Changes, die Änderungen zu sehen, die sich kürzlich in dem Gebiet gemacht wurden, dann stellt man fest, geht gar nicht. Weil man wird erdrängt in Changesets, die irgendwie global eine globale Abdeckung haben und man sieht die danach immer noch keine Änderungen, die lokal passiert sind.
02:24
So, es gibt noch ein paar andere Probleme. Das ist die, dass es Geometrieänderungen ohne neue Way-Versionen gibt und die gleiche Version kann verschiedene Geometrien haben. Und das ist das Problem, den wir uns eigentlich annehmen wollen, um das mal zu illustrieren.
02:41
Wir sehen hier ein Gebäude, auch hier direkt in der Nachbarschaft vom Campus. So, da sagt uns hier das Bearbeitungsfeld da oben, mit, es sei für über zehn Jahren bearbeitet worden. Und also, grob gesagt, von 2012. Und okay, ist auch wunderschön eingezeichnet.
03:02
Nur ist leider die Geometrie, die tatsächlich 2012 eingezeichnet wurde, die Geometrie, die jetzt hier rechts zu sehen ist, die blaue. Die Geometrie, die wir links sehen, ist eine Geometrie, die 2018 entstanden ist, weil jemand die Nodes noch mal zurechtgezupft hat. Da wurde aber einfach keine neue Way-Version angelegt, weil der Way schaut nur drauf, also das Datenmodell schaut nur drauf,
03:25
ob sich die Reihenfolge der Nodes geändert hat, also die ID's der Nodes geändert haben und nicht ob sich deren Position geändert hat. Das heißt also, das was man an Geometrie angezeigt, kriegt oft überhaupt nicht mal das, was tatsächlich in Geometrie drin ist. So, bevor wir uns da zu viel Energie reinstecken,
03:42
wollen wir erst mal was anderes wissen. Erst mal was anderes, die Frage wäre, wäre das behebbar? Da gab es einen großen Ansatz zu, zu der Frage, wie könnte man das Datenmodell entwickeln? Und das ist Bestandteil eines größeren Problems, dass man eigentlich gerne die Node ID's loswerden wollte, weil die Node ID's tragen exakt nichts zum Inhalt der Datenbank bei.
04:05
Niemand behandelt ein Feature anders, weil es Node ID in 1234 ist, anstelle von 1432, wir könnten alle Nodes umnummerieren. Die Datenbank hätte den gleichen Inhalt, und die würden ungefähr die Hälfte der Daten loswerden.
04:20
Wir würden die Verarbeitung der Daten dramatisch vereinfachen. Also viele Leute machen in den ersten Prozessschritten nicht den Waze Geometrie zu machen, weil es sehr viele Tools gibt, die einen dabei unterstützen. Aber diejenigen, die es machen müssen, wissen, dass man da durchaus auch mal die Mehrheit der Zeit darauf verwendet, um aus den OSM-RO-Daten Geometrien auf Waze zu bekommen.
04:42
Und das war alles die Idee, die Jochen mit seiner Studie angeschaut hat, mit man könnte das lösen. Es würde sich auch lohnen, einen echten ARIA-Datentyp einzuführen, weil das ebenfalls eine große Menge Zeit ist, die Leute, die mit den OSM-Daten arbeiten wollen, erst mal lösen müssen oder eben ein geeignisches Tool finden müssen,
05:02
womit sie dann nicht mehr mit den RO-Daten arbeiten. Was eigentlich auch dämlich ist, weil wir wollen die Daten selbst ja so zugänglich machen wie möglich. Und alle anderen Ideen, das Datenmodell zu entwickeln, sind eigentlich eher noch nicht so ausgereift, dass man sagen würde, man müsste mit diesem ARIA und den MWA-Problemen darauf warten, das alles andere sich anzuschauen. Beim anderen ist eher nicht so klar, ob man das überhaupt will oder nicht.
05:23
So, der wichtige Punkt ist aber, nach Jochens Einschätzung bzw. nach einem ordentlichen Lesen, sorgfältigem Lesen der Studie, hört es sich an nach einem Multimillionenprojekt, was über viele Jahre dauert, um es umzusetzen. Was sich so ein bisschen, wenn man da überlegt, dass die OSMF, die Organisation, der die Datenbank gehört,
05:42
mit der wir versuchen, das Ganze hier zu betreiben, irgendwie mit 700.000 Euro im Jahr auskommen muss, wenn es gut läuft, kann man sich vorstellen, dass es einfach etwas wäre, was nicht zu stemmen wäre. Deswegen, die Idee hinter diesem Vortrag ist es, sich anzuschauen, das ist eine Beobachtung, die zwei clevere Entwickler auf der State,
06:01
nicht mich, nicht ich, sondern zwei Entwickler, von der OSM main.com hauptsächlich gemacht haben, war die Influenz auf der State of the Map. Eigentlich brauchen wir erst mal den großen Schritt nicht zwingend, sondern wenn wir zwingen, dass ein Editor, also eine Editing-Software, beim Entverschieben eines Notes
06:20
automatisch auch eine neue Version von dem Way mitliefern muss, zwingend. Also im Prinzip heißt das, man ändert auf der API-Seite, ändert man, dass man ein Change in Up weist, wenn eine oder mehrere von den erforderlichen Ways fehlen. Und vorher natürlich, sagen wir den Leuten mit der Editor-Software Bescheid mit, sie sollen bitte die Editor-Software so anpassen,
06:40
dass es immer geht. Daten wir ebenfalls, in dieser Session war zum Beispiel auch der Simon Puhl dabei und auch ein paar Jawsome Leute und ich glaube Martin Reifer war glaube ich auch dabei, womit wir glaube ich das ganze Team komplett hatten von ihm. Und wir sagten mit, es wäre auf jeden Fall machbar, diese Daten mit zu liefern. Das ist ein absolut lösbares Problem auf der Editor-Seite. Das heißt, man kann es danach auf der API erzwingen.
07:01
Und das Coole wäre, danach wäre dieses Problem, was wir gerade gesehen haben, dass hier zwei komplett verschiedene Geometrien, bei der Version 4 heißen, das Problem ist danach weg. Danach ist das, was eine Version ist, ist auch tatsächlich eine, das was eine Geometrie ist, ist tatsächlich danach auch eine echte Version, eine nummerierte Version.
07:22
So, zusätzlich, weil es historisch das gegeben hat, müsste man einmal durch die Datenbank gehen und die Versionen neu zuzuteilen, neu zuteilen. An der Stelle fängt jetzt ein bisschen die Politik an, ob man das jetzt wirklich macht oder ob man sagt, man macht einen Cut-Off-Date, wo man sagt, vorher muss der Nutzer der Daten aufpassen, dass er seine Daten selbst ignoriert.
07:41
Das ist eine andere Frage. Das sind alles politische Prozesse, auch ob man das überhaupt macht, weil man muss ehrlicherweise sagen, es ist ein Problem, was so ein bisschen eine Verknöcherung, eine Stagnation von OSM zeigt. Aber es ist kein Problem, was jetzt unmittelbar nächstes Jahr die Datenbank explodiert. Ich hätte mal eher über den Daumen geschätzt.
08:01
In fünf bis zehn Jahren wird es, je nachdem, wie sich die Rechnertechnik entwickelt, richtig ungemütlich und natürlich wie schnell die OSM-Daten wachsen. Aber aktuell ist es noch nicht so, dass es drängt. Deswegen wäre es denkbar, dass man sagt, man wartet damit eher noch einige Zeit, bis man zum Beispiel die API-Seitig, die Software soweit hat, dass man dort auch gut Dinge,
08:22
dort gut Commits machen kann und dort gut entwickeln kann. Momentan ist auch die Entwicklung der Website ist auch ein bisschen zögerlich. Das ist jetzt nicht die konkrete Einleitung, um es dazu einzuführen, sondern das ist ein Gedanke, worauf ich hinarbeiten würde, dass es stattfindet. Wie würde das konkret aussehen?
08:41
Bei dem Way, den wir uns vorhin angeschaut haben, da gab es noch mehr Änderungen. Da ist es so, dass es im Grunde genommen 2012 relativ schnell eine Version 4 gab. Danach gab es ganz viele Leute, die Nodes immer mal wieder zurechtgezupft haben. Da würden also die Versionsnummern jetzt relativ flott hochzählen. Jetzt wäre die erste berechtigte Frage, wie viele Ways betrifft es eigentlich?
09:02
Haben wir danach eine komplett neue Datenbank? Oder sind dazu drei Randfälle? Und die andere Frage ist, haben wir danach übersinnlich hohe Versionsnummern? Weil wir auf einmal vielleicht tausende von solchen impliziten Verschiebungen haben. Und dazu will ich jetzt ein paar Zahlen zeigen. Also erst mal von gut 900 Millionen aktuellen Ways,
09:21
die wir ja da haben, ist bei immerhin sportlichen, knapp 150 Millionen Ways, die die Geometrie, die angezeigt wird, falsch. Oft ist es nicht so schlimm. Oft ist es so ein, zwei Meter. Das sieht man nicht. Das sieht man nur, wenn man ranzoomt. Aber trotzdem, prinzipbedingt, es ist schon eine ganz stattliche Anzahl von Ways. Das war dementsprechend auch nicht schwierig,
09:41
das Gebäude zu finden. Das Gebäude ist um hier zwei Gebäude weiter. Es ist also nicht schwierig, solche Fälle zu finden, wo das tatsächlich der Fall ist. Und von den insgesamt 1,1 Milliarden Ways, die es historisch gegeben hat, ich habe mir das jetzt relativ einfach gemacht. Ich habe mir einen festen Datenstand genommen vom 26.01.2023
10:01
und habe dann da einfach gezählt, was die höchste bis dahin vergebende ID ist, davon auszugehen, dass die IDs alle mal vergeben waren und ein bisschen kleingedrucktes außen vorlassen. Und davon immerhin haben 191 Millionen mindestens eine Version mit Mehrfachgeometrien, also Problem, wo man sozusagen eine Zusatzversion einschieben müsste, um die angezeigten Geometrien sauber zu kriegen.
10:21
Und insgesamt gibt es knapp 380 Millionen davon. Wie schon gesagt, etwa 15 Prozent der Ways haben irreführende Versionsdaten. Also es ist schon etwas, was Leuten, die versuchen, Daten zu verstehen, begegnet. Etwas, wo wir den Leuten das Leben leichter machen,
10:41
wenn Waveversions-Ageometrieänderungen tatsächlich auch Waveversionswechsel bedeuten. So, dann schauen wir uns erst mal an, ob die Versionsnummern durch die Decke gehen. Es gibt solche Fälle, die man finden kann. Es gibt hier diesen einen Wave, den ich mal rausgesucht habe, der immerhin 200 Geometrien ohne Versionsnummer hat, hat aber auch schon sportliche 616 Versionen.
11:03
Und es ist tatsächlich einfach ein Ausnahmefall. Also es gibt nur rund 30 Ways mit über 200 Versionen. Und das heißt, also wir haben nicht das Problem, wenn wir das durchführen würden, dass wir auf einmal große Mengen mit großen Versionsnummern kriegen. Und ich glaube, auch die absolut größte Versionsnummer,
11:21
die vorkommt, ist nur vierstellig. Aber das ist ein Objekt, wo man sich fragen muss, was man überhaupt haben will. Ja, es gibt einen Mapper, der irgendwie eingezeichnet hat, bis hierhin bin ich gekommen. Und der hat irgendwie so einen senkrechten Strich, den er also irgendwo hin geschoben hat und den er dann irgendwie über Tausende von Mapping-Schritten
11:41
immer ein bisschen nach Osten geschoben hat. Und dieser Strich hat eine irrsinnig hohe Versionsnummer. Und das ist das Objekt mit der höchsten Versionsnummer. Ja. Also es gibt immer sehr seltsame Dinge, wenn man es sucht. Es gibt aber sehr wenige davon. Es ist auch nicht so, dass die 200 jetzt ein bisschen in die Trickkiste gegriffen sind,
12:02
sondern es wäre da ein bisschen mehr, aber es wäre nicht dramatisch mehr, wenn man die Versionsnummer tiefer nimmt. So, bevor wir jetzt sagen, wir brauchen diese hohen Versionsnummer überhaupt, möchte ich noch ein anderes Phänomen ansprechen, auf das mich MMD freundlicherweise aufmerksam gemacht hat. Nämlich, es gibt Ways, bei denen sich jede Sekunde
12:21
so eine implizite Version ergibt. Und das liegt daran, dass wir früher eine API hatten, die jedes Objekt zum Editieren einzeln entgegen genommen hat. Und wenn man jetzt so einen Way mit so ein paar Tausend Punkten hochgeladen hat, das ist länger als eine Sekunde gedauert. Und dann hat das Ding also Zeitstempel, wenn das Ding jetzt das Hochladen jetzt eine Minute gedauert, eineinhalb,
12:40
dann hat das Ding halt ein Zeitstempel, die Zeitstempel über die Notes munter verteilt und am Ende erst den Way geändert. Also, man muss dann extra in damals zu den Zeiten extra in der Software implementieren, die Logik, dass alle Ways erst mal, also eigentlich erst mal alle Relationen, die bezogen hätte, gelöscht werden, alle Ways gelöscht werden, die gelöscht werden sollen. Danach konnte man auch Notes löschen,
13:00
weil dann sichergestellt war, dass die Bezüge auch weg waren. Dann erst Notes neu anlegen, dann erst Ways anlegen, dann erst Relationen anlegen. Der ganze Zirkus hat halt gedauert. Das ist aber eigentlich ein reines Artefakt. Derjenige hat hier eine Änderung machen wollen und derjenige hat nicht irgendwie hier ein Kunstprojekt gemacht, über mehrere Minuten weg jede Sekunde oder fast jede Sekunde den Way geändert zu wollen.
13:22
Deswegen hatte ich mal geplottet, was eigentlich so die Lebensdauer ist dieser impliziten Version. Und dann stellt man fest, also die Mehrheit der Versionen hat eine lange Lebensdauer. Das ist aber, es gibt eben schon eine beträchtliche Anzahl, die eine relativ kurze haben, was man aber auch sieht. Ich habe da jetzt keinen
13:41
hochwertigen Statistik-Indikator draufgeschmissen. Aber die grobe Daumenregel sagt, bis zu einer Minute hat man relativ schnell eine große Anzahl, die zusammenkommt. Danach tut sich nicht mehr so viel. Das heißt also, man könnte sich durchaus vorstellen, wenn man jetzt tatsächlich diesen Schritt macht, dass man sagt, jede implizite Version,
14:00
die unter einer Minute Lebensdauer hat, vergesse ich einfach dabei, damit man nicht so eine ganze verrauschte Datenbank hat. Deswegen ist es kein trivialer Schritt, wo man einfach rein maschinell konvertieren will. Es ist ein Prozess, wo die Community bzw. die Entwickler, die sich dann dafür interessieren. Auf Jochen's Studio gibt es auch
14:20
ein GitLab-Repo, wo man diskutieren kann. Im Prinzip, sich einig werden sollten, wie weit man diese Vereinfachung treibt. Aber ich vermute von den Daten her, dass man in der Nähe von einer Minute landet. Und dann kann ich nämlich eigentlich auch schon zum Fazit kommen.
14:41
Wave-Geometrien ohne Versionszimmer sind häufig. Das ist ein Problem, bei dem es sich tatsächlich lohnt, es zu lösen. Es ist nicht nur, dass es drei Dinge gibt, mit denen man irgendwie die Software abschießt als Eckfälle, sondern man lässt ernsthaft Daten liegen, wenn man versucht, das Problem zu ignorieren. Schon die OSM-Org-Seite, Webseite, funktioniert fehlerhaft damit. Also es ist ein Problem, was eigentlich alle betrifft,
15:02
die mit die OSM-Daten eben selbst direkt verstehen wollen. Die Mehrheit dieser Geometrien sind explizit von Mappern erstellt. Es ist auch nicht nur so, dass wir diese IPI-Artifakte hatten, die wir stillschweigend entsorgen können. Und es ist insgesamt so, es ist möglich, dass über eine Änderung des unterliegenden Datenbankschemas zu machen.
15:22
Es wird ein bisschen geschickt unter den Entwicklern brauchen, dass man auch die Artifakte schön hinkriegt dabei. Aber es wäre also möglich, diesen Schritt der Verbesserung des Datenmodells vorab durchzuführen, damit man nicht wie das Kaninchen vor der Schlange Angst davor hat,
15:40
dass man die paar Millionen das Datenmodell in einem Big Bang umzustellen, einfach realistischerweise in den nächsten zehn Jahren nicht auf den Tisch legen kann. So, dann bedanke ich mich jetzt für die Aufmerksamkeit. Vielen Dank. Und sehr gespannt eventuellen Fragen entgegen. Vielen Dank für den Vortrag. Das Gebäude hier nebenan,
16:01
das ist das Psychologische Institut. Ich weiß nicht, was Sie mit dem Haus machen. Wir haben einen Hinweis über das Venue, und zwar die Änderung eines Nodes muss nicht zwangsläufig auch die Geometrie ändern. Zum Beispiel Benennung des Hauseingangs. Soll das dann auch eine neue Version werden? Das ist korrekt.
16:21
Über dieses Detail habe ich nicht nachgedacht, aber es ist wahrscheinlich, also es kommt selten genug vor. Es ist inhaltlich im Datenmodell nicht so häufig sinnvoll, dass eine Note, die auf eine Welle geteckt ist, es kommt vor, aber es ist nicht so häufig sinnvoll, dass die auch Informationen trägt. Dann müsste sich on top noch ändern und dabei aber nicht die Geometrie.
16:41
Also wird ein Randfall sein, wo man sagt, ein paar Versionen mehr ist wahrscheinlich sinnvoll. Müsste man aber separat untersuchen, wie viele Objekte das betrifft, habe ich jetzt nicht gemacht. Ich hatte jetzt nur auf Änderungen an den Nodes selbst geschaut. Also die hätte ich jetzt mitgezählt. Okay, gibt es hier? Ja, hier gibt es noch Fragen.
17:03
Wäre es nicht grundsätzlich möglich, dass mit der AP ein Note seine Position ändert und Bestandteil eines Ways, dass die API eine neue Version des Ways erstellt? Eigentlich möchte man das Problem der kleinsten, oder eigentlich möchte man ein Prinzip
17:20
der kleinsten Überraschungen haben, dass die API so wenig wie möglich implizit macht, weil all diese Implicitemperationen ziehen einen ganzen Stapel an möglichen Fehlerzuständen nach sich. Und man endet dann in einer Situation, wo ich eine Fehlermeldung der Art zurückgeben muss mit, ich kann dieses Change Check nicht annehmen, weil die daraus impliziert
17:41
sich ergebenden Operationen in Konflikt zu folgendem dritten überhaupt nicht berührten Objekt stehen. Das versteht keiner mehr. Deswegen, da jetzt gerade auch von den Editoren, also von Editorentwicklern, die das Signal haben, das ist eine lösbare Anforderung. Deswegen lieber das an die Editoren übertragen, die einfach näher dran sind dabei,
18:00
sinnvolle Fehlermeldungen, Interaktionen mit dem Benutzer zu haben. Die API soll ja eigentlich mit Editoren und Editoren interagieren, mit den Endusern. Und da ist es dann einfacher, sinnvoller Fehlermeldungen zu übermitteln. Jetzt gibt es hier eine Frage im Venioles. Erst einmal Glückwunsch an Roland, dass er wie so oft Lösungswege
18:21
für kommende Probleme aufzeigt, die die Mehrzahl der OSMler noch nicht einmal wahrgenommen haben. Ich kann das nicht beurteilen, aber sehe ich es richtig, dass dies für die editierenden User keine Auswirkungen hat? Ja und nein. Also für das Benutzen eines Editors
18:40
hat es keine Auswirkungen. Ich hoffe, dass es eine positive Auswirkung ist für die Benutzer, wenn sowas wie die OSM History Tab auf einmal auch funktioniert. Okay, danke. Gibt es hier im Raum noch eine Frage? Eine letzte Frage. Letzter Aufruf, eine letzte Frage.
19:00
Da haben wir... Also wenn dein Hauptproblem ist, dass die letzte Änderung auf der OSM Website nicht angezeigt wird, dann kann man das aber auch auf der Website selber lösen, weil die lädt ja die Notes mit runter und die kann einfach anzeigen,
19:22
dass die letzte Änderung an den Notes vom Way ein bisschen zeitlicher ist. Das wäre also eine einfachere Lösung für genau das Problem. Ich möchte mal versuchen, so zu erwidern. Wir haben ein Problem, dass wir sinnvolle Änderungen am Datenmodell identifiziert haben, dass wir festgestellt haben, es ist ein Big Bang, der einen Haufen Geld kostet
19:41
und 10 Jahre dauert. Das würde einfach nicht passieren. Wir können den Leuten jetzt verkaufen, dass wir Baustellenzustand 1 bis 800 haben und dass man die in jedem Schritt ohne große Schmerzen durchkommt. Aber es wird sich genauso anfühlen wie Baustelle 1 bis 800. Wir können auch versuchen, sinnvolle Blöcke rauszulösen, wo man nach Anwendung des Blocks
20:05
das Gesamtziel, die Note IDs loszuwerden, ist es eine notwendige Voraussetzung, weil man diesen Aufräumschritt machen muss. Umgekehrt ist es etwas, was aber für den Normal-User einen messbaren Fortschritt hat, nämlich, dass diese Way-Historie
20:22
sauber wird. Deswegen ist dieser Schritt so rausgelöst. Es ist schon von oben große Datenmodelländerung nach unten passiert. Nicht so, dass das jetzt das drängendste Anliegen wäre, sondern um eben diesen Datenmodelländerung schrittweise durchzuführen und tatsächlich durchzuführen.
20:44
Vielen Dank.