Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix sunrise/sunset scatter plots #16

Merged
merged 4 commits into from
Mar 12, 2024
Merged

Conversation

cdkl
Copy link

@cdkl cdkl commented Mar 8, 2024

This bug has affected me for a while! I finally got to fixing it now that there's an active fork to benefit from the fix. :)

Sunrise/sunset scatter plots are misplaced for

  • Date ranges that are a subset of the entire DB date range
  • Species whose first/last detections are inside the bounds of the current date range.

This fixes those problems by using the same date range as the heatmap data. Before, it was making a simple date count from "now" without paying attention to the date bounds of the heatmap data.

To see these heatmaps and reproduce the problem:

  • launch "Species Stats"
  • On the left, select "DAILY"
  • (a) use the date range sliders to narrow the date range and pick a species on the right, or
  • (b) leave the date range as is, and pick a species on the right that you have sparse detections for
  • BUG: The sunrise/sunset lines will be wrong for the dates shown.

Additional notes:

There are a lot of issues from this code that come from the original repo. The heat maps are beautiful if you've been running birdnet-pi for a while, but they are very slow!

I see a lot of room for improving the performance here, because it basically works with your entire DB starting with a "SELECT * FROM detections;" I have close to 700K detections on my system (mostly Canada Geese, I live by a river) and the Species Stats pane takes several seconds to work. Narrowing date ranges makes it incredibly slow. Plus, the way that the heatmap can be different than the date range selected isn't ideal, but I'm not fixing that here yet.

So this is a "simple" fix just to get the sunrise/set lines to align, as I get to understand how pandas and plotly work.

Below are some images of before/after this fix on my system:

Before: Eastern Phoebe (active just before dawn). Despite a full date range selected, the heatmap stops in October (when they left last fall) but the sunrise/sunset dates are for the full period.
Screenshot 2024-03-07 8 52 35 PM

After: the sunrise/sunset dates respect the inputted date range.
Screenshot 2024-03-07 9 01 21 PM

Before: Canada Geese, for a narrowed date range. The geese are most active around sunrise/sunset, but the sunrise/sunset lines don't match the dates (note how despite it being summer, sunrise is getting "later" - red arrow)
Screenshot 2024-03-07 8 55 43 PM

After: Canada Geese activity aligns with sunrise/sunset, and the summer solstice has the earliest sunrise again (green arrow)
Screenshot 2024-03-07 8 59 39 PM

Let me know if you have any questions or concerns. :)

cdkl added 3 commits March 7, 2024 21:38
Sunrise/sunset scatter plots are misplaced for
* Date ranges that are a subset of the entire DB date range
* Species whose first/last detections are inside the bounds of the current date range.

This fixes those problems.
@lloydbayley
Copy link

This is an interesting discovery. Not one that I had considered before. I must admit, I don't go into Species Stats much and tend to let that part of it run itself, however, on investigation, the logic is sound. I would have missed that problem.

latitude = df2['Lat'][0]
longitude = df2['Lon'][0]
def sunrise_sunset_scatter(date_range):
latitude = df2['Lat'][-1]
Copy link
Author

@cdkl cdkl Mar 8, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Use the most recent lat/long in the db for finding sunrise/sunset times.

Not strictly necessary but I had a secondary problem that others might have: My initial lat/long configuration (back when I first set up birdnet-pi) was wrong. Why does this matter? Well, the existing code uses the earliest lat/long it can find in the database! I cleaned up my data a bit, but decided to include this change.

This is a simple change that uses the latest lat/long in the database. I figure that's going to be as or more correct pretty much all the time. (Ideally, this would instead do an actual configuration lookup instead of inferring from db detection records.)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well-done! That is a good find! There's been quite a lot of people over the years who didn't initially set their lat/lon and did it afterwards. That would indeed result in the problem. I see what you mean about config lookup too. I agree that it would be ideal. Never looked at the code in Species Stats. Might have to familiarise myself with that!

Copy link
Owner

@Nachtzuster Nachtzuster left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I forgot to actually submit my review :-(

Comment on lines 184 to 185
latitude = df2['Lat'][-1]
longitude = df2['Lon'][-1]
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You could import

def get_settings(settings_path='/etc/birdnet/birdnet.conf', force_reload=False):

and then:

Suggested change
latitude = df2['Lat'][-1]
longitude = df2['Lon'][-1]
conf = get_settings()
latitude = conf.getfloat('LATITUDE')
longitude = conf.getfloat('LONGITUDE')

If you don't feel like doing that (now), please add a your explanation in a comment.

Also, if your git foo allows it, I would prefer this change and the actual fix in two separate commits.
Apart from these nitpicks, great fix, Thanks!

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes! that's a great idea. This can be a separate change. Let me adjust this merge request to use the old lat/lon method, and I'll prep separate changes for this.

We'll enhance this separately
@cdkl
Copy link
Author

cdkl commented Mar 12, 2024

@Nachtzuster look for a separate MR for the lat/lon config settings changes. I'll do that after this goes in, just to simplify my own workflow. Assuming no other issues, I think this is ready for merge.

@cdkl cdkl requested a review from Nachtzuster March 12, 2024 22:07
@Nachtzuster Nachtzuster merged commit 37b023b into Nachtzuster:main Mar 12, 2024
1 check passed
@lloydbayley
Copy link

Well-done to both of you. That is quite the elegant solution. Less fuss having two separate PRs for that! :)

@cdkl cdkl mentioned this pull request Mar 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants