OBIS and species distributionsTony Rees discussion presentation, March 2003

• Some fundamental intentions for OBIS ...

– Choose any species and discover its distribution

– Click on a body of water and discover what lives there

– Then ...

• Examine/discover correlations with environmental variables, etc.

• Currently:

– OBIS connects to sources of point data, retrieves relevant points, displays on map and/or passes to modelling packages (also displays some relevant ancillary information and provides link to more if available)

Point vs. polygon data• Point data ...

– Limited by:

• restricted distribution of sampling activity (vs world ocean area)

• only a subset of possible specimens retained (or catches recorded)

• only a further subset of these acessible to OBIS

– “Real” distribution will always require interpolation/ extrapolation (=> ranges, expressible in polygons)

– Only then can do meaningful queries as per initial slide

• Polygon data ...

– Could need mechanisms for OBIS to:• import• store• query• display• export

Types of polygons• May cover more than simple binary (presence/absence) states, e.g. ..

– “Normal” vs. extralimital (occasional/vagrant) distribution

– Breeding vs. non-breeding ranges

– Seasonal distributions (winter/summer/migration paths etc.)

– Juveniles vs. adults

– infraspecific variation (subspecies, varieties ...)

– confidence limits (known vs. doubtful)

– historic vs. current (decadal variability)

– etc.

• May also vary by source/ method of construction:– Comprehensive sampling (present vs. definitely absent)

– Indicative sampling (with inferred presence/absence where not sampled)

– Modelled distribution based on proxies (environmental, other species)

Examples of polygons (butterfly data) - actually a gridded dataset with both presence+absence data

Examples of polygons - cont’d (bird species)

Examples of polygons - cont’d (whale species)

Examples of polygons - cont’d (modelled fish distribution)

Expression of polygons

• Polygons expressed in various forms ..– DIGITAL - vector

• string of points connected by simple lines

• as above, but with exclusion areas

*** need GIS back end for spatial queries and display

– DIGITAL- non-vector• gridded (tiled) representation

• nominated regions/zones

*** potentially simpler to query and display, but may be less exact

– NON-DIGITAL• paper / diagrammatic representation

• ms textual descriptions

*** need digitising before accessible to online querying

An approach using gridded (tiled) data

• Express any species distribution as list of tiles (grid squares) in which that species occurs

• Tile size would be matched to scale of query system would be designed to support, e.g. 1 x 1 deg [100 x 100 km approx.], 0.5 x 0.5 deg.

• Could then query any tile and rapidly extract a list of what species occur there - especially if secondary (“inverted”) index built based on tile IDs

• Could accept species distributions as gridded data directly, or as vector polygons (then use polygon converter tool on the data)

“C-squares” system does exactly this

• Provides a unique, easily organised and searchable nomenclature for individual tiles (gridsquares)

• Prototype “polygon-to-c-square” converter available to look at / try out

• Distributions expressed in c-squares are straightforward to map using existing c-squares mapper (or OBIS could construct its own)

• Could accept species distributions as gridded data directly, or as vector polygons (then use polygon converter tool on the data)

- True GIS system might be better (ultimately more accurate, smoother diagonal lines/curves, more flexible overlays etc.) but may be slower for searching ?? (considering numbers of species potentially involved)

How might this be implemented?

• ? OBIS master distributions table:

Species 1 ... square A ... source x

Species 1 ... square B ... source x

Species 2 ... square B ... source y

etc.

... can then easily extract:

– all squares occupied by Species 1

– all species in square A

– source of any record (also needed for internal tracking)

• would potentially need to qualify “source” information as to type of record (as previously discussed)

• could also need to qualify by depth, season, decade (etc.) in “sources” list (table)

Getting these data into OBIS ...

• ? A persistent index, regularly refreshed/updated by querying distributed data sources

– OBIS could handle the polygon => gridsquare conversion as a background task

• ? Live broadcast query, polygon/raster data interrogated on-the-fly

– would be quickest if polygon => gridsquare conversion had already been undertaken at the partner end

... data could potentially be transferred as vector data (polygon boundaries), or gridded data (either standardised, or non-standardised). Need to consider optimum method(s) for transfer, with implications as to where required conversions would be done.

“Click on a square” search interface (from current “MarLIN” system)

Could generate (for example) ...

species are registered in OBIS