subdivide by > altitude (grouping)

[AndyAmphlett]

Hi Tom,

Sibbaldia procumbens is recorded from 532 monads. If I run a query using the option subdivide by > altitude (grouping), and counting distinct monads, ie.

https://database.bsbi.org/search.php#re ... fc8aaac4c4

the monad total is still given as 532. But if I add up the monad totals in the 100m altitude bands I get a total of 750 which is incorrect. A monad, eg. min or mean altitude, can only fall within a single altitude band, so the numbers the query returns must be incorrect. Or am I misunderstanding how this query is working?

Thanks,

Andy.

[admin]

Hi Andy,

It took me a long time to work out what's happening:

Mean altitude is being calculated for the occurrence's grid-square (at up to 100m precision) and that is used (rather than monad) to assign the occurrence to a subset. That means that monads with multiple precise occurrences can end up being double counted if they contain 100m squares with mean altitudes falling in different bands.

e.g NN9999 has two distinct records with gridrefs:

NN9999 => mean alt. 1203m
NN99709971 => mean alt. 1125m

this is allowing the monad to be double-counted in both the 1100 and 1200 bucket.

I don't know whether this is 'correct' behaviour. The alternative would be to test occurrence altitude at monad-scale when running this type of search.

[AndyAmphlett]

Thanks Tom. It's not an immediately obvious approach, but I can see how it works. To clarify, for anyone reading this post, the steps the query performs are:

1). Calculate altitude of each record grid square. Options are minimum, average, or maximum.
2). Assign each record to a 100m class interval, based on its altitude.
3). Count the number of, (in this instance), monads per class interval.

Another option worth considering, is to assign unique grid refs to the 100m class intervals. Currently you can assign records to class intervals (with option to remove duplicates), but the same grid ref may be included multiple times, which must distort results.

Anyone using these types of queries, I would usually recommend limiting records to those at higher precision, eg. monad or better.

Andy.