![]() ![]() Note one thing, though, that will be relevant when we create the Power BI dashboard – the time reported by the WSDOT web service and forwarded to our Event Hub is UTC, so the above table is really showing traffic around 1pm Seattle time, not 8pm. We can take the data for the last few weeks and filter it for (Road Name = 520 AND Location Description = Midspan), map the Flow Value to a color, and voila, the eastbound traffic pattern emerges: As I mentioned earlier, I am interested in the traffic on the I-520 bridge as I have to commute over it. Now we just have to get this data into Azure, but it is worth going on one last tangent before showing how to construct the Power BI dashboard. The first row of the data shown above would be parsed and formatted as follows:Īnd here is an export to Excel of a few of the 5,742,180 records received in 3 weeks (yes, 5.7M records!): In the TrafficFlow worker role we parsed the data as JSON and shortened the names provided by the WSDOT schema. Sample code, which you will need to modify, is available on the TrafficFlow branch of ConnectTheDots on GitHub. To get the data from the WSDOT web service we wrote a simple Azure worker role that pulls data from the WSDOT URL shown above every 20 seconds, parses the data stream, and immediately sends it to an Azure instance of the ConnectTheDots gateway. Now it is just a matter of getting it into Azure and Power BI. The site also contains a button to request the access code to include in the web service call. If you want to understand the traffic on the roadways, selecting the Traffic Flow link shows the function calls and fields retrieved, and the Help link shows how to call the service: This data is accessed through a single gateway and API, as described on their website at. ![]() Most are updated hourly, some as frequently as every 20 seconds. I thought it might be a daunting task to collect that data, but fortunately the Washington State Department of Transportation provides data for 170 permanent traffic recorder locations in Washington State, including those two highways. I really, really care about the traffic on the two bridges separating Seattle and Bellevue (on highways I-90 and I-520), as I have to drive over them daily. Since I live in the Seattle area, I am interested in knowing about the traffic in the state of Washington. Once we have pulled data from the WSDOT web service and sent it to an Azure Event hub, the rest is basically the same as we did last time. Instead of connecting the data sources (sensors in the previous blog, the WSDOT web service in this one) to a gateway running on a Raspberry Pi, we will run that same gateway code in Azure. To keep things simple, I’m going to use the same basic infrastructure to get the traffic data into Power BI, as I used in the previous post – with a twist. There is lots of valuable information, however, in public data sources which it would be great to be able to munge and view. The constraint in that scenario is that those sensors need to be ones which you can access and program, and probably own. In a previous post, I showed how to get data from IoT sensors into Azure and Power BI based upon a simple infrastructure that we published in an open source project called ConnectTheDots. Who hasn’t wanted to have a personalized view of the vehicle traffic on the route to and from their office, for example? Let’s do it by getting data from a public data feed into Azure and Power BI! At the same time, this will serve as an example of how to get data from thousands of public data feeds and visualize them with Power BI. Today we have Spyros Sakellariadis, joining us again to continue our series of how to use Power BI to monitor real-time IoT events. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |