There are currently only 3 ways to deal with this: one is to ignore it and cut the roots to make way for utilities, irrigation, etc. This will result in tree decline/death. The second is to use a high pressure air knife to excavate the roots starting from the trunk and working towards the construction site. This is messy and time consuming, but effective. The final is to use ground penetrating radar (GPR) to survey the land from the tree to the construction area to find the roots. I believe this is more expensive, probably much more time consuming and the data is difficult to interpret as the radar signature for earth and root and man made object varies very slightly (and some materials prohibit wave penetration very far). It does have he advantage of being unobtrusive and doesn't require digging down 1 to 3 feet of soil to find all the roots which a lax/quick excavation may miss.

So my idea came from a mixture of my reaction to a GPR presentation and day-to-day experience with removing trees. What about GPR in reverse, so to speak? I noticed that when standing 'near' (by the dripline)a tree undergoing removal, there is an perceptable vibration in the ground as the chainsaw bites into the trunk of the tree. I wondered if there would be some way of analyzing that vibration on a seismographic network spread out around the tree. I propse you would place some sort of non-destructive 'thumper' (ala dune) on the trunk to produce vibrations through the trunk at varying amplitudes and frequencies and pick these vibrations up from the siesmographic network that you've spread out around the tree. I imagine the big trick is going to be filtering out the noise and tuning it to such precision that you'll be able to 'see' (difference between baseline earth vibration and earth-with-root-through-it-vibration) the basic 2D root structure as it is propagated through the earth. I imagine some pretty hefty controlled testing will be required to filter out the fact that sensor A will be getting vibration 'noise' from the root structure all the way across the tree that sensor B is there to detect! Perhaps some fancy 'noise comparison' software that find the similar noise frequency and edit it out?

So there's no real benefit to this compared to GPR in that when all is said and done and the funding and kinks have been worked out, you just sent up your fancy network in the morning, break for lunch as you collect the data, and analyze the data in the afternoon. GPR seems to take about the same amount of time and you're just exchanging walking-the-radar-around-slowly-time for installing-the-sensor-net-time. Perhaps it would be a good comparison model for GPR to stand up against. But it was pretty fun to contemplate:).