Search - Map aggregate functionality (R2)
Status
-
Proposed -
Trialing -
Under review -
Approved -
Retired
Context & Scope
- Displays wells on map to ensure return result is as soon as possible; restricts # of fields and wells. Allows returning wells based on searches of child data.
- If query is geographic boundary and otherwise minimal, return all wells within that boundary: three fields (well name, unique id, …?)
- This functionality is a popular request, but implemented as special case in the data platform; not clear whether it can be generalized - Alan
Decision
Retain map aggregate functionality through a more generalized mechanism than R1
- Replace with injection of Elastic spatial filter
Rationale
Supports ISVs required functionality in a way that's not over-fitted for INT and SSIO
Consequences
INT and SSIO need to re-work R1 implementations.
Implementation Tasks:
- Gap fit on this use case
- Test according to the definition of done (Write test cases)
- Add a user story to the project ADO
When to revisit
Tradeoff Analysis - Input to decision
Alternatives and implications
- Retain R1 map aggregate functionality: no porting required, but overfits for INT and SSIO
- Retain map aggregate functionality through a more generalized mechanism: supports ISVs required functionality in a way that's not over-fitted for INT and SSIO
- Deprecate map aggregate functionality: simplifies OSDU but causes excessive burden on ISV client and networking