DataClassesSpatial - AtlasOfLivingAustralia/ala-datamob GitHub Wiki
2013/14 - i rescued this from the old sites portal, which is behind a closed door - maybe one day i'll revise it to read a little easier
ALAhandlingspatiallocationdata.pdf
DataClassesCoordinateConversion#Conversion
DataClassesCoordinateConversion#Obfuscation
In the context of the Atlas there appear to be many forms of spatial data. Generally speaking, the notion relates a fact to a point in space. The fact may be one of a number of concepts that surface (i.e. appear, or are made accessible) in various sub-systems:
| Context | Fact type | Notes |
|---|---|---|
| Occurrence | point-location | specimen/species observation see darwincore terms dwc.decimalLatitude, dwc.decimalLongitude and associated metadata; also, review DataClassesCoordinateQuality |
can be defined as lines, eg: a trawl, or specified as closed boundaries such as a paddock or catchment boundary
dwc.footprintWKT
shape data define boundaries and are more complex than simple points, or point & radius
Environmental (gridded) sample at pointor more likely a 'smoothed' or averaged value across a defined area
gridded data are usually (/can be) environmental properties within a particular spaceproperties might be 'rainfall for summer months' or 'primary soil classification'
the areas are usually normalised to allow easy comparison of variables between data sets (eg: grids of 1km2 or 1 degree2), hence the name 'gridded'
Contextual (polygonal) simple or complex boundary a defined area, and usually some sort of associated classification/value, stored against a specific propertyeg: property='state/territory', value='NSW'; or
property='soil classification', value='Pfry';
Descriptive locations textual often found against specimen records as verbatim data/quality caveats, an example might be '13 mi NW dry ck'dwc.verbatimLocality
may also be used as evidence to georeference or standardise locations
Coordinates (aka. geocodes, latitude/longitude, lat/long, grid reference, ...) - effectively an x,y pairas points in: biocache, spatial portal
as shapes in: biocache?, spatial portal
'add to map->layers' in spatial portal,
biocache also stores a matrix of all environmental data at any given point - somewhat of an 'inverted index' for analysis purposes - visible as 'property-value' pairs within an occurrence record that has been ingested completely
(section 'Environmental sampling for this location' at time of writing, example: http://biocache.ala.org.au/occurrences/2f2cb5b5-819b-4bd3-854b-59849cd13622)
as for gridded environmental properties (samples), placement within areas/classifications are also stored against occurrences
(section 'Additional political boundaries information' at time of writing, see previous biocache occurrence example)
it is expected that the above logic (psuedo-code) and such will need to be modified to handle lcc if it proves to be widely used.
it may be that the prototype mobilisation utility will wind up using the geotrans libraries to handle conversions in a more robust fashion, although my gut feeling at this stage is that the complexity is better handled here within ala servers (maybe called up as a web-service?); in any case the utility should include a switch to enter a test-mode, to ensure that the version of the geotrans native code library that winds up being installed can be accessed from the jvm & performs correct conversions: