Introductie
Begin 2021 erkent het Smart Flanders-programma van het Agentschap Binnenlands Bestuur (ABB) de noodzaak om mobiliteitsstromen van alle transportmodi overzichtelijk in kaart te brengen om (de mobiliteitsexpert van) de steden te ondersteunen bij de uitwerking van hun datagedreven mobiliteitsbeleid. Het vooropgezette plan was om een totaalbeeld van de mobiliteitsstromen te ontwikkelen door de al bestaande databronnen rond mobiliteit te integreren met eenvoudige wiskundige fusies. Samen met imec werd er binnen het kader van het CityFlows-traject gezocht naar twee pilootsteden die het datafusiemodel wilden gebruiken en hieraan een use case konden koppelen.
Als pilootsteden werden Stad Mechelen en Gent geselecteerd. In Mechelen moest de invoering van een schoolstraat getoetst worden aan de hand van het model. Er moest beoordeeld worden of en hoe het mobiliteitsgedrag was veranderd nadat de schoolstraat ingevoerd was. In Gent moest een wijkmobiliteitsplan (Zwijnaarde) geëvalueerd worden als onderdeel van het project. In beide pilootsteden moest de evaluatie uitgevoerd worden op basis van een combinatie van databronnen, zodat er niet enkel uitspraken gedaan konden worden op plaatsen waar gemeten werd, maar ook daar waar niet werd gemeten
Het model dat hiervoor ontwikkeld werd, bouwt verder op een proof of concept (PoC) dat de universiteit van Antwerpen ontwikkelde in de Sint-Andrieswijk die de naam Antwerp Smart Zone kreeg. Hier werden verschillende technologische toepassingen getest in een echte leefomgeving. Een van die toepassingen was een datafusiemodel dat verschillende databronnen rond mobiliteit combineerde om het aantal deelnemers aan het verkeer te bepalen per modaliteit in elke straat en op elk moment van de dag. Het model dat daarvoor gebouwd was, combineerde databronnen zonder echte regels (bijvoorbeeld de regel dat mensen ’s ochtends hun woongebied verlaten en ’s avonds weer terugkomen), maar op basis van een wiskundige verdeling. Het oorspronkelijke model in de PoC had slechts een beperkt aantal modaliteiten (twee: wel en niet-gemotoriseerd) werkte slechts op een kleine geografische oppervlakte met beperkte databronnen.
De opdracht van imec was om het ontwikkelde model van de PoC op te schalen naar meer modaliteiten en meer databronnen. Er moest ook een mechanisme ontwikkeld worden dat de accuraatheid van de output van het model controleerde. imec voegde meer databronnen toe (Telraam, fietstellussen van Signco, tijdelijke tellingen en ANPR-data) en trachtte het model bruikbaar te maken op stadsniveau en voor alle modaliteiten (voetgangers, fietsers en gemotoriseerde voertuigen).
Het mechanisme dat de accuraatheid van de output van het model controleerde (validatiescore) werd ontwikkeld aan de hand van Straatvinkendata (ground truth). Bij het samenvoegen van de eerste databronnen bleek de validatiescore echter laag. Onze hypothese was dat de validatiescore zou toenemen naarmate er meer databronnen toegevoegd zouden worden. Die hypothese werd echter niet bevestigd. Om de kwaliteit van het model te optimaliseren werd ook de verdeling van de modaliteiten per straat geoptimaliseerd, maar ook hierna bleef een positief effect op de validatiescore uit.
We kunnen daaruit concluderen dat deze versie van het opgeschaalde model geen betrouwbaar middel is om de use cases in de pilootsteden op te lossen. Delen van het model zijn mogelijk wel herbruikbaar, zodat de data-uniformisatie en - ingestie. Die zullen dan ook samen met de andere componenten van het model beschikbaar worden gemaakt. Onze belangrijkste aanbeveling is dat een toekomstig model meer rekening zal moeten houden met het dynamische karakter van een stad. Dat wil zeggen: de wegingscoëfficiënten die wij hebben toegepast, zouden dynamischer moeten zijn en bedacht moeten zijn op het menselijke verplaatsingsgedrag. Artificiële intelligentie kan daarvoor mogelijk een oplossing zijn.
Nadat de lage betrouwbaarheid van het model aan het licht was gekomen, zijn de use cases met de pilootsteden herbekeken om te onderzoeken hoe die wel opgelost konden worden. Na nauw overleg met de twee centrumsteden en de stuurgroep van CityFlows heeft imec een analysetoolbox ontwikkeld die de mobiliteitsexpert in staat stelt met enkele muisklikken een bepaalde beleidsuitdaging op vlak van mobiliteit te evalueren. Op die manier creëerden we meer zekerheid dat de steden echt vooruitgeholpen waren met hun problematiek.
De opdeling van deze pagina bestaat er als volgt in: in de eerste sectie worden de gebruikte databronnen geëvalueerd waarna er opvergegaan wordt op een beschrijving van het model in deel 2. In deel 3 benoemen we de uitdagingen en de mogelijke oplossingen. In dit deel wordt ook de toolbox toegelicht.
Input van het model
Zoals aangegeven in de inleiding worden de databronnen die gebruikt zijn voor het CityFlows-project met de twee pilootsteden, als eerste nader bekeken. In iedere sectie komt een andere databron aan bod. Aan de hand van een SWOTanalyse wordt elke databron afzonderlijk geanalyseerd en op basis van die analyse worden er enkele aanbevelingen voor de sensoren en databronnen gedaan.
Telecomdata
Telecomdata is data over het aantal smartphones dat aanwezig is in een specifieke zone (vierkante cellen van 500 m x 500 m, of in het geval van Mechelen één grote onregelmatige cel). De frequentie waarmee geüpdatet wordt wie aanwezig is in een cel, verschilt per data-aanbieder. Voor Mechelen was de updatefrequentie vijftien minuten, terwijl dat voor Gent een keer per uur was. Per updatefrequentie wordt bijgehouden hoe veel smartphones zich in een specifieke cel bevinden (snapshots). De locatie van een smartphone wordt, afhankelijk van wat eerst komt, elk kwartier of aan de hand van de laatste ping (de laatste connectie met het netwerk) bepaald. Het is hierbij belangrijk om te vermelden dat er in elke stad met één provider gewerkt wordt en dat die enkel data heeft over zijn eigen gebruikers. Om een telling te kunnen leveren voor alle toestellen zal de provider extrapoleren op zijn geschatte marktaandeel.
➢ Sterktes
• Deze databron geeft een beeld van het totaal aantal mensen dat aanwezig is. Dat beeld omvat dus alle modaliteiten, maar ook de achtergrond (mensen die niet deelnemen aan het verkeer, maar die hun smartphone bijvoorbeeld in huis gebruiken).
• De data is al veel gebruikt in een andere context (Toerisme).
• Goede geografische dekking: geeft niet enkel een lokaal beeld van een plek waar een specifieke sensor staat, maar geeft een beeld van een grotere zone.
➢ Zwaktes
• Er is geen opsplitsing per modaliteit mogelijk, omdat er geen beeld is van de snelheid/modaliteit per persoon.
• Ook mensen die niet deelnemen aan mobiliteit worden meegenomen in de telling.
• Door anonimisatie kan er geen link gelegd worden tussen verschillende snapshots.
• Weinig tot geen inkijk in hoe de output (snapshots) tot stand komen.
• Het is onduidelijk hoe accuraat de extrapolatie op basis van het marktaandeel is.
• Het update van de locatie van een smartphone gebeurt niet realtime (in functie van het gebruik van de smartphone). Dat zorgt voor vertraging en kan betekenen dat de persoon in kwestie inmiddels al uit de zone is, en dat er dus onjuist geteld wordt. Bovendien is er geen inschatting van hoe groot deze “fout” is.
➢ Opportuniteiten
• Dankzij CityFlows werden gebreken in datakwaliteit aangekaart en konden de steden die gebreken terugkoppelen aan hun leverancier. De ervaring van CityFlows geeft de steden de kans om kwaliteitsvollere data in de toekomst in een contract te laten beschrijven.
• Hogere updatefrequenties van smartphonelocaties (bij gebruik van meer apps) zorgt ervoor dat deze databron in de toekomst potentieel heeft.
• De verkoop van smartphones groeit nog steeds. Hoe meer mensen een smartphone bezitten, hoe meer mensen gedetecteerd kunnen worden.
➢ Bedreigingen
• Door de GDPR-wetgeving kan deze databron mogelijk extra beperkingen/anonimisering opgelegd krijgen.
• De verantwoordelijkheid voor het oplossen van bepaalde beperkingen het potentieel gebruik van deze data ligt bij de telecomproviders. Zij zouden de snelheid van verplaatsing of modaliteit kunnen meegeven. De vraag is of deze (vaak grote) telecomproviders het potentieel hiervan inzien en de technische uitdagingen kunnen en willen aangaan.
➢ Conclusies
Deze databron had veel potentieel, maar na het eerste gebruik gaf de databron meer problemen dan vooraf verwacht. De achtergrond (zowel van personen die niet deelnemen aan het verkeer als van smartphones die nog niet geüpdatet zijn op vlak van locatie) is groot en variabel. Bovendien is het formaat (snapshots) een beperking, want veranderingen tussen snapshots kunnen moeilijk gedetecteerd worden en de modaliteit kan daaruit ook moeilijk worden afgeleid.
Voor beide pilootsteden werd deze data aan imec overhandigd door middel van een datadump. Beide steden hadden echter wel een andere operator. Bovendien verschilde de updatefrequentie per stad (15 minuten voor Mechelen en 60 minuten voor Gent).
De interessante opportuniteiten die hieruit afgeleid kunnen worden, zijn kansen die grote telecomoperatoren moeten aannemen om hun data te verbeteren en in lijn te brengen met de behoeften van de steden. Onze aanbeveling is dan ook dat steden de kwaliteit van de data meenemen in een aanbestedingsprocedure bij een volgende aankoop van deze data. Op basis van een eerste analyse stelde Gent bijvoorbeeld al vast dat de eerste datalevering niet klopte. Na overleg met de provider werd dat echter bijgestuurd. De ervaring die is opgedaan binnen CityFlows kan dan ook helpen om het potentieel van deze databron te verbeteren voordat er wordt over gegaan tot de aankoop van dergelijke data.
Er kan bijvoorbeeld gevraagd worden om niet enkel aantallen per snapshot te leveren, maar ook om aantallen per modaliteit en per snapshot te leveren. Het is echter nog de vraag of dat technisch binnen de mogelijkheden van de telecomoperatoren valt. Er kan ook gevraagd worden naar meer inzicht in de zogenaamde “black box” die nu al achter de data zit. De steden krijgen momenteel namelijk enkel ruwe aantallen per cel en niet meer. Meer inzicht in de manier waarop de data verzameld worden en de manier waarop die geïnterpreteerd moeten worden, zal de kwaliteit en het gebruik ervan alleen maar ten goede komen.
Telraam
Telraam is een Citizen Science-initiatief van het beleidsondersteunend onderzoeksbureau TML (Transport & Mobiliteit Leuven). Dat initiatief voorziet camera’s voor burgers die daarvoor betalen (127 euro op 02/03/2023) om een beeld te krijgen van de mobiliteit in hun straat. De door de burger zelf geïnstalleerde camera bevat beeldherkenningssoftware die detecteert hoeveel auto’s, fietsers en/of voetgangers er per uur passeren. TML ontwikkelde een architectuur, hardware en software voor deze sensor binnen het Europees project WeCount. Er werd een pilootstudie uitgevoerd in Kessel-Lo (Leuven) waarbij er veel Telraamsensoren gratis ter beschikking werden gesteld aan enthousiaste burgers.
➢ Sterktes
• Een lokaal beeld van verkeersvolumes (op secundaire en tertiaire wegen)
• Multimodaal
• Laagdrempelig en goedkoop vanuit het oogpunt van de steden, want de kost wordt gedragen door de burgers (met uitzondering van projecten waarvoor de steden de sensors kopen).
• Langdurige meting en dus een grote tijdspanne, wat deze databron geschikt maakt voor zowel use cases met kleine tijdsvensters als voor use cases met grote tijdsvensters.
➢ Zwaktes
• Beeldherkenningssoftware werkt niet altijd zonder problemen (dubbele telling fietsers/voetgangers).
• Bij schemering of donkere omstandigheden en ’s nachts werkt de camera niet.
• Het blijft een burgerinitiatief en is dus afhankelijk van de bereidheid van burgers om de camera’s te betalen, te installeren en te onderhouden (verbinding/stroomverbruik).
• De invloed die de stand van de camera (hoek tot de straat, parkeren van vrachtwagens voor de camera, invallende zon, etc.) uitoefent op de metingen is vaak onbekend.
• De camera staat op een vast punt en meet dus enkel op dat punt en niet over een grote geografische zone
➢ Opportuniteiten
• Dankzij verschillende projecten kunnen deze camera’s beschikbaar worden gesteld voor burgers zodat zij een constante meting kunnen opstarten en zo andere projecten kunnen ondersteunen (zoals het WeCount-project waarnaar hierboven verwezen is).
• Telraam werkt aan een verbetering van zijn sensor met een Telraam 2.0-sensor die geüpdatete beeldherkenningssoftware bevat en minder gevoelig is voor tijdelijke onderbrekingen van elektriciteit en/of internet.
• Telraam wint meer en meer aan bekendheid binnen de maatschappij, wat de bereidheid tot aankoop en installatie vergroot
➢ Bedreigingen
• Sterk afhankelijk van de bereidwilligheid van de bewoners om te investeren in de camera en die te blijven monitoren
• De verschillen in beschikbare Telraamsensoren per wijk/stad zijn zeer divers en bepalen in veel gevallen de functionaliteit van deze sensor voor een specifieke use case.
➢ Conclusies
De multimodale telling en lokale beschikbaarheid van deze sensor is een meerwaarde ten opzichte van veel andere sensoren. Het belangrijkste nadeel blijft echter de lokale context die vaak ontbreek. Dat zorgt er ook voor dat er geen algemene oplossing toegepast kan worden op alle Telraamdata. Er moet namelijk steeds lokaal nagegaan worden wat de mogelijke afwijkingen kunnen zijn, en dat zelfs voor elk tijdstip. Dat nadeel heeft een grote invloed op de nauwkeurigheid van deze sensor. Deze databron kan mogelijk verbeterd worden door bij de installatie een validatie per sensor uit te voeren. Dat kan bijvoorbeeld een kwaliteitscontrole zijn die patronen detecteren op lange en korte termijn om op die manier afwijkingen te bepalen en wiskundig te kunnen opheffen.
De Telraamdata is redelijk eenvoudig op te vragen via een publieke API die je voor elke sensor/straatsegment afzonderlijk dient op te vragen. Als je de data hebt opgevraagd, ontvang je de verwerkte data met het aantal passages per uur per modaliteit terug. Deze dataverwerking heeft reeds plaatsgevonden op de camera zelf om privacyproblemen uit de weg te gaan.
Als verbetering stellen we voor om de beeldherkenningssoftware te verbeteren en het toestel bestendiger te maken tegen tijdelijk netwerk- en stroomverlies. We zien daarvoor wel mogelijkheden in de Telraam 2.0-versie. Die moet echter wel nog uitvoerig getest worden om te kunnen bepalen of dat ook daadwerkelijk een positieve invloed heeft op de nauwkeurigheid van de resultaten. De vraag daarbij blijft ook of dat technisch gezien toch niet op beperkingen gaat botsen (slechte zichtbaarheid, ...). Ook hier zou gedacht kunnen worden aan een validatieproces per sensor. Bovendien moet er rekening gehouden worden met een overgangsperiode voordat de bestaande Telraamsensoren vervangen zijn door nieuwe exemplaren. Het gevaar dreigt daarbij dat de oude sensors evenwaardig behandeld worden als de (betere) nieuwe generatie. Daar komt bij dat het type sensor ook duidelijk weergegeven moet worden in de metadata.
ANPR
ANPR is een afkorting die staat voor “automatic number plate recognition” (automatische nummerplaatherkenning). Sinds de terroristische aanslagen in België is deze sensor wijdverspreid in Vlaanderen. ANPR werkt via een camera die een foto maakt van de voorkant van elk voertuig en zo de passage van dat voertuig op die plaats registreert.
ANPR data werd voor de use case in Mechelen meegenomen in het CityFlows-project. Het ontsluiten van de ANPR data voor analyse doeleinden is tot op vandaag geen eenvoudige klus. Het gebruik van deze camera’s wordt geregeld door de Wet op het politieambt (WPA) en de Camerawet (21/3/2007). Het Controleorgaan op de politionele informatie (COC) kijkt toe op het naleven van deze wetgeving. Daarnaast is ook de Algemene Verordering Gegevenbescherming (AVG) van toepassing die regels op verwerking van persoonsgegevens beschrijft.
In de casus van Mechelen onderzoekt het projectteam de impact van het afsluiten van een schoolstraat. Meer specifiek wordt er onderzocht of er met de beschikbare mobiliteitsdata iets kan verteld worden over de verandering in de verkeersveiligheid, leefbaarheid en doorstroming op de straten rond de schoolstraat. Dit draagt bij tot handhaving van de openbare orde en het verzekeren van de veiligheid. Dit vormt de grond waarop de motivatie tot gebruik van deze ANPRdata stoelt. Stad Mechelen diende een aanvraag bij het Controleorgaan op de politionele informatie COC in om de ANPR-gegevens op te vragen. De aanvraag bestond uit twee delen.
• In het eerste deel vraagt Stad Mechelen (aanvrager en primaire verwerkingsverantwoordelijke) aan de Politiezone Mechelen-Willebroek om geanonimiseerde gegevens van de ANPR-camera registraties te verkrijgen. Dit aspect valt onder de Wet op het Politieambt (WPA), meer bepaald artikel 44/11/7.
• In het tweede deel geeft Stad Mechelen de opdracht aan imec (verwerker) om de gegevensstroom van geanonimiseerde ANPR-gegevens te verwerken. Dit aspect valt onder de AVG. Daarnaast beroept Stad Mechelen zich ook op Artikel 2 uit het gemeentedecreet “De gemeenten beogen om op het lokale niveau bij te dragen tot het welzijn van de burgers en tot de duurzame ontwikkeling van het gemeentelijk gebied”. Dit is ook overeenkomstig met artikel 41 uit de Grondwet dat aangeeft dat ze bevoegd zijn voor “de aangelegenheden van gemeentelijk belang voor de verwezenlijking waarvan ze alle initiatieven kunnen nemen.”
Na goedkeuring van het COC werden de uiteindelijke gegevens uitgewisseld. In eerste instantie betreft het gegevens over plaats en tijdstip van de registratie door de camera die door de Politiezone Mechelen-Willebroek aan de stad Mechelen overgemaakt worden. Er wordt geen verrijking gemaakt met de databank van Dienst Inschrijving Voertuigen (DIV) en ook geen gepseudonimiseerde gegevens om voertuigen over meerdere camera’s te volgen. In een tweede instantie worden deze gegevens overgedragen aan imec (verwerker) die als eerste actie een aggregatie op hoger niveau doorvoert in lijn met bepalingen in het AVG (minimum 5 voertuigen per record). Door de finale aggregatie van de verschillende mobiliteitsdata is resulterende datastroom niet langer onderhevig aan de WPA en/of AVG.
In dit proces is een nauwe samenwerking tussen de verschillende actoren belangrijk. In de casus van stad Mechelen was de mobilitieitsdienst de initiatiefnemer om de ANPR data te gebruiken. Samen met de verwerker imec werd er ingeschat of deze databron een toegevoegde waarde kon brengen in de analyse. De Data Protection Officer (DPO) van de stad evalueerde mee of de juiste evaluaties en stappen inzake gegevensverwerking gevolgd werden.
➢ Sterktes
• Zeer nauwkeurige sensor die zo goed als al het gemotoriseerde verkeer meet.
• Link met voertuigklasse/motortype is in principe mogelijk (hoewel dat niet in de scope van CityFlows zat), dit houdt een koppeling in met DIV databank.
• Reeds op grote schaal uitgerold en beschikbaar in Vlaanderen.
➢ Zwaktes
• Wetgeving bemoeilijkt wijdverspreid gebruik van deze sensor voor analyse doeleinden. In deze casus diende een duidelijke link met de handhaving van openbare orde en verzekeren van de veiligheid aangetoond te worden.
• Niet multimodaal: enkel gemotoriseerd verkeer wordt gedetecteerd. Nieuwe generatie camera's zijn in staat zijn meerdere modaliteiten te identificeren.
• Camera staat op één vast punt en meet dus ook enkel op dat vaste punt en geeft geen data over een grote geografische zone.
➢ Opportuniteiten
• Indien het wetgevend kader zou gevormd worden (dat ANPR-data beschikbaar maakt voor analyse doeleinden) dan dienen ook de achterliggende diensten, die instaan voor verwerking van de ruwe data, ondersteund te worden. De huidige technologie staat vandaag ver genoeg om deze verwerking procedures in hoge mate te automatiseren. Dit zou een volgende stap kunnen zijn in de digitale transformatie van de publieke diensten met het oog op betere dienstverlening.
• In financieel moeilijke tijden is het voor steden en gemeenten belangrijk om bestaande infrastructuur optimaal te benutten. Die politieke wil zorgt ervoor dat er nu een uitgelezen kans is om het gebruik van deze data in mobiliteitstoepassingen in een wettelijk kader te plaatsen en al doende de beschikbaarheid van deze data te verbeteren.
• Deze sensor staat op veel plaatsen en als deze data beschikbaar wordt gesteld, is die daardoor geschikt voor verschillende use cases.
➢ Bedreigingen
• Het aanslepende debat rond het gebruik van ANPR data voor analyse doeleinden (dat aanpassingen aan huidige wetgevend kader vraagt) zorgt ervoor dat het geloof dat deze data beschikbaar gesteld kan worden, aan het afbrokkelen is
➢ Conclusies
De sterkte van deze sensor is vooral de grote nauwkeurigheid in het meten van al het gemotoriseerde verkeer. Die sterkte is echter ook meteen het grootste nadeel: er is namelijk geen meting van niet-gemotoriseerde transportmodi. Bovendien zorgt de huidige wetgeving ervoor dat deze databron op het moment nog niet eenvoudig benut kan worden. Wij adviseren dan ook aan om die wetgeving zo spoedig mogelijk te herzien zodat er een duidelijk afgebakend toepassingsgebied kan komen voor deze sensor. Nu moet er per initiatief bekeken worden waar deze sensor wel en niet voor gebruikt mag worden. Uit de use case van CityFlows in Mechelen is gebleken dat dat veel tijd vraagt.
Fietstelpalen
Deze databron bevat data die komt uit een tellus, een geleider die in het fietspad of wegdek geslepen is. Wanneer die geleider onder stroom gezet wordt, genereert die een magnetisch veld. Wanneer er vervolgens magnetisch materiaal (een fiets) door en over dat magnetische veld rijdt, wordt het gegenereerde magnetische veld verstoord en wordt de stroom in de geleider beïnvloed. De verwerking van deze stroomveranderingen in het aantal fietsers wordt lokaal uitgevoerd. De provincie Oost-Vlaanderen was de eigenaar van de fietstelpaal in Gent en stelde de data van deze fietstelpaal ter beschikking via een datadump. Andere instanties van fietstelpalen zoals Signco en AWV stelde hun data ter beschikking via een openbare API. In Mechelen werd er bijvoorbeeld gebruik gemaakt van een fietstelpaal van Signco.
➢ Sterktes
• De nauwkeurigheid is relatief voldoende.
• De uitrol in Vlaanderen is aan de gang.
➢ Zwaktes
• Enkel fietsers worden gemeten.
• Aangezien carbonfietsen geen magnetisch materiaal hebben, worden die niet gemeten.
• Er is nog geen eenduidige standaard voor data uit fietstelpalen.
• De paal staat op een vast punt en meet dus enkel op dat punt en geeft dus geen data voor een grote geografische zone.
• De kostprijs is nog relatief hoog, wat een verdere geografische verspreiding beperkt.
➢ Opportuniteiten
• Dankzij de ervaringen in CityFlows en andere projecten is het OSLO-traject voor verkeersmetingen gestart om datastromen uit verkeerssensoren semantisch te modelleren en de structuur van die data te standaardiseren . Dat traject werd opgestart binnen het relanceproject “Data Integratiediensten voor Slimme Mobiliteit” (DIM) waarvoor imec de geleerde lessen van CityFlows ingebracht.
• De uitrol van fietssnelwegen en het groeiende belang voor de fietsers zorgen ervoor dat het aantal meetpunten toeneemt.
• Als alle organisaties die deze palen plaatsen, de data die uit die palen voortkomt, ook zouden delen (na anonimisatie), zou de geografische dekking van deze databron verbeteren.
➢ Bedreigingen
• Er is geen classificatie mogelijk tussen e-bike/speedpedelec of een gewone fiets.
• Enkel het aantal fietsers wordt gemeten.
• Bij afhankelijkheid van een API moet de voorbewerking van de data herbekeken worden wanneer er wijzigingen zijn aan de standaarden van de API.
➢ Conclusies
De conclusies die uit de analyse van deze databron getrokken kunnen worden, zijn te vergelijken met de conclusies over de ANPR-camera. Ook deze databron meet slechts één modaliteit, niettemin met een aanvaardbare nauwkeurigheid. Het probleem is echter dat zowel AWV als de provincies voorlopig werken volgens de standaard die CROW Fietsberaad samen met UGent heeft opgebouwd. Die standaard wordt (nog) niet overal gebruikt en is ook (nog) niet vertaald in een OSLOstandaard. Op basis van de ervaring die is opgedaan in CityFlows, gaat imec samen met Digitaal Vlaanderen echter wel OSLO-verkeersmetingen opstellen waarin dat wordt meegenomen. Ons voorstel te verbetering van deze databron is dan ook het OSLO-traject waaraan imec actief meewerkt als deel van het kernteam.
Voor de use case in Gent is de data van deze soort sensoren ter beschikking gesteld via een datadump. Voor de fietspaal van Signco in Mechelen werd die als open data (via API) afgehaald. Voor telpalen van andere leveranciers (de provincies of andere spelers) moest er aparte toegang verkregen worden. Het zou een positieve verandering zijn als het verlenen van die toegang geoptimaliseerd kan worden (bijvoorbeeld met behulp van dataspaces of een andere technologie voor datadeling). Met de kennis die is opgedaan binnen het CityFlows-project is imec dan ook in het VSDS-project (Vlaamse Smart Data Space) en het CitCom.AI-project gestapt. Daarover volgt later in dit document meer.
Tijdelijke meetinstallaties
Tijdelijke meetcampagnes werden in Gent en Mechelen uitgevoerd door telslangen. In Gent werd gewerkt met een onderleverancier die de telslangen plaatste. In Mechelen werden er enkele door de politie gelegd voor een specifieke use case (politierapporten genoemd). Er zijn zowel fietstelslangen als algemene telslangen geplaatst. Telslangen werken op een gelijkaardige manier als tellussen, maar de geleider wordt bij telslangen niet in het wegdek geslepen, maar tijdelijk in een rubberen “slang” over het wegdek gelegd.
➢ Sterktes
• Relatief hoge nauwkeurigheid
• Relatief eenvoudige installatie met minimale schade aan wegdek en zonder invloed op de doorstroming
➢ Zwaktes
• Weggebruikers proberen dergelijke installaties vaak te vermijden als ze zien liggen, wat kan leiden tot onnauwkeurige tellingen.
• Carbonfietsen worden niet gedetecteerd.
• Tijdelijk van aard, en daardoor wordt het door seizoenseffecten moeilijk om trends op lange termijn te zien.
• Er bestaat geen echte standaard voor deze metingen (op basis van de geleerde lessen van CityFlows is het OSLOtraject voor verkeersmetingen opgestart).
• Bij remmend/stilstaand verkeer (file) is de werking van de lus niet optimaal.
➢ Opportuniteiten
• Op basis van de ervaringen van CityFlows en andere projecten is het OSLO-traject voor verkeersmetingen opgestart om de semantiek rond data eenduidig te krijgen.
• Deze data blijft vaak bij één lokaal bestuur en lokale bevinden worden niet gedeeld buiten de grenzen van de steden. Er is dus nog ruimte om die data- en kennisdeling te optimaliseren aan de hand van een dataspace/samenwerking.
➢ Bedreigingen
• Classificatie tussen soorten fietsers blijft moeilijk.
• Classificatie tussen wagen/bestelwagen/vrachtwagen bij traag, accelererend of remmend verkeer is niet 16 nauwkeurig
➢ Conclusies
In het algemeen werd de data uit deze tijdelijke meetcampagnes binnen CityFlows als zeer waardevol gezien, omdat deze databron door de relatief hoge nauwkeurigheid als “ground truth” beschouwd kan worden en daardoor geschikt is om te vergelijken met andere databronnen. Het is aan te bevelen om deze data beter te delen buiten de grenzen van steden. Een dataspace zoals de Vlaamse Smart Data Space (VSDS) kan een mogelijke enabler zijn om dat te bereiken. Ook zouden alle vormen van tijdelijke telcampagnes een eenduidige beschrijving moeten hebben. Op basis van deze aanbevelingen heeft imec het al eerdergenoemde OSLO-traject voor verkeersmetingen opgestart.
Voor het CityFlows-project werd de data op verschillende manieren ter beschikking gesteld. Sommige leveranciers hadden daarvoor een API voorzien waarvan de data afgehaald kon worden. De politierapporten in Mechelen werden via een datadump beschikbaar gesteld.
Straatvinken
Straatvinken is een burgerinitiatief dat jaarlijks burgers tellingen gedurende één uur (van 17.00 uur tot 18.00 uur) laat uitvoeren. De tellingen worden elk jaar rond hetzelfde moment uitgevoerd (in de tweede helft van mei) om ervoor te zorgen dat die statistisch gezien correct zijn. Burgers krijgen de kans om het voorbijkomende verkeer te tellen met een applicatie. Via die applicatie worden hun tellingen vervolgens verwerkt.
➢ Sterktes
• Relatief hoge nauwkeurigheid die kan dienen als ground truth
• Lage kostprijs
• Multimodaal beeld
• Kwaliteitscontrole op de tellingen door Ringland Academie , Universiteit Antwerpen en HIVA - KU Leuven
➢ Zwaktes
• Confirmation bias speelt mogelijk bij burgers (ik zie wat ik wil zien en/of ik wil mijn gelijk bewijzen).
• Beperkt in tijd (slechts één uur op jaarbasis), dus beperkt bruikbaar voor kleinere tijdsvensters.
• De burger maakt mogelijk fouten als hij één uur lang gefocust moet blijven en daarnaast is het in een drukke straat soms moeilijk om het verkeer goed te blijven volgen en tellen. Aangezien elke telling achteraf nog geanalyseerd wordt, blijft deze foutgevoeligheid echter beperkt.
➢ Opportuniteiten
• De geografische dekking is relatief gezien voldoende (het initiatief is relatief wijdverspreid en bekend).
• Ondersteuning door universiteiten zorgt ervoor dat deze databron voldoende gecontroleerd wordt. Een transparante communicatie daarover kan het vertrouwen in de data mogelijks nog doen toenemen
➢ Bedreigingen
• Deze data is mogelijk foutgevoelig, omdat de aandacht van burgers kan verslappen als ze één uur lang achter elkaar volledig geconcentreerd moeten tellen.
• Vrijwillige participatie van burgers is noodzakelijk. Het blijft daardoor onzeker of er een engagement is voor meerdere jaren zodat de lange termijn in kaart gebracht kan worden.
➢ Conclusies
De conclusies die we kunnen trekken uit de analyse van deze databron is beperkter in vergelijking met de andere databronnen, omdat de databron beperkter is in tijd ten opzichte van de andere databronnen. Het nadeel van deze databron is dat het gevoelig is voor menselijke fouten, ondanks controle achteraf. Daarover dient dan ook duidelijk gecommuniceerd te worden.
Het is aan te raden om deze tellingen vooral te laten uitvoeren door burgers met een Telraamsensor. De toegevoegde waarde van een dergelijke sensor is de creatie van een lokaal kalibratiepunt. De vraag is echter of burgers die een Telraamsensor in hun bezit hebben, de extra inspanning willen en kunnen leveren om een dergelijke telling binnen dit initiatief uit te voeren. Daarnaast is het ook aan te bevelen om de telling twee keer per jaar te organiseren om meer meetpunten te hebben aangezien één uur per jaar te beperkt is.
Floating car data
Floating car data is data van weggebruikers die gebruikmaken van een navigatieapp (op hun smartphone) tijdens hun verplaatsing. De data is goed te gebruiken om te weten hoeveel wagens naar een stad rijden en via welke wegen ze dat doen. Bij meer lokale use cases (bijvoorbeeld bij metingen in een schoolstraat of bij het meten van lokaal verkeer) is deze data echter vaak beperkt bruikbaar aangezien mensen voor kleine, lokale verplaatsingen vaak geen navigatie gebruiken. Hoewel het in theorie mogelijk is om op dezelfde manier data te verzamen van actieve weggebruikers (fietsers en voetgangers), is dat in de praktijk onuitvoerbaar omdat navigatieapps door deze weggebruikers beperkt of zelfs niet gebruikt worden. Als deze soort data van fietsers komt, wordt er gesproken over floating bike data. Voor het CityFlowsproject werd uitsluitend floating car data (FCD) voor Mechelen ter beschikking gesteld.
➢ Sterktes
• Multimodaal verkeer is in theorie mogelijk.
• Het is mogelijk om een heel traject te volgen; er is dus geen beperkte puntmeting.
• Geografische dekking is direct op stadsniveau.
➢ Zwaktes
• Het aantal gebruikers van dergelijke navigatieapps is voor lokaal verkeer zeer laag. Voor de schoolstraat in Mechelen was er vaak geen enkel datapunt beschikbaar.
• In de praktijk worden dergelijke navigatieapps niet gebruikt door actieve weggebruikers.
➢ Opportuniteiten
• De uitrol van intelligente verkeerslichten (iVRI) binnen het Mobilidata-programma zal het gebruik van dergelijke navigatieapps wellicht kunnen aanmoedigen.
• Geconnecteerde wagens delen veel meer data waardoor het in de toekomst interessanter kan zijn om gebruik te maken van deze databron.
➢ Bedreigingen
• Steden nemen vaak bij één leverancier af en zijn dus ook afhankelijk van het aantal gebruikers van één app.
➢ Conclusies
De meerwaarde van deze data is de hogere geografische dekking doordat de data trajectdata bevat en niet enkel data van een lokale sensor. Het nadeel van deze data is de zeer beperkte penetratiegraad. Op primaire wegen is die penetratiegraad nog relatief hoog, maar op secundaire en tertiaire wegen is die vaak toch zeer beperkt. Voor lokale use cases zoals de evaluatie van een wijkmobiliteitsplan of het invoeren van een schoolstraat, is deze databron minder geschikt, omdat weggebruikers zelden tot nooit gebruikmaken van een navigatieapp voor wegen die ze al goed kennen. Bovendien worden dergelijke navigatieapps door actieve weggebruikers zelden gebruikt. In de praktijk is deze databron dus enkel geschikt voor gemotoriseerd verkeer.
Deze databron werd enkel gebruikt in Mechelen. Er werd gewerkt met leverancier Be-Mobile. Deze databron is doorgaans relatief duur vergeleken met de mogelijke functionaliteiten die de databron oplevert (althans binnen de context van het CityFlows-project). De data werd ter beschikking gesteld via een datadump (een statisch CSV-bestand dat doorgestuurd werd).
Datafusiemodel
In dit deel wordt beschreven hoe er vanuit de data, de dataverwerking en het model naar de output gegaan wordt. Aangezien dit deel technischer van aard is, wordt in dit deel soms verwezen naar een PowerPointpresentatie. Met beelden kunnen zaken soms namelijk veel beter overgebracht worden dan met een lange tekst. De algemene dataflow is te zien in onderstaande figuur. Vanuit die dataflow is dit deel van het rapport opgebouwd. Deze flow wordt in de volgende delen van de tekst verklaard.
In het eerste blok van de dataflow worden de datadumps of API-bevragingen uit het eerste deel van dit rapport gecontroleerd op hun kwaliteit. Er wordt bekeken hoe het signaal van de sensoren zich gedraagt om eventuele gaten of hiaten in de data te kunnen signaleren. De meetfrequentie en opbouw van de data wordt ook in deze fase gecontroleerd. Het formaat waarin de data binnenkomt, wordt getransformeerd naar een uniform formaat dat specifiek is voor het CityFlows-model. Als elke bron individueel bewerkt is tot het gewenste formaat, wordt alle data samengevoegd in één bestand (het “all_data.csv”-bestand in Figuur 5).
Het handling script voor een bepaalde databron begint telkens met het opkuisen van lege velden en het verwijderen van onnodige of lege kolommen. Voor een databron die voor een punt intensiteiten (aantal passages per tijdseenheid) 20 teruggeeft, is de volgende stap om deze intensiteiten om te zetten naar dichtheden (het aantal weggebruikers per lengteeenheid). Hiervoor geldt de volgende formule:
dichtheid = aantal passages / ( tijdsperiode * snelheid)
Voor deze formule is het nodig om het gegeven “snelheid” te kennen. Als die niet gekend is (omdat de databron dat niet meet), wordt er een bepaalde snelheid aangenomen. Voor databronnen die de data direct in een snapshotformaat aanleveren, is dat uiteraard niet nodig
Als meettoestellen een puntmeting uitvoeren, moet het punt gelinkt worden aan het corresponderende straatsegment in het Vlaamse wegenregister. Als de meting uitgevoerd wordt voor een groter geografisch gebied, kan dat uiteraard niet gelinkt worden aan een straat, en zal het gehele gebied beschreven moeten worden. In dat geval beschrijft de kolom voor de geometrie een oppervlak en geen lijn.
In de laatste stap krijgen alle kolommen een andere naam en worden ze gestructureerd tot ze overeenkomen met het formaat van het “all_data.csv”-bestand.
Model
Er werd een model ontwikkeld dat data van verschillende databronnen benut om een beeld te geven van de dichtheid van verschillende modaliteiten. Het ontwikkelende model bouwt verder op het rapport “Data fusion model for CityFlows” van de Universiteit Antwerpen. Dat model werd ontwikkeld in een PoC in de smart zone van Antwerpen. In de smart zone (waar veel databronnen aanwezig waren) werkte het model voor twee modaliteiten (wel en niet-gemotoriseerd). Binnen dat traject werd onderzocht of het model ook op grotere schaal (stadsniveau) en voor meer modaliteiten kan werken.
Het model heeft in essentie maar drie elementen nodig om te werken:
• “street_segments.csv” – Straatinformatie
• “intersections.csv” - Kruispuntinformatie
• “all_data.csv” - Data met de tellingen van de verschillende gegevensbronnen
Het model dient die input aan te krijgen als CSV-bestanden met een specifieke structuur. Op GitHub staat ook een voorbeeld van de roadcutter procedure. Dat is een procedure om de eerste twee bestanden (met straat- en kruispuntinformatie) te creëren. Als basis zal daarvoor het Vlaamse Wegenregister gebruikt worden. De roadcutter heeft als input ook het “all_data”-bestand nodig.
Voor elke beschikbare meting van elk van de niet-weerhouden databronnen is er een lijn in het databestand. Die lijn bevat ook informatie over de regio van de meting. Dat is belangrijk voor de roadcutter procedure. Daarnaast staan er in de lijn nog het tijdstip en enkele indexen.
De gewichten van de gewogen verdeling is optioneel. Die input is ook een CSV-bestand. De structuur van dat bestand is simpel: elke straat heeft een lijn en in de kolommen staan de gewichten per modaliteit. Als deze optionele input niet ingegeven wordt in het model zullen alle gewichten gelijkgesteld worden aan 1 en zal het model in feite dus een uniforme verdeling maken.
Output van model
De outputdata van CityFlows kan worden aangeleverd in het NGSI-LD formaat TrafficFlowObserved. Enkele attributen zijn daaraan toegevoegd om tot een werkbare standaard te komen voor CityFlows. Het bovenstaande dataformaat staat het toe om data in te geven:
• voor elk straatsegment in de afgebakende zone;
• voor elke vijf minuten - op voorwaarde dat er voldoende databronnen bestaan die deze mate van detail kunnen aanleveren;
• voor elke modaliteit - indien er voldoende sensoren zijn die de betrokken modaliteiten meten. In het kader van de voorgestelde scope zullen dat de volgende gemodelleerde modaliteiten zijn: voetgangers, fietsers, gemotoriseerd verkeer en de achtergrond (de personen die geteld zijn door telecomdata maar die niet actief deelnemen aan het verkeer).
Het model bepaalt de verkeersdichtheid (het resultaat van de modelberekening) voor elk van de bovenstaande gegevens. Daarmee kan men vervolgens de use cases per stad evalueren.
Datafusie
Het model is een datafusiemodel dat zo min mogelijk effecten of menselijk gedrag opgelegd kreeg om ervoor te zorgen dat het gedrag enkel in kaart gebracht zou worden door de data. Zonder a priori kennis van het wegennet bleek dat echter niet mogelijk. De wiskundige insteek bleek onvoldoende om het menselijke gedrag weer te geven.
Stapsgewijs werd er meer data aan het model toegevoegd om de hypothese dat het model betrouwbaarder zou worden naarmate er meer databronnen aan toegevoegd zouden worden, te kunnen bewijzen. Zoals eerder aangegeven, waren de resultaten daarvan teleurstellend.
Nog een ander effect was zichtbaar. De uniforme verdeling die gebruikt werd, was nog te zien in de output. Daarom werd er gezocht naar een gewogen verdeling. Die gewogen verdeling gaf visueel een beter beeld, maar zorgde uiteindelijk niet voor een verbetering van de resultaten op zich.
Validatieproces
In het validatieproces voor het model werden de data van Straatvinken gebruikt als ground truth.
Het model geeft zijn uitkomsten weer in dichtheden. Om de dichtheden van het model te kunnen vergelijken met die van de Straatvinkendataset moet het resultaat van die dataset eerst omgezet worden van intensiteiten (het aantal personen per tijdseenheid) naar dichtheden (het aantal personen per meter). De Straatvinkentelling houdt het gegeven “snelheid” echter niet bij. Aangezien dat gegeven noodzakelijk is voor het omzetten van de data wordt er een bepaalde snelheid verondersteld. Om één enkele validatiescore te krijgen, wordt de gewogen som genomen met de relatieve straatlengtes als gewichten. De validatiescore die daaruit volgt, is de gewogen verhouding van het aantal straten waarvan het resultaat ligt in een geaccepteerde zone (tussen de 66% en 150% van de Straatvinkendata). Zoals hierboven reeds vermeld zijn er stapsgewijs extra databronnen aan het model toegevoegd. Een dergelijke stap wordt aangeduid met een “learning cycle”. In Tabel 2 staan de validatiescores van de verschillende learning cycles en van de gewone en de aangepaste gewogen verdeling.
Uit de tabel blijkt dat het model een validatiescore heeft die grofweg tussen de 1% en 5% accuraatheid varieert, afhankelijk van het aantal gebruikte databronnen. Volgens de validatiehypothese levert het model dus in 1 tot 5% van de berekende dichtheden op straatniveau een betrouwbaar resultaat, een zeer laag resultaat. De hypothese dat de score zou stijgen zodra er meer bronnen toegevoegd zouden worden, is bij dezen dus verworpen. Ook de gewogen verdelingen leidden niet tot een verbetering van de validatiescore. Dit suggereert ook dat het design van het CityFlows validatieproces niet exact meet wat het zou moeten meten.
Resultaten model
Voor het controleren van de output van het model ontwikkelde imec een methode. De validatiescore (het resultaat van het validatieproces van imec) was laag en kon niet verbeterd worden door meerdere databronnen aan het model toe te voegen. Ook het toevoegen van de gewogen verdeling leverde geen betere validatiescore op.
In het rapport dat de basis vormde voor het CityFlows-project werd de hypothese naar voren gebracht dat andere databronnen toegevoegd konden worden aan het model. Die hypothese bleek te kloppen. Het is inderdaad mogelijk gebleken om databronnen te gebruiken die oorspronkelijk niet in het model zaten. Daarbij moet wel opgemerkt worden dat het belangrijk is om de context van de meettoestellen goed te kennen. De locatie van een ANPR-camera is bijvoorbeeld onvoldoende om te weten wat die camera exact meet. Het bemachtigen, uniformiseren en analyseren van de data vergde meer werk dan oorspronkelijk was voorzien. Het werk dat verzet is, is echter wel herbruikbaar voor verdere analyses van de besproken bronnen. Het kan ook gebruikt worden als een voorbeeld voor eventuele nieuwe gegevensbronnen in de toekomst.
Het kan gezegd worden dat het model vollediger is geworden. Het functioneert op stadsniveau en werkt met meerdere databronnen. Hoewel de input van de verschillende bronnen goed gefit worden, is de output van het model gelet op de lage validatiescores toch onbetrouwbaar.
Analyse toolbox
Een van de grote lessen van het project CityFlows is dat er nog heel wat uitdagingen zijn opdat lokale besturen effectief aan de slag kunnen met mobiliteitsdata. Enerzijds bleek het opzetten van een datafusiemodel geen sinecure: zowel het tekort aan data en de ongelijkmatige spreiding, kwaliteitsvolle data als het gebrek aan standaarden, speelden in belangrijke mate parten. Omdat er met het CityFlows project wel een antwoord gevonden wou worden op de use cases van de steden werd een Analyse toolbox ontwikkeld.
Om lokale besturen toch een beter inzicht in bestaande mobiliteitsdata op hun grondgebied te verschaffen, ontwikkelde imec een analyse-toolbox die de huidige datameetpunten in de stad visualiseert en de voor- en na-situatie van een mobiliteitsingreep statistisch toetst. Samen met de twee pilootsteden, Mechelen en Gent, werd de analyse-toolbox verder vormgegeven. De toolbox kan worden ingezet in de dagelijkse praktijk van de mobiliteitsambtenaar: mits het opladen van de beschikbare databronnen per stad kan je analyseren wat de huidige situatie is en hoe deze verandert na de implementatie van een ingreep in de mobiliteitsstromen van de verschillende modi van de stad.
Interessante linken
De codering van zowel het model (opent in nieuw venster)als de toolbox (opent in nieuw venster)zijn open-source ter beschikking gesteld, met bijhorende guidelines.
Om zeker te zijn dat de toolbox voldoende toegankelijk is voor de steden werd er ook een instructiefilmpje opgesteld dat hier terug te vinden is.
Het rapport over het project CityFlows kan je hier vinden.
De website van het CityFlows project kan je hier vinden