There are many ways to deal with this, but a few stand out as being general and effective. To understand this, let's enumerate a few of the problems that might have to be dealt with:
There could be gaps between poles that are so great, the algorithm might view the gaps as being actual breaks in the transmission system.
There may be some short segments of road, crucial for connecting the roads into a network, that nevertheless do not have any poles near them. These segments would not be selected by proximity to poles but are a necessary part of the solution.
There may be poles not accessible by road from the central point. These poles might be parts of other transmission networks originating from other central points.
I am also adopting the stance that since you already have a polyline network (the roads), it would be advantageous to exploit it rather than connecting the pole points with a completely new polyline, which is likely not to parallel the roads very well.
These considerations suggest that the ingredients of a good solution would include a few key steps:
Compute the road distances from the central point to all poles.
Identify the poles that have locally maximum distances along their particular road segment: that is, none of their neighbors along the same segment have greater distances.
Form the shortest paths back from these local maxima to the central point.
The union of these shortest paths would trace out the transmission network. (Indeed, step 2 is not really necessary, but it would greatly reduce the computation involved in step 3.)
Steps 1 and 3 can be carried out using a network representation (in Network Analyst) or a raster representation (in Spatial Analyst, using a CostDistance or FlowAccumulation calculation). Step 2 is a straightforward database summary: after step 1, each pole will have its road segment and distance as attributes. Find the maximum distance by road segment and select the poles attaining those maximum distances.
There are some potential problem situations:
Some poles might not be close to roads. There's nothing in the problem statement that tells us what should be done about these. They can be handled automatically with raster calculations (an appropriate cost grid will assign high impedances to non-road cells, but not infinite impedances, allowing isolated poles to become connected to the nearest roads, but not to each other, unfortunately). At the least, after obtaining the solution in step 3 you can select all poles not on that network and consider how they should be handled (perhaps by manually creating connections for them or maybe with a Euclidean minimum spanning tree solution).
If some road segments form loops, you should skip step 2, for otherwise portions of those loops may be lost.
The road polylines might not actually form a connected network. There can be tiny gaps between road segments (sometimes just millimeters in size) that split up a network that appears visually connected. This is a data quality problem that would plague any solution, except for some of the raster-based ones.
At one point I mentioned FlowAccumulation in passing. This may surprise people: what does this problem have to do with streams and watersheds? Stare at the image for a while. Imagine the origin point as the low point on a landscape and the roads with telephone poles as traces of streams flowing toward that low point. If we can create a surface for which the roads really are the streams, then we can let a little "rain" fall at the location of each pole and flow downhill. The points that get wet are the solution we seek: they connect the poles efficiently into a network that follows the roads. An appropriate CostDistance calculation--with low nonzero impedance along the roads and extremely high but not infinite impedance off the roads--will create exactly that kind of surface. Another way to create that surface is from the Euclidean distance grid for the roads. That's perfect, except the roads are level. They have to get tilted; for this, add an extremely small multiple of the distances along the roads to the Euclidean distance grid. (The road distance still requires a CostDistance calculation, which is expensive, but this time it only needs to be carried out for road cells, rather than all grid cells, which will speed it up by orders of magnitude. That permits us to use an extremely high-resolution grid if we like, thereby avoiding possible discretization errors made with coarse grids.)
