The data signals used for LEDs is usually pretty fast, and has limits on total transmission distance. You can slow down clocked LEDs like the APA102 to make them more reliable over longer distances, but then you are slowing down your frame rate, especially if you are also adding more LEDs to control at the same time. There are long range transceivers that can be used, but that adds cost and complexity and more wiring. So I think one PB per tree will be simpler, though that means you have 24 PBs instead of 4.
From a pattern/software perspective, I’d pixel map the rings identically. The pixel map implementation doesn’t have the resolution to encompass the entire forest (though it could work for smaller installations). Then, like @jeff recommends an X and Y offset can be combined with the local x, y from the pixel map…
I plan to add some tools to help this that will be very similar. The local pixel map will still normalize everything to “world units”, which will then get scaled and offset. This can make them effectively cover a small higher-resolution part of the global coordinate space (or even scale outside of the 0-1 range, though pattern compatibility would be best within that range). This would be totally compatible with the existing render APIs.
The Firestorm and exported var hack @jeff mentions would let you do something pretty similar with only small code changes to patterns.
As an alternative, you could put the local offsets into the patterns, but then you have 24x slightly different patterns to maintain. I think Jeff’s approach is slicker.