Migration

Migration von LocationIQ

LocationIQ positioniert sich über offene Geodaten und ein einfaches schlüsselbasiertes Authentifizierungsmodell, bei dem der Schlüssel als Query-Parameter gesendet wird. Die JSON-Antworten enthalten lat, lon, display_name und ein address-Objekt, das in Felder aufgeteilt ist, die jedem vertraut sind, der auch direkt mit aus OpenStreetMap abgeleiteten Daten gearbeitet hat. Diese Vertrautheit ist kein Zufall: Anbieter, die auf offenen Datenquellen aufbauen, nähern sich oft ähnlichen Feldnamen an. Das ist gut zu wissen, wenn Sie mehrere Anbieter gleichzeitig vergleichen.

Teams, die sich für LocationIQ entschieden haben, taten das oft wegen der Kombination aus einem großzügigen Einstieg und einer unkomplizierten Integration, ohne zuerst einen Enterprise-Vertrag aushandeln zu müssen. Eine Migration sollte diese Erfahrung idealerweise bewahren, statt sie gegen ein aufwendigeres Onboarding einzutauschen.

Der LocationIQ-Kompatibilitäts-Host von My Geocode bildet die Felder lat, lon, display_name sowie die Adresskomponenten exakt nach. Lediglich die Hinweise zu Urheberrecht, Nutzungsbedingungen und Datenschutz unterscheiden sich vom Original. Details finden Sie unter /compatibility/locationiq/. Anwendungscode, der response.display_name liest oder über die Felder von response.address iteriert, sollte außer beim Host-Namen und beim Schlüssel keine Änderungen benötigen.

Eine kurze Checkliste für genau diesen Umstieg:

  • Prüfen Sie, welche Authentifizierungsmethode Ihre Client-Bibliothek heute verwendet (LocationIQ akzeptiert in der Regel einen Query-Parameter), und gleichen Sie sie mit den vier hier unterstützten Varianten ab: X-API-Key-Header, Authorization: Bearer, HTTP Basic Auth oder ein Query-Parameter
  • Prüfen Sie, ob Ihre Integration auch einen Endpunkt für Reverse-Geokodierung aufruft, da sich die Form der Anfrage dort von der normalen Geokodierung unterscheidet und einen eigenen Test wert ist
  • Überprüfen Sie jeglichen Code zur Behandlung von Ratenlimits, den Sie speziell für die Antwort-Header von LocationIQ geschrieben haben, da sich die Header-Namen zwischen Anbietern unterscheiden und Ihre Retry-Logik sie möglicherweise namentlich referenziert

Beim Preis ist der Vergleich recht direkt: Für 2.500 Anfragen pro Tag ist überhaupt kein Schlüssel nötig, und pro Schlüssel kommen täglich 2.500 weitere kostenlose Anfragen hinzu, gezählt pro Netzwerk, ob IPv4 (pro /24) oder IPv6 (pro /48). Jenseits des kostenlosen Kontingents gibt es Prepaid-Guthaben zu 0,0001 € pro Anfrage oder einen Unlimited-Schlüssel zu 50 € pro Monat, und jeder Endpunkt kostet gleich viel, ohne eigene Stufe für Geokodierungsvolumen im Vergleich zu anderen Abfragen.

Wenn Ihre Nutzung von LocationIQ organisch aus einem Nebenprojekt zu etwas gewachsen ist, auf das sich Menschen verlassen, dann soll ein Kompatibilitäts-Host genau diese Art von Migration im besten Sinne langweilig machen: Host-Namen ändern, Schlüssel ändern und weiter ausliefern. Der Parsing-Code, der beim ersten Mal Zeit gekostet hat, braucht keine zweite Runde, nur weil der Anbieter dahinter gewechselt hat. Volle Transparenz über das Kontingent, einschließlich der Nutzung pro Netzwerk, liefern die Standard-Antwort-Header, die unter /docs/rate-limits/ dokumentiert sind.