Change WellsLayer data-model to use WellLogJson instead

[Anders2303]

As discussed; we want to change the wells layer to use WellLogJson instead of GeoJson, so the data types are more unified across components. I'll start working on this; we can use this issue for further discussion if needed

[Anders2303]

@hkfb @w1nklr @Midtveit

As I'm working on this, I'm realizing that going purely WellLogJson data might not be the best; we still need the data objects to include information about the well and wellbore itself (such as id, name, and so on), but there's no place for that in the WellLogJson format (the header field is for metadata pertaining to the log set itself).

I propose the following data type, does it seem okay to you at AspenTech?

type WellboreData = {
    // Data specific to the *wellbore*
    id: string;
    name: string;

    // Logs for all measurements along the wellbore (this would include trajectory logs)
    wellLogs: LogCurveDataType[] | LogCurveDataType[][];

    // Data about the well that owns the wellbore
    well: {
        id: string;
        position: [easting: number, northing: number, tvd: number];
        // ...
    };

    // ...
};

[Anders2303]

As for the trajectory as a log, that works well as a log; the only thing we need here is to define what names we'd expect, and how you configure them.

An example of a log is shown below; are these good defaults curve names?

const exampleTrajectoryLog: LogCurveDataType = {
    header: {
        name: "WELL_TRAJECTORY",
        well: "well1",
        wellbore: "well1-A"
    },
    curves: [
        { name: "MD", description: "Measured Depth" },
        // Azimuth?
        // Inclination?
        { name: "TVD", description: "tvd" },
        { name: "EASTING", description: "Easting trajectory" },
        { name: "NORTHING", description: "Northing trajectory" },
    ],
    data: [
        [0, 0, 500, 500],
        [100, 100, 600, 600],
        [200, 200, 700, 700],
        [300, 300, 800, 800],
    ],
    metadata_discrete: {},
};

For user config, I'm considering accessors for log-name and curve indices, which I think should be sufficient

type WellsLayerProps = {
    // ... most existing props
    data: WellData[];

    // Return the exact log object, or the name of the log set   
    getTrajectoryLog: TrajectoryLogAccessor;
    // Return curve indices as [number, number, number] or {x: number, y: number, z: number
    getTrajectoryCurveIndices: CurveIndicesAccessor; 
 };

[w1nklr]

What does getTrajectoryCurveIndices: CurveIndicesAccessor return ?

How is the returned value decided ?
I guess {x: number, y: number, z: number} (BTW, missing closing bracket) is the XYZ coordinates.
But are the [number, number, number] really indices ?

[Anders2303]

What does getTrajectoryCurveIndices: CurveIndicesAccessor return ?
@w1nklr

It should return the indexes of the curves, i.e. the column for each trajectory and their data. So for this example, the value would be [2, 3, 1] (or {x: 2, y: 3, z: 1}) since xyz is defined by Easting, Northing, and TVD respectively.

Looking back at it, I see that this is probably needlessly confusing; the getter should probably just return the curve names:

// Return the name of each curve that describe the trajectory path of the wellbore.
// Value can be *either* a list or object
getTrajectoryCurveNames: CurveNamesAccessor;

As for the array vs the object, the idea was to accept either, just as a QoL for layer users

[Midtveit]

Hi We have near full day workshop this week, and Håvard is sick. So we probably have to come back the format discussion I should know, but can not remember are this format versioned Regards Knut

…

________________________________ From: Anders Rantala Hunderi ***@***.***> Sent: Tuesday, November 25, 2025 12:00 PM To: equinor/webviz-subsurface-components ***@***.***> Cc: X, Knut Midtveit ***@***.***>; Mention ***@***.***> Subject: [EXTERNAL] Re: [equinor/webviz-subsurface-components] Change WellsLayer data-model to use WellLogJson instead (Issue #2661) [https://avatars.githubusercontent.com/u/23122793?s=20&v=4]Anders2303 left a comment (equinor/webviz-subsurface-components#2661) [github.com]<https://urldefense.com/v3/__https://github.com/equinor/webviz-subsurface-components/issues/2661*issuecomment-3575048693__;Iw!!OkyjEqkqqe9UhNQ!1DvWRhH8wKybQiwA5L_HasJowLw9dr10SlEIQFAxkWGqCStctdJiZSjn8mHQtVNZvPrfEvRcYpfUr43g58jKF_2UC8TJBQ$> What does getTrajectoryCurveIndices: CurveIndicesAccessor return ? @w1nklr [github.com]<https://urldefense.com/v3/__https://github.com/w1nklr__;!!OkyjEqkqqe9UhNQ!1DvWRhH8wKybQiwA5L_HasJowLw9dr10SlEIQFAxkWGqCStctdJiZSjn8mHQtVNZvPrfEvRcYpfUr43g58jKF_2MkKUUXg$> It should return the indexes of the curves, i.e. the column for each trajectory and their data. So for this example, the value would be [2, 3, 1] (or {x: 2, y: 3, z: 1}) since xyz is defined by Easting, Northing, and TVD respectively. Looking back at it, I see that this is probably needlessly confusing; the getter should probably just return the curve names: // Return the name of each curve that describe the trajectory path of the wellbore. // Value can be *either* a list or object getTrajectoryCurveNames: CurveIndicesAccessor; As for the array vs the object, the idea was to accept either, just as a QoL for layer users — Reply to this email directly, view it on GitHub [github.com]<https://urldefense.com/v3/__https://github.com/equinor/webviz-subsurface-components/issues/2661*issuecomment-3575048693__;Iw!!OkyjEqkqqe9UhNQ!1DvWRhH8wKybQiwA5L_HasJowLw9dr10SlEIQFAxkWGqCStctdJiZSjn8mHQtVNZvPrfEvRcYpfUr43g58jKF_2UC8TJBQ$>, or unsubscribe [github.com]<https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AKCHHEME6AR46X4AWN4IROD36QZGRAVCNFSM6AAAAACMOUCZJCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTKNZVGA2DQNRZGM__;!!OkyjEqkqqe9UhNQ!1DvWRhH8wKybQiwA5L_HasJowLw9dr10SlEIQFAxkWGqCStctdJiZSjn8mHQtVNZvPrfEvRcYpfUr43g58jKF_0U6F34zA$>. You are receiving this because you were mentioned.Message ID: ***@***.***>