Geocoding vs. Place Search

Geocoding vs. Place Search ist die erste Trennung in einer Standortabfrage: Ein Aufruf löst ein geografisches Subjekt auf, der andere entdeckt Kandidatenorte. Eine Adresse, eine Koordinate oder eine Ortskennung gehört zum Geocoding. Eine Anfrage nach Unternehmen, Sehenswürdigkeiten oder anderen benannten Orten gehört zur Place Search. Eine räumliche Abfrage prüft anschließend die Geometrie von Datensätzen, die die Anwendung bereits besitzt, und die Vektorsuche gleicht Bedeutung ab, ohne zu beweisen, dass ein Datensatz in der Nähe liegt oder zulässig ist.

Welche Frage beantwortet die jeweilige Standortabfrage?

Jede Methode beantwortet eine andere Frage, und ein Anbietermenü, das sie in einer Produktfamilie bündelt, hebt diesen Unterschied nicht auf. Geocoding löst Identität auf. Place Search entdeckt Kandidaten in einem Anbieter- oder privaten Index. Eine räumliche Abfrage wendet eine geometrische Beziehung auf Datensätze an, die die Anwendung bereits speichert. Die Vektorsuche ruft Datensätze ab, deren Embeddings semantisch nahe liegen. Eine Produktionsentscheidung benötigt häufig mehr als eine dieser Antworten, und zwar in einer Reihenfolge, die die Frage selbst vorgibt.

Die vier Karten trennen Auflösen, Entdecken, geografisches Filtern und Bedeutungsabgleich. Jede Karte verbindet eine Eingabe mit einer Ausgabe: eine Adresse mit einer Koordinate, eine Kategorie mit Points of Interest, eine Geometriebeziehung mit passenden Datensätzen und ein Konzept mit semantischen Nachbarn. Die Straßenadresse, die Koordinate, die Café-Abfrage und die Anzahl der Orte im Polygon sind Beispielbeschriftungen in der Abbildung. Diese Beschriftungen stammen nicht aus einer Live-Abfrage gegen einen Kaleidr-Index.

Die Tabelle ist die Auswahlregel. Ein Team, das beim Endpoint-Namen statt bei der Frage beginnt, wird einen Geocoder nach einer Empfehlung oder einen Vektorindex nach einem Enthaltensein-Test fragen. Beide Fehler liefern eine selbstsichere Antwort auf eine Frage, die das System nie ausgeführt hat. Der Rest dieses Leitfadens hält die vier Aufgaben getrennt und zeigt anschließend, wo eine Pipeline sie zusammenführen muss.

Welche Abfrage passt zur Frage?

Die ersten Wörter der Anfrage benennen meist die Methode. „Wo ist diese Adresse?“ beginnt mit Geocoding. „Welche Orte passen zu diesem Text oder dieser Kategorie?“ beginnt mit Place Search. „Welche unserer Datensätze erfüllen diese geografische Beziehung?“ beginnt mit einer räumlichen Abfrage. „Welche Datensätze bedeuten etwas Ähnliches wie dies?“ ist der Fall für Vektorsuche – und zwar erst, nachdem harte geografische und geschäftliche Grenzen gesetzt sind. Eine Anfrage, die diese Fragen mischt, braucht einen Hybridansatz, keinen einzelnen Gewinner.

Der Baum beginnt mit der Frage, die der Aufrufer beantworten möchte, und verzweigt dann zur Auflösung einer Adresse, zur Entdeckung von Unternehmen, zur geografischen Filterung eigener Datensätze des Aufrufers oder zum Finden von Datensätzen mit ähnlicher Bedeutung. Ein fünftes Band unten kombiniert die vier Methoden, wenn eine einzelne Abfrage nicht reicht. Die Beispieladresse, die Café-Karten, der Ein-Kilometer-Radius und der zitierte Date-Night-Satz sind Abbildungsbeschriftungen. Die Häkchen beschreiben die Aufgabe jeder Methode, nicht einen gemessenen Qualitätswert.

Ein Hybrid ist bei einem KI-Kartenassistenten der Normalfall und keine Ausnahme für eine spätere Version. „Kaffee nahe 20 W 34th St“ erfordert weiterhin, dass die Adresse zuerst aufgelöst wird, bevor eine Nearby-Suche laufen kann. „Ein ruhiges Café nahe dem Hotel, nach neun geöffnet“ ergänzt diese Auflösung um einen Geschäftsfilter und eine semantische Präferenz. Die Pipeline-Abschnitte unten halten diese Schritte in einer Reihenfolge, die ein Prüfer testen kann.

Was löst Geocoding auf?

Geocoding wandelt eine textuelle Ortsangabe in eine geografische Repräsentation um, und Reverse Geocoding wandelt eine Koordinate oder Ortskennung zurück in eine lesbare Adresse. Googles Überblick zur Geocoding API definiert den Dienst so, dass er eine Adresse, Breiten- und Längengrad oder eine Place ID akzeptiert und eine Adresse in Koordinaten und eine Place ID oder Koordinaten bzw. eine Place ID in eine Adresse umwandelt (Google, 2026). Derselbe Überblick verwendet „1600 Amphitheatre Parkway, Mountain View, CA“ als Beispiel für Forward Geocoding und nennt Lieferungen und Abholungen als Anwendungen für Reverse Geocoding. Die Ausgabe eines erfolgreichen Aufrufs ist ein Subjekt, das die Karte platzieren kann, keine gerankte Menge von Unternehmen.

