Alteryx biedt veel mogelijkheden op het gebied van geografische bewerkingen, waaronder het berekenen van (hemelsbrede) afstanden, oppervlaktes, het bouwen van trade areas, het creëren van polygonen, etc. Optioneel kun je hierbij nog een Alteryx Spatial pack aanschaffen, wat een uitbreiding is met Tom Tom data. Deze dataset kun je dan direct koppelen met Alteryx, wat het mogelijk maakt om afstanden te berekenen op basis van reistijden (in plaats van hemelsbrede afstanden) en ook om trade-areas te creëren op basis van deze reistijden (geef mij het gebied wat ik kan bereizen binnen 30 minuten vanaf mijn vertrekpunt). Dit kan voor o.a. logistiek dienstverleners een noodzakelijke toevoeging zijn. Het probleem hierbij is dat dit optionele pakket slechts beschikbaar is voor de VS, het VK en Canada en dus (nog?) niet voor Nederland en de rest van de wereld (is Tom Tom niet een Nederlands bedrijf?). In deze blog zoeken we naar een oplossing voor dit probleem.
Google Distance Matrix API
Alteryx zou Alteryx echter niet zijn, als we daar zelf niet iets voor zouden kunnen verzinnen. Nu zijn er ruimschoots aanbieders te vinden van exacte reistijden, gegeven vertrek- en eindpunten, veelal betaalde pakketten. De Google Distance Matrix API biedt een alternatief. Hierbij voer je in een URL een of meerdere vertrekpunten en eindpunten in en krijg je als resultaat in JSON formaat de reistijden en –afstanden. De gebruiker moet een betaalaccount aanmaken waar elke maand een budget tot 200$ wordt aangevuld door Google. Per 1000 elementen betaald men 5$. Met die 200$ die Google dus elke maand op je rekening stort kan je dan “gratis” 40,000 elementen downloaden. Hierbij staat een element gelijk aan een afstand tussen één vertrekpunt en één eindpunt.
*In je account kan je een limiet plaatsen die ervoor zorgt dat je niet over de grens van 40.000 gaat.
Ondanks de beperking in het aantal afstanden, kan dit toch bruikbaar genoeg zijn voor een aantal business cases. Vandaar dat we dit in Alteryx hebben gebouwd in de vorm van een macro. Simpel gezegd geeft deze macro, gegeven een lijst van vertrekpunten en een lijst van eindpunten, als resultaat de reistijden en reisafstanden tussen al deze punten. Zonder de macro gedetailleerd te beschrijven, kan ik zeggen dat de macro rekening houdt met het maximum aantal elementen per seconde en dat vervolgens het gedownloade JSON bestand wordt ontleed, zodat er twee kolommen worden toegevoegd met reistijden en reisafstanden.
Ook heb ik een macro Google Geocoding toegevoegd die adressen omzet in latitude en longitude coordinaten. Hierbij is gebruik gemaakt van de Google Geocoding API, die onder hetzelfde budget aangeroepen wordt.
Business case 1: Dekking aantal inwoners per ijsbaan in Nederland
Nu willen we een antwoord op de volgende business case: Gegeven een lijst met alle ijsbanen in Nederland, wat is de dekking per ijsbaan als we kijken naar het aantal inwoners van Nederland per postcode en aangenomen dat iemand voor de dichtstbijzijnde (op basis van reisafstanden) ijsbaan kiest om te schaatsen? We hebben data van inwoners van Nederland per viercijferige postcode (inclusief polygonen) en een lijst van alle 25 ijsbanen van Nederland, inclusief adres. Als we nu het middelpunt van elke postcode als gemiddelde nemen, komen we al snel uit op het moeten berekenen van ruim 4,000 postcodes x 25 ijsbaanlocaties = meer dan 100,000 afstanden. Hiervoor zouden we 3 maanden geduld moeten hebben, wat niet wenselijk is. Dus we kiezen ervoor om te generaliseren naar driecijferige postcodes. Nu hebben we zo’n 800 vertrekpunten en 25 eindpunten. Om dit nog wat te optimaliseren, kiezen we ervoor om eerst alle afstanden te berekenen op basis van hemelsbrede afstanden en vervolgens van de drie dichtstbijzijnde ijsbanen per postcodegebied de daadwerkelijk reistijden te berekenen, om uiteindelijk per postcodegebied te kunnen bepalen welke ijsbaan het dichtstbij ligt. Het resultaat ziet er in Tableau als volgt uit:
We zien hier de kaart van Nederland, gevuld met polygonen van driecijferige postcodegebieden met de bijbehorende dichtstbijzijnde ijsbaan, als ware de dekking per ijsbaan. Per postcodegebied kun je ook de reistijden, reisafstanden en hemelsbrede afstanden vinden. Ook vinden we in het staafdiagram rechtsboven de dekking in aantal inwoners en percentage van totaal aantal inwoners per ijsbaan. Hieruit kunnen we dus concluderen dat op basis van deze gegevens de ijsbaan Triavium in Nijmegen potentieel de grootste dekking heeft. Ten slotte vinden we rechtsonder nog de dekking voor een geselecteerde ijsbaan, waarbij de intensiteit van de kleur iets over de reistijd zegt (hoe donkerder, hoe verder weg). Deze informatie zou verder gebruikt kunnen worden om te bekijken wat de dekking zou zijn als ik een ijsbaan ga openen op een bepaalde locatie. Of beter nog: Wat zou de beste locatie voor een nieuw te openen ijsbaan zijn?
We zien hier dus dat we met het slim toepassen van het beperkte aantal mogelijke reisafstanden, toch een bruikbaar algemeen plaatje kunnen creëren over de dekkingsgraad per ijsbaan. Wellicht leuk om te weten is dat ruim 15% van de postcodegebieden een andere ijsbaan als dichtstbijzijnde locatie heeft wanneer er gekeken wordt naar reisafstanden ten opzichte van hemelsbrede afstanden.
Business case 2: Dekking aantal inwoners per ambulancepost in Twente
We hebben dit ook in meer detail toegepast voor een andere business case, waarbij er gezocht is naar de dekking van viercijferige postcodegebieden (meer detail) van ambulanceposten in de regio Twente. Het resultaat is een overzicht van gekleurde postcodegebieden per ambulancepost en daarbij ook de dekking van het aantal inwoners. In het overzicht is te zien dat de ambulancepost in Enschede het meeste aantal inwoners dekt en Tubbergen het minste. Dit is wederom allemaal op reistijden gebaseerd. We kunnen dit ook nog uitbreiden naar aanrijtijden per postcodegebied of naar gemiddelde aanrijtijd per ambulancepost: De mogelijkheden zijn eindeloos!
Business case 3: Reistijden voor de wijk Bothoven vanuit ambulancepost Enschede
We zijn zelfs nog een niveau dieper gegaan. Nu willen we van de ambulancepost in Enschede weten hoe snel ze gemiddeld bij elk pand in de wijk Bothoven kunnen zijn en hoe de verdeling daarbij eruit ziet. Omdat er iets minder dan 2,500 panden in de betreffende wijk staan kunnen we dit met de google API makkelijk berekenen. In de visualisatie vinden we de locatie van de ambulancepost en elk ingekleurde pand in de wijk, waarbij geldt dat groen gelijkstaat aan een korte reistijd en rood aan een langere reistijd. Het is vanzelfsprekend dat dit waardevolle informatie kan zijn om de locaties van ambulanceposten te bepalen.
Uiteraard zouden we bovengenoemde analyses verder kunnen uitbreiden als we meer reistijden per dag kunnen berekenen, maar hiervoor zouden we moeten betalen. Dat hebben we in dit voorbeeld buiten beschouwing gelaten.
Vragen
Heb je vragen, opmerkingen of wil je reisafstanden implementeren in jouw eigen business case? Neem contact met ons op via salesdesk@infotopics.nl of 088-8225328.
