How does it work?

The mapsheet analogy

Imagine someone has a database of "spatial objects" of some kind - either points (e.g. bird sightings), or extents (e.g. National Parks). He/she wants to make the data available for spatial queries so that enquirers can quickly retrieve, for example, all bird species recorded in a particular 0.5 x 0.5 degree square (approx. 50 x 35 km), and also (possibly) know which National Parks also occur in the vicinity.

A simple way to enable this would be to divide the region of interest up into a local grid of some kind (similar to large scale mapsheets), give each grid square (sheet) a unique code, then for each species of bird, compile an index of all the squares/mapsheets in which that species has been recorded. Then it is a very simple matter to quickly discover what species occur in which squares in answer to the user's enquiry, without even needing the base data to be on-line: the system looks for a text match between the enquirer's "search" square or squares, encoded according to the same system, and the list of squares stored for each species in turn, returning "hit" or "miss" in each case. If the spatial extents of the National Parks have been indexed in the same way, the second part of our query can also be answered as well, by determining which "National Park" squares overlap the user's "search" square(s) of interest. We could also easily produce a list of species within (or close to) any particular National Park, the limit of uncertainty being the size of the squares actually used when building the index.

C-squares uses just such a system, with two important extensions: (1) the nomenclature for the squares is globally applicable, rather than just local (and applies equally on land or on sea), and (2), the system can be used at any scale, from 10 x 10 degree squares (approx. 1000 km or 700 miles each side) through 5 x 5, 1 x 1, 0.5 x 0.5, 0.1 x 0.1 degree squares, and so on, as fine as the user requires.

The suitability of such a system for text searching can be illustrated using another example. A randomly selected portion of the (printed) index to a popular atlas lists the following:

• Newcastle, Australia ....... 33 00 S, 151 46 E ... map 117 B9
• Newcastle, Canada .......... 47 01 N, 65 38 W .... map 129 C6
• Newcastle, S. Africa ....... 27 45 S, 29 58 E .... map 105 D4
• Newcastle, U.K. ............ 54 13 N, 5 54 W ..... map 19 B6
• Newcastle, Calif., U.S.A. .. 38 53 N, 121 08 W ... map 144 G5

Obviously, the map references here are provided so that the user can quickly go to the relevant page to find the location of the particular "Newcastle" in question. Less apparent from the printed copy (but quite feasible for an electronic version) is that one could also use this index in reverse, i.e., generate a list of all names occurring on map 144 - or if desired, in Map 144 square G5 - and that this could be done rapidly using only a standard text matching procedure (no numeric calculations required) so long as the location information against each name was text searchable. In effect, holding the "mapsheet" and (smaller) "subsquare" references enables both latitude and longitude elements to be combined into a single, easily searchable "word".

>> History and References