Die Produktgrenze verändert sich, doch die Retrieval-Aufgabe bleibt das, was benannt werden muss. Googles Überblick zur Geocoding API v4 listet Forward Geocoding, Reverse Geocoding, Place Geocoding und eine Destination-Search-Methode, die eine Adresse, eine Place ID oder Koordinaten akzeptiert (Google, 2026). Der Überblick trennt außerdem Generally Available-, Preview- und Experimental-Kanäle und weist Aufrufer an, den experimentellen Kanal für Destination-Funktionen zu verwenden, die nicht im allgemein verfügbaren Pfad liegen. Ein Destination-Lookup kann einen Ort anreichern, den die Anwendung bereits aufgelöst hat. Ein Destination-Lookup wird dadurch nicht zu einem Place-Discovery-Index, und ein experimenteller Kanal ist kein Versprechen, dass jedes Feld für einen Produktionsvertrag bereit ist.

Geocoding ist das richtige Werkzeug, wenn die Anwendung eine Adresse auf der Karte darstellen, vor dem Speichern normalisieren, eine Karte zentrieren, einen Gerätestandort reverse-geocodieren oder einen Lieferpunkt vor einer späteren Abfrage auflösen muss. Geocoding wählt nicht das beste nahe Restaurant aus, liest keinen privaten Bestand, testet kein privates Service-Area-Polygon und rankt Ergebnisse nicht nach Kundenabsicht. Diese Aufgaben beginnen erst, nachdem ein Subjekt existiert. Orte auf einer Karte darstellen behandelt den Schritt von der Adresse zum Marker nach einer erfolgreichen Auflösung.

Wie unterscheiden sich Geocoding vs. Place Search?

Place Search entdeckt benannte geografische Entitäten: Restaurants, Geschäfte, Stationen, Sehenswürdigkeiten und andere Points of Interest. Mapbox zieht die Produktgrenze in der aktuellen Geocoding API ausdrücklich. Diese API führt Forward und Reverse Geocoding aus, und die Geocoding v6 API stellt keine Point-of-Interest-Daten mehr bereit (Mapbox, 2026). Für Point-of-Interest-Suchen verweist Mapbox auf die Search Box API, die interaktive und eigenständige Abfragen für Adressen, Orte und Points of Interest einschließlich Kategoriesuche unterstützt (Mapbox, 2026). Die Endpoint-Familie gehört einem Anbieter. Die Aufgaben bleiben zwei verschiedene.

Googles aktuelle Places API nimmt dieselbe Trennung innerhalb der Place Search selbst vor. Text Search (New) gibt Orte für eine Textzeichenfolge zurück, und die dokumentierten Beispiele enthalten „shoe stores near Ottawa“ und „123 Main Street“, sodass eine adressähnliche Zeichenfolge in einen Place-Search-Aufruf eingehen kann (Google, 2026). Nearby Search (New) nimmt einen oder mehrere Ortstypen entgegen und gibt passende Orte innerhalb eines festgelegten Gebiets zurück (Google, 2026). Text Search kann daher wie Geocoding aussehen, wenn die Zeichenfolge eine Adresse ist, und Nearby Search kann wie eine räumliche Abfrage aussehen, wenn das Gebiet ein Kreis ist. Das Ergebnis bleibt dennoch eine Kandidatenmenge aus dem Index dieses Anbieters. Geöffnet-Status, Bestand, Autorisierung und Reisezeit bleiben spätere Prüfungen. Dieselbe Text-Search-Seite sagt außerdem, dass der Dienst nicht für mehrdeutige Abfragen vorgesehen ist, einschließlich Formen von Postadressen, die nicht als Orte repräsentiert sind.

Das linke Panel fragt, wo eine Adresse liegt, und zeigt eine einzelne Ortsidentität. Adresse und Koordinate in diesem Panel entsprechen dem Beispiel in Kaleidrs Forward-Geocode-Referenz; die Café-Namen, Distanzen und Sternebewertungen rechts sind Beispielbeschriftungen und keine Live-Antwort einer Place Search. Die Fußzeile führt „coffee near 20 W 34th St“ durch das Geocoding der Adresse und anschließend durch die Suche nach Kaffee. Die Kernaussage rechts nennt das Ergebnis eine Kandidatenmenge – der richtige Haltepunkt vor Zulässigkeit und Ranking.

Eine robuste Anwendung nutzt beides, wenn der Anker eine Adresse und das Ziel eine Kategorie ist. Geocodiere „20 W 34th St“, suche dann nahe dem aufgelösten Punkt nach Kaffee, berechne anschließend die Gehzeit und ranke nur die Orte, die zulässig bleiben. Eine Nearby-Places-Karte ist die Discovery-Oberfläche für diesen zweiten Schritt. Die Reihenfolge des Anbieters ist eine Retrieval-Bequemlichkeit. Die Reihenfolge des Produkts ist eine spätere Entscheidung.

Was prüft eine räumliche Abfrage?

Eine räumliche Abfrage filtert Datensätze, die die Anwendung bereits besitzt, anhand einer Beziehung zwischen Geometrien. Häufige Beziehungen sind innerhalb einer Distanz, innerhalb eines Polygons, schneidet, enthält und nächster Nachbar. Die Datensätze und ihre Geometrie existieren vor der Abfrage. Die Abfrage fragt, welche dieser Datensätze die Beziehung erfüllen. Eine Place-Search-API beantwortet eine andere Frage, weil die Kandidatenmenge aus dem Index des Anbieters statt aus der Tabelle des Aufrufers kommt.

