Wer schon einmal versucht hat, in FileMaker mit vielen Adressen eine Route über die Google Maps API zu planen, kennt das Problem. Ab einer gewissen Anzahl von Stopps schnellen die Kosten nach oben und die Performance leidet. Aber genau hier setzt mein Ansatz an: -Clustering-.

Warum Clustering?

Google erlaubt pro Request in der Directions API nur 25 Zwischenstopps (plus Start und Ziel). Mehr geht nicht. Mit 80 Kundenadressen wären das also drei bis vier Requests, wenn man clever plant.

Ohne Clustering würde man mit der Distance Matrix API schnell in den vierstelligen Bereich an Elementen kommen (80 × 80 = 6.400), die abgerechnet werden. Mit Clustering dagegen, vier kleine Matrizen a 20 × 20 = 400. Macht in Summe 1.600. Das sind 75 % weniger Kosten und dazu deutlich weniger Wartezeit.

1.	Geocoding – jede Adresse bekommt saubere Koordinaten.
2.	K-Means Clustering – die Adressen werden nach geografischer Nähe in Gruppen aufgeteilt (z. B. vier Cluster mit je 20 Stopps).
3.	Optimierung je Cluster – innerhalb des Clusters wird die Reihenfolge berechnet.
4.	Routes API – für jedes Cluster wird die Route berechnet, nie mehr als 25 Stopps.
5.	FileMaker-Integration – die Ergebnisse landen als einfache JSON-/GET-Antwort wieder in FileMaker, wo sie importiert und angezeigt werden können.

Das Ganze läuft mit Session-IDs, sodass FileMaker volle Kontrolle über den Ablauf hat und wir persistente Daten auch später noch abrufen können.

Demo-Daten für den Praxistest

Für das nächste FileMaker-Magazin haben wir Demo-Daten vorbereitet: • 80 Adressen im Raum Berlin/Brandenburg (kann natürlich geändert werden) • passende Kontaktdaten • und natürlich die fertige Clusterlösung

Damit kann jeder sofort ausprobieren, wie aus einer unübersichtlichen Masse von Stopps überschaubare Touren werden.