Just get the data as a Tables.Table compatible object?

[nilshg]

Sorry if I'm being thick here, but is there no way to just get historical data as a table?

I can see the hist_plot functions, as well as the export_to_sqlite functions, but get_hist_data is unexported and undocumented and I can't seem to get it to work.

(somewhat relatedly, this package could be a lot more lightweight if all the plotting and database functionality were to be put in an extension)

[nilshg]

A minimal change to enable this would be to define

function get_hist_temp_data(city::String = "",
    i_row::Int64 = 1;
    lat::Float64 = 0.0,
    long::Float64 = 0.0,
    start_date::String = "2023-01-01",
    end_date::String = "2023-01-10")

# Get city based on user preference
if isempty(city) && (lat == long == 0.0)
city = get_city()
end

df_temp, time_zone = get_hist_temp_data(city,
                        i_row,
                        lat,
                        long,
                        start_date,
                        end_date)

    return df_temp
end

and then export get_hist_temp_data - happy to create a PR if this is agreeable.

[vnegi10]

Sorry if I'm being thick here, but is there no way to just get historical data as a table?

I can see the hist_plot functions, as well as the export_to_sqlite functions, but get_hist_data is unexported and undocumented and I can't seem to get it to work.

(somewhat relatedly, this package could be a lot more lightweight if all the plotting and database functionality were to be put in an extension)

Hi @nilshg, I am glad to learn that you found this package useful. The functionality can indeed be refined further. Unfortunately, I haven't had the time to actively work on it during the past year. All suggestions are welcome nonetheless!

get_hist_data is not exported since it's meant to be an internal helper function. General practice is to keep such functions hidden from the end user. In case you want to make use of it, you will need to call it in the following manner: PackageName.some_function

julia> using WeatherReport

# These are just dummy defaults, actual lat/long will be determined based on the city name.
julia> lat, long = 0.0, 0.0
(0.0, 0.0)

# Row index 2 will select Europe/London as the timezone
julia> df_rain, _ = WeatherReport.get_hist_data("rain", "London", 2, lat, long, "2024-01-01", "2024-03-31")

[ Info: More than one match found, showing report for location in row 2.
[ Info: You can select another location by its row index.
6×4 DataFrame
 Row │ CITY     TIMEZONE             LATITUDE  LONGITUDE  
     │ String?  String31             Float64   Float64    
─────┼────────────────────────────────────────────────────
   1 │ London   America/Toronto       42.9834   -81.233
   2 │ London   Europe/London         51.5085    -0.12574
   3 │ London   America/Chicago       35.329    -93.253
   4 │ London   America/New_York      37.129    -84.0833
   5 │ London   America/New_York      39.8865   -83.4483
   6 │ London   America/Los_Angeles   36.4761  -119.443
(2184×2 DataFrame
  Row │ TIME                 FORECAST 
      │ DateTime             Float64  
──────┼───────────────────────────────
    1 │ 2024-01-01T00:00:00       0.0
    2 │ 2024-01-01T01:00:00       0.0
    3 │ 2024-01-01T02:00:00       0.0
    4 │ 2024-01-01T03:00:00       0.0
    5 │ 2024-01-01T04:00:00       0.0
...

You now have a DataFrame df_rain with the following structure:

julia> size(df_rain)
(2184, 2)

julia> names(df_rain)
2-element Vector{String}:
 "TIME"
 "FORECAST"

Let me know if this works for you.

[nilshg]

Sure this works (although I didn't manage to do this myself before, I got some inscrutable error when calling the unexported function which isn't surprising given it's undocumented). My point is that I would assume my use case - needing weather data to feed into some wider analysis - is fairly common, so exporting a function that gets you the data as a Tables.Table compatible object and documenting it would be useful.

Like I said above, happy to make a PR for this.

[vnegi10]

I got some inscrutable error when calling the unexported function which isn't surprising given it's undocumented).

Were the HTTP calls stuck? This could be due to an issue with the Open-Meteo API itself. Some of them were unresponsive yesterday afternoon (CET), but seem to be working okay today.

My point is that I would assume my use case - needing weather data to feed into some wider analysis - is fairly common, so exporting a function that gets you the data as a Tables.Table compatible object and documenting it would be useful.

It's a common use case indeed, but feels more suited as a functionality to be implemented in an Open-Meteo Julia client. For example, something similar already exists for Python. If you have the time and motivation, you could think of creating one.

When developing this package, my focus was on generating a visual report/plot tailored for the REPL. 😉 Hence, the specific exports.

Like I said above, happy to make a PR for this.

Sure, go ahead and make one.

Changes seem rather straightforward. The functions get_hist_temp_data and get_hist_data already exist in helpers.jl. You need to update the signature to add some defaults (for lat/long etc.) and then export them by updating the module definition. Adding a descriptive docstring will be a nice cherry on top.