Die Panels zeigen innerhalb einer Distanz, innerhalb eines Polygons, eine Route, die eine Zone schneidet, und das nächste Feature. Der Ein-Kilometer-Radius, die Service-Area-Kontur und das Distanz-Badge sind Beispielgeometrien, keine gemessene Service Area. Das Nearest-Panel markiert außerdem ein Feature als ausgeschlossen. Dieser Ausschluss ist ein Beispiel für eine spätere Zulässigkeitsprüfung. Das Distanzprädikat allein prüft nicht, ob ein Ort geöffnet ist.

PostGIS definiert ST_DWithin als Test, ob zwei Geometrien innerhalb einer gegebenen Distanz liegen, und der Aufruf enthält einen Bounding-Box-Vergleich, der alle verfügbaren räumlichen Indizes der Geometrien nutzt (PostGIS, 2026). Für den Geography-Typ ist die Distanz in Metern angegeben. Eine Store-Tabelle mit Geography-Spalte kann „innerhalb von fünf Kilometern“ daher als Prädikat halten, statt als Satz, den ein Sprachmodell interpretieren soll.

SELECT store_id, name
FROM stores
WHERE ST_DWithin(stores.geog, user_location, 5000);

Containment ist dieselbe Prädikatklasse. ST_Within gibt true zurück, wenn jeder Punkt der ersten Geometrie in der zweiten liegt und die Innenbereiche einen Punkt teilen; auch diese Funktion nutzt verfügbare räumliche Indizes (PostGIS, 2026). ST_Within(A, B) ist die Umkehrung von ST_Contains(B, A). Eine Lieferfrage wie „liegt diese Adresse innerhalb des Servicegebiets?“ besteht aus Geocoding, dann einem Containment-Test und dann der operativen Regel. Ein Vektorindex ersetzt das Polygon nicht, und eine öffentliche Place Search ersetzt nicht die Service-Area-Geometrie, die das Unternehmen gezeichnet hat.

Der Hinweis auf den Index ist eine Architekturvorgabe, keine Tuning-Fußnote. Ein Distanz-Ausdruck, der keinen Index verwenden kann, vergleicht weit mehr Zeilen als ST_DWithin auf derselben Tabelle. Die praktische Regel für einen standortbewussten Assistenten lautet, geografisch zu filtern, bevor ein Modell die Menge sieht. Wenn nur ein kleiner Anteil eines großen Katalogs die Geometrie erfüllen kann, sollte das Sprachmodell diesen Anteil erhalten, zusammen mit dem Grund, warum die anderen ausgeschlossen wurden. Den Rest zu senden verbraucht Kontext für Datensätze, die das Prädikat bereits ausgeschlossen hat.

Was gleicht Vektorsuche ab?

Vektorsuche ruft Datensätze ab, deren Embeddings der Abfrage in einem Vektorraum nahe liegen. pgvector, die für diese Aufgabe häufig verwendete Postgres-Erweiterung, führt standardmäßig exakte Nearest-Neighbor-Suche aus und kann für approximative Suche einen HNSW- oder IVFFlat-Index hinzufügen (pgvector, 2026). Dieselbe Dokumentation listet L2-Distanz, Inner Product, Cosine Distance und weitere Maße auf. Exakte Suche ist die Recall-Baseline. Ein approximativer Index tauscht einen Teil dieses Recalls gegen Geschwindigkeit, und Abfragen können nach dem Anlegen des Index andere Nachbarn zurückgeben. Diese Eigenschaft ist wichtig, wenn ein Team einen Prototyp mit exakter Suche mit einer Produktionsabfrage vergleicht, die den Index verwendet.

Vektorsuche lohnt sich, wenn die Wörter in der Anfrage nicht dieselben sind wie im Datensatz. Eine Beschreibung wie „intime Weinbar mit gedämpftem Licht“ kann ein sinnvoller Nachbar für „ruhiger Ort für ein erstes Treffen“ sein, obwohl die Zeichenfolgen nicht übereinstimmen. Ortsbeschreibungen, Hinweise zu Ausstattungen und Destination-Text sind typische Eingaben, sofern die Lizenz erlaubt, den Text einzubetten. Eine bekannte Marke, eine Filialnummer, ein Flughafencode oder eine explizite Kategorie ist gewöhnlich besser für Keyword- oder strukturierte Suche geeignet. Embeddings fügen ein weiteres zu betreibendes System hinzu und sollten nur eingesetzt werden, wenn die semantische Lücke real ist.

Vektorähnlichkeit enthält keine geografische Distanz, Reisezeit, Service-Area-Containment, aktuellen Bestand, Öffnungszeiten, Autorisierung oder Information darüber, ob der eingebettete Text noch stimmt. Ein naher Nachbar im Embedding-Raum kann Hunderte Kilometer vom Aufrufer entfernt liegen. Ein Ort auf der anderen Straßenseite kann semantisch schlecht passen und dennoch die richtige operative Antwort sein. Die beiden Ergebnisse widersprechen sich nicht. Sie stammen aus unterschiedlichen Räumen, und die Pipeline muss festlegen, welcher Raum einen Kandidaten verwerfen darf.

Warum unterscheiden sich geografische Distanz und Vektordistanz?

