I was exploring the occurrence web services on Friday and thought I would document what I found. As Mandy said, the required information is at the link she provided in the original post but, excuse the loose analogy, that is a bit like giving me a Greek dictionary and saying that is the required information to speak Greek. It depends a bit on your existing linguistic skills as to just how easy that is.
The Occurrence Details service allows you to retrieve the details of any individual record in the database by calling it with the universally unique identifier (UUID) of the record you are interested in. For example, https://records-ws.nbnatlas.org/occurre … 1b32cf663a. The information returned is in JSON format which I have found easiest to read by copying and pasting in to JSON Editor Online. I can paste the response in to the left panel and use the format button in the panel header to beautify it. I can use the central arrow button to move it to the right panel where it is presented in a tree editor allowing me to expand and collapse sections.
The object returned has 5 top-level elements
object {5}
processed {28}
raw {28}
userAssertions [0]
consensus {28}
systemAssertions {5}
We have not been provided with any information about this but I would infer that the raw object is the original data. I'm guessing this could have come with some assertions from the user but did not. I imagine the import of data in to the Atlas involved some processing resulting in a processed version of the record and some assertions from the system as a consequence of the processing. Just possibly there was a comparison between the processed and raw data resulting in a consensus object indicating the areas of agreement. This is speculation and the facts needs documenting.
For info, the data for this record can be found on the gateway from https://data.nbn.org.uk/api/taxonObservations/442905281
Let's dive a bit deeper in to the returned data and look at the location information contained within it as an example. Expanding the raw object's location element I see
raw {28}
location {6} {
decimalLatitude : 57.63
decimalLongitude : -1.94
gridReference : NK0360
marine : false
terrestrial : false
coordinatePrecision : 1km
I think it likely that this record would have been provided as a 1km grid square and the latitude and longitude have been calculated from the centroid of the square to the nearest 2 decimal places.
Expanding the processed element I see
processed {28}
location {8}
decimalLatitude : 57.63
decimalLongitude : -1.94
stateProvince : Scotland
coordinateUncertaintyInMeters : 1000
marine : false
terrestrial : false
geodeticDatum : EPSG:4326
country : United Kingdom
This is has dispensed with the grid square and now only has the rather low precision latitude and longitude and an uncertainty in metres. If I were giving uncertainty on a point I would provide it as a radius. We don't have any documentation to tell us if that is the case here but, if so, our record has gone from a square of area 1km^2 to a circle of area 3.14km^2. Therefore, if you are accessing this data, you may wish to ensure you refer to the raw data rather than the processed data. The raw data also contains elsewhere the rather charming comment "Marten accessing garage through cat flap over period of 4 months and killed pet rabbit." which is not in the processed object.
I don't know what to make of them but there are also some system assertions to do with the location of the record. There is a failed assertion, precisionRangeMismatch, with the comment "Unable to parse the coordinate precision", and a warning, geodeticDatumAssumedWgs84, with the comment "Geodetic datum assumed to be WGS84 (EPSG:4326)".
I hope this is of some use to other users but I think it is perhaps more use as feedback to the NBN on how much more information I would need to use the service confidently.
Jim Bacon.