Wo Karten auf Code treffen

Stellen Sie sich vor, Sie entwickeln eine App für Essenslieferungen. Ihre Nutzer wollen wissen: „Welche Restaurants liefern in meinem Umkreis?" Eine einfache Frage – doch dahinter steckt eine komplexe Herausforderung: Wie speichert und durchsucht man geografische Daten effizient? Lange Zeit bedeutete das: PostGIS, komplexe SQL-Queries und viel Kopfzerbrechen. MongoDB hat das Spiel verändert. Als NoSQL-Datenbank bringt sie native Geodaten-Unterstützung mit, die sich nahtlos in .NET-Anwendungen integrieren lässt. Kein externes GIS-System, keine komplizierten Joins – nur sauberer C#-Code und leistungsstarke räumliche Abfragen.

Von Koordinaten zu Geschäftslogik: Warum Geodaten komplex sind

Geodaten sind anders als normale Datenbankfelder. Ein Name ist ein String, ein Preis ist eine Zahl – aber ein Standort? Das ist ein Punkt auf einer Kugel, die sich dreht, mit Koordinaten, die je nach Projektion variieren können. Dazu kommt die Herausforderung der Berechnung: Luftlinie zwischen München und Berlin? Das ist Kugelgeometrie, keine einfache Mathematik.

Klassische relationale Datenbanken haben Jahre gebraucht, um brauchbare Geodaten-Unterstützung zu entwickeln. PostGIS für PostgreSQL ist mächtig, aber auch komplex. SQL Server Spatial ist vorhanden, aber oft umständlich. Die meisten Entwickler kennen das Gefühl: Man will einfach nur „Restaurants in 5 km Umkreis“ abfragen, verbringt aber Stunden mit Koordinatensystem-Konfigurationen und räumlichen Indizes.

MongoDB geht einen anderen Weg. Geodaten werden als Teil des Dokuments gespeichert – natürlich, flexibel und mit integrierter Suchfunktionalität. Während PostGIS mächtig ist, wenn es um komplexe räumliche Analysen geht, brilliert MongoDB bei dem, was 90 Prozent aller Anwendungen wirklich brauchen: einfache Umkreissuchen, Geofencing und standortbasierte Filter.

GeoJSON: Der Standard, der endlich funktioniert

Der Schlüssel zu MongoDBs Geodaten-Erfolg liegt im GeoJSON-Format. Während andere Datenbanken proprietäre Formate verwenden, setzt MongoDB auf einen offenen Standard, der sich in der gesamten Webentwicklung durchgesetzt hat. GeoJSON ist nicht nur ein MongoDB-Feature – es ist das, was auch Google Maps, Leaflet und praktisch jede moderne Mapping-Bibliothek verwenden.

Die Grundstruktur ist erfrischend einfach:

{ "type": "Point", "coordinates": [11.5820, 48.1351] }

Das ist ein Punkt in München als GeoJSON-Point. Beachten Sie die Reihenfolge: Längengrad zuerst, dann Breitengrad. Das verwirrt zunächst (wir denken meist in Lat/Lng), aber es folgt der mathematischen Konvention von x/y-Koordinaten. Einmal verinnerlicht, ergibt es Sinn.

MongoDB unterstützt alle wichtigen GeoJSON-Typen: Point für einzelne Standorte, LineString für Routen, Polygon für Gebiete und sogar komplexe MultiPolygon-Strukturen für Länder mit Inseln. Das Schöne daran: Jeder Webentwickler, der schon einmal mit Google Maps gearbeitet hat, versteht diese Strukturen intuitiv.

C# trifft auf Koordinaten: Der MongoDB-.NET-Driver

Hier wird es interessant für .NET-Entwickler. Der MongoDB C# Driver bringt vollständige GeoJSON-Unterstützung mit – nicht als String-Parsing oder JSON-Manipulation, sondern als typisierte C#-Klassen. Das bedeutet IntelliSense, Compile-Time-Checks und die gewohnte .NET-Entwicklererfahrung.

using MongoDB.Driver.GeoJsonObjectModel;
using MongoDB.Bson.Serialization.Attributes;

public class Restaurant
{
  [BsonId]
  public ObjectId Id { get; set; }

  [BsonElement("name")]
  public string Name { get; set; }

  [BsonElement("location")]
  public GeoJsonPoint<GeoJson2DGeographicCoordinates> Location { get; set; }

  [BsonElement("cuisine")]
  public string Cuisine { get; set; }

  [BsonElement("delivery_area")]
  public GeoJsonPolygon<GeoJson2DGeographicCoordinates> DeliveryArea { get; set; }
}

Schauen wir uns diese Klasse genauer an: Das Location-Feld ist nicht einfach ein beliebiges Objekt, sondern ein stark typisiertes GeoJsonPoint mit geografischen Koordinaten. Das heißt, der Compiler weiß, dass hier Geodaten erwartet werden. Das DeliveryArea-Feld ist ein Polygon – perfekt für Liefergebiete, Stadtgrenzen oder andere räumliche Bereiche.

Der Typ GeoJson2DGeographicCoordinates sagt MongoDB, dass wir mit echten Erdkoordinaten arbeiten, nicht mit abstrakten 2D-Koordinaten. Das ist wichtig, weil MongoDB dann sphärische Berechnungen verwendet – die Erde ist schließlich rund, nicht flach.

Was hier besonders elegant ist: Sie können normale Geschäftsobjekte mit Geodaten mischen. Ein Restaurant hat einen Namen, eine Küche und geografische Eigenschaften – alles in einem einzigen Dokument, ohne komplizierte Joins oder separate Geo-Tabellen.

Beispiel aus der Praxis: Eine einfache Umkreissuche

Lassen Sie uns ein konkretes Beispiel durchspielen. Angenommen, Sie sitzen in Augsburg (Koordinaten: 10.8978° Ost, 48.3705° Nord) und suchen Restaurants im Umkreis von zehn Kilometern:

public async Task<List<Restaurant>> FindNearbyRestaurants(
    double longitude, double latitude, int radiusInMeters)
{
  var userLocation = GeoJson.Point(GeoJson.Geographic(longitude, latitude));
  var filter = Builders<Restaurant>.Filter.Near(r => r.Location, userLocation, radiusInMeters);

  return await _collection
    .Find(filter)
    .Sort(Builders<Restaurant>.Sort.Ascending("$natural"))
    .Limit(20)
    .ToListAsync();
}

// Aufruf für Augsburg
var restaurants = await FindNearbyRestaurants(10.8978, 48.3705, 10000);

Das ist bemerkenswert einfach für etwas so Komplexes. Sie erstellen einen GeoJSON-Point aus den Nutzerkoordinaten, definieren einen Near-Filter mit dem gewünschten Radius, und MongoDB erledigt den Rest. Die Sortierung nach $natural ist ein kleiner Trick – sie gibt die Ergebnisse in der Reihenfolge zurück, wie MongoDB sie intern gefunden hat, was oft der Entfernung entspricht.

Was hier passiert: MongoDB verwendet einen speziellen 2dsphere-Index, findet alle Restaurants im Umkreis und berechnet dabei echte Kugelentfernungen. Das bedeutet, 1000 Meter sind in Hamburg etwas anderes als in München (aufgrund der Erdkrümmung), aber MongoDB berücksichtigt das automatisch.

Geo-Indizes: Performance, die zählt

Geodaten ohne Index sind nutzlos. MongoDB bietet zwei Arten von Geo-Indizes: Der 2dsphere-Index versteht, dass die Erde eine Kugel ist, und berechnet Entfernungen entsprechend. Unter der Haube nutzt MongoDB Googles S2-Bibliothek – dieselbe Technologie, die Google Maps verwendet. Der 2d-Index hingegen ist für flache Koordinatensysteme gedacht – perfekt für CAD-Daten, Gebäudepläne oder Gaming-Koordinaten.

Anwendungsbeispiele aus der echten Welt

In der Logistik nutzen Unternehmen MongoDB für dynamische Routenoptimierung und Warehouse-Management. Lieferdienste können in Echtzeit prüfen, welche Fahrer für welche Aufträge in Frage kommen. Location-based Services, wie Dating-Apps oder Social Networks verwenden Umkreissuchen, um relevante Nutzer oder Events zu finden. IoT und Tracking profitieren von MongoDBs Change Streams für Live-Updates von Fahrzeugpositionen oder Asset-Tracking.

Besonders interessant ist der Einsatz in CAD-Systemen und technischen Zeichnungen. Hier nutzen Entwickler den 2d-Index für präzise planare Berechnungen – zum Beispiel, um Bauteile zu finden, die sich in einem bestimmten Bereich einer technischen Zeichnung befinden. Die Koordinaten haben hier nichts mit Erdkoordinaten zu tun, sondern sind flach.

Performance und Skalierung in der Praxis

Die Geodaten-Performance von MongoDB ist beeindruckend: Ein gut indizierter 2dsphere-Index kann millionenfache Umkreis-Queries pro Tag verkraften. Uber macht das täglich vor. Wichtige Performance-Tipps: Verwenden Sie Compound-Indizes für häufige Kombinationen, nutzen Sie Partial Indexes für selektive Abfragen, und verwenden Sie nie Geodaten-Felder als Shard-Keys.

Die 16-MByte-Dokumentgrenze ist wohl selbst bei komplexen Anwendungsfällen kaum auszureizen, jedoch ist es gut, diese Beschränkung zu kennen. In solchen Fällen müssen Sie die Geometrie vereinfachen oder aufteilen.

Koordinatensysteme: 2D versus Sphärisch

MongoDB unterstützt beide Welten: echte Erdkoordinaten und flache 2D-Systeme. Für geografische Anwendungen verwenden Sie immer 2dsphere-Indizes und GeoJson2DGeographicCoordinates. MongoDB berechnet dann echte Kugelentfernungen und berücksichtigt die Erdkrümmung. Für technische Anwendungen – CAD-Systeme, Gebäudepläne, Spiele – verwenden Sie 2d-Indizes und planare Koordinaten.

Meine ehrliche Meinung: Warum MongoDB bei Geodaten überzeugt

Nach Jahren der Arbeit mit verschiedenen Geodaten-Systemen bin ich überzeugt: MongoDB hat das richtige Gleichgewicht gefunden. Es ist mächtig genug für echte Anwendungen, aber einfach genug, dass normale Entwickler damit produktiv werden.

Das Schöne am Geodaten-Ansatz von MongoDB ist die Natürlichkeit. Sie speichern ein Restaurant mit Name, Adresse und Standort in einem Dokument – genau so, wie Sie darüber denken. Keine künstlichen Trennungen zwischen „Business-Daten“ und „Geo-Daten", keine komplexen Joins zwischen Tabellen.

Für die meisten Location-based Apps ist MongoDB mehr als ausreichend. Es skaliert horizontal, integriert sich nahtlos in moderne Web-Stacks und macht Entwickler produktiv. Die Tatsache, dass Unternehmen wie Foursquare, Uber und viele andere MongoDB für ihre Geodaten verwenden, spricht für sich.

Ja, für hochkomplexe GIS-Anwendungen brauchen Sie vielleicht PostGIS. Aber für die 90 Prozent der Anwendungen, die einfach nur „Was ist in meiner Nähe?“ wissen wollen, ist MongoDB die pragmatische und elegante Lösung.