Lots of constructor parameters - Is there a better way?

In this case composition might be a good fit. Especially since there are some parameters that belongs to specific categories.

For instance:

public int WindSpeed;
public string WindDirection;
public decimal WindDegrees;

Create a new object for them and then access the different values as:

weatherData.Wind.Speed;

and pass the new wind object to the constructor:

var wind = new Wind(xmlData.WindSpeed, xmlData.WindDirection, xmldata.WindDegrees);
var weatherReport = new WeatherReport(wind, /* .... */);

I would also introduce a few enums. Because as of now, the users of the weatherReport would for instance have to know which values the string WindDirection can have. If you convert the string to an enum instead it's a lot easier to use the different values.

A final note is that I typically only use constructors if the are some values that really have to be specified for the class to have a valid state. For instance, in your case the minimum valid state would be a date and the temperature? Then just put those in the constructor.

Re Is there a better OOP approach?

A large number of properties on a class can often indicate a need for splitting the class up (the Single Responsibility Principle of SOLID).

e.g. It would appear that HourlyForecastData models Wind (speed and direction), Precipitation (Snow, Dew and Rain), and Temperature (Min, Max ...) These concerns can be split into separate classes, and then the HourlyForecastData would be a composition of the three.

Re : Builder Pattern

The Builder Pattern can be useful to ease the burden during construction of large (often immutable) classes or graphs, but would obviously require additional (mutable) Builder class(es) to build up the target class representation (i.e. HourlyForecastData) and eventually create it (viz, by constructing it immutably by passing it all parameters to the constructor). So it isn't less effort, if that is what you required by 'better', but this can certainly can be easier to read e.g.:

HourlyForecastData todaysForecast = new HourlyForecastDataBuilder()
   .WithBaseline(ObjectMother.WinterSnow) // Provide an archetype
   .WithPrecipitation(snow: 5, rain:1) // Dew defaults to 0
   .Build();

Baseline archetypes / object mothers would be useful if the weather patterns in an area were frequently stable and just required small adjustments. IMO builder pattern is most useful in Testing. I can't see an obvious fit in an Xml Serialization usage.

See also Named and Optional parameters

Re: Immutability

A private setter technically still allows mutability, although restricted within the class itself. C#6 and later supports getter-only auto properties which is the simplest form for implementing immutable properties

public class HourlyForecastData
{
    public DateTime DateTime { get; }
    ...

    public HourlyForecastData(DateTime dateTime, ...)
    {
        // Get only auto properties can only be set at construction time
        DateTime = dateTime;
        ...

Unrelated, but Scala offers an even more concise syntax than C# for defining immutable public properties on a class, by declaring them once in the (primary) constructor:

class HourlyForecastData(val temperature: Int, val station: String, ...) {
}

Without the need for any further property or backing fields, whilst expressing and enforcing immutability. However, the burden still remains on the caller to provide all the parameters (whether directly, or via Builder, etc).

Re : Xml If you are offering an API, I would suggest using WebAPI. Instead of building Xml serialization concerns into your DTO classes, I would suggest instead on relying on Content Negotiation. This will allow the caller to determine whether the data should be returned in Xml or JSON format.

* Note however that Xml Deserialization technologies often make use of reflection to populate DTO properties, which MAY require that the serializable properties have setters (even if private).