How we did a project about hidden economy of parking places in Kyiv
What is actually going on at Kyiv’s parking lots? We were curious about the matter back in 2016, after the disclosure of financial statements of the municipal community-owned enterprises.
It came to our knowledge that the Kyivtransparkservis (community-owned enterprise in charge of parking places, KTPS below) has been incurring millions of hryvnias of losses annually for a few years in a row. Explaining the losses in their statements, the enterprise grumbles about technically obsolete parking machines and impossibility to pay in cash to a parking assistant (which was prohibited long before 2017).
Meanwhile, the parking lots in the downtown are overcrowded, most of the drivers do not use parking machines, but instead hand a ten-hryvnia note to a parking assistant without asking for a receipt. During our investigation we found cases when parking assistant would thrust a hundred hryvnias into the parking machine, but snatch the rest. Part of the money were used to provide a kickback to the higher level management, probably. Of course, KTPS statements are completely silent about the unaccounted cash.
Thus, we decided to assess how much money one might actually collect from a downtown parking lot. So we recorded some of the parking lots on video and then calculated the number of cars. Next we compared our results with the KTPS data for these parking lots for the same period of time.
We (semi-randomly) picked three locations: Ciklum office in the Gulliver shopping mall, office of the Institute for Mass Information at Velyka Vasylkivska Street and “European Pravda” newsroom at Suvorova Street. We had to record the first parking lot twice due to the memory chip failure.
When we started watching the records, we understood that automatic car counting in our circumstances is impossible. The camera had wide angle lenses and was located far from the parking lot, thus even a person counting cars manually sometimes had difficulties with distinguishing two separate cars from the same car appearing on the video twice. It turned out especially difficult in the evening, when the sun sets and throws flecks of light to the lenses.
Automation of the manual work
Thus, we had to count cars manually. We wanted to make this process as automated as possible to save more time. So we chose the following methodology: we would cut the video into frames with the 5 min interval, count the cars on the parking lot in each frame and record the number of cars in the table.
The ffmpeg utility allowing to cut video into frames with 5 minutes interval. After these operations we were able to perform counting for 3 days’ records of parking lots in about 4 hours of manual work.
However, the idea of finding an automated counting method lingered in our minds during this work. We obtained an interesting result by selecting the same column of pixels which intersected parking zone on each video frame and stitch such columns together in one image(it was made with a help of python and OpenCV). In such a way we could compress a few hours of video into one picture, as below:
This visualization allows to estimate the filling of the parking lot during the entire day. Each car leaves a horizontal track with a same color profile, the length of which shows the duration of stay. We played with this approach a bit and decided that we cannot count automatically, but were able to use it to assess how full the parking lot is at the given moment, as well as estimate an approximate percentage of cars which stop by for less than 15 minutes (free of charge period).
Results
Having counting the cars, we calculated daily revenue of each parking lot. It turned out that only 10–20% of the actual possible revenues are declared!
Interactive content
The key idea of interactive visualization in this material is to present a visual proof of the collected data. Thus, a reader may calculate the cars in each frame and be assured that we are not mistaken and our data correspond to the actual situation.
On this widget when one moves the mouse along the chart, the video moves too. The approach to split video on frames along the timescale and insert the necessary image in the html is not optimal: each random movement of the mouse would generate a hundred html requests. So this approach works very slowly and the video is not running smoothly.
Finally, we decided to combine lots of separate frames in one very long picture, and connect its position to movement of a mouse. The resulting image is something like a film tape. However, we faced the first limitation: JPEG format limits the maximum height or width to 65535 pixels (because only 2 bytes are allocated for this parameter).
That’s why we had to divide each “film tape” into a dozen of pieces and substitute the necessary part of the “tape” depending on the cursor position at the chart. Visualization started working faster; however, there appeared an unpleasant flickering when one image was changed for the other one.
This behavior turned out to be browser-dependent. Firefox sometimes re-loads the already downloaded pictures and shows white background while the image is downloading.
We found a solution. Instead of substituting a link to another picture each time when it has to be changed, we keep blocks for all pictures in a way when they are stacked one over another, and the image to be displayed is on top of the stack (with the highest z-index parameter).
As the result of this, this widget showed high-speed performance — our “quasi-video” could be scrolled really quick.
Below you could see some unpublished versions of our UI for this project.
Lastly, we opted for a simplified option reflecting only minimum necessary information about the parking lot, the chart with the dynamics of the number of cars and a window with linked video:
You could see the project in full here http://texty.org.ua/d/parkings/
(in Ukrainian)