Beide Systeme verwenden das Wort Distanz, und das Wort verdeckt einen Wechsel des Gegenstands. Geografische Distanz ist die Trennung auf der Erde oder entlang eines Pfads: Luftlinie, Fußweg, Fahrt oder Containment-Ergebnis. Vektordistanz ist die Trennung in einem Embedding-Raum: Cosine Distance, euklidische Distanz oder ein Inner-Product-Score. Eine kleine Vektordistanz platziert zwei Orte nicht geografisch nahe beieinander. Ein kurzer Fußweg macht zwei Beschreibungen nicht bedeutungsgleich.

Das linke Panel misst physische Trennung und zeigt einen Beispiel-Fußweg zwischen zwei beschrifteten Orten. Kilometer- und Minuten-Badges sind Beispielbeschriftungen, keine geroutete Reise. Das rechte Panel platziert Wörter in einem Embedding-Diagramm und markiert „coffee“ als semantisch weit von „train“ entfernt. Der Cosine-Hinweis illustriert die beiden Räume und ist kein gemessenes Embedding aus einem Kaleidr-Index. Die Beschriftung in der Mitte ist der Punkt der Abbildung: Dasselbe Wort „Distanz“ bezeichnet beide Größen.

Die Namenskollision erscheint auch im Produkttext. Ein Bildschirm mit „nächster“ kann den nächsten Eintrag im Embedding-Index, den nächsten in Luftlinienmetern oder den mit den wenigsten Umwegminuten meinen. Diese drei Reihenfolgen widersprechen sich oft genug, dass die Oberfläche die Größe benennen sollte. Ein Ranker kann mehr als eine davon verwenden. Er sollte aber keinen Cosine-Score zu einem Kilometerwert addieren und die Summe als eine einzige Distanz behandeln.

Wie sollte eine hybride Pipeline die Arbeit anordnen?

Eine Produktionssuche nach Orten ist gewöhnlich eine Pipeline, weil die Anfrage ein Subjekt, eine Kategorie, eine geografische Grenze, eine Geschäftsregel und eine Präferenz mischt. Eine praktikable Reihenfolge ist: Anfrage interpretieren, Anker auflösen, Kandidaten abrufen, räumlichen Filter anwenden, geschäftliche Zulässigkeit anwenden und semantische Ähnlichkeit erst innerhalb der zulässigen Menge nutzen. Routing und weitere Anreicherung laufen auf den Überlebenden. Das Ranking ordnet diese Überlebenden. Erklärung und Kartenaktion verwenden dieselben Kennungen wie die Filter. Spatial Context Engineering ist die Begleitfrage dazu, was aus dieser Pipeline das Sprachmodell erreichen darf.

Die Stufen sind mit der jeweils zuständigen Methode beschriftet: Geocoding, Place Search, räumliche Abfrage, Geschäftsdaten und Vektorsuche, gefolgt von Anreicherung, Ranking und Kartenaktion. Ortsnamen, Sternebewertungen, Score-Balken, der „100K+“-Trichter und die Aussage „top 3–5“ sind illustrative Beschriftungen. Die Abbildung ist eine Referenzskizze zur Arbeitsreihenfolge, kein Kaleidr-Benchmark und kein Request-Format. Die Spalte für Geschäftsfilter zeigt Beispielregeln wie „jetzt geöffnet“ und eine Mindestbewertung; diese gehören zu den Daten des Hosts und nicht zum öffentlichen Place-Index.

Die Reihenfolge verändert den Recall. Wenn zuerst der gesamte Embedding-Index durchsucht und die Geografie erst anschließend auf einer kurzen semantischen Liste geprüft wird, kann ein gültiger lokaler Ort fehlen, der nie in diese kurze Liste gelangt ist. Wird die Kandidatenmenge zuerst mit harten geografischen und geschäftlichen Regeln begrenzt und Bedeutung erst innerhalb dieser Menge gerankt, bleibt die Grenze erhalten. Wo die Datenbank beide Filter in einer Abfrage anwenden kann, gilt dasselbe Prinzip: Semantische Ähnlichkeit darf eine erforderliche geografische Grenze nicht aufheben.

Die Filterhinweise von pgvector sind die praktische Warnung. Bei einem approximativen Index wird der Filter nach dem Index-Scan angewandt; das Dokumentationsbeispiel verwendet eine Bedingung, die bei einem standardmäßigen HNSW-ef_search von 40 auf 10 Prozent der Zeilen passt, wodurch im Mittel etwa vier Zeilen verbleiben. Iterative Index-Scans, die die Dokumentation für diesen Engpass einführt, laufen weiter, bis genügend Zeilen übrig sind. Ein Team sollte gefilterten Recall auf realistischen Daten testen, statt anzunehmen, dass die elegante Abfrage bereits die Produktionsabfrage ist.

Warum müssen harte Filter vor Ähnlichkeit laufen?

Retrieval fragt, welche Kandidaten überhaupt in Betracht kommen dürfen. Ranking fragt, in welcher Reihenfolge die gültigen Kandidaten erscheinen sollen. Wer beides vermischt, lässt einen geschlossenen, nicht autorisierten oder ausverkauften Ort gewinnen, weil er bequem oder semantisch ähnlich ist. Kaleidrs Leitfaden zum Place Ranking hält Autorisierung, Verfügbarkeit, erforderliche Fähigkeit und Servicegebiet als Filter vor dem Scoring fest, statt als schwache Strafwerte (Kaleidr, 2026). Eine Strafe kann gegen einen großen Convenience-Term verlieren. Ein Filter nicht.

Die linke Spalte listet vier boolesche Gates auf und endet mit dem Entfernen ungültiger Kandidaten. Die rechte Spalte zeigt Beispiel-Ähnlichkeitsscores für ruhig, familienfreundlich und arbeitsfreundlich und rankt nur die Orte, die bestanden haben. Die Fotos und drei Scores sind Beispielbeschriftungen, keine gemessenen Bewertungen und kein Kaleidr-Score. Der Pfeil zeigt die Reihenfolge: Zulässigkeit, dann Ähnlichkeit.

Harte Gates bleiben boolesch. Autorisiert, auf Lager, bei Ankunft geöffnet und innerhalb des Servicegebiets sind Bedingungen, keine Gewichte. Semantische Signale können Scores bleiben und gelten für die Orte, die die Gates behalten haben. Dieselbe Trennung gilt für eine erforderliche Barrierefreiheitsregel oder eine Tenant-Grenze. Eine erforderliche Tatsache, die unbekannt ist, sollte unbekannt bleiben. Einen nicht verfügbaren Lookup als false zu behandeln, macht aus einer fehlenden Bestandsabfrage ein selbstsicheres „nicht auf Lager“ – ein anderer und schwerwiegenderer Fehler.

Warum ist „auf dem Weg“ keine Radius-Suche?

„In meiner Nähe“ und „auf meinem Heimweg“ beschreiben unterschiedliche Geometrie. Ein Radius um den Ursprung liefert Orte innerhalb einer Distanz zum Startpunkt, einschließlich Orten in der falschen Richtung. Eine Route-Corridor-Abfrage liefert Orte, die nur wenig Umweg zu einer Reise hinzufügen, die der Routing-Dienst bereits geplant hat. Luftlinienentfernung ist ein legitimer Filter, wenn die Frage tatsächlich radial ist. Sie ist die falsche Größe, wenn die Entscheidung von der Reise abhängt. Zwei Kilometer Luftlinie können eine lange Fahrt sein, und eine größere Luftlinie kann die kürzere Reise ergeben.

Das linke Panel zeigt einen einfachen Radius und Beispielapotheken innerhalb und außerhalb eines Ein-Meilen-Rings. Das rechte Panel folgt einer Beispielroute von der Arbeit nach Hause und beschriftet Apotheken mit Umwegminuten. Meilenwerte, Umwegminuten und Ortsnamen sind Beispielbeschriftungen, keine Live-Route. Der Punkt der Abbildung ist die Beziehung: Geringe Routenabweichung ist nicht dasselbe Prädikat wie ein Kreis um den Ursprung.

Der Routing-Dienst sollte den Umweg berechnen, und der Ranker sollte dieses Ergebnis erhalten. Ein Sprachmodell, das die Minuten schätzt, wird gelegentlich der Route widersprechen, die der Dienst gerade zurückgegeben hat. Der Routenaufruf gehört nach die Auflösung und nach die Kandidatenauswahl. Er ist keine Place Search, und ein fehlender Pfad sollte als sichtbarer Fehler bestehen bleiben statt als geschätzte Linie auf der Karte.

Wo passt Kaleidr in diese Pipeline?

Kaleidrs öffentliche Platform API stellt einen Forward-Geocode-Endpoint bereit, der für ein Suchfeld oder ein From/To-Feld gedacht ist, nicht für einen privaten Geschäftsindex. GET /retrieval/geocode/forward akzeptiert q als Ortsname, Straßenadresse mit Hausnummer oder eingegebenen Breiten- und Längengrad sowie optional near_lat und near_lng zusammen, limit und einen Reise-mode (Kaleidr, 2026). Dieselbe Referenz dokumentiert eine Route zwischen Koordinaten, die der Aufrufer bereits besitzt, mit Profilen für Fahren, Gehen, Radfahren und Transit. Eine Route, die nicht geplant werden kann, kommt mit erfolgreichem HTTP-Status und einem Fehler im Body zurück statt als Pfad. Ergebnisse enthalten Attribution, die der Aufrufer weitergeben muss, und ein Straßenadress-Ergebnis kann eine Kennung enthalten, die über Datenupdates hinweg stabil bleibt. Eine leere results-Liste bedeutet, dass nichts angezeigt werden kann – auch im Fall eines internen Lookup-Fehlers. Eine leere Liste ist daher kein Beweis, dass die Adresse ungültig ist.

Die dokumentierten Parameter enthalten keinen privaten Katalog des Kunden. Öffentliches Geocoding wird nicht dadurch zum Bestandssystem, dass es auf derselben Karte eingebunden ist. Ein Aufrufer, der private Filialen oder Bestand benötigt, muss diese Systeme direkt lesen und sie anschließend über eine stabile Kennung mit einem aufgelösten Ort verbinden. Die Geocode-Antwort ist das öffentliche Subjekt, und der Geschäftsdatensatz bleibt der Geschäftsdatensatz.

Für Place Detail gibt es einen aktuellen Nachfolger, und der ältere Pfad sollte nicht die Grundlage einer neuen Integration sein. Die Endpoint-Referenz markiert GET /retrieval/poi/enrich als veraltet und verweist neue Arbeit auf POST /spot, das beantwortet, was sich an einem Punkt befindet, und beschreibende Inhalte und Fotos hinzufügen kann. Die veraltete Route kann nach dem 2027-01-15 entfernt werden.

Anreicherung entscheidet weiterhin nicht über private Zulässigkeit. Öffnungszeiten, Fotos und eine Kategorie aus einer öffentlichen Quelle sind öffentliche Fakten mit der von dieser Quelle verlangten Attribution. Bestand, Kontoberechtigung und ein vom Kunden gezeichnetes Servicegebiet bleiben in den Systemen, denen sie gehören. Grounded Spatial AI for Business Data ist der Leitfaden für diese Grenze.

