23. Aug. 2025·8 Min
Mike Bostock und D3.js: Wie das Web lernte, Daten zu sehen
Ein praxisorientierter Blick auf Mike Bostocks D3.js: was es ist, warum es wichtig war, Kernkonzepte und wie Teams es nutzen, um klare Web-Visuals zu bauen.
Ein praxisorientierter Blick auf Mike Bostocks D3.js: was es ist, warum es wichtig war, Kernkonzepte und wie Teams es nutzen, um klare Web-Visuals zu bauen.
Mike Bostock hat nicht nur eine beliebte JavaScript-Bibliothek geschrieben — er hat neu gedacht, was Web-Visualisierung sein kann. Seine Kernidee, zusammengefasst im Begriff „data-driven documents“, ist einfach, aber mächtig: Betrachte Daten als etwas, das die Seite direkt formen kann. Statt ein Diagramm in einer Blackbox zu zeichnen, bindest du Daten an Elemente im DOM (wie SVG-Formen, HTML-Knoten oder Canvas-Pixel) und lässt den Browser das Ergebnis rendern.
Vor D3.js konzentrierten sich viele Chart-Tools auf fertige Outputs: Charttyp wählen, Daten rein, Optionen anpassen und hoffen, dass das Design zur Geschichte passt. D3.js ging anders vor. Es ist nicht in erster Linie „eine Chart-Bibliothek“ — es ist ein Toolkit zum Bauen von Visualisierungen.
Dieser Unterschied ist wichtig, weil reale Daten und Produktanforderungen selten perfekt in eine einzelne Vorlage passen. Mit D3 kannst du:
Dieser Artikel ist ein konzeptioneller Leitfaden, kein Schritt-für-Schritt-Tutorial. Du wirst kein einsetzbares Chart als Kopiervorlage erhalten; du wirst ein klares mentales Modell davon bekommen, wie D3 über Daten, Visuals und Interaktion denkt — damit du es gezielt auswählen und schneller lernen kannst.
Wenn du in einem Produktteam arbeitest, ein Analyst bist, der Erkenntnisse vermitteln will, eine Designerin, die bestimmt, wie Daten sich anfühlen sollen, oder eine Entwicklerin, die interaktive UI baut — D3s Einfluss lohnt sich, selbst wenn du nie eine Zeile D3-Code schreibst.
Vor D3.js waren viele „Web-Charts“ eher Bilder als Interfaces. Teams exportierten Grafiken aus Excel oder R als PNG, betteten sie ein und erledigt. Selbst wenn Grafiken serverseitig generiert wurden, war das Ergebnis oft ein statisches Bild — einfach zu publizieren, schwer zu erkunden.
Menschen wollten Charts, die sich wie das Web verhalten: klickbar, responsiv und aktualisierbar. Häufige Optionen fielen in ein paar vorhersehbare Kategorien zurück:
Die fehlende Zutat war nicht nur eine Bibliothek — die Plattform holte auf. Browser-Standards reiften:
Diese Technologien machten es möglich, Grafiken wie echte UI-Komponenten zu behandeln, nicht als exportierte Artefakte.
D3 kam nicht als „Chart-Builder“. Es kam als Weg, Daten mit nativen Web-Primitiven (DOM, SVG, Canvas) zu verbinden, sodass du genau das Graphic entwerfen konntest, das du brauchst — und es interaktiv sowie anpassungsfähig machst. Die Lücke zwischen „Chart-Bildern“ und „datengetriebenen Interfaces“ hat D3 geschlossen.
D3s Kernannahme ist simpel: Statt ein Chart irgendwo zu zeichnen, bindest du deine Daten an die tatsächlichen Elemente auf der Seite. Das bedeutet, jede Datenzeile wird einem sichtbaren Element (ein Balken, ein Punkt, ein Label) zugeordnet, und Änderungen in den Daten können direkt die Darstellung steuern.
Ein nützliches mentales Modell lautet: Datenzeilen werden Marks auf dem Bildschirm. Hat dein Datensatz 50 Reihen, kannst du 50 Kreise in einem SVG haben. Wächst er auf 60, solltest du 60 Kreise sehen. Schrumpft er auf 40, verschwinden 10 Kreise. D3 ist so gestaltet, dass diese Beziehung explizit wird.
„Selections“ sind D3s Methode, Elemente zu finden und dann etwas mit ihnen zu machen.
circle).Eine Selection ist im Grunde: „Finde alle Punkte in diesem Chart und lass jeden Punkt zu seinem Datum passen."
Das bekannte D3-„Update-Muster“ ist der Workflow, um DOM-Elemente mit Daten in Einklang zu halten:
Deshalb fühlt sich D3 weniger wie ein Chart-Generator an und mehr wie eine Methode, eine lebende Visualisierung zu pflegen — eine, die korrekt bleibt, während sich die zugrunde liegenden Daten ändern.
Ein D3-Chart ist im Grunde eine Übersetzungsmaschine. Deine Daten beginnen als Werte (Umsatz, Temperatur, Stimmen), aber der Bildschirm versteht nur Pixel. D3s „Daten → Skala → Pixel“-Pipeline ist die saubere Brücke zwischen diesen beiden Welten.
Eine Skala ist eine Funktion, die einen Datenwert in einen visuellen Wert übersetzt.
Wenn dein Monatsumsatz von 0 bis 50.000 reicht, kannst du ihn auf eine Balkenhöhe von 0 bis 300 Pixel abbilden. Die Skala übernimmt die Rechnung, sodass du nicht überall / 50000 * 300 verteilen musst.
Ebenso wichtig: Skalen unterstützen Invertierung (Pixel → Daten). Das macht präzise Interaktionen möglich — etwa den genauen Wert unter dem Cursor anzuzeigen.
Achsen sind mehr als Dekoration: sie sind der Vertrag des Betrachters mit dem Chart. Gute Ticks verhindern Fehlinterpretationen. Zu wenige Ticks können Unterschiede verbergen; zu viele erzeugen visuelles Rauschen. Konsistente Tick-Abstände und sinnvolle Endpunkte (insbesondere Null bei Balkendiagrammen) helfen Menschen, dem Gezeigten zu vertrauen.
Formatierung entscheidet über Klarheit. Daten sollten zum Kontext passen (z. B. „Jan 2025“ vs „2025-01-15“). Zahlen brauchen oft Rundung, Tausendertrennzeichen und Einheiten („12.400“ vs „€12,4k“ kommunizieren unterschiedlich). D3s Formatierungstools sorgen für Konsistenz, damit das Diagramm nicht ungenau oder schlampig wirkt.
D3 sperrt dich nicht auf eine Rendering-Technologie. Es konzentriert sich auf die Daten-zu-Elemente-Logik (Joins, Skalen, Interaktion) — und du entscheidest, wo diese Marks liegen: SVG, Canvas oder normales HTML. Die richtige Wahl hängt meist davon ab, wie viele Dinge du zeichnen musst und wie wichtig Styling und Zugänglichkeit sind.
SVG ist eine DOM-basierte Zeichenoberfläche: Jede Form, jeder Pfad und jedes Label ist ein Element, das du mit CSS stylen und in DevTools inspizieren kannst.
SVG eignet sich, wenn du brauchst:
Der Nachteil: Tausende von SVG-Elementen können schwer werden, weil der Browser jedes einzelne im DOM verwalten muss.
Canvas ist pixelbasiert: du „malst“ und der Browser behält nicht für jeden Punkt einen DOM-Knoten. Das macht Canvas geeignet für Scatterplots mit Zehntausenden Punkten, dichte Heatmaps oder Echtzeit-Rendering.
Die praktischen Kompromisse: Styling ist manuell, scharfer Text erfordert oft mehr Arbeit, und Interaktionen brauchen meist Hit-Testing-Logik (um zu bestimmen, über welchem Element die Maus ist).
HTML ist optimal, wenn die Visualisierung eher ein UI-Baustein ist — denk an sortierbare Tabellen, Tooltips, Filter oder Karten-basierte Zusammenfassungen. Es ist auch üblich, HTML-Kontrollen mit einem SVG- oder Canvas-Chart zu mischen.
D3 kann Daten an SVG/HTML-Elemente binden oder Skalen, Layouts und Interaktionen berechnen, die du dann auf Canvas renderst. Diese Flexibilität macht D3 zu einem echten Toolkit: die Zeichenfläche ist eine Entscheidung, kein Zwang.
In D3 ist ein „Layout“ eine Funktion (oder ein kleines System von Funktionen), das deine Daten nimmt und Geometrie berechnet: x/y-Positionen, Winkel, Radien, Pfade oder Eltern/Kind-Beziehungen, die du zeichnen kannst. Es rendert keine Pixel für dich — es liefert die Zahlen, die Formen möglich machen.
Früher lieferte D3 benannte Layouts (force, pack, tree, cluster, chord). Neuere Versionen gliedern viele dieser Ideen in fokussierte Module — daher siehst du oft Beispiele mit d3-force für Netzwerke oder d3-geo für Karten direkt, statt einer einzigen „Layout“-API.
Die meisten interessanten Charts sind „versteckte Matheprobleme“. Ohne Layouts würdest du Kollisionsvermeidung, Knotenplatzierung, Rechteck-Tiling oder Projektionen von Längen-/Breitengraden selbst schreiben müssen. Layouts reduzieren diese Arbeit auf Konfiguration:
Das bedeutet schnellere Iteration bei Designentscheidungen — Farbe, Beschriftung, Interaktion — weil die Geometrie konsistent gehandhabt wird.
Netzwerkgraphen: d3.forceSimulation() positioniert iterativ Knoten und Links und gibt jedem Knoten x/y, die du als Kreise und Linien zeichnest.
Treemaps: Hierarchische Layouts berechnen verschachtelte Rechtecke, die nach Wert skaliert sind — ideal für Part-to-Whole-Ansichten mit vielen Kategorien.
Karten: d3.geoPath() wandelt GeoJSON mit einer Projektion (Mercator, Albers usw.) in SVG-Pfade um und verwandelt reale Koordinaten in Bildschirmkoordinaten.
Der Kern: Layouts transformieren rohe Zahlen in zeichnungsfähige Geometrie, und D3s Datenbindung macht diese Geometrie zu Marks auf der Seite.
Interaktivität ist nicht nur ein „nettes Extra“ — oft bestätigt sie, was Menschen sehen. Ein dichtes Chart kann überzeugend aussehen und trotzdem missverstanden werden. Wenn Leser hoveren, um einen Wert zu prüfen, filtern, um ein Segment zu isolieren, oder zoomen, um einen dichten Cluster zu inspizieren, wird die Grafik vom Bild zum Denkwerkzeug.
Eines der bekanntesten D3-Style-Interaktionen ist der Tooltip. Das Chart bleibt aufgeräumt, aber präzise Werte sind bei Bedarf verfügbar. Die besten Tooltips wiederholen nicht nur die Achsenbeschriftung — sie fügen Kontext hinzu (Einheiten, Zeitraum, Quelle, Rang) und werden so positioniert, dass sie das untersuchte Mark nicht verdecken.
Brushing — klicken und ziehen, um einen Bereich auszuwählen — ist ein direkter Weg, Fragen zu stellen wie „Was passierte in diesem Zeitfenster?“ oder „Welche Punkte sind in diesem Cluster?“ D3 machte dieses Muster auf dem Web zugänglich, besonders für Zeitreihen und Scatterplots.
In Kombination mit Filtern (Auswahl hervorheben, andere abdunkeln oder neu zeichnen) verwandelt Brushing eine statische Ansicht in eine explorative.
D3 populärisierte Dashboards, in denen Interaktionen über Charts hinweg wirken. Klicke einen Balken, um eine Karte zu aktualisieren; brush eine Zeitachse, um eine Tabelle zu filtern; hover ein Punkt, um die entsprechende Zeile hervorzuheben. Verknüpfte Ansichten helfen Menschen, Kategorien, Geografie und Zeit zu verbinden, ohne alles in einem überladenen Chart unterzubringen.
Die meisten Interaktionen reduzieren sich auf wenige Events — click, mousemove, mouseenter/mouseleave und Touch-Äquivalente. D3s Ansatz ermutigte Teams, Verhalten direkt an visuelle Elemente zu hängen (die Balken, Punkte, Labels), sodass Interaktionen „nativ“ zum Graphic gehören und nicht angeklebt wirken.
Interaktive Charts sollten über die Maus hinaus funktionieren. Mach zentrale Aktionen per Tastatur verfügbar (fokussierbare Elemente, klare Fokus-Zustände), biete Textalternativen für Screenreader (Labels und Beschreibungen) und vermeide es, Bedeutung nur über Farbe zu kodieren. Respektiere zudem Präferenzen für reduzierte Bewegung, damit Tooltips, Hervorhebungen und Übergänge keine Barriere werden.
D3 popularisierte die einfache Idee: Ein Transition ist eine animierte Veränderung zwischen Zuständen. Anstatt ein Chart neu zu zeichnen, lässt du Marks von ihrem alten in den neuen Zustand gleiten — Balken wachsen, Punkte verschieben sich, Labels aktualisieren sich. Diese Zwischenbewegung hilft Menschen nachzuverfolgen, was sich geändert hat, nicht nur dass etwas sich geändert hat.
Gezielt eingesetzt, erhöhen Übergänge die Klarheit:
Animation wird störend, wenn sie mit den Daten konkurriert:
Eine nützliche Regel: Wenn das Publikum das Update sofort ohne Bewegung verstehen würde, halte die Transition subtil — oder lasse sie ganz weg.
Transitions kosten Ressourcen. Konzeptuell verbesserst du Performance, wenn du:
Und: Denk an den Nutzerkomfort. Respektiere reduzierte-Bewegungs-Präferenzen (z. B. kürzere Dauern oder Ausblenden von Transitionen) und biete Kontrolle — etwa einen „Animation pausieren“-Schalter oder eine Option, von animierten zu sofortigen Updates zu wechseln. Motion sollte Verständnis fördern, nicht Aufmerksamkeit fordern.
D3 wird oft missverstanden als „eine Chart-Bibliothek“. Ist es nicht. D3 gibt dir nicht einfach eine fertige Balken-Chart-Komponente mit vielen Konfigurationsoptionen. Stattdessen liefert es low-level Bausteine: Skalen, Achsen, Formen, Layouts, Selections und Verhalten. Deshalb ist D3 extrem flexibel — und damit manchmal aufwändiger als erwartet.
Wenn du „ein Chart einfügen und abliefern“ willst, greifst du meist zu höherstufigen Bibliotheken, die vorgefertigte Charttypen liefern. D3 ist eher wie ein Satz Präzisionswerkzeuge: Du entscheidest, wie das Chart aussieht, wie es gezeichnet wird und wie es sich verhält.
Dieser Kompromiss ist bewusst. D3 bleibt wenig vorschreibend, wodurch alles möglich ist — klassische Charts, benutzerdefinierte Karten, Netzwerkdiagramme und besondere redaktionelle Grafiken.
In modernen Teams wird D3 oft mit einem UI-Framework kombiniert:
Dieser Hybrid-Ansatz zwingt D3 nicht, die gesamte App zu managen, nutzt aber seine Kernfähigkeiten optimal.
Eine praktische Regel: Lass das Framework DOM-Elemente erstellen und updaten; nutze D3, um Positionen und Geometrie zu berechnen.
Beispiel: Verwende D3, um Werte in Pixel zu übersetzen (Skalen) und einen SVG-Pfad zu generieren, aber lass deine Komponenten die <svg>-Struktur rendern und auf Nutzerinput reagieren.
Zwei Fehler tauchen wiederholt auf:
Behandle D3 wie ein Toolkit für spezifische Aufgaben — so bleibt dein Code klarer und deine Charts wartbar.
D3s größtes Erbe ist nicht ein einzelner Charttyp — es ist die Erwartung, dass Webgrafiken präzise, ausdrucksstark und eng mit Daten verbunden sein können. Nach D3 behandelten viele Teams Visualisierung als integralen Teil der Oberfläche, nicht als nachträglich angebrachtes Element.
D3 tauchte früh im Data-Journalismus auf, weil es gut zu den Arbeitsabläufen passte: Reporter und Designer konnten maßgeschneiderte Visuals für einzelne Geschichten bauen, statt jeden Datensatz in eine Standardvorlage zu pressen. Interaktive Wahlkarten, Scroll-gesteuerte Erklärgrafiken und annotierte Diagramme wurden häufiger — nicht weil D3 alles „einfach“ gemacht hat, sondern weil es mit Web-Bausteinen möglich wurde.
Auch Civic-Tech-Gruppen profitierten. Öffentliche Datensätze sind oft unordentlich, und Fragen variieren nach Stadt, Politik und Publikum. D3s Ansatz ermutigte Projekte, die sich an die Daten anpassen — von einfachen, gut beschrifteten Charts bis zu explorativen Interfaces.
Selbst Teams, die D3 nicht direkt einsetzen, übernahmen viele Praktiken: Denken in Skalen und Koordinatensystemen, Trennung von Datenumformung und Rendering, und die Nutzung von DOM/Canvas als programmierbare Grafikfläche.
D3s Einfluss verbreitete sich durch seine Community. Die Gewohnheit, kleine, fokussierte Beispiele zu veröffentlichen — jeweils eine Idee — erleichterte das Lernen durch Remix. Observable-Notebooks erweiterten diese Tradition mit einem interaktiven Medium: Live-Code, sofortiges Feedback und teilbare „Skizzenbücher“ für Visualisierungs-Ideen. Bibliothek und Community halfen gemeinsam zu definieren, wie moderne Web-Visualisierung heute aussieht.
D3 lässt sich am leichtesten auswählen, wenn du es als Designwerkzeug betrachtest, nicht als Abkürzung. Es gibt dir feine Kontrolle darüber, wie Daten zu Marks werden, wie diese auf Eingaben reagieren und wie alles sich über die Zeit aktualisiert. Diese Freiheit hat ihren Preis: Du bist verantwortlich für viele Entscheidungen, die eine Chart-Library für dich treffen würde.
Bevor du ein Tool wählst, kläre vier Dinge:
Brauchen die Fragen Exploration und ist der Chart nicht „von der Stange“, wird D3 sinnvoll.
Wähle D3 bei kundenspezifischen Interaktionen (Brushing, verknüpfte Ansichten, ungewöhnliche Tooltips, progressive Offenlegung), einzigartigen Designs (nichtstandard Encodings, bespoke Layout-Regeln) oder präziser Kontrolle über Performance und Rendering (SVG + Canvas-Hybride). D3 glänzt auch, wenn die Visualisierung ein Produktfeature ist — etwas, das dein Team iterativ verbessern wird.
Für ein standardisiertes Dashboard mit üblichen Charts, konsistentem Theme und schneller Lieferung ist eine höherstufige Bibliothek meist schneller und sicherer. Du bekommst Achsen, Legenden, Responsivität und Accessibility-Patterns, ohne alles selbst zu implementieren.
Für substanzielle Visualisierungen plane Zeit für: Lernen von Selections und Joins, Skalen, Event-Handling und Testen von Edge-Cases. Gute D3-Arbeit umfasst Design-Iteration, nicht nur Implementierung — also budgetiere für beides.
D3 belohnt praktisches Lernen. Der schnellste Weg, das „D3-Mindset“ zu fühlen, ist ein kleines Chart Ende-zu-Ende zu bauen und es dann in gezielten Schritten zu verbessern, statt gleich ein Dashboard zu versuchen.
Wähle einen kleinen Datensatz (10–50 Reihen) und bau ein einfaches Balken- oder Liniendiagramm. Halte die erste Version bewusst schlicht: ein SVG, eine Gruppe (<g>), eine Reihe. Wenn es korrekt rendert, füge Verbesserungen nacheinander hinzu — Hover-Tooltips, Hervorhebung, dann Filtern oder Sortieren. Diese Reihenfolge lehrt, wie Updates funktionieren, ohne dich in Features zu verlieren.
Wenn du eine Referenz beim Bauen möchtest, halte eine Notizseite im Teamwiki mit Links zu Beispielen aus /blog.
Eine einfache Regel: Wenn du es nicht aktualisieren kannst, verstehst du es noch nicht.
Nach dem ersten Chart dokumentiere ein wiederverwendbares „Chart-Pattern“ (Struktur, Margin-Konvention, Update-Funktion, Event-Handler). Behandle es wie eine kleine interne Komponentenbibliothek — auch ohne Framework. So baust du mit der Zeit ein gemeinsames Vokabular und lieferst schneller.
Wenn du ein internes Analytics-Tool entwickelst, lohnt sich oft, die umgebende App (Authentifizierung, Routing, Tabellen, Filter, API-Endpoints) zu prototypen, bevor du viel in Visualisierungsdetails investierst. Plattformen wie Koder.ai können hier hilfreich sein: Du kannst eine React-basierte Web-App um deine D3-Komponenten per Chat prototypen, im Planungsmodus iterieren und dann mit Hosting und Custom Domains deployen. Für Teams, die verschiedene Interaktionsdesigns testen, sind Snapshots und Rollbacks praktisch — so probierst du einen neuen Brushing-/Zoom-Flow, ohne eine funktionierende Version zu verlieren.
Für tiefergehende Anleitung verweise Neueinsteiger auf /docs; wenn du Tools und Support evaluierst, lege eine Vergleichsseite unter /pricing an.
Mike Bostock führte ein klares mentales Modell ein: Daten an das DOM binden, sodass jedes Datenobjekt einem sichtbaren „Mark“ auf dem Bildschirm entspricht (ein Balken, ein Punkt, ein Label, ein Pfad). Anstatt ein Diagramm als abgeschlossenes Bild zu erzeugen, aktualisierst du echte Web-Elemente (SVG/HTML) oder zeichnest auf Canvas mit datengetriebener Logik.
Traditionelle Werkzeuge beginnen oft mit einer Chart-Vorlage (Balken/Linie/Kuchen) und erlauben das Anpassen von Optionen. D3 startet bei den Web-Primitiven (DOM, SVG, Canvas) und liefert Bausteine — Skalen, Formen, Achsen, Layouts, Verhaltensweisen — damit du die Visualisierung bauen kannst, die du wirklich brauchst, inklusive individueller Interaktionen und nicht-standardisierter Layouts.
Der Browser bekam zu dieser Zeit robuste, standardisierte Grafik- und Strukturfunktionen:
D3 passte perfekt in diesen Moment, weil es Daten mit diesen nativen Fähigkeiten verband, anstatt statische Bilder auszugeben.
Eine Selection ist D3s Weg, Elemente anzusprechen und Änderungen anzuwenden. Praktisch ist es: „Finde diese Knoten und setze dann Attribute/Styles/Events basierend auf Daten.“ Typischerweise wählst du einen Container, wählst Marks (z. B. circle), bindest Daten und setzt dann x/y, r, fill und Text aus jedem Datensatz.
Es ist der Workflow, um visuelle Elemente mit sich ändernden Daten synchron zu halten:
Deshalb eignet sich D3 gut für Filter, Live-Updates und interaktive Neuordnungen, ohne alles neu zu zeichnen.
Eine D3-Skala ist eine Funktion, die Datenwerte in visuelle Werte (meist Pixel) übersetzt: daten → skala → bildschirm. Sie zentralisiert Mapping (domain/range), sodass du nicht überall in deinem Code manuelle Rechnungen verteilst. Viele Skalen unterstützen zudem die Invertierung (Pixel → Daten), was für präzise Interaktionen wie Hover-Auslesungen, Brushing oder Zoom nützlich ist.
Verwende SVG, wenn du scharfen Text/Achsen, Styling pro Mark, Barrierefreiheit und einfache Event-Handhabung brauchst. Verwende Canvas, wenn du sehr viele Marks zeichnen musst (Tausende bis Zehntausende) und Performance wichtiger ist als ein DOM-Knoten pro Punkt. Verwende HTML für UI-intensive Teile wie Tabellen, Filter, Tooltips und hybride Layouts.
In D3 berechnet ein Layout üblicherweise Geometrie (Positionen, Winkel, Rechtecke, Pfade) aus Daten; es rendert das Chart nicht für dich. Beispiele:
d3.force/d3.forceSimulation() berechnet x/y für Netzwerk-Knoten.D3 machte mehrere web-native Interaktionsmuster zum Standard:
Eine gute Regel ist, Interaktionen an Daten-Updates zu koppeln und dann neu zu rendern, sodass die Visualisierung konsistent und nachvollziehbar bleibt.
Wähle D3, wenn du maßgeschneiderte Designs, spezielle Interaktionen oder feine Kontrolle über Rendering/Performance brauchst (inkl. SVG+Canvas-Hybriden). Verzichte auf D3, wenn du standardisierte Dashboard-Charts schnell brauchst — höhere Libraries und BI-Tools liefern meist schneller integrierte Achsen, Legenden, Theming und Accessibility-Defaults.
Der schnellste Weg, die „D3-Mentalität“ zu verinnerlichen, ist ein kleines Chart komplett zu bauen und schrittweise zu erweitern:
Wenn du Referenzen brauchst, halte Notizen im Teamwiki und verlinke Beispiele aus /blog. Für Projektteams kann es sinnvoll sein, die umgebende App (Auth, Routing, Tabellen, Endpoints) zu prototypen, bevor du in Visualisierungsdetails investierst.
Das Ziel ist, die Visualisierung als Designtool zu betrachten, nicht als Abkürzung. D3 gibt dir feingranulare Kontrolle darüber, wie Daten zu Marks werden und wie diese auf Eingaben reagieren. Diese Freiheit bedeutet auch Verantwortung: viele Entscheidungen, die eine Chart-Library abnehmen würde, musst du selbst treffen. Plane deshalb Zeit für Lernen, Design-Iteration und Tests ein.
d3.geo/d3.geoPath() wandelt GeoJSON in zeichnbare Pfade um.Diese berechneten Werte bindest du dann an Marks in SVG/Canvas/HTML.