As mentioned in my comments, your question is very broad (if not too broad, to be off-topic here). But let me try to give you a grasp:
will be gathered and displayed on site ...
is data collection a use case , if it is who will be the actor?
Yes, data collection is a use case that is a precondition to your primary identified use case of viewing the data ("displayed on site").
The point of use case diagrams is mainly to identify what happens inside / outside of your well defined system boundaries. Definition of the system boundary is essential, so a first approach for a diagram might look as follows:
Actors are elements that exist outside your system boundaries and either trigger actions provided by your system, or being triggered by your system to do something.
The Actors can communicate with your system actively or passively. That can be expressed with directed associations in UML.
Use Cases have to reside inside your system boundaries, and will describe (even in pure textual form), how the interaction with the Actors should be done in more detail.
As shown in the above diagram, actors may be more specialized by means of how they interact with your system (database).
A system boundary and description is dependent on identified requirements in first place (this might be also part of contracts with 3rd parties, and worth being payed or not!).
Actors can be generalized (specialized) as shown above.
If you have identified your systems primary use cases, you may want to break these down, to identify more specific sub-systems (and extended use cases), and interaction with your specific Actors, e.g. like:
As the ole' saying goes:
"A picture can be worth to tell more than thousand words, though picture interpretation might need whole libraries to be written!"
Anyways, UML is a generic (picture) language, and comes along with specifically agreed interpretations (only a single book, instead of a whole library).