Die linke Spalte trennt Adressen und benannte Orte von privaten Filialen, Bestand und Servicegebieten. Die mittlere Spalte nennt Kaleidr Forward Geocoding, einen Place-Detail-Schritt sowie die eigene räumliche Datenbank und Geschäftssysteme des Hosts. Die Place-Detail-Box ist die Aufgabe, die jetzt als POST /spot dokumentiert ist. Der ältere Enrich-Endpoint ist der veraltete Vorgänger, nicht die Integration, mit der begonnen werden sollte. Die rechte Spalte zeigt, was nach dem Retrieval passiert: eine Route zwischen bekannten Koordinaten, ein Ranking zulässiger Orte, eine Erklärung und eine Kartenaktion. Die Warnung in der Abbildung entspricht der Endpoint-Referenz. Eine öffentliche Geocode- oder Place-API indiziert nicht die privaten Standorte, Bestände oder Servicegebiete des Aufrufers.

Organisationsspezifische Daten folgen der Plangrenze, nicht der Karte. Kaleidrs Kontodokumentation sagt, dass das Hochladen eigener Geschäftsdaten einer Organisation für KI-Antworten nur in Enterprise verfügbar ist und dass auch der Key-Scope, mit dem Antworten diese hochgeladenen Daten verwenden können, nur in Enterprise verfügbar ist (Kaleidr, 2026). Die aktuelle öffentliche Endpoint-Referenz dokumentiert keinen allgemeinen Vector-Search-Endpoint. Ein Team, das semantisches Retrieval über eigene Beschreibungen braucht, sollte diesen Index als Teil des Host- oder Enterprise-Designs behandeln und den aktuellen Vertrag bestätigen, statt einen Pfad aufzurufen, den dieser Artikel nicht zitiert. Wie man einen map-aware KI-Assistenten baut behandelt die Kartenaktionen nach einer validierten Ortskennung.

Was sollte ein Team getrennt messen?

Jede Schicht scheitert auf ihre eigene Weise, und ein einzelner Relevanzscore verdeckt, welche Schicht versagt hat. Geocoding scheitert an einer mehrdeutigen Adresse, einer fehlenden Einheit, vertauschten Koordinate oder einem Match nur auf Straßenebene. Place Search scheitert, wenn Abdeckung, Kategorie oder Aktualität des Anbieters nicht zum Produkt passen. Eine räumliche Abfrage scheitert an ungültiger Geometrie, einem nicht passenden Koordinatenbezug oder einem Polygon, das nicht mehr zur Operation passt.

Vektorsuche scheitert an schwachem Embedding, veraltetem Text oder einem approximativen Index, der nach einem Filter zu wenig zurückgibt. Geschäftsdaten scheitern, wenn Bestand unbekannt, der Datensatz nicht autorisiert oder die Öffnungszeiten veraltet sind. Ein nützliches Log benennt die Schicht. „Search failed“ tut das nicht.

Bewerte die Schicht anhand ihrer Aufgabe und dann die Entscheidung. Geocoding braucht Match-Qualität und stabile Kennungen. Place Search braucht Kandidaten-Recall, Kategoriepräzision und eine Quote veralteter Orte. Räumliche Abfragen brauchen geometrische Korrektheit und Belege dafür, dass die Abfrage den Index verwendet hat. Vektorsuche braucht semantische Relevanz und gefilterten Recall gegenüber einer Exact-Search-Baseline. Die End-to-End-Prüfung fragt, ob ein zulässiger Ort abgerufen wurde, ob „kein Ergebnis“ das ehrliche Resultat war und ob die Aktion die Kennung verwendete, die die Filter freigegeben hatten. Ein Autorisierungs- oder Containment-Fehler sollte nicht in einer durchschnittlichen Click-through-Rate verschwinden.

Wo sollte der Stack beginnen?

Wähle die Methode, die die vom Nutzer gestellte Klausel beweisen kann. Geocoding beweist, wo ein Subjekt ist. Place Search beweist, welche bekannten Orte in diesem Index zu Text, Kategorie oder Gebiet passen. Eine räumliche Abfrage beweist eine geometrische Beziehung über Datensätze, die die Anwendung hält. Vektorsuche beweist Bedeutungsähnlichkeit – und nur innerhalb der Menge, die harte Filter behalten haben. Geschäftssysteme beweisen die aktuelle Tatsache. Ein Routing-Dienst beweist die Reise. Ein Ranker ordnet, was übrig bleibt. Das Sprachmodell erklärt dieses Ergebnis und sollte nicht die Quelle für Distanz, Containment-Test oder Bestandszahl sein.

Öffentliche Ortsdaten sind die richtige Quelle, wenn öffentliche Entdeckung die Aufgabe ist. Private Filialen, Bestand und Zulässigkeit bleiben in den Systemen, denen sie gehören; stabile Kennungen verbinden den Anbieterort, den Bestandsstandort und den Kartenmarker. Semantische Ähnlichkeit hebt keine geografische Grenze auf, und ein Radius beantwortet keine „auf dem Weg“-Frage. Erkunde Kaleidr Enterprise, wenn Retrieval auf organisationsspezifischen Daten laufen muss, und lies die Platform API endpoints für die oben zitierten Verträge zu Forward Geocode, Spot und Route.

Hinweis: Kaleidr verwendet KI-gestützte Tools für Bilderstellung, Inhaltsverfeinerung und Recherche in seinen kreativen und Entwicklungs-Workflows.

