Use concatenation instead of hashes for occurrenceIDs about data-publication

[timrobertson100]

The benefits of an approach are that:
a) it is recognisable to anyone who knows the data
b) one can sort a CSV file on the column (using e.g. a linux sort) and then iterate over it to do e.g. a time series map without actually loading into a database - it is already in time sorted order
c) it is possible that pre-sorting data will make it load quicker into a data store (e.g. database) as there is less fragmentation in the data to arrange
d) there is no change of collisions due to duplicate hashing

This structure would colocate data about an individual in the file. If your query patterns were primarily time oriented (e.g. across all individuals) then it might make sense to reverse the key order (time first, then individual).

The downside is this is likely to require more bytes than a hash and changing resolution (e.g. from seconds to nanoseconds) would result in a changed length of key (different number of bytes) and that means a variable width type is needed.

[peterdesmet]

We might probably use 891:20150301112532 (with colon), to reflect the format of the occurrenceIDs of our other datasets. Any downsides?

[timrobertson100]

Looks good to me.
It was just a suggestion...

[peterdesmet]

Done in ff49bcd