Skip to content

369: Extend Trajectory Ingestion to Support Station Retrieval from Well DDMS

Levi Remington requested to merge 369-extend-trajectory-ingestion-to-support-ddms-lr into master

Type of change

  • Bug Fix
  • Feature

Please provide link to gitlab issue or ADR(Architecture Decision Record) #369 (closed)

Does this introduce a change in the core logic?

  • [YES/NO] Extension of existing Trajectory logic

Does this introduce a change in the cloud provider implementation, if so which cloud?

  • AWS
  • Azure
  • GCP
  • IBM

Does this introduce a breaking change?

  • [YES/NO]

What is the current behavior?

  • When fetching RefPoints for a Trajectory, the current behavior is to query OSDU Search once for every Trajectory's associated wellbore.
  • When configuring application.yml for Trajectory ingestion, user must specify trajectoryWellboreKind
  • Programmatic Trajectory Completion depends on existence of Datasets array, from which we may fetch a CSV of Trajectory stations, which can be parsed into a ConvertTrajectory request to complete the Trajectory.

What is the new/expected behavior?

  • RefPoints are retrieved all at once via singular OSDU Search request per Trajectory batch, greatly reducing load on OSDU Search
  • trajectoryWellboreKind is no longer required. Instead, an id search is executed across all kinds, reducing configuration and expanding support for Trajectory datasets where individual trajectories may correspond with Wellbores of different kinds.
  • Now, Programmatic Trajectory Completion first checks for existence of DDMSDatasets array, from which we can assume loading of Trajectory through DDMS, indicating that station metadata should be retrieved back through the DDMS:

Fetching stations from DDMS is faster and more flexible than CSV parsing approach. Here are the steps:

  1. If Trajectory record has DDMSDatasets array with a size > 0... Proceed to fetch stations through DDMS
  2. In order to know which columns to request from DDMS, we scan AvailableTrajectoryStationProperties to identify column names for the following TypeIDs:
    • TrajectoryStationPropertyType:TVD:
    • TrajectoryStationPropertyType:MD:
    • TrajectoryStationPropertyType:AzimuthTN:
    • TrajectoryStationPropertyType:Inclination
  3. Afterwards, the request to DDMS is executed, and the response is parsed into a LineString representing the completed Trajectory.

Have you added/updated Unit Tests and Integration Tests?

Any other useful information

Closes #369 (closed)

Merge request reports