FAQs

Was ist der Unterschied zwischen Geocoding und Place Search?

Geocoding löst eine Adresse, eine Koordinate oder eine bekannte Ortsreferenz in eine geografische Identität auf. Place Search entdeckt Unternehmen, Sehenswürdigkeiten, Stationen und andere benannte Orte, die zu Text, Kategorie oder Nearby-Gebiet passen. Das eine liefert ein Subjekt. Das andere liefert Kandidaten.

Ist Point-of-Interest-Suche dasselbe wie Geocoding?

Nein. Manche Anbieter-APIs können sowohl eine Adresse als auch eine Place-Anfrage akzeptieren. Im Gegensatz dazu stellt Mapbox' Geocoding v6 API überhaupt keine Point-of-Interest-Daten mehr bereit. Point-of-Interest-Suche entdeckt Kandidaten. Geocoding löst einen Ort auf.

Was ist eine räumliche Abfrage?

Eine räumliche Abfrage filtert geografische Datensätze nach einer Geometriebeziehung wie innerhalb einer Distanz, innerhalb eines Polygons, schneidet oder nächster Nachbar. Die Datensätze und ihre Geometrie gehören bereits zur Anwendung. Das Prädikat ist deterministisch.

Was ist Vektorsuche?

Vektorsuche ruft Datensätze ab, deren Embeddings nahe am Query-Embedding liegen. Die Methode ist nützlich für Bedeutung und Formulierungen, die nicht mit dem Quelltext übereinstimmen. Sie beweist weder Distanz noch Containment noch Zulässigkeit.

Kann Vektorsuche eine räumliche Abfrage ersetzen?

Nein. Ähnlichkeit in einem Embedding-Raum beweist weder geografische Distanz noch Containment, Routenpassung oder Zugehörigkeit zu einem Servicegebiet. Verwende ein räumliches Prädikat für geografische Wahrheit und Vektorsuche für semantische Relevanz innerhalb der Menge, die dieses Prädikat erlaubt.

Sollte Geografie die Menge vor der Vektorsuche filtern?

Ja, wenn Geografie eine harte Grenze ist. Einen globalen Embedding-Index zu durchsuchen und erst danach den Standort auf einer kurzen Liste zu prüfen, kann gültige lokale Orte verwerfen, die nie in diese Liste gelangt sind. Datenbank und Index bestimmen die Implementierung. Die Grenze bleibt bestehen.

Sollte ein Team vor einer Nearby-Suche geocodieren?

Ja, wenn der Anker eine Adresse oder ein anderer noch nicht aufgelöster Ort ist. Löse den Anker auf und führe dann Place Retrieval oder eine räumliche Abfrage um den aufgelösten Punkt aus. Eine Kategoriesuche ohne Anker ist bereits eine Place-Search-Frage.

Sollte ein Produkt eine Places API oder seine eigene Datenbank verwenden?

Verwende eine Places API für öffentliche Discovery, wenn Abdeckung, Lizenz und Attribution zum Produkt passen. Verwende die eigene Produktdatenbank für First-Party-Filialen, Bestand, private Einrichtungen, Zulässigkeit und aktuellen Geschäftsstatus. Ein öffentlicher Place-Datensatz kann eine Filiale identifizieren. Er sollte nicht die Autorität dafür sein, was diese Filiale heute auf Lager hat.

Was ist hybride Standortsuche?

Hybride Standortsuche kombiniert zwei oder mehr dieser Methoden für eine Entscheidung. Eine typische Kette löst einen Anker auf, ruft Place-Kandidaten ab, wendet ein räumliches Prädikat und eine Geschäftsregel an und rankt anschließend eine semantische Präferenz innerhalb der zulässigen Menge. Das Sprachmodell erklärt die verbleibenden Kandidaten.

Dokumentiert Kaleidr einen öffentlichen Vector-Search-Endpoint?

Die hier zitierte Platform-API-Endpoint-Referenz dokumentiert keinen allgemeinen Vector-Search-Endpoint. Die in diesem Artikel verwendeten dokumentierten Retrieval-Oberflächen sind Forward Geocoding, POST /spot für das, was sich an einem Punkt befindet, und der Route-Aufruf zwischen bereits bekannten Koordinaten. Bestätige den aktuellen Enterprise-Vertrag, bevor ein semantischer Index in einen Produktplan eingebaut wird.

References

