A couple of people have stumbled over this one in recent weeks. No “bug bounties” I’m afraid folks – this behaviour is intentional. Honestly, it’s not a bug, it’s a feature!
In a high precision study, you may have analysed many samples within a small depth range. If the occurrence data were plotted at the exact analysis depth, then all the histograms and labels would plot on top of each other.
This can make it difficult to see the finer detail. In order to get around this problem, we ‘distribute’ the analyses into the surrounding empty space, such that each data point is readable.
Possibly the most frequently asked question we are asked is “why do my samples show with different numbers of decimal places?”, or “where are the decimal places on my cuttings?”. StrataBugs charts have always displayed the different sample types with precision which reflects the nature of the sampling. Cuttings samples show to the nearest whole metre (or foot) because it would be misleading to suggest the depth was any more precise than that.
Here’s the full information for all sample types:
|CU||cutting||nearest whole metre or foot|
|SC||sidewall core||1 decimal place|
|CO||core||2 decimal places|
|OC||outcrop||2 decimal places|
|LOG||log pick||1, 2 or 3dp – configurable by super-user (Control Panel > Config > Default samples depths)|
This affects the charts and wherever samples are displayed along with their type and label in the data tables. The position of samples is still determined by the depth you give them (and which, in the case of cores (and optionally cuttings) may be affected by core shifting).
These levels of precision follow an industry convention used since version 1.0 of StrataBugs. One drawback is sometimes where you have a well originally drilled in feet and now dislayed in metres, where you would like to show the cuttings depths to 2 decimal places to reflect the converted number. You can do this in the Samples panel by checking off the “Display symbols” option in the panel propeties.
Within the database itself, all sample depths are stored in metres to at least three decimal places (dependent on the database type).