Caption: If you are atlasing the Wildlife Drive of Blackwater NWR, a block boundary cuts across the road. If you create two checklists, one on each side of the block boundary, but assign both to the Wildlife Drive hotspot, Checklist 1 will have an incorrect location associated with it. Instead, a personal location should be created for Checklist 1.
Atlas blocks provide a way to map out species occurrence, sure, but more importantly they distribute effort across the region. One of the fundamental assumptions of the Atlas is that all sightings reported from a block occurred within that block—that is, no one crossed block boundaries on a checklist. In fact, this is one of the main reasons why we ask atlasers to submit checklists through the portal, and we don’t just go searching through eBird for breeding codes. If you submit your checklists through the Atlas portal, then we can assume that you understand and follow the project protocols, like staying within block boundaries.
This seems simple. But if you’re like me, you’re atlasing wherever you are, and sometimes you’re not thinking as much about the block you’re in as what birds you are finding. It’s easy to cross a block boundary and not notice. The addition of the block grid to the eBird app’s map helps a lot with this (when using the Atlas portal, tap on the elapsed time and distance to see where you are in relation to the block’s boundaries), but an even more helpful feature will be coming out soon (if you have an Android, you may have it already). As you approach a block boundary, a message will pop up and notify you that, hey, there’s a block boundary coming up. I’m excited about this, because my memory needs all the help it can get.
There’s still one more boundary-related issue to be aware of though. If you’ve been birding a location with a hotspot, be cautious of hotspots that are located outside of the block you were atlasing in. If your checklist is in block A, but the hotspot is in block B, you will need to use a personal location for your checklist. Don’t assign your checklist to a hotspot that is located in a different block.
If you want your observations associated with the hotspot’s recent sightings, top 100, etc., then don’t use the Atlas portal to submit your checklist; just use core eBird. If you have observations on that checklist that you still want included in the Atlas dataset, then submit them as Incidental observations from the appropriate block. This is not ideal, of course—the better solution by far is for you not to use the hotspot—but fortunately the hotspots that fit this description are fairly limited.
Similarly, if you are atlasing near a block boundary then you may observe birds in the other block. You should include these birds on your current checklist (this is required for you to submit a complete checklist), but you should not include a breeding code for those individuals. Instead, finish your checklist and make a new, Incidental checklist located where you saw those birds and use the appropriate breeding code.
There are lots of details to remember when you’re atlasing. If you occasionally forget, you won’t break the Atlas. But the more often that you do remember and, as a result, our assumptions are met, the more accurate the predictions we make from our analyses will be.