Correct a well's position

A well imported from a table is located by its row of the copy the import kept (see Import wells from a table). When that position is wrong you correct it here, not in the table: the corrected position is a small item of its own about that one well. The copy is never changed, every earlier version of the correction is kept, and the well moves only for the people who may read the correction.

What a correction keeps fixed:

• The well. A correction stays with the well it was made for; it cannot be moved to another well.
• The coordinate system and the elevation reference of the position it corrects. Only the coordinates change; nothing is converted.

Who may correct:

The position shown comes from	What is sent	Who
a row of the kept copy	a new corrected position for this well	a project administrator
a corrected position you may add versions to	its next version	its author, or a colleague the project names with the author
a corrected position you may not add versions to	a separate corrected position of yours, built on it	anyone allowed to build on it

In Workspace

1. Open Data → Wells and wellbores and choose the well. Its view shows the position and where it comes from, for example “From row ALO-01 of a kept copy of a table, stated by Alice on 5 Oct 2026”.
2. Choose Correct this position and type the coordinates in the coordinate system shown (easting and northing, or longitude and latitude).
3. Review shows the old and the new coordinates. Choose Send.
4. A first correction is yours alone: “Only you can see this position until you share it.” Share it from the panel underneath. A later version is seen at once by everyone who can read the corrected position: “Sent as version 2. Version 1 is kept.”

If someone sent a newer position first, the view says so and offers Look at the newer position (your typed coordinates stay in the form) or Save mine as a separate item. Sending the same coordinates as an earlier version sends nothing and names that version.

A later import of the same table row is newer evidence: it becomes the well’s position again for its readers, and the correction stays in the history. Unsharing the correction moves the well back to the copy’s row for the people who no longer read it.

In Python

Say which well, where it is, and who should see the corrected position:

well_name = "ALO-01"           # the well whose position you correct
x, y = 217012.5, 568540.0      # the corrected coordinates, in the coordinate system of the position shown
colleagues = ["bob"]           # project members who should see it

Read the position you are correcting. Its source names the kept copy and the row it comes from:

well = next(w for w in client.wells() if w.name == well_name)
shown = well.location
print(shown["x"], shown["y"], shown["crs"], shown["elevation_reference"])
print(shown["source"]["profile"])   # sql-wells/1: a row of a kept copy of a table

Write the corrected position and send it, built on the copy and naming the well. The file holds the coordinate system and elevation reference of the position shown and the new coordinates, written the way Workspace writes them, so the same coordinates are always the same file. The command id comes from the well, the version built on and the file, so sending again after a lost answer returns the same receipt and creates nothing twice:

import hashlib
import json
from ophiolite.writers import WrittenOriginal


def number(value):
    # 217012.0 is written 217012, as Workspace writes it
    return int(value) if float(value).is_integer() else float(value)


def send(x, y, parent, version_of=None):
    position = {"crs": shown["crs"], "elevation_reference": shown["elevation_reference"], "x": number(x), "y": number(y)}
    raw = json.dumps(position, sort_keys=True, separators=(",", ":")).encode()
    command = hashlib.sha256(json.dumps(["e74b", well.entity_id, parent[1], hashlib.sha256(raw).hexdigest()],
                                        separators=(",", ":")).encode()).hexdigest()
    version = {"new_version_of": version_of, "expected_parent": parent[1]} if version_of else {}
    return client.publish_derived(WrittenOriginal(raw, "well-location/1"), name=well_name + " position", from_=[parent],
                                  method={"name": "Corrected in Python", "declared": False}, command_id=command,
                                  of_entity={"kind": "well", "entity_id": well.entity_id}, **version)


copy = (shown["source"]["asset_id"], shown["source"]["revision"])
receipt = send(x, y, copy)
print(receipt.revision_number)   # 1: only you see it until you share it

Share it. Sharing covers every version, earlier and later:

grants = client.grants(receipt)
client.share(receipt, read=colleagues, expected_generation=grants.generation)

To correct it again, send the next version of the same item, naming the version you replace. If someone sent a newer version first, the server refuses yours (409) and nothing is written; read the newer one and decide again:

again = send(217013.0, 568541.0, (receipt.asset_id, receipt.revision), version_of=receipt.asset_id)
print(again.revision_number)     # 2; version 1 and the copy are kept

Everyone who reads the correction now finds the well there (client.wells(), ophiolite wells list, the QGIS map feed), and a program holding version 1 hears from ophiolite check that version 2 is newer. In wells().with_source() a corrected well is marked no origin: its position comes from a location item, not from a row of a source table.

The server refuses, with a sentence saying why: a version naming another well, a version in another coordinate system or elevation reference, a first correction from a copy whose association with that well was withdrawn, and associating a correction with another well.