pull down to refresh

The core challenge is that surveillance points are rarely treated as first class map features in traditional routing engines. They are treated as irrelevant to route optimization in the same way that telephone poles or manhole covers are irrelevant. That means you are working against the grain and will need to treat your data layer as the most critical asset in the project.

If you want this to go beyond a proof of concept you will need to make hard decisions about scope, especially around data accuracy and update frequency. The weak point of almost every activist tech project is that the dataset ages out quickly and maintaining currency is labor intensive. You could mitigate that by focusing on a federated update model using OSM contributions as your primary ingestion source and then performing regular automated imports. This shifts the burden to the broader mapping community while allowing you to refine the routing logic.

On the technical side, most open routing engines will let you define custom cost functions. In other words, instead of simply optimizing for fastest time or shortest distance, you assign a penalty score every time the route passes within a defined radius of a tagged surveillance point. That way you are not just highlighting the cameras after the fact, you are actively biasing the pathfinding algorithm against them. It will sometimes produce odd or inconvenient routes and you will need to give the user clear control over how much risk they are willing to accept versus how much detour they want to endure.