Płacisz za każdą trasę i każdy adres. Czy musisz?

Jak w transporcie zastąpiliśmy płatne API tras własnym silnikiem open source — i gdzie jeszcze da się to zrobić.

Jeden z operatorów transportowo-logistycznych, z którymi pracujemy, płacił za routing ciężarówek ponad 1000 € miesięcznie. Nie za żadną wyjątkową funkcję — za to, że system wyceny i planowania pytał zewnętrzne API o trasę za każdym razem, gdy ktoś zmienił punkt załadunku, kolejność przystanków albo pojazd.

Taki rachunek ma jedną cechę: rośnie razem z biznesem. Więcej wycen, więcej planów, więcej zmian — więcej zapytań. A to oznacza, że im lepiej Ci idzie, tym drożej płacisz za coś, co w gruncie rzeczy jest obliczeniem na danych, które i tak są publiczne.

Skąd taki rachunek

Płatne API map liczą za zapytanie, zwykle za 1000 zapytań po przekroczeniu darmowego limitu. W systemie, który planuje trasy na bieżąco, zapytań jest dużo:

każda wycena to przynajmniej jedna trasa,
każda zmiana w planie przelicza trasy ponownie,
optymalizacja wielu pojazdów potrzebuje całych macierzy czasów przejazdu.

Prosty rachunek — liczba zapytań × cena za 1000 — pokazuje, że przy kilkudziesięciu tysiącach zapytań miesięcznie koszt zaczyna być istotną pozycją budżetu.

Co zrobiliśmy

Zamiast płacić za każde zapytanie, postawiliśmy własny silnik routingu: Valhalla — open source'owy silnik tras oparty na danych OpenStreetMap. Działa jako jedna usługa w tym samym klastrze co reszta systemu. Aplikacja pyta ją tak samo, jak wcześniej pytała zewnętrzne API, więc zmiana w kodzie była niewielka: nowy klient, pamięć podręczna wyników i obsługa błędów.

Efekt:

koniec opłat za zapytanie — koszt to utrzymanie jednej małej usługi,
brak zależności od dostawcy — nikt nie zmieni cennika ani nie wyłączy starej wersji API,
dane zostają u klienta — współrzędne ładunków i klientów nie wychodzą poza jego infrastrukturę.

Liczby z praktyki

Mierzyliśmy to na produkcji, nie w laboratorium:

ok. 65 ms na jeden odcinek trasy, a przy powtarzających się odcinkach odpowiedź z pamięci podręcznej trwa praktycznie 0 ms;
ranking 15 propozycji terminów według rzeczywistego czasu dojazdu: ok. 1,4 s przy pustej pamięci, natychmiast przy kolejnym otwarciu;
usługa zajmuje ok. 250 MB RAM;
zgodność z Google Maps: na próbie rzeczywistych tras mediana odległości wyszła 1,03× względem najlepszej trasy Google, a 8 z 13 tras mieściło się w ±5%. Różnice wynikają zwykle z tego, że Google wybiera inną trasę przez bieżący ruch. Dla wycen wystarczył niewielki margines (7%).

To dobra jakość do wycen, planowania i szacowania kosztów dojazdu.

Gdzie jeszcze Valhalla się sprawdza

Transport to dopiero początek. Wszędzie, gdzie potrzebujesz czasu lub odległości dojazdu, własny silnik może zastąpić płatne API:

Serwis terenowy — kolejność wizyt techników według faktycznego czasu dojazdu, a nie odległości w linii prostej. Proponowane terminy dopasowują się do trasy dnia.
Dostawy i planowanie tras — macierze czasów przejazdu dla optymalizatora (solvera) i okna dostaw.
Wyceny i rozliczenia — automatyczne kilometry dojazdu do klienta.
Zasięg obsługi — obszary dojazdu (izochrony): „co obsłużymy w 60 minut od oddziału”.
Instalacje on-premise — gdy system działa u klienta, często bez dostępu do internetu, zewnętrzne API w ogóle nie wchodzi w grę.

Geokodowanie też możesz mieć u siebie

Trasa to tylko część historii. Zanim system obliczy trasę, musi zamienić adres na współrzędne — to geokodowanie, i też zwykle jest płatne.

Te same dane OpenStreetMap obsługuje Nominatim, open source'owy geokoder. W jednym z naszych projektów budujemy mapę, trasy i geokodowanie z jednego ekstraktu OSM, więc kafelki mapy, trasy i adresy pochodzą z tego samego stanu danych i są ze sobą spójne. Geokodowanie działa w tle, kolejką — zlecenie zapisuje się od razu, a punkt na mapie dochodzi chwilę później, więc awaria geokodera nie blokuje pracy.

Dwie korzyści poza kosztem:

prywatność — adresy Twoich klientów nie trafiają do zewnętrznego dostawcy,
praca offline — całość da się uruchomić na serwerze bez dostępu do internetu.

Uczciwie: w małych miejscowościach OpenStreetMap bywa niekompletny — brakuje numerów domów. Wtedy wynik jest oznaczony jako przybliżony, a biuro może ustawić punkt ręcznie.

Kiedy to się nie opłaca

Własny silnik nie jest rozwiązaniem na wszystko. Zostań przy płatnym API, jeśli:

potrzebujesz ruchu drogowego na żywo — nasz silnik liczy czasy z danych OSM, bez natężenia ruchu;
potrzebujesz kwot myta dla ciężarówek — w jednym z projektów nadal korzystamy z HERE właśnie do tego, bo to funkcja, której darmowe silniki nie zastąpią;
wolumen zapytań jest mały — przy kilku tysiącach zapytań miesięcznie darmowy limit dostawcy zwykle wystarcza;
nie masz kto tego utrzymać — dane map trzeba odświeżać (my robimy to ręcznie, kilka razy w roku), a usługę monitorować.

Przy dużym wolumenie zapytań i potrzebie czasu dojazdu, odległości lub adresów rachunek zwykle wygląda odwrotnie.

Co z tego wynika

Jeśli płacisz za mapy tysiące euro rocznie, warto zadać trzy pytania:

Ile zapytań wysyłamy miesięcznie i ile za nie płacimy?
Czy potrzebujemy ruchu na żywo i myta, czy wystarczy czas dojazdu i odległość?
Czy dane o adresach i trasach mogą wychodzić poza naszą infrastrukturę?

Jeśli odpowiedzi wskazują, że własny silnik mógłby się opłacić — chętnie pomożemy to policzyć, a w razie potrzeby wdrożyć.