I disagree. In the absence of any other evidence, the evidence you have is all you know about a subject. You would not disregard this evidence and say "perhaps it's biased so I'll completely ignore it". Instead you'd say "well perhaps this information is wrong or biased but it's all I have and so I'll use it". Later, if you discover that it's biased then you'll make steps to correct for that bias and, if that's not possible you'll be forced to discard the observations. But you can only do that later with the benefit of later information. So it is with ebird. Some information is better than no information.
-
Welcome to BirdForum, the internet's largest birding community with thousands of members from all over the world. The forums are dedicated to wild birds, birding, binoculars and equipment and all that goes with it.
Please register for an account to take part in the discussions in the forum, post your pictures in the gallery and more.
eBird and Birding on the move (2 Viewers)
- Thread starter ohlookabirdie
- Start date
raymie
Well-known member
I agree. Use hotspots if a good hotspot applies. If not, there's no shame in using a personal location.
🥳
eBird Polygon Tool (Herramienta de polĂgono para eBird) - eBird Spain
eBird Polygon Tool es una herramienta externa a eBird que sirve para realizar análisis básicos de los datos de eBird mediante el uso de polĂgonos personalizados. Podrás acceder a eBird Polygon Tool a travĂ©s de este enlace: https://ebird-tools.thruhere.net/polygon.html.
David Ellsworth's eBird Polygon Tool
First-time poster. About a month ago, I and some fellow birders/conservationists in Montreal discovered David Ellsworth's amazing eBird polygon tool eBird Polygon Tool, described in this now-seemingly-inactive thread (eBird Polygon Tool). About three weeks ago, queries that involved over 100...
www.birdforum.net
All very well, and you can this for any arbitrary boundaries if you get the entire database (which you can also do). It doesn't get around the problem that the data model is wrong. The checklists refer to an area in most cases and don't represent locations of individual bird sightings. And those areas vary in size and geometry. This introduces errors and biases🥳
eBird Polygon Tool (Herramienta de polĂgono para eBird) - eBird Spain
eBird Polygon Tool es una herramienta externa a eBird que sirve para realizar análisis básicos de los datos de eBird mediante el uso de polĂgonos personalizados. Podrás acceder a eBird Polygon Tool a travĂ©s de este enlace: https://ebird-tools.thruhere.net/polygon.html.ebird.org
David Ellsworth's eBird Polygon Tool
First-time poster. About a month ago, I and some fellow birders/conservationists in Montreal discovered David Ellsworth's amazing eBird polygon tool eBird Polygon Tool, described in this now-seemingly-inactive thread (eBird Polygon Tool). About three weeks ago, queries that involved over 100...
Ebird is a compromise between usability and accuracy to encourage birders to use it frequently. But it is wrong to say that makes the data model "wrong." Mapping precise locations of birds would be very time consuming and burdensome. In addition to having to stop every time you see or hear a bird--which for many is very disruptive to enjoying birding and nature--you (and your smartphone) are almost never in the same location as the bird. You see or hear it many meters away from your location--and in the case of hearing you often won't really know the actual location or the distance. And of course there is the issue of flyovers vs. perched birds.
Sorry but this misses on nearly all points. They've been examined in various other threads, perhaps including this one (not looked back to see).
Just to give a flavour, the whole point of ebird on mobs is that you can enter things as you see them with minimum fuss. It would be no extra work at all for ebird to capture and store the location when the record was entered (i.e. at point of encounter). Other apps do work in this way.
Then you have locations of encounters rather than the ebird model where the relationship between the encounter and its location is ambiguated away through "checklists" or "hotspots". To remove that ambiguity, many birders add lat/long to comments against "interesting" birds. Now that does require extra effort
Your response misses my points; I'm familiar with the other threads and participated in some of them. My main point is that the eBird model is not "wrong" or stupid, and you should stop saying so or implying that because it will discourage people from using it and providing the data which has already enhanced our understanding of birds in many ways.
Further, the encounter location information you think is so important is overrated for at least two reasons. First, as I already suggested, the exact location of the encounter may not even be useful information in many cases, e.g. when you are seawatching or scoping from a distance, observing a flyover, or hearing a bird at a distance. In those cases the location information is providing false precision and is misleading. And there won't be any way to distinguish the good from the bad unless you add additional burdensome steps, e.g. mapping the location of the bird rather than the encounter (or in the case of flyovers, the direction of flight). Second, place of entry of an observation will only be the location of the encounter if the observer makes it so, i.e. the observer stops and enters each and every record at the time it is encountered. That is an extra burden for the observer, esp. if there are a lot of birds about, that will discourage many from using eBird if it comes to be expected. (Also, even if you are trying to add birds as you see them, most birders will recall after a session that they forgot to add a bird or two--under your model there would have to be some way to flag those as not being added to the checklist at the point of encounter. That's another complication.)
Paul Chapman
Well-known member
Out of interest do you use eBird? If you did, I suspect that you would see the flaw in your point. To reinforce the point above, this is my Checklist today:-
It totals 31 species plus one hybrid. I was travelling for 85 mins with a significant period stationary and I covered 1.85kms.
I recorded species as I encountered them as new but that was not always convenient. As a result, the point at which I first encountered them was not always the same point as when I first recorded them.
I updated the count sometimes when I saw additional birds of that species. But that was not always the case.
I also then reviewed the Checklist before I submitted it. At that point, I checked and realised that I had missed some species. Occasionally, bizarrely, that is the species that you were looking for! Daft but it happens especially when you need to add additional information because it is unusual. I also updated my counts which were often still at 1.
As a result, the locations when the record was entered would be haphazard at best and more often actually wrong rather than accurate. The majority would show for where I parked my car and reviewed my Checklist. Sometimes that review is even later!
As a result, your repeated refrain on this point is wrong and would cause more confusion than otherwise.
When looking for locations for interesting species, it is sensible to review generally to reach an approach for your target. For Red-lored Whistler, this Checklist is useless - it is completed by someone lacking diligence and attention to detail who is recording a general list for his own purposes:-
This Checklist should be used - it is completed by someone far more diligent and helpful - it was used to find Red-lored Whistler by the person who produced the general list above:-
Personally, I am grateful for a free service & all birders who share their gen whether through eBird or otherwise.
All the best
Paul
Last edited:
I do use ebird.
If ebird captures the data at point of entry then yes there will be some erroneous positions but the error will be lower and less systematic than the hotspot approach. One way to understand that if you walk a straight line transect recording as you go
There will always be inaccuracies in any form of surveying: more so in ebird / crowd-sourced material where the protocols are not as strictly controlled. It's obvious and well-known that the point of encounter (where the human saw or heard it) is not the same as where the bird actually was. Either way of recording suffers from that source of error. The fact that sometimes you record something after the fact misses the point too.
To see why the ebird approach introduces error, it helps to imagine a situation where you walk an entirely straight transect under the 2 approaches [We assume that things recorded later are still assigned to the same "checklist" and that the GPS track for that is known and used]:
When you use ebird data "naively" without any knowledge of the distance travelled and time spent you introduce significant bias into your results. When you take both these things into account but without knowledge of the route taken you still introduce error because different parts of any reasonably large area will be less productive, species/individual rich. For example, a hotspot which includes both parkland and woodland. Not accounting for this effectively smooths the results across productive and unproductive areas adding imprecision (error). We cannot account for this because we have no idea what route you took or how large a "hotspot" is—what its boundaries are. If instead, we had locations of encounters with individual birds/groups of birds we would not have this problem.
So at best (if we take "effort" into account), ebird's approach adds uncertainty (=error). At worst, if we don't take account of effort we introduce bias. These two things uncertainty/error and bias are precisely what any analysis seeks to minimise.
I've said before there's no technical reason why a) an app can't capture location for each observation and b) you can't access this and edit it on an individual basis (e.g. to add approximate locations for those things you forgot). There are already at least some apps which do at least some of this (observation.org). There's also no reason an app can be set to treat nominated records as belonging to a wider "checklist" or "hotspot", and no reason this shouldn't be editable after the fact.
If ebird captures the data at point of entry then yes there will be some erroneous positions but the error will be lower and less systematic than the hotspot approach. One way to understand that if you walk a straight line transect recording as you go
I use ebird but only because I've been too lazy to write my own app.
There will always be inaccuracies in any form of surveying: more so in ebird / crowd-sourced material where the protocols are not as strictly controlled. It's obvious and well-known that the point of encounter (where the human saw or heard it) is not the same as where the bird actually was. Either way of recording suffers from that source of error. The fact that sometimes you record something after the fact misses the point too.
To see why the ebird approach introduces error, it helps to imagine a situation where you walk an entirely straight transect under the 2 approaches [We assume that things recorded later are still assigned to the same "checklist" and that the GPS track for that is known and used]:
- if you record every bird as you go along, the error under "record point of encounter" approach will be zero. Under the ebird approach it will be in the range 0<= x<= length of the transect. On average it will tend to be half the length of transect if the the probability of encounter is the same along the transect. The maximum error for ebird will be the length of the transect. So here ebird has introduced error where there was none.
- if you record some things after the fact then the error for the ebird approach remains the same. If you do not / cannot (i.e. if using ebird) assign an exact or approximate location under the other approach then the error will approach the ebird error. But this will be only for the fraction of the records entered later—those you did not record at the point of encounter. So the error for the ebird approach still exceeds the point of encounter approach.
When you use ebird data "naively" without any knowledge of the distance travelled and time spent you introduce significant bias into your results. When you take both these things into account but without knowledge of the route taken you still introduce error because different parts of any reasonably large area will be less productive, species/individual rich. For example, a hotspot which includes both parkland and woodland. Not accounting for this effectively smooths the results across productive and unproductive areas adding imprecision (error). We cannot account for this because we have no idea what route you took or how large a "hotspot" is—what its boundaries are. If instead, we had locations of encounters with individual birds/groups of birds we would not have this problem.
So at best (if we take "effort" into account), ebird's approach adds uncertainty (=error). At worst, if we don't take account of effort we introduce bias. These two things uncertainty/error and bias are precisely what any analysis seeks to minimise.
I've said before there's no technical reason why a) an app can't capture location for each observation and b) you can't access this and edit it on an individual basis (e.g. to add approximate locations for those things you forgot). There are already at least some apps which do at least some of this (observation.org). There's also no reason an app can be set to treat nominated records as belonging to a wider "checklist" or "hotspot", and no reason this shouldn't be editable after the fact.
That would make some sense from a mathematical perspective. Still, I'd prefer if it were hidden from perfectionist users like me.
A similar method (worse in the average/best case but better in the worst case, and still better than what is used now) would be to put the location of a single individual of a given species halfway between the starting point and the point of adding to the checklist (if a count is lowered, all previous individuals could be reset to half the distance between the beginning and the location of the substraction). This system would--in fact--in all cases be at least as good as what we have now or better (the error rate would be the same or smaller: the former for birds logged in late and the latter for birds logged in on the go).
A similar method (worse in the average/best case but better in the worst case, and still better than what is used now) would be to put the location of a single individual of a given species halfway between the starting point and the point of adding to the checklist (if a count is lowered, all previous individuals could be reset to half the distance between the beginning and the location of the substraction). This system would--in fact--in all cases be at least as good as what we have now or better (the error rate would be the same or smaller: the former for birds logged in late and the latter for birds logged in on the go).
No because we know or can account for differences in the distances at which it's possible to perceive species. Either grossly (e.g. blanket approach for sea watches or prairies) or specifically based on knowledge of the place and/or the species. The corrections will be imperfect but better than trying to work with a "hotspot".
[ Ebird on the whole provides "false precision"—or do you believe all the species on the list for place have actually occurred there ? ]
see above. In principle, you're meant to use the different codes for recording things like "flyovers" for precisely this reason. (In practice I find them too burdensome.)
I've covered this in the other reply: if only one record is at point of encounter the error is still lower than the ebird model.
I personally try to capture things when I see them because I try to count everything too. If I were try to remember the >100 carrion crows and >10s of robins after the fact it wouldn't be burdensome but it would be impossible. I don't know why you wouldn't try to capture things as you go along—that is after all the whole point of the app...
There are various ways of dealing with birds recorded after the point of encounter. One approach is conceptually the same as the "x" for count—it's an "x" for location. Another is to allow you to add a point [you can technically do this now, of course, if you record an "incidental"]. If you took the latter approach, there would be some error but—here's the point again—less than present in ebird's (incorrect) model. A more sophisticated app would allow you to infer the time from the gps track given the approximate place (again you can do this by hand).
Paul Chapman
Well-known member
Thank you for the very detailed explanation with which I agree in principle.
But for the avoidance of doubt, I wouldn't edit eBird to make it more accurate if it worked as you suggest. I doubt anyone else who does a lot of birding and records Checklists like mine would. I anticipate that they would simply be less likely to use it. That is a net negative outcome.
I suppose my principal difficulty is why you would want to worry about a degree of error. You either have an accurate location or an inaccurate general location. The percentage general approach and the degree of error is ordinarily less than the mobility of the bird or the extent to which you can reduce the error by familiarity with the bird's preferred habitat or behaviour. I am not sure your approach would help me.
There are a limited number of locations on my Checklist where you could find a Black-necked or Slavonian Grebe and the same would be true of a Penduline Tit in this Checklist:-
If I had a general location, I would start by looking at Google Maps & habitat to narrow my search. Even where I have an exact GPS location, my immediate thought on arrival and looking for a bird is to think - OK. Where would I expect to find an xxxx?
Similarly, if I am looking for a species and using eBird to research it, I will look at the Checklist details to determine whether they narrow the location or not based on distance and duration. That is also before variables produced by tides, weather, etc.
All the best
Paul
Hotspots are only for users, not for data aggregation (unless you have an incomplete checklist, of course, but they are next to useless anyway).
Flyovers should be for something a bit different and more specific:
eBird Breeding and Behavior Codes
Breeding and Behavior Codes provide a way for birders to document the breeding activities of birds around the world, providing crucial information for research and conservation globally. Our goal is to collect information about the timing and loc...
support.ebird.org
There is an even safer way (though it is not expected to offer as much improvement); see my post above: eBird and Birding on the move.
There should be no problem with that: eBird can compute the duration when the track is clipped.
Last edited:
But people are encouraged to assign their data to them at point of entry and many will. So they will "hoover up" stuff they probably shouldn't have [although we cannot know because hotspots have no boundaries]
ok probably. But point remains. Even if you're working with ebird data as it comes you'll apply some of the corrections I mention. Many people do record "flyover" etc in the comments.Flyovers should be for something a bit different and more specific:
eBird Breeding and Behavior Codes
Breeding and Behavior Codes provide a way for birders to document the breeding activities of birds around the world, providing crucial information for research and conservation globally. Our goal is to collect information about the timing and loc...
the fact you remembered the bird at all usually means you have a fair idea of roughly where you saw it—at least in my experience. In the old days of paper notebooks I would often record after the fact. In that case I would mentally retrace my route and recall what I saw. I would also (often separately), review a list of British birds to see if there were any there I'd forgotten about. If there were I'd then usually be able to remember where (roughly) I saw them.
There should be no problem with that: eBird can compute the duration when the track is clipped.
EDIT: Sorry for getting everyone (incl. myself) started all over again.
Paul Chapman
Well-known member
Occasionally, it is obvious. Hotspots randomly appear often close to each other. For instance, New Passage & Pilning Wetland. Difficult not to combine the two if you walk for more than 10 mins.... So you end up with species under New Passage that were at Pilning Wetland & vice versa...
Similarly, when reviewing the Portbury Wharf Hotspot last night, the Purple Sandpipers were obviously "hoover up"... I looked at the Checklist and that was the case. They were the usual Battery Point birds:-
I agree that it is random but it is also pretty obvious & not detrimental to using the information overall if you interrogate it properly and are aware of the shortcomings.
Personally, I have however ignored the proliferation of Clevedon hotspots in favour of my personal general location that I had created far before eBird ever paid any attention to my home town!
All the best
Paul
Last edited:
qwerty5
Controversial opinion generator
The solution here is to either submit two checklists, one for each hotspot (this is what I do), or one checklist to a third location (either personal or a hotspot) that includes both hotspots. Especially locally, I tend to make as many checklists as there are hotspots to report them to. A thorough morning or afternoon at my local state park could include five or more checklists, all to different small hotspots. I could make one big list for the day and report it to the main park hotspot, but that's less precise, much less helpful to others, and it's also just fun to build lists for each hotspot.
Optimally, of course, hotspots would be area-based. The only problem is that would require knowledgeable local reviewers who actually care to accurately define the borders.
