Drill hole trace

[DUGUEY]

The drill hole traces created by Albion were compared with the traces created by other 3D modelling software. The both traces using the tangentiel balanced algorthm are the exactly the same. Nevertheless, I notice a difference with the location of geological intersect ( shifting round 40 cm) along the drill hole, if I enter in my project a gamma table or not. I believe that the shift is comming from the fact that gamma table (avp table) is used to calculate the maxmum depth of the drill holes, if this depth is different from the depth calculate from resistivity table there is shift. It is not a big issue, but it seems important to fix this problem

[vmora]

The hole depth is the max of the depth found in other tables:

with dep as (
                    select hole_id, max(to_) as mx
                        from (
                            select hole_id, max(to_) as to_ from _albion.radiometry group by hole_id
                            union all
                            select hole_id, max(to_) as to_ from _albion.resistivity group by hole_id
                            union all
                            select hole_id, max(to_) as to_ from _albion.formation group by hole_id
                            union all
                            select hole_id, max(to_) as to_ from _albion.lithology group by hole_id
                            union all
                            select hole_id, max(to_) as to_ from _albion.facies group by hole_id
                            union all
                            select hole_id, max(from_) as to_ from _albion.deviation group by hole_id
                            ) as t
                    group by hole_id
                )
                update _albion.hole as h set depth_=d.mx
                from dep as d where h.id=d.hole_id

[DUGUEY]

I create small Albion projects with 3 drillholes, the trace and the intersect location are calculated with Albion, in one project I have gamma table, in the other project no gamma table. The collar, the deviation and lithology table are the same in the two projects. At the end the traces are the same in the two projects, but lithology intersect (in blue and brown) are not located at the same level (see figure below) with the two project.

[vmora]

Can you change the symbology to include a line offset for all lines such that they can be distinguished from one another plz ?

This is a weird result indeed.

[vmora]

@DUGUEY I found the source of the issue.

To take care of the case where there is no deviation information fro the hole, we use the attribute depth_ that we compute as the max depth of all data defined as hole segments between a from_ and a to_. We do that for each hole.

The hole geometry is computed with the deviation information. If the length of the obtained geometry is too short, we lengthen it up to depth_ by prolongating the last (deepest) segment if it exists, or creating a vertical segment for the hole (case when no deviation info exists for this hole. So, if everything is coded properly (and I believe it is), at the end of this lengthening operation, the length of the hole geometry st_3dlength(geom) is equal to depth_.

The problem arises when the deviation information goes actually beyond any other information, in that case the length of the hole geometry is greater than the value stored in depth_.

Why do we care ? Because we assumed that st_3dlength(geom) = depth_ and used that to speedup the hole_piece function that compute the geometry of a hole segment given a to_ and a from_ value. So we use depth_ (a constant) instead of st_3dlength(geom) (a function call).

There are two easy fixes:

• use st_3dlength(geom) in the hole_piece function instead of depth_
• update the depth_ attribute after computing the hole geometry

In the first case, we can't rely on depth_ which remains wrong, we don't really use it anywhere else but I don't like the idea of keeping false information (for the matter I don't like the information duplication that depth_ is either).

In the second case, it's the database user's responsibility to make sure that this update is performed. And I really don't like giving that kind of responsibility to users.

I'm still trying to figure out a third option that does not impair performance, and solves a latent isssue: if the user adds data after the hole geometry computation and the data goes deeper than the hole geometry, it is not possible to compute the data geometry.

[vmora]

create or replace function albion.hole_piece(from_ real, to_ real, hole_id_ varchar)
returns geometry
language plpgsql stable
as
$$
    begin
        return (
            select st_makeline(
                st_3dlineinterpolatepoint(geom, from_/l),
                st_3dlineinterpolatepoint(geom, to_/l))
            from (select geom, st_3dlength(geom) as l from albion.hole where id=hole_id_) as t
        );
    end;
$$
;

[vmora]

fixed in r2.2