1. Google Maps Platform. Geocoding API overview. The service accepts an address, coordinates, or a Place ID, and converts an address into coordinates and a Place ID, or coordinates or a Place ID into an address. Accessed October 27, 2026. https://developers.google.com/maps/documentation/geocoding/overview
2. Google Maps Platform. Geocoding API v4 overview. Documents forward geocoding, reverse geocoding, place geocoding, and destination search, and separates generally available, preview, and experimental channels. Accessed October 27, 2026. https://developers.google.com/maps/documentation/geocoding/geocoding-v4-overview
3. Mapbox. Geocoding API. Forward and reverse geocoding. The Geocoding v6 API no longer provides point-of-interest data and directs that job to the Search Box API. Accessed October 27, 2026. https://docs.mapbox.com/api/search/geocoding/
4. Mapbox. Search Box API. Interactive and stand-alone search for addresses, places, and points of interest, including category search. Accessed October 27, 2026. https://docs.mapbox.com/api/search/search-box/
5. Google Maps Platform. Text Search (New). Returns places for a text string. Documented examples include "shoe stores near Ottawa" and "123 Main Street." Accessed October 27, 2026. https://developers.google.com/maps/documentation/places/web-service/text-search
6. Google Maps Platform. Nearby Search (New). Takes one or more place types and returns matching places within a specified area. Accessed October 27, 2026. https://developers.google.com/maps/documentation/places/web-service/nearby-search
7. PostGIS. ST_DWithin. Tests whether two geometries are within a given distance. The call includes a bounding-box comparison that uses available spatial indexes. Geography distance is in meters. Accessed October 27, 2026. https://postgis.net/docs/ST_DWithin.html
8. PostGIS. ST_Within. Tests whether every point of one geometry lies in another and the interiors share a point. The function uses available spatial indexes. Accessed October 27, 2026. https://postgis.net/docs/ST_Within.html
9. pgvector. pgvector. Exact and approximate nearest-neighbor search in Postgres, including HNSW and IVFFlat indexes, cosine and other distances, and iterative scans when a filter leaves too few approximate results. Accessed October 27, 2026. https://github.com/pgvector/pgvector
10. Kaleidr Developer Docs. Platform API endpoints. Documents forward geocoding for a search box or From/To field, POST /spot as the successor to the deprecated POI enrich endpoint, and a route call between known coordinates. Accessed October 27, 2026. https://docs.kaleidr.com/platform-api/endpoints
11. Kaleidr. Place Ranking API for Customer Intent. Hard filters such as authorization, availability, required capability, and service area run before scoring. Accessed October 27, 2026. https://kaleidr.com/blog/place-ranking-api
12. Kaleidr Developer Docs. How Kaleidr works. Uploading an organization's own business data for AI answers is Enterprise only, as is the key scope that lets answers draw on that data. Accessed October 27, 2026. https://docs.kaleidr.com/concepts/how-kaleidr-works
13. Kaleidr. Plot Places on a Map. A related guide for turning resolved places into markers. Accessed October 27, 2026. https://kaleidr.com/blog/plot-places-on-a-map
14. Kaleidr. How to Build a Nearby Places Map for Near Me Search. A related guide for nearby discovery. Accessed October 27, 2026. https://kaleidr.com/blog/how-to-build-a-nearby-places-map-for-near-me-search
15. Kaleidr. Spatial Context Engineering for Map-Aware AI. A related guide for what reaches the model after retrieval. Accessed October 27, 2026. https://kaleidr.com/blog/spatial-context-engineering
16. Kaleidr. Grounded Spatial AI for Business Data. A related guide for keeping business facts in the systems that own them. Accessed October 27, 2026. https://kaleidr.com/blog/grounded-spatial-ai-business-data
17. Kaleidr. Map-Aware AI Assistant: How to Build One. A related guide for map actions around a validated place. Accessed October 27, 2026. https://kaleidr.com/blog/how-to-build-a-map-aware-ai-assistant

References in BibTeX

@misc{google_geocoding_overview_2026,
  title  = {Geocoding API overview},
  author = {{Google Maps Platform}},
  year   = {2026},
  url    = {https://developers.google.com/maps/documentation/geocoding/overview}
}

@misc{google_geocoding_v4_overview_2026,
  title  = {Geocoding API v4 overview},
  author = {{Google Maps Platform}},
  year   = {2026},
  url    = {https://developers.google.com/maps/documentation/geocoding/geocoding-v4-overview}
}

@misc{mapbox_geocoding_api_2026,
  title  = {Geocoding API},
  author = {{Mapbox}},
  year   = {2026},
  url    = {https://docs.mapbox.com/api/search/geocoding/}
}

@misc{mapbox_search_box_api_2026,
  title  = {Search Box API},
  author = {{Mapbox}},
  year   = {2026},
  url    = {https://docs.mapbox.com/api/search/search-box/}
}

@misc{google_places_text_search_2026,
  title  = {Text Search (New)},
  author = {{Google Maps Platform}},
  year   = {2026},
  url    = {https://developers.google.com/maps/documentation/places/web-service/text-search}
}

@misc{google_places_nearby_search_2026,
  title  = {Nearby Search (New)},
  author = {{Google Maps Platform}},
  year   = {2026},
  url    = {https://developers.google.com/maps/documentation/places/web-service/nearby-search}
}

@misc{postgis_st_dwithin_2026,
  title  = {ST_DWithin},
  author = {{PostGIS}},
  year   = {2026},
  url    = {https://postgis.net/docs/ST_DWithin.html}
}

@misc{postgis_st_within_2026,
  title  = {ST_Within},
  author = {{PostGIS}},
  year   = {2026},
  url    = {https://postgis.net/docs/ST_Within.html}
}

@misc{pgvector_2026,
  title  = {pgvector},
  author = {{pgvector}},
  year   = {2026},
  url    = {https://github.com/pgvector/pgvector}
}

@misc{kaleidr_platform_api_endpoints_2026,
  title  = {Platform API endpoints},
  author = {{Kaleidr}},
  year   = {2026},
  url    = {https://docs.kaleidr.com/platform-api/endpoints}
}

@misc{kaleidr_place_ranking_api_2026,
  title  = {Place Ranking API for Customer Intent},
  author = {{Kaleidr}},
  year   = {2026},
  url    = {https://kaleidr.com/blog/place-ranking-api}
}

@misc{kaleidr_how_kaleidr_works_2026,
  title  = {How Kaleidr works},
  author = {{Kaleidr}},
  year   = {2026},
  url    = {https://docs.kaleidr.com/concepts/how-kaleidr-works}
}