eBird and Birding on the move (1 Viewer)

[Jim M.]

Really, please have some more respect for the audience—it's blindingly obvious that the place you see or hear the bird from isn't (exactly) the place where the bird is, and no-one has claimed it is !

You have relentlessly complained about eBird as if the folks who run it are obtuse dolts who don't understand birding and use a model that is simply "wrong," and you ask me to have respect? Please. (I know some of the folks at eBird central by the way--they include several of the most skilled birders in the world.)

In any event, I believe all my posts have been quite respectful. The point of emphasizing that the encounter location is not the bird location is that you and a few others have written as though tracking locations are the perfect data point and Opisska has said that recording encounter locations allows him to record "birds" rather than using those imprecise hotspots. So, you conclude, the eBird folks must be just obtuse not to allow encounter location tracking. But if you focus on the imprecision of the encounter locations, you can see that the advantages of encounter locations are not as great as you suggest--both methods require significant assumptions and approximations to be useful for analysis. It is just a matter of degree, and at that point it becomes a pragmatic analysis of the costs/benefits of each method regarding ease of use, privacy of data, etc. on which reasonable people can differ. It is not a matter of using a data model that is "wrong" or "right".

In any event, I think I'm done with this thread.

 

[Tomgibo]

Wait. So when I see my friends walking with the app on and recording each bird as they register those, this still doesn't get posted to eBird as individual locations, but it get bunched up in one point? Does that mean that all the individual points for birds are a) only when the observe went an extra mile and made it a separate observation or b) are there some average representation of the moving checklists?

I haven't read every message in this thread yet so maybe my point is covered by someone else already, but very little would be gained by doing this. The huge amount of extra work that @THE_FERN is proposing that an individual undertakes does not lead to accurate positioning of the birds locations, it leads to accurate positioning of the observer and probably a decrease in the amount of observations the observer makes due to increased workload. If I stood on a hill and observed an ostrich at 1 mile and a Namaqua Dove 20 meters away the proposed recording style would produce location information that is no more useful than Ebird's current recording style for both species (The_fern wants accurate true locations) and it would mean massively expanding the amount of time spent using your phone rather than observing birds while birding. Well created and curated hotspots are already accurate enough for most uses, some hotspots are not well created or curated but that can be improved and some areas need hotspots that haven't yet been created (you can send the suggestions yourself). This idea would lead to a reduction in users reporting all species and an increase in users reporting only the highlights. Usability is a very high consideration and a must for platforms like ebird to drive engagement.

The proposals for an always on app also bring in problems of battery life and processor usage, maybe some people would be happy having an app constantly draining their battery in case they want to record an exact location they were at every time they saw a bird an unrecorded distance from them at any point 24/7, but I do not. I can always just press start and then stop and make an incidental checklist if I wish to do so.

All this would culminate in a very large proposed extra workload for the developers, users and battery of the devices used in recording for results that would produce results that still contain inherent ambiguity. I think the ultimate issue is that The_Fern wants ebird to be used for very specific applications that require high levels of accuracy and a lot of cogent corroborating information recorded at a level that isn't reasonable to expect from a citizen science project.

 

[opisska]

Maybe you meant to quite another post and not mine? Because all I was asking really was how it worked: I do regularly see my eBird friends logging bird into the app in the field as they see them, so the per-bird location data already exist without any extra work at least for those observers.

 

[01101001]

I haven't read every message in this thread yet so maybe my point is covered by someone else already, but very little would be gained by doing this. The huge amount of extra work that @THE_FERN is proposing that an individual undertakes does not lead to accurate positioning of the birds locations, it leads to accurate positioning of the observer and probably a decrease in the amount of observations the observer makes due to increased workload. If I stood on a hill and observed an ostrich at 1 mile and a Namaqua Dove 20 meters away the proposed recording style would produce location information that is no more useful than Ebird's current recording style for both species (The_fern wants accurate true locations) and it would mean massively expanding the amount of time spent using your phone rather than observing birds while birding. Well created and curated hotspots are already accurate enough for most uses, some hotspots are not well created or curated but that can be improved and some areas need hotspots that haven't yet been created (you can send the suggestions yourself). This idea would lead to a reduction in users reporting all species and an increase in users reporting only the highlights. Usability is a very high consideration and a must for platforms like ebird to drive engagement.

The proposals for an always on app also bring in problems of battery life and processor usage, maybe some people would be happy having an app constantly draining their battery in case they want to record an exact location they were at every time they saw a bird an unrecorded distance from them at any point 24/7, but I do not. I can always just press start and then stop and make an incidental checklist if I wish to do so.

All this would culminate in a very large proposed extra workload for the developers, users and battery of the devices used in recording for results that would produce results that still contain inherent ambiguity. I think the ultimate issue is that The_Fern wants ebird to be used for very specific applications that require high levels of accuracy and a lot of cogent corroborating information recorded at a level that isn't reasonable to expect from a citizen science project.

I agree, but--maybe--if at least the time of each observation was recorded, then the point assigned to that bird could be placed midway between the beginning of the track and the point of it being recorded rather than in the middle of the entire track (as it used to be done) or at the beginning of it (as it is done now, I think). That would mean more workload for the mapping algorithm, but--then--the locations would always be no less accurate (in most cases more accurate and twice better on average, I think) than in the current approach, which could've helped with mapping the locations of the smaller birds especially. It would also require no additional effort from the observer.

 

[qwerty5]

rather than in the middle of the entire track (as it used to be done) or at the beginning of it (as it is done now, I think).

What you are describing is the place eBird suggests a brand new location for the checklist. The observations are actually placed at the location the observer chooses (usually a hotspot or personal location, which typically already exists). Thus the location is independent of the track.

 

[THE_FERN]

I haven't read every message in this thread yet so maybe my point is covered by someone else already, but very little would be gained by doing this. The huge amount of extra work that @THE_FERN is proposing that an individual undertakes does not lead to accurate positioning of the birds locations, it leads to accurate positioning of the observer and probably a decrease in the amount of observations the observer makes due to increased workload. If I stood on a hill and observed an ostrich at 1 mile and a Namaqua Dove 20 meters away the proposed recording style would produce location information that is no more useful than Ebird's current recording style for both species (The_fern wants accurate true locations) and it would mean massively expanding the amount of time spent using your phone rather than observing birds while birding. Well created and curated hotspots are already accurate enough for most uses, some hotspots are not well created or curated but that can be improved and some areas need hotspots that haven't yet been created (you can send the suggestions yourself). This idea would lead to a reduction in users reporting all species and an increase in users reporting only the highlights. Usability is a very high consideration and a must for platforms like ebird to drive engagement.

The proposals for an always on app also bring in problems of battery life and processor usage, maybe some people would be happy having an app constantly draining their battery in case they want to record an exact location they were at every time they saw a bird an unrecorded distance from them at any point 24/7, but I do not. I can always just press start and then stop and make an incidental checklist if I wish to do so.

All this would culminate in a very large proposed extra workload for the developers, users and battery of the devices used in recording for results that would produce results that still contain inherent ambiguity. I think the ultimate issue is that The_Fern wants ebird to be used for very specific applications that require high levels of accuracy and a lot of cogent corroborating information recorded at a level that isn't reasonable to expect from a citizen science project.

Suggest you probably need to read a bit more. All these points are covered elsewhere and, as I've said several times, there are already apps which do what I suggest

 

[Kirk Roth]

I was sometimes considering starting using eBird. But the way how it works just annoys me so much. I do not wish to record "checklists" for "hotspots", I wish to record birds. I would like to be able to just record any bird, at the moment I see it and I would like this to be the location stored and provided to others. eBird goes wildly out of its way to make this difficult. Maybe it's not "stupid", but it's the chief reason why it's very unlikely to be ever getting any data from me.

Just adding information for future viewers - eBird does indeed allow people to record any bird at any moment and location. These checklists are easy to do - on a computer it is as simple as clicking a location on the map and on the app this is in fact the default suggestion unless you are in immediate proximity to the marker for a hotspot. In either case, an "override" of the suggestion is again as simple as pointing to your preferred location on a map.

 

[THE_FERN]

Just adding information for future viewers - eBird does indeed allow people to record any bird at any moment and location. These checklists are easy to do - on a computer it is as simple as clicking a location on the map and on the app this is in fact the default suggestion unless you are in immediate proximity to the marker for a hotspot. In either case, an "override" of the suggestion is again as simple as pointing to your preferred location on a map.

Weird that you often have to name points which aren't hotspots, and that these names need to be unique. One might have thought the well-established lat-long system uniquely identifies a place without further id required...

Yes ebird allows one to "record [...] location" but it doesn't let you capture each individual sighting in turn without massive hassle---it's predicated on obscuring observations together as a list. That's the subject of the foregoing discussion.

 

[Kirk Roth]

Weird that you often have to name points which aren't hotspots, and that these names need to be unique. One might have thought the well-established lat-long system uniquely identifies a place without further id required...

Yes ebird allows one to "record [...] location" but it doesn't let you capture each individual sighting in turn without massive hassle---it's predicated on obscuring observations together as a list. That's the subject of the foregoing discussion.

Yes - I believe the lat/long problem is a quirk of the Google Maps layout they use. The easiest way to get lat/long when you're on a computer is to click on the lower left of the map where it says "Google" and it brings up Google Maps in another window - the lat/long is in the site address and it can be copy/pasted. I don't find it too difficult, but I agree its less than ideal - I would much rather have coordinates there on the "Where did you bird" map, but I'm guessing that if this were a simple problem to solve it would have been done. If one has coordinates already from some other means its easy to just add those to the search bar and the location name. Its not a problem on the mobile app because both coordinates and address come up when choosing a novel location.

Individual sightings at a discreet location can be captured in two basic ways with very little hassle - incidental checklists for "moment in time" bird observations (meaning no "list" if that obscures something), and stationary checklists if one is using a point count system. There are of course more complicated ways of doing this and for various reasons some people do, but those two methods work well for a vast majority of users.

 

[THE_FERN]

Yes - I believe the lat/long problem is a quirk of the Google Maps layout they use. The easiest way to get lat/long when you're on a computer is to click on the lower left of the map where it says "Google" and it brings up Google Maps in another window - the lat/long is in the site address and it can be copy/pasted. I don't find it too difficult, but I agree its less than ideal - I would much rather have coordinates there on the "Where did you bird" map, but I'm guessing that if this were a simple problem to solve it would have been done. If one has coordinates already from some other means its easy to just add those to the search bar and the location name. Its not a problem on the mobile app because both coordinates and address come up when choosing a novel location.

Individual sightings at a discreet location can be captured in two basic ways with very little hassle - incidental checklists for "moment in time" bird observations (meaning no "list" if that obscures something), and stationary checklists if one is using a point count system. There are of course more complicated ways of doing this and for various reasons some people do, but those two methods work well for a vast majority of users.

When you enter a "novel" location in the mobile app you have to give it a unique name. The auto-generated one is based around some Google understanding of the street and may well not be unique if you're (e.g.) birding sections of a long road. The real q is why it has to have a name at all, and, if it does, why the unique "lat, long" doesn't suffice.

The whole discussion elsewhere has not been about recording occasional incidentals but rather about capturing the location of every encounter along a route. There's no reason ebird couldn't store the location the key was pressed in the same way other apps do. It should be up to me if I want to call a string of point encounters a single checklist or not

 

[Kirk Roth]

When you enter a "novel" location in the mobile app you have to give it a unique name. The auto-generated one is based around some Google understanding of the street and may well not be unique if you're (e.g.) birding sections of a long road. The real q is why it has to have a name at all, and, if it does, why the unique "lat, long" doesn't suffice.

The whole discussion elsewhere has not been about recording occasional incidentals but rather about capturing the location of every encounter along a route. There's no reason ebird couldn't store the location the key was pressed in the same way other apps do. It should be up to me if I want to call a string of point encounters a single checklist or not

The first statement doesn't match my experience with the app at all, nor that of anyone else I've known who uses it. When I go to "Choose a location" in the app, it provides suggestions, and as I said before, if I'm not right on a hotspot marker or a checklist marker that I've previously made, the first suggestion is always in the format "Street name, City Country-State (Latitude, Longitude)" They always include coordinates and they are always as unique as the scale of four decimal degrees. The question about why checklists need names seems philosophical in nature - I can't really contribute to that other than to say I think most people appreciate having a discrete reference to a checklist or anything else for multiple useful reasons.

I've also not known many birders or researchers to consider a string of point encounters to be a single "checklist" - typically we refer to a single geographic point of bird sightings as a "point count" and that is one discreet unit of data, because (as you've noted before) the specific location is important to information or research at hand. A series of these is not exactly one geographic datum by itself, but a grouping of data. This differs from, for example, a transect method in which the transect (and all birds detected along it) is the unit, but the geographic identification is less precise. These are commonly used and long accepted methods for comparable bird occurrence data collection. If one wants to blend them in some way, that is certainly anyone's right - but as with anything and as you've observed, it necessitates some difficulty to create novel methods that differ from the established ones.

All that said, eBird does accommodate what I believe you're describing with a feature called "trip reports" which is basically a lumping of point-count type observations. I rarely use these myself, but there are some articles about them here:

Introducing eBird Trip Reports - eBird

We’re thrilled to introduce eBird Trip Reports—an exciting new way to tell your birding story through eBird. eBird Trip Reports bring together your eBird checklists to create a fun summary of where you went and what you found, along with your photos and audio recordings, all in one easy-to-share...

ebird.org

eBird Trip Reports

TABLE OF CONTENTS What are eBird Trip Reports? Sharing eBird Trip Reports eBird Trip Report Roles Narratives and Comments Delete an eBird Trip Report Bulk checklist sharing Additional eBird Trip Report features eBird Trip Report FAQs ...

support.ebird.org

I've also known several birders who will use a single checklist in the way you are describing and add the coordinates in the comments - at least for the more widely spaced species. I've never seen someone enter every location of every common species, but if that were worth it to someone I suppose they could.

 

[THE_FERN]

The first statement doesn't match my experience with the app at all, nor that of anyone else I've known who uses it.

Oh dear must just be me: about 10+ times each in South Africa and Brazil respectively recently (for example). Rather than inventing full new names I just append "1", "2" etc. to the auto-generated one. But annoying

The question about why checklists need names seems philosophical in nature - I can't really contribute to that other than to say I think most people appreciate having a discrete reference to a checklist or anything else for multiple useful reasons.

Given that coordinates are used behind the scenes (are the primary identifier), any alias should surely be optional not mandatory.

I've also not known many birders or researchers to consider a string of point encounters to be a single "checklist" -

No that's not the point but it's been thoroughly covered elsewhere. One could use a "trip report" (just metadata associating one or more checklists together) with collections of incidental observations to cobble together something approaching the correct data model but that's simply not what we're talking about: would be massively tedious to compile

Why would you want to associate a series of individual point encounters as a "checklist"? There are lots of obvious reasons---estimate of overall effort, for example, understanding of habitats traversed or whatever. Same as if conducting a transect

 

[RyanI]

Oh dear must just be me: about 10+ times each in South Africa and Brazil respectively recently (for example). Rather than inventing full new names I just append "1", "2" etc. to the auto-generated one. But annoying

I think it must be you, I have just checked my locations and every auto-generated ones I have created on the app have coordinates (see a few examples attached).

 

[wheatearlp]

I think it must be you, I have just checked my locations and every auto-generated ones I have created on the app have coordinates (see a few examples attached).

Comment from a non-ebird user (I use BirdTrack) - how do you know where a set of co-ordinates relates to if they're all called 'Auto selected' and you don't name them?

 

[RyanI]

Ones on land have the street/road/area name first. The ones with just coordinates are at sea records so won’t have these but will have the country/sea it’s located in as part of the location

 

[wheatearlp]

Ones on land have the street/road/area name first. The ones with just coordinates are at sea records so won’t have these but will have the country/sea it’s located in as part of the location

So on the screen-shot in the post above my initial post there would be a description to the left of the word 'Auto'? It's just not shown on the screen-shot?

 

[RyanI]

So on the screen-shot in the post above my initial post there would be a description to the left of the word 'Auto'? It's just not shown on the screen-shot?

Those are the at sea records, this is it in full. SO I know the locations were at sea in the Falklands and SG

 

[wheatearlp]

Those are the at sea records, this is it in full. SO I know the locations were at sea in the Falklands and SGView attachment 1559829

Fair enough, makes sense now.

 

[Tomgibo]

Suggest you probably need to read a bit more. All these points are covered elsewhere and, as I've said several times, there are already apps which do what I suggest

And no one uses those apps for logging all individuals and species the way ebird is used because it would be too cumbersome and time consuming, which is my point. But if there are apps that already do exactly what you want just use those, that's it, problem solved.

 

[temmie]

And no one uses those apps for logging all individuals and species the way ebird is used because it would be too cumbersome and time consuming, which is my point. But if there are apps that already do exactly what you want just use those, that's it, problem solved.

not true.
Just to give you one example:

These are the 655 entries I made, in the field, with exact coordinates, during 2 weeks of birding in Brazil.


The raw data you get from one trip like this is worth 10x more than any list in ebird.
Just the Bahia Tapaculo spot took me some hours to find the place (based on ebird sightings), thanks to my own field craft and knowledge of habitat requirements, while the GPS point in my observation will enable anyone to go to that spot in minutes.

That's the difference between frustration about badly designed databases (ebird) and efficient ones (observation) while birding some place you're not familiar with.

You can even make a kind of breadcrumb trail by displaying each point on a map (example for one morning, compared that to any list in ebird and the info you get out of it. I remind you: any user can create this from my data, on the website, it's not hidden like tracks on ebird are hidden for viewers). In ebird, this would look like a list with the following info:
1 kilometer, 5 hours, 35 species. Good luck finding the birds at the stake-outs!