Van file-informatie naar route-informatie ° 7 nov 06
Door Sawan Bruins | Alle berichten van Sawan
Enkele weken geleden las ik op verschillende websites dat Vodafone en TomTom een techniek gaan gebruiken voor het verzamelen van verkeersinformatie. In plaats van met lussen in de weg en camera’s langs de weg de snelheid van het verkeer te meten en in te schatten, worden mobiele telefoons anoniem “gevolgd”. Door te meten hoe snel een telefoon zich beweegt, kan bepaald worden of ergens een file staat. Door dit te doen met vele telefoons tegelijkertijd kan bepaald worden hoe lang de file is. Een groot voordeel ten opzichte van de huidige manier van meten is dat dit minder arbeidsintensief is en tevens nauwkeuriger.
De informatie die door het netwerk van Vodafone verzameld wordt, kan met een abonnement gedownload worden naar de navigatie oplossing van TomTom. De navigatiesoftware zal op basis van deze informatie de snelste route bepalen, zoals dat nu al gebeurt met de op de oude manier verzamelde informatie.
TomTom en Vodafone verwachten dat deze aanvullende dienst in de tweede helft van volgend jaar beschikbaar komt.
(Bron: telecomwereld.nl)
Nieuwe mogelijkheden voor bovenstaand idee
Natuurlijk is het geweldig om accurate en realtime informatie over het verkeer te kunnen ontvangen, alleen er zijn meer mogelijkheden die voor meer dan alleen commerciële bedrijven interessant zijn.
Kosten van files
Het is bekend dat files het goederenverkeer ongeveer een half miljard euro kosten (Bron: rtl.nl). De overheid is al jaren bezig met een oplossing te vinden door te investeren in extra rijstroken, snelwegen en het openbaar vervoer. Ook staan er op steeds meer plaatsen informatieborden boven de weg met informatie over de files. Deze informatie komt nu nog van de eerder genoemde lussen en camera’s, maar kan ook via de telecombedrijven aangeleverd worden. Ik denk zelf dat hier wel een goede business case voor te maken valt. Het gaat dus om het verkrijgen van informatie via bijvoorbeeld de overheidseigen VID (verkeersinformatie dienst) of de informatie winning outsourcen bij een telecomprovider. Een derde mogelijkheid is dat het VID de informatie onttrekt bij een telecomprovider en de besparing die gehaald wordt op de controle van de camera’s gebruikt wordt voor nieuwe diensten.
Nieuwe diensten
Duidelijk is dat ontwikkelaars van navigatiesystemen steeds meer doen met verkeersinformatie. Deze informatie wordt binnen gehaald via internet (GPRS) of via radiogolven (TMC). Als de overheid niet alleen file-informatie, maar ook alternatieven beschikbaar zou stellen aan deze bedrijven ligt hier misschien wel een mogelijkheid tot het terugdringen van het fileprobleem. De navigatiesystemen bekijken op basis van de verkeersinformatie die beschikbaar is (via de lussen en camera’s) wat de snelste route is. Dit kan door de file zijn, maar ook een alternatief om de file heen. Nadelen hiervan is dat dit nooit gebeurd op basis van actuele informatie en altijd door het doorrekenen van alternatieven op het navigatiesysteem zelf. De overheid zou ook kunnen meehelpen met het ontwikkelen van een systeem waarbij de nadruk niet lig op files vermijden, maar op een “hoger” niveau collectief de files in het algemeen terug te dringen.
Van file-informatie naar route-informatie
Door te evalueren van het aanbieden van file-informatie naar route-informatie kunnen de files verkort worden. De VID of een andere instantie biedt informatie aan over de alternatief te volgen route. Dit kan op basis van de informatie die via de mobiele telefoons wordt verkregen. Door naast de snelheid en de coördinatie van de telefoons ook de dichtheid te verkrijgen kan het verkeer “verdeeld” worden over verschillende alternatieve routes. Ook wordt het mogelijk om opleidingen direct aan te bieden als er ergens een ongeluk is gebeurd. De veiligheid kan ook geholpen worden door de maximum snelheid aan te bieden op het navigatiesysteem zodat de bestuurder weet dat hij een file nadert, dit zal kettingbotsingen voorkomen wat ook weer leid tot minder files. Tot slot kunnen ook de autowegen, die vaak rustiger zijn dan de snelwegen, worden gebruikt in de strijd tegen de files.
Keuzevrijheid
Net als bij de huidige file-informatie is het uiteraard de keuze van de bestuurder om de aangeboden route te kiezen, dit wordt niet opgedrongen. In praktijk is dit ook niet nodig want als eenmaal blijkt dat het navigatie-systeem steeds een snellere route aanbied zijn we gek om deze niet te volgen.
Popularity: 2% [?]
Loading ...
Eigenlijk is het niet van “file-informatie naar route-informatie”, maar van “file-informatie naar route-optimalisatie” (of een dergelijke benaming).
Informatie komt – gevoelsmatig – over als een soort “push”, als een bron die gebruikt kan worden. Het gaat hier over volledig dynamisch, creatief en interactief te integreren toepassing. Inspelend op de omstandigheid van de individu met een optimaal gebruik van de aanwezige informatie als effect.
Ik zit te denken aan de stappen, de mars route hiervoor, die genomen moeten worden om dergelijke toepassing van idee naar werkelijkheid te maken.
Stephan (8 nov 06 om 12:57)Ik denk dat het ingewikkelder lijkt dan het is. De meeste navigatiesystemen werken met way-points (meerdere locaties waar een je naar toe wordt gestuurd door het navigatisyteem). Als jij TMC-informatie opvraagd wordt eerst jouw huidige- en eindlocatie doorgegeven aan de server. Op deze server zijn de wegen waar files staan opgedeeld in “stukjes” weg. Tussen iedere twee afslagen/opritten wordt bepaald of er files staan (dit gebeurd dus generiek). Als er tussen twee afslagen/opritten een file staat, wordt generiek een alternatief bepaald. Op het moment dat het alternatief te druk dreigt te worden wordt een ander alternatief bepaald. Ieder alternatief heeft een begin en eindpunt (wederom per stukje weg tussen iedere afslag en oprit). Deze begin en eindpunten vormen de way-points in het navigatiesysteem. Het navigatiesysteem haalt bijvoorbeeld iedere 3 minuten nieuwe informatie op. Door dit niet realtime te laten verlopen zal er minder belasting op de server zijn, daarnaast is het ook niet nodig omdat 3 minuten in het verkeer verwaarloosbaar is ten opzichte van de reistijd als er in de spits wordt gereden. Het gaat dus om pure route-informatie.
Sawan Bruins (8 nov 06 om 13:14)Leuke discussie. De TMC informatie wordt bij een geintegreerd systeem (radio-navigatie) “automatisch” geladen en verwerkt met de actuele route. De verwerking vindt op het device plaats. Net als het berekenen hoe de lijn tussen de huidige plaats en het way-point op de ‘echte’ kaart moet worden geprojecteerd (kortste, snelste, optimaal). De “pure” route-informatie kan worden gebruikt voor de route-optimalisatie, of het vinden van de optimale route. Het wordt optimaler als er actuele informatie van buiten wordt meegenomen.
Je moet juist die practische slag maken, alleen het aanbieden of beschikbaar stellen van de informatie (of dat nu file of route informatie is), is niet voldoende voor het gebruik en bijhorende gemak. Hoe vaak heb ik niet toch in de file gestaan, met mijn navigatie en TMC functie ingeschakeld. Meestal omdat de route/file informatie niet volledig was of niet op tijd was geintegreerd (verwerkt) met de ingestelde route. Of je was al voorbij de afslag en kan niet meer terug. Hoe vaak heb ik niet mijn navigatie systeem getest en ‘verslagen’ op routes waarvan in de sluiproutes ook kende. Hoe vaak heb ik me verbaasd over het feit, dat ik toch weer de snelweg opgestuurd werd, waar al eerder een file werd aangegeven (en er ook stond) waardoor de eerste omleidingsberekening werd geactiveerd.
De rekencapaciteit en de grote bulk aan informatie (anonieme positie van de mobiele telefoons) verwerking kan alleen aan de server kant plaatsvinden, plus het plotten op de “stukjes” weg. Deze route-informatie moet beschikbaar komen voor de berekening (in de auto) van de route-optimalisatie. De hele route en alle alternatieven moet voor iedereen continue worden bijgehouden. Daarnaast continue worden vergeleken met de ETA en de ETE (de tijd van aankomst en de tijd nog onderweg).
Het gaat op snelheid van verwerking, de grote hoeveelheid informatie (van, rond, op en over de route) en het gebruiken van de slimme algoritmes die de Navigatie software al in zich heeft. Ik zeg niet dat het niet ingewikkeld is, ik zeg alleen dat ik wel een grote behoefte zie en wellicht een oplossing voor het mobiliteits probleem….
Stephan (8 nov 06 om 15:24)Zeer interessante discussie. De ETA en ETE is niet relevant, op basis van de gekozen waypoints kan het locale navigatiesysteem dit prima zelf. Ik probeer het nog meer te verduidelijken:
Sawan Bruins (8 nov 06 om 15:40)- Een auto rijdt van A naar D
- Dit kan via A-B-D en via A-C-D
Het navigatiesysteem maakt verbinding met de server en geeft daarbij het volgende aan:
* Ik ben bij A
* Ik moet naar D
De software op de server heeft al de drukte bepaald van A-B, A-C, B-D en C-D. Op de server is ook al bepaald dat het op A-B dusdanig druk is dat deze weg voor al het verkeer vermeden moet worden. De server stuurt dus alleen waypoint C door. Doordat het navigatiesysteem automatisch de kortste route naar C en vervolgens D bepaald, wordt je via de goede route geleid.
Het doorgeven van de coördinaten door het navigatiesysteem is geen probleem, nu wordt door TomTom bijvoorbeeld ook al gecontroleerd of je een valide account hebt voor TCM. Daarnaast kan ook de andere kant op geredeneerd worden. Bijvoorbeeld het doorgeven van de waypoints die vermeden dienen te worden. Op deze manier hoeft de server niet meer te weten waar jij je bevind. De drukke “stukjes” weg worden uit gezet of in prioriteit door het navigatiesysteem op een dusdanige manier behandeld zoals dit met een weg binnen de bebouwde kom gebeurd, dus negeren als het kan.
Precies op dit onderwerp ben ik afgesturdeerd. Het onderscheidende van dit onderzoek is dat ook de mate waarin men hierop reageert!
http://ieeexplore.ieee.org/iel5/9503/30160/01384735.pdf
Abdes Karimi (15 dec 06 om 17:26)* te snel verzonden.
Het onderscheidende van het onderzoek is dat in de simulatie het gedrag en reactievermogen van bestuurders is meegenomen.
Abdes Karimi (15 dec 06 om 17:29)