Ideas to make Ozone better - both for users and contributors!

[Milind220]

What do you guys think we could add to Ozone to make it a more useful package, or a better project for contributors to help out with?

Any awesome features that you can think of?

All ideas are welcome!

[lahdjirayhan]

Does the returned AQI value change/update a lot in a short timespan? If not, then caching may be a good feature.

I'm not really sure if it's a definitely good idea, though, so please take my opinion with a grain of salt.

[Milind220]

@lahdjirayhan Also, it's probably a good idea, from a development standpoint, for us to know exactly how often the data is updated (if there's a fixed frequency at all). Good new issue to file!

[lahdjirayhan]

@Milind220

With caching, if a user calls a method with the exact same parameters (say get_city_air('London')) twice in a row, the second call won't be executed. Instead, the first call's return values are given again in the second call. This means the we won't need to send a request, parse the response, construct the DataFrame, etc. twice. Which (I think) will improve performance.

The caching I was thinking is functools decorator @lru_cache.

[Milind220]

@lahdjirayhan I understand what you mean now. While I don't think this is a major issue (most people won't repeatedly want the exact same data over and over in a short period of time, the requests go through pretty fast), there's no harm in speeding up the API further.

This would be useful as long as we ensure that the cache is cleared when new data is available, or even when the user ends the program.

But this does bring up a potential issue - caching this data using the @lru_cache decorator stores it as a dictionary in memory. If every API call were cached, wouldn't this make Ozone very memory heavy?

[lahdjirayhan]

@Milind220 If I remember correctly, cache size can be limited so I don't think it will make it memory-heavy.

Now on the other hand, you're right: this is a minor issue and we haven't seen the necessity in implementing it.

[Milind220]

@lahdjirayhan I think this would be a little unnecessary considering that there's no urgent requirement for it. But thanks for the suggestion though! If we ever do run into this problem, then your caching solution can be our go to fix for it.

[Samxx97]

Hey @Milind220 i have an idea for a cool new feature we can add to ozone , is this where I can share it ? or is this thread only for fixes ?

[Milind220]

@Sam-damn Yess, this is the perfect place for it!

[Samxx97]

Alright so here is my idea:

Currently all the data that we offer for our Users is in raw numerical form and that is great , but i think some users would benefit greatly if along the data we provide that we also provide a visualization of some sort that would better convey the meaning of the data in an easier to digest form , and honestly the first thing that pops in my head is a map, we can offer Geographical map image or even an HTML file (like folium does) showing each place or country with a color tint spanning those regions in question, and those colors would of course come from the AQI meaning and levels that we already fetch from the API, and this is just an idea, the general consensus behind is:

Ozone currently just fetches data from API and provides it to the user in its raw form , it would be nice if we can do some sort of processing on that data (perhaps even machine learning) and provide more services that the user of the library would be too lazy to do themselves.

would love to hear your opinion on this @Milind220 :)

[Milind220]

@Sam-damn I actually love this idea!

Doing some data analysis and visualisation for users would be awesome, and would motivate more people to use Ozone.

I've been doing some research for the map visualisation thing myself as well, and I found this great article which I thought could guide someone to add this feature for Ozone. The author of the article uses the same WAQI API to make the map visualisation in a very similar way to how you describe it.

• Let's think about how this would integrate with Ozone though - structure wise. If we plan to add some visualisation/analysis features, it might be wise to create a separate module or package within Ozone for better code compartmentalisation.

The machine learning part sounds great too - the current forecasting data offered by the WAQI API is kinda strange as they don't tell us what ML model/methodology they use to get it.

[Milind220]

For now, I think at least a separate module within ozone definitely makes sense. This would separate the visualisation/analysis code to avoid an extra long, cluttered, monolithic file.

[Samxx97]

Great:) @Milind220 the article that you linked is exactly what i had in mind. this is uncanny hahahah

and yes we should definitely plan how to integrate this in a seamless way, i think a separate module like you suggested is a good starting point

[lahdjirayhan]

Here's another idea for a feature: a command-line interface.

[Milind220]

OH yesssss absolutely. That's a wonderful idea, and a decent sized undertaking too (great for more contributors to join the fun). Let's look into this and the basic map data visualisation methods after we get the historical data function merged in.