BSBI Distribution Database > message board

subdivide by > altitude (grouping)

Please report any problems with the website. Suggestions for changes are also very welcome.

subdivide by > altitude (grouping)

by AndyAmphlett » Tue Jan 12, 2021 5:01 pm

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. ... 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?


Posts: 410
Joined: Fri Nov 23, 2012 9:32 am
name: Andy Amphlett

Re: subdivide by > altitude (grouping)

by admin » Tue Jan 12, 2021 5:57 pm

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.
Tom Humphrey
Database Officer, Botanical Society of Britain and Ireland (BSBI)
c/o Centre for Ecology and Hydrology,Maclean Building, Crowmarsh Gifford, Wallingford, Oxon, OX10 8BB, UK.
User avatar
Posts: 438
Joined: Tue Nov 20, 2012 4:16 pm
name: Tom Humphrey

Re: subdivide by > altitude (grouping)

by AndyAmphlett » Wed Jan 13, 2021 10:14 am

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.

Posts: 410
Joined: Fri Nov 23, 2012 9:32 am
name: Andy Amphlett

Return to Bugs and suggestions