Firstly, there basically are no hotspots in Halmahera. But let's say I use "Foli old logging road" or whatever it's called. That extends for more than 10 kms before it becomes very overgrown, and eventually (I understand) reaches the south coast. The birds are subtly different along it (I've not gone more than about 10 kms), with different habitats at intervals. So if I substitute that "hotspot" for the actual location I lose valuable information—what the habitat was like where I made the sighting. In this particular (hypothetical) example, since it's a scuba diving holiday and I'm on the coast the sighting becomes "dangerously" imprecise. Why do any of that? Instead, let's just keep the coordinates of the location where I actually did make the observation (why on earth wouldn't we?)
Forcing you to assign a hotspot is like GB Ordnance Survey's points of interest dataset where they forced actual locations on to a grid so that coordinates were always at grid intersection points (I've not checked if these data are still available). This was a very effective way of hiding the very points of interest the dataset was designed to expose. It also made any form geospatial analysis +/- meaningless since you were comparing one set of incorrect locations with another.
I noted that track-less lists are the only ones where it makes sense for ebird to ask where you "are" at point of list submission.
Actually, I think it's quite likely one could construct an "artificial" track and submit that. The underlying database model isn't complicated. I've not experimented, but I will. Why would one want to do this?
...Well, perhaps you have an old checklist (or even a new one) where you didn't record the trace for whatever reason, but you know the route you followed. Such is the case for nearly all checklists prior to about 2004... ...Well then you might well wish to construct a track which follows your route. Using start and end time information, you could divide the route into equal segments and that becomes your "trace". Obviously, the information about precisely where you were at any moment will be wrong. But since it's ebird and we have no information about where each sighting occurred it doesn't matter ! And it provides more info than just a "bald" point. We now know more than the simple statements of "time taken" and "distance travelled" give us. We can work out what habitats you're likely to have passed through, for example, what altitude you traversed.
(Note that if we treated trips and sightings as the logically distinct things they are, and treated them appropriately, the artificial nature of the track wouldn't matter either. It would mean details of the track were wrong (duration along a given portion) but locations of sightings (recorded separately) would be correct.)
Yes but where there's a trace, ebird can work it out for you—it could just use the centroid, for example. It doesn't have to ask, and there's no sense in forcing you to assign a "hotspot" (see above; it's like forcing you to use the OS PoI grid—it's ambiguating away the actual location)
It is actually possible to assign a wholly inappropriate hotspot. Sometimes this could happen cryptically. So for example, let's say I'm trying to assign a village weaver sighting and I'm in Kenya. I could assign it to completely the wrong hotspot in completely the wrong part of the country ! Since this species is widespread, it's quite likely ebird wouldn't flag it as unusual. So hotspot assignment has turned a good record into a bad one.
(I actually did this temporarily on a recent trip when wifi issues meant ebird was refusing to show a sensible list of possibles. By assigning a wrong hotspot I was able to submit a list which I could then correct later.)
