Skip to content

[Search.Phase 2] Implement search of rock samples by formation of the wellbore

Context

The user story covers the search capabilities, which include a mix of data sources: OSDU catalog(WKE) and RAFS bulk data.

The functionality will allow to manage the following use cases:

I need a rock sample analysis data from the specified basin with a TOC value > 2%

1 - Filter SampleID by basin id
2 - Check Sample.SampleType whether Rock/Fluid
3 - Filter Samples on having analysis with requested attribute
4 - Filter by value range for a specified attribute

Expected output:

  1. Bulk data (parquet or JSON) for the /{analysis_type}/search/data endpoint
  2. SampleAnalysis WPC ids (JSON) for the /{analysis_type}/search endpoint

Give me all compositional analysis done in Well ABC

1 - Check all Samples and retrieve the WellboreID from them
2 - From all wellbores retrieve the WellID
3 - Search for a specified Well Name
4 - Retrieve corresponding samples

Expected output:

  1. Bulk data (parquet or JSON) for the /{analysis_type}/search/data endpoint
  2. SampleAnalysis WPC ids (JSON) for the /{analysis_type}/search endpoint

Search for porosity values measured with a specified tool or method

Expected output:

  1. Bulk data (parquet or JSON) for the /{analysis_type}/search/data endpoint
  2. SampleAnalysis WPC ids (JSON) for the /{analysis_type}/search endpoint

Note: only if a Wellbore DDMS connection is not required

1 - Find WellboreMarkerSets that contains the specified formation name
2 - Check the top/bottom depth of the identified formation
3 - Retrieve the WellboreID
4 - Check the depth of all Samples with reference to identified WellboreID in RAFS DDMS
5 - Cross-check the formation top/bottom depth against the sample depth

Expected output:

  1. Bulk data (parquet or JSON) for the /{analysis_type}/search/data endpoint
  2. SampleAnalysis WPC ids (JSON) for the /{analysis_type}/search endpoint

Constraints

  1. Search within one type of analysis per request:

Due to schema versioning, some overlay (overwriting) of the values can occur for the properties from different content schemas but with the same name.

  1. Search for only one content schema version

Due to the absence of a final decision about backward compatibility, the service will support requests for only one schema version.

image

  1. Search by only a limited set of WKE properties, e.g., Basin, Field, WellID, WellName, WellboreName...

To ensure the service's performance, all WKE-related entities must be indexed in the cache. Each property requires its specific logic for indexing.

  1. There is no interconnection with other DDMSs.
Edited by Siarhei Khaletski (EPAM)