Gleiche Kachelspezifikation, andere Rechnung.
Vektorkacheln folgen derselben MVT-Spezifikation und das Stildokument demselben Schema, sodass die Rendering-Seite mit einer Umbenennung umzieht. Such- und Routing-Antworten unterscheiden sich stärker als die Kacheln.
- MVT- und stilspezifikationskompatibel: Ihr Renderer bleibt
- Isochrone bildet direkt auf Isochronen ab, inklusive Verbrauchsbereichen
- Lkw-Profile enthalten statt in einer separaten Produktstufe
- Veröffentlichte Tarife statt gestaffelter Kartenaufruf-Pakete
Der Tausch
Host und Auth-Header. Alles darunter ist die Parameterzuordnung.
- https://api.mapbox.com?access_token=YOUR_TOKEN
+ https://api.apinavi.com
+ Authorization: Bearer $APINAVI_KEYParameterzuordnung
Search & navigation
| Mapbox | ApiNavi | Note |
|---|---|---|
| GET /geocoding/v5/mapbox.places/{q}.json | GET /v1/geocode?q= | — |
| GET /search/geocode/v6/reverse | GET /v1/revgeocode?at= | — |
| features[].place_name | items[].address.label | — |
| features[].center [lng,lat] | items[].position {lat,lng} | Axis order differs: GeoJSON positions are lng-first, our object is keyed. |
| GET /directions/v5/mapbox/driving | GET /v1/routes?transportMode=car | — |
| GET /directions-matrix/v1 | POST /v1/matrix | — |
| GET /isochrone/v1 | GET /v1/isolines | — |
Tiles & styles
| Mapbox | ApiNavi | Note |
|---|---|---|
| GET /v4/{tileset}/{z}/{x}/{y}.mvt | GET /v1/tiles/vector/{z}/{x}/{y}.mvt | — |
| GET /styles/v1/{user}/{style} | GET /v1/styles/{style} | Style JSON follows the same spec; layer ids differ. |
| GET /styles/v1/.../static/ | GET /v1/static | — |
Wo es kein Eins-zu-eins-Tausch ist
Achsenreihenfolge
Mapbox liefert center als [lng, lat]. Unsere position ist ein Objekt mit lat- und lng-Schlüsseln, was die Mehrdeutigkeit beseitigt, aber einen kleinen Adapter braucht.
Ebenen-IDs im Stil
Beide folgen der Stilspezifikation, die Ebenen-IDs unterscheiden sich jedoch. Ein Fork eines Mapbox-Stils braucht neu zugeordnete IDs — die Entsprechungen stehen in der Doku.
Objekt-IDs
Mapbox-Objekt-IDs sind über Datenaktualisierungen hinweg nicht stabil und mit unseren nicht austauschbar. Gespeicherte Verweise neu auflösen.
Clientseitiges Navigations-SDK
Wir liefern Routing-APIs, kein Turn-by-turn-Navigations-SDK mit Sprachansagen. Diese Ebene bleibt bei Ihnen oder bei ihnen.
Wie Teams das üblicherweise machen
- 01
Schatten
Eine Woche lang eine Kopie des Produktivtraffics an beide senden. Für Nutzer ändert sich nichts.
- 02
Vergleich
Feld für Feld auf den Endpunkten vergleichen, die Sie wirklich nutzen. Meist finden Teams zwei oder drei echte Unterschiede, nicht zwanzig.
- 03
Aufteilen
5 % umlegen, dann 50 %, dabei Fehlerrate und Latenz je Region beobachten.
- 04
Umstellen
Den Rest umlegen, den alten Schlüssel zwei Wochen aktiv lassen, dann rotieren.
Parallelbetrieb
Schicken Sie einen Prozentsatz des Traffics an beide Anbieter und vergleichen Sie die Antworten. Die Konsole zeigt die Abweichungsraten je Feld und Endpunkt, sodass Sie auf Basis von Belegen umstellen statt auf Stichproben.
Später wieder gehen
Dieselben Tabellen liest man rückwärts, und ein Export-Endpunkt gibt Ihre Geofences, Stile und Batch-Ergebnisse in offenen Formaten zurück. Ein Migrationsleitfaden, der nur nach innen zeigt, ist ein Warnzeichen, kein Feature.
Checkliste für die Umstellung
- Rate-Limits auf dem neuen Schlüssel vor der Aufteilung angehoben, nicht danach
- Ausgabenlimit für den ersten vollen Monat gesetzt
- Gespeicherte Orts-IDs neu aufgelöst, falls Sie sie speichern
- Polyline-Decoder an einer bekannten Route geprüft
- Abdeckung für die Länder im langen Schwanz Ihres Traffics geprüft
- Alter Schlüssel rotiert und aus den Secrets entfernt