Cameras Map

Vizzion's Camera Map sample application illustrates a number of considerations when developing an application that displays cameras on a map, including downloading large numbers of cameras, maximizing responsiveness,keeping data fresh, and observing rate limiting.

The full sample application source code is available for download.

Downloading Large Numbers of Cameras

Vizzion’s Camera API includes hundreds of thousands of roadside and hotspot cameras. This is a significant data payload, and a commonly encountered issue is that calls to methods such as GetCamerasInBox will often timeout if a very large geographic area is requested. In this sample application, the continental USA is divided into several smaller tiles which are downloaded separately, reducing the possibility of a timeout.

Another technique demonstrated by this sample app is downloading and showing only in-service cameras. By default, both in-service and out-of-service camera data is returned from methods such as GetCamerasInBox. Using the “in service only” option (option 32) significantly reduces the number of cameras to download, particularly when using hotspot cameras.

Maximizing responsiveness

Few mapping systems can provide a responsive experience with thousands of items. This sample app uses the GetRegions method to show markets, instead of cameras, when zoomed out. This reduces the number of items to display to a few hundred, even when displaying an entire continent. When a market is selected, the map then shows just the cameras in that market:

Keeping Data Fresh

Camera data in Vizzion's traffic camera database updates at regular intervals. Cameras may suddenly go out-of-service as a result of power failures, cabling problems, equipment failures, and more (see Out-of-Service Cameras). It is recommended to automatically refresh camera data at least every 15 minutes to ensure camera in-service/out-of-service status stays up to date. A refresh rate slower than 15 minutes will cause a larger number of out-of-service cameras to be visible in the application. Similarly, a slow refresh rate will cause fewer in-service cameras to be available. This sample app employs a timer to request fresh camera data every 15 minutes. The data is requested asynchronously so the app can continue to be responsive while fresh data is downloaded. Once the data is downloaded, the data used by the map is replaced.

Since this app also uses data for market locations, the market data is similarly refreshed with a timer. However, market data changes much less frequently than cameras, so the timer interval is set to daily.

Observing Rate limiting

Every customer has a limit on the number of concurrent requests that can be made to the API. Your account manager can provide the rate limit for your account. Exceeding the rate limit will result in an HTTP 429 error.

This sample app downloads camera data by dividing the full coverage area into numerous tiles. This avoids any timeouts associated with excessively large data downloads. However, downloading all the tiles sequentially may not allow the data to be refreshed every 15 minutes. But downloading all the tiles concurrently would exceed the assigned rate limit. Instead, the code allocates a limited number of threads to download the tiles. The number of threads is less than the assigned rate limit. Since there are more tiles than threads, the app waits for another thread to be available before downloading another tile. In this way the assigned rate limit is always observed, while also minimizing the total download time.

Note: Ensure that your platform has been configured to allow multiple concurrent connections to the API. For example, .NET requires the ServicePointManager “ConnectionLimit” property to be increased from the default value of 2.

Downloads

Download	Details
Source code	Requires Visual Studio 2012 or later

Vizzion Confidential and Proprietary