--- term: 'Geodaten-Abfragen und standortbasierte Indizierung in BaaS' seoTitle: 'Geodaten-Abfragen und standortbasierte Indizierung in BaaS' headline: 'Was sind Geodaten-Abfragen?' slug: geodaten-abfragen category: database shortDefinition: 'Eine Geodaten-Abfrage ist eine Datenbanksuche, die Datensätze nach Standort filtert und sortiert – nahe einem Punkt, im Umkreis oder innerhalb einer Fläche.' relatedTerms: - database-index - database-queries - relational-queries-document-databases - auto-generated-database-apis contrastsWith: - database-index faq: - question: 'Was ist eine Geodaten-Abfrage?' answer: 'Eine Datenbanksuche, deren Filter räumlich statt wertbasiert ist: Sie liefert Datensätze nahe einem Punkt, im Umkreis oder innerhalb einer Box oder eines Polygons, meist sortiert vom nächsten zum entferntesten. Die Datenbank speichert Koordinaten als eigenständigen Typ – einen GeoPoint aus Breiten- und Längengrad – und ein räumlicher Index beantwortet die Frage, ohne die Distanz zu jeder Zeile zu berechnen.' - question: 'Was ist ein GeoPoint-Feld?' answer: 'Ein Spaltentyp, der ein Paar aus Breiten- und Längengrad hält, mit Breitengrad von -90 bis 90 und Längengrad von -180 bis 180. Weil die Datenbank weiß, dass das Feld geografisch ist – und nicht einfach zwei Fließkommazahlen –, kann sie es räumlich indizieren und Distanzoperatoren anbieten: im Umkreis von so vielen Kilometern oder Meilen, innerhalb dieser Bounding Box, enthalten in diesem Polygon, nach Nähe sortiert.' - question: 'Wie funktioniert ein Geo-Index vom Typ 2dsphere?' answer: 'Er bildet die gekrümmte Erdoberfläche auf sortierte, indizierbare Zellen ab – grobe Zellen, unterteilt in feinere –, sodass Nähe auf dem Globus zur Nachbarschaft im Index wird. Eine Near-Abfrage sieht sich die Handvoll Zellen an, die das Suchgebiet abdecken, statt jede Zeile, und sphärische Geometrie hält die Distanzen ehrlich, auch über den Antimeridian hinweg und in Polnähe.' - question: 'Warum ist eine Umkreissuche ohne Geo-Index langsam?' answer: 'Weil die Engine ohne ihn die Distanz von Ihrem Punkt zu jeder Zeile berechnen und anschließend alles sortieren muss – ein vollständiger Scan im Kostüm der Trigonometrie, bei jeder Anfrage aufs Neue. Ein Geo-Index dreht die Arbeit um: Er geht direkt zu den Zellen, die den Suchradius abdecken, und fasst nur plausible Kandidaten an. Der Abstand wächst mit der Tabellengröße, genau wie bei jedem fehlenden Index, nur teurer pro Zeile.' - question: 'Was ist der Unterschied zwischen einer Near- und einer Within-Abfrage?' answer: 'Eine Near-Abfrage beantwortet "was ist am nächsten?" – sie sortiert nach Distanz von einem Punkt und deckelt die Ergebnisse üblicherweise mit einem Limit oder einem Maximalradius. Eine Within-Abfrage beantwortet "was liegt innerhalb?" – sie filtert nach Enthaltensein in einem Umkreis, einer Box oder einem Polygon und impliziert keine Sortierung. Listen der nächsten Cafés sind Near-Abfragen; "Geschäfte in diesem Kartenausschnitt" und Geofencing-Prüfungen sind Within-Abfragen.' - question: 'Kann ich Geo-Filter mit gewöhnlichen Abfragefiltern kombinieren?' answer: 'Ja, und echte Features tun das fast immer: im Umkreis von 2 km *und* jetzt geöffnet *und* besser als vier Sterne bewertet. Die Geo-Bedingung lässt sich mit Gleichheits-, Bereichs- und Pointer-Filtern in einer Abfrage kombinieren. Achten Sie auf das Zusammenspiel mit der Indizierung – der räumliche Index schränkt zuerst nach Standort ein, und stark selektive gewöhnliche Filter verdienen womöglich einen eigenen Index, damit die kombinierte Abfrage günstig bleibt.' - question: 'Wie genau sind Umkreisabfragen über große Distanzen?' answer: 'Sphärische Berechnungen modellieren die Erde als Kugel, was vom tatsächlichen Ellipsoid um bis zu rund ein Drittel Prozent abweicht – Meter auf Stadtdistanzen und für die Produktlogik meist ohne Belang. Früher schmerzt die Genauigkeit der gespeicherten Punkte selbst: Koordinaten aus dem Telefon-GPS tragen im Freien einen Fehler von Metern, in Gebäuden mehr. Für "finde X in der Nähe" sind beide Effekte Rauschen.' codeLanguages: [javascript, dart, swift, kotlin] externalAuthorities: - name: 'MongoDB geospatial queries' url: 'https://www.mongodb.com/docs/manual/geospatial-queries/' - name: 'Parse SDK guide — GeoPoints' url: 'https://docs.parseplatform.org/js/guide/' - name: 'PostGIS — spatial extension for PostgreSQL' url: 'https://postgis.net/' - name: 'Spatial database (Wikipedia)' url: 'https://en.wikipedia.org/wiki/Spatial_database' cta: title: '"In der Nähe" noch heute Nachmittag ausliefern' text: 'Back4app gibt jeder Klasse GeoPoint-Felder, mit Umkreis-, Box- und Nähe-Abfragen direkt in den automatisch generierten APIs und in jedem SDK – aus dem Standort-Feature, das sonst einen Umweg über eine räumliche Datenbank verlangt, werden drei Zeilen Abfragecode.' linkText: 'Kostenlos starten' linkUrl: 'https://www.back4app.com/signup' author: 'Back4app Engineering' publishedDate: '2026-09-28' translationKey: geospatial-queries-indexing --- **Eine Geodaten-Abfrage ist eine Datenbanksuche, die Datensätze nach Standort filtert und sortiert – nahe einem Punkt, im Umkreis oder innerhalb einer Fläche.** Sie trägt den Feature-Wunsch, der in fast jedem Produkt im zweiten Monat eintrifft: *finde X in der Nähe* – Cafés, Fahrer, Geschäfte, andere Benutzer. Und sie ist der klarste Fall einer Abfrageklasse, die gewöhnliche [B-Tree-Indizierung](/glossary/de/datenbankindex/) nicht bedienen kann: Nähe ist zweidimensional, und eine Struktur, die nach einer Dimension sortiert ist, kann sie nicht sehen. ## Das Wichtigste in Kürze | Frage | Antwort | | --- | --- | | Der Feldtyp | GeoPoint – ein Paar aus Breiten- und Längengrad, das die Datenbank versteht | | Die Abfragen | Near (nach Distanz sortiert), im Umkreis, in Box/Polygon | | Der Index | Vom Typ 2dsphere: der Globus auf indizierbare Zellen abgebildet | | Ohne ihn | Distanz zu jeder Zeile berechnet – ein vollständiger Scan mit Trigonometrie | | Das kanonische Feature | "Finde X in der Nähe", kombiniert mit gewöhnlichen Filtern | ## Die Umkreisabfrage, geschrieben und gespürt **JavaScript:** ```javascript // JavaScript / Node.js — Back4app JS SDK // "Find cafes within 2 km, nearest first" — the canonical geo query const here = new Parse.GeoPoint({ latitude: 40.7484, longitude: -73.9857 }); const query = new Parse.Query('Cafe'); query.withinKilometers('location', here, 2); // radius filter, nearest-first query.equalTo('openNow', true); // geo + ordinary filters compose query.limit(20); const cafes = await query.find(); cafes.forEach((c) => { const km = here.kilometersTo(c.get('location')); console.log(`${c.get('name')} — ${km.toFixed(2)} km away`); }); ``` **Flutter:** ```dart // Flutter / Dart — Back4app Flutter SDK // "Find cafes within 2 km, nearest first" — the canonical geo query final here = ParseGeoPoint(latitude: 40.7484, longitude: -73.9857); final query = QueryBuilder(ParseObject('Cafe')) ..whereWithinKilometers('location', here, 2) // radius filter, nearest-first ..whereEqualTo('openNow', true) // geo + ordinary filters compose ..setLimit(20); final response = await query.query(); for (final result in response.results ?? []) { final cafe = result as ParseObject; final loc = cafe.get('location'); print('${cafe.get('name')} at ' '${loc?.latitude}, ${loc?.longitude}'); } ``` **Swift:** ```swift // iOS / Swift — Back4app Swift SDK // "Find cafes within 2 km, nearest first" — the canonical geo query let here = try ParseGeoPoint(latitude: 40.7484, longitude: -73.9857) let query = Cafe.query( withinKilometers(key: "location", geoPoint: here, distance: 2), "openNow" == true // geo + ordinary filters compose ).limit(20) query.find { result in if case .success(let cafes) = result { for cafe in cafes { print("\(cafe.name ?? "?") — \(String(describing: cafe.location))") } } } ``` **Kotlin:** ```kotlin // Android / Kotlin — Back4app Android SDK // "Find cafes within 2 km, nearest first" — the canonical geo query val here = ParseGeoPoint(40.7484, -73.9857) val query = ParseQuery.getQuery("Cafe") query.whereWithinKilometers("location", here, 2.0) // radius, nearest-first query.whereEqualTo("openNow", true) // geo + filters compose query.limit = 20 query.findInBackground { cafes, e -> if (e == null) cafes.forEach { cafe -> val loc = cafe.getParseGeoPoint("location") val km = loc?.distanceInKilometersTo(here) println("${cafe.getString("name")} — ${"%.2f".format(km)} km away") } } ``` Dieselbe Physik in SQL, über [PostGIS](https://postgis.net/) – und der Index, der sie tragfähig macht: ```sql -- Ein räumlicher Index über der geography-Spalte: CREATE INDEX cafe_location_gix ON cafe USING GIST (location); -- "Cafés im Umkreis von 2 km, die nächsten zuerst": SELECT name, ST_Distance(location, ST_MakePoint(-73.9857, 40.7484)::geography) AS meters FROM cafe WHERE ST_DWithin(location, ST_MakePoint(-73.9857, 40.7484)::geography, 2000) ORDER BY location <-> ST_MakePoint(-73.9857, 40.7484)::geography LIMIT 20; -- mit Index: fasst nur die Zellen an, die den 2-km-Kreis abdecken -- ohne Index: berechnet für jede Zeile der Tabelle eine Distanz ``` ## Wie der Index den Globus sieht ```mermaid flowchart TB accTitle: Wie ein sphärischer Geo-Index eine Umkreisabfrage beantwortet accDescr: Die Erdoberfläche wird in hierarchische Zellen zerlegt, die in sortierter Reihenfolge abgelegt sind. Eine Umkreisabfrage wählt die wenigen Zellen aus, die den Suchkreis abdecken, durchsucht nur die Kandidatenpunkte darin und berechnet die exakten Distanzen für diese kurze Liste. G["Globus zerlegt in
hierarchische Zellen"] --> C1["Grobe Zelle
(Stadtmaßstab)"] C1 --> F1["Feinere Zellen, die den
2-km-Kreis abdecken"] F1 --> P["Kandidatenpunkte
nur in diesen Zellen"] P --> D["Exakte Distanzprüfung
+ Sortierung, nächste zuerst"] ``` Ein [Index vom Typ 2dsphere](https://www.mongodb.com/docs/manual/geospatial-queries/) macht Nähe indizierbar, indem er die gekrümmte Oberfläche auf hierarchische Zellen abbildet, deren Sortierreihenfolge die Nachbarschaft erhält – auf dem Globus benachbarte Punkte landen in benachbarten Indexeinträgen. Eine Umkreisabfrage liest sich dann wie jeder Indexzugriff: die wenigen Zellen bestimmen, die den Kreis abdecken, deren Kandidaten durchsuchen, die exakten Distanzen auf dieser kurzen Liste prüfen. Sphärische Geometrie – statt Mathematik in der Ebene – hält die Ergebnisse in realen Maßstäben korrekt, über den Antimeridian hinweg und zu den Polen hin. Die Regel für die Kombination folgt aus gewöhnlicher [Abfragemechanik](/glossary/de/datenbankabfragen/): Geo-Bedingungen lassen sich frei mit Gleichheits-, Bereichs- und Pointer-Filtern verbinden (`openNow == true` in den Tabs oben), und die selektiven nicht-geografischen Filter in heißen Abfragen verdienen womöglich eigene Indizes. Die Paginierung verdient eine eigene Anmerkung, denn nach Distanz sortierte Ergebnisse brechen die Offset-Gewohnheit. Über die erste Seite einer Near-Abfrage hinauszuspringen zwingt die Engine, alles Übersprungene neu zu ranken, und ein Punkt, der sich zwischen zwei Anfragen bewegt hat, kann die Reihenfolge unter den Füßen der Benutzer verschieben. Die robusteren Muster: den Radius für "mehr laden" schrittweise erweitern oder innerhalb eines festen Radius über einen stabilen Schlüssel paginieren. Nächste-zuerst ist ein Ranking über lebende Daten – behandeln Sie Seitengrenzen als Richtwert, nicht als Zeilen in einem Hauptbuch. ## Near- vs. Within- vs. Abfragen in der Ebene ### Welche Geodaten-Abfrage passt? | Abfrageform | Beantwortet | Sortierung | Typischer Einsatz | | --- | --- | --- | --- | | Near (Nähe) | Was ist am nächsten? | Nächste zuerst | Listen "Cafés in der Nähe", Fahrervermittlung | | Im Umkreis | Was liegt innerhalb von r km? | Keine impliziert | Lieferbarkeit, Alarme | | In einer Box | Was liegt in diesem Rechteck? | Keine | Darstellung des Kartenausschnitts | | In einem Polygon | Was liegt in dieser Form? | Keine | Stadtviertel, Zonen, Geofences | | In der Ebene (2d) | Dasselbe, auf einer projizierten Ebene | Wechselnd | Spielkarten, Grundrisse – nicht die Erde | Die Unterscheidung Near/Within ist Produktlogik, keine Pedanterie: *near* ist ein Ranking (deckeln Sie es mit einem Limit und einem Maximalradius, sonst liefern dichte Städte Tausende Zeilen), *within* ist ein Prädikat (koppeln Sie es an die Geometrie des Ausschnitts oder des Zauns). Die Zeile zur Ebene ist die ehrliche Fußnote – für Koordinaten, die nicht auf einer Kugel liegen, sind sphärische Indizes das falsche Werkzeug. ## Typische Anwendungsfälle - **"Finde X in der Nähe."** Cafés, Fitnessstudios, Geldautomaten, Ladesäulen – die kanonische Nähe-Liste, radiusgedeckelt und nächste zuerst. - **Vermittlung und Disposition.** Fahrgäste zu Fahrern, Aufträge zu Kurieren – Near-Abfragen über häufig aktualisierten GeoPoints. - **Kartenausschnitte.** Box-Abfragen, die Pins nachliefern, während Benutzer die Karte verschieben – günstig, unsortiert, in Ausschnittsgröße. - **Geofencing.** Polygon-Prüfungen für Liefergebiete, Servicegebiete und standortgesteuerte Logik. - **Lokale soziale Features.** "Menschen in der Nähe" und "Events an diesem Wochenende", kombiniert mit Datenschutzfiltern und [Pointer-Beziehungen](/glossary/de/joins-in-dokumentdatenbanken/). ## Sollten Sie Geodaten-Abfragen nutzen oder Regionen vorberechnen? Entscheidungsmatrix | Live mit einem Geo-Index abfragen, wenn… | Regionen vorab zuordnen, wenn… | | --- | --- | | Radien und Formen pro Anfrage variieren | Grenzen fest sind (Filialen, Zonen, Bezirke) | | Punkte sich häufig bewegen (Fahrer, Benutzer) | Die Zugehörigkeit sich selten ändert | | Die Sortierung nächste-zuerst zählt | Sie ohnehin nur nach Regionsgleichheit filtern | | Die Geometrie wirklich räumlich ist | Eine einfache `region`-Spalte alles beantwortet | | Ihnen ein räumlicher Index zur Verfügung steht | Sie gruppieren statt messen | Der Ausweg zählt: Wenn sich jede Abfrage auf "in Zone A?" reduziert, schlägt eine schlichte indizierte Textspalte die räumliche Maschinerie – günstiger, einfacher und von gewöhnlichen B-Trees abgedeckt. Räumliche Indizierung verdient ihr Geld genau dann, wenn die Geometrie dynamisch ist: beliebige Mittelpunkte, bewegte Punkte, echte Distanzen. ## Grenzen und Trade-offs - **Geo-Indizes sind Spezialisten.** Sie bedienen nur räumliche Prädikate; Ihre übrigen Filter brauchen weiterhin eigene Indizes, und Indexpflege kostet Schreibzugriffe – dieselbe Steuer, nur zum räumlichen Satz. - **Unbegrenzte Near-Abfragen sind Fallstricke.** Nächste-zuerst über einer dichten Stadt ohne Radiusdeckel oder Limit rankt die halbe Tabelle. Begrenzen Sie die Suche immer. - **Bewegte Punkte schreiben ununterbrochen.** Live-Fahrerstandorte bedeuten hochfrequente GeoPoint-Aktualisierungen, von denen jede den Index pflegt – bündeln oder drosseln Sie Positionsupdates, wo das Produkt es erlaubt. - **Ein Punkt pro Zeile ist das Grundmodell.** Ein Geschäft mit fünf Filialen sind fünf Datensätze; Formen, die reicher sind als Punkte (Routen, Abdeckungsgebiete), drängen in Richtung vollwertiger [räumlicher Datenbanken](https://en.wikipedia.org/wiki/Spatial_database). - **Genauigkeit hat Untergrenzen.** Der Fehler zwischen Kugel und Ellipsoid ist vernachlässigbar, aber GPS-Rauschen liegt selbst im besten Fall im Meterbereich – legen Sie Produktlogik (Zonen, Schwellenwerte) so aus, dass sie das verträgt. ## Geodaten-Abfragen mit Back4app Back4app ist eine Open-Source-Plattform für Backend as a Service (BaaS), die eine verwaltete Datenbank, automatisch generierte REST- und GraphQL-APIs, Authentifizierung, Dateispeicher und Serverless-Funktionen mit Cloud Code kombiniert. GeoPoint ist ein nativer Spaltentyp auf dem verwalteten, MongoDB-gestützten Speicher, und die Operatoren für Nähe, Umkreis und Box – `withinKilometers`, `near`, `withinGeoBox` – stecken in den [automatisch generierten APIs](/glossary/de/automatisch-generierte-apis/) und in jedem SDK, genau so, wie die Code-Tabs oben sie verwenden. Geo-Indizes werden im Dashboard zusammen mit dem Rest Ihrer [Index-Strategie](/glossary/de/datenbankindex/) verwaltet, was aus dem üblichen Infrastrukturprojekt "finde X in der Nähe" eine Schemaentscheidung und drei Zeilen Abfrage macht.