Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in / Register
  • S Storage
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 46
    • Issues 46
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
    • Requirements
  • Merge requests 15
    • Merge requests 15
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Package Registry
    • Container Registry
    • Infrastructure Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Open Subsurface Data Universe SoftwareOpen Subsurface Data Universe Software
  • Platform
  • System
  • Storage
  • Issues
  • #55
Closed
Open
Issue created Mar 08, 2021 by Gary Murphy@gtmurphyDeveloper

With R3 Schemas, Storage Frame of Reference is (generally) broken

Background
In the R2 timeframe, SLB contributed a feature for Storage that allowed (optional) fetching of records that also performed conversion to a standard Frame of Reference (FoR) in terms of CRS (WGS84), Unit, and datetime (UTC).
Here is the relevant Gitlab issue: Storage Issue #9
The salient point is that in this FoR implementation, the markup that determined what frame of reference the source data was in resided in the "metadata" block of the storage record.

Bug
With the new R3 Schemas, the metadata for "AnyCRS" feature collections has moved to the JSON block that directly contains the coordinate points, thus rendering the metadata block obsolete for CRS conversions and breaking the Storage FoR service. Records input in a different schema that uses the metadata block to markup the attributes with their source CRS, Unit, and datetime "units' will still work, but all R3 Coordinates using AbstractAnyCrsFeatureCollection will not work with the Storage FoR and will be indexed in their source values making them more or less meaningless.

Edited Mar 08, 2021 by Gary Murphy
Assignee
Assign to
Time tracking