Skip to main content
Implemented

Global Unit System in GraphQL Requests

Related products:API and SDKs
  • January 13, 2025
  • 4 replies
  • 39 views

Problem

Currently, Cognite's GraphQL API requires specifying the unit system for each attribute individually. This approach can be repetitive and impractical when querying multiple attributes, especially for large-scale use cases.

Proposed idea

Introduce a global unit system parameter at the query level, allowing users to define a default unit system (e.g., metric or imperial) that applies to all attributes in the request. Individual attributes can still override this setting if needed.

 

4 replies

Everton Colling
Seasoned Practitioner
Forum|alt.badge.img
  • Seasoned Practitioner
  • January 13, 2025

Hi ​@Oussama ALLALI!

I want to let you know that this functionality already exists in our GraphQL API through GraphQL variables and the targetUnitSystem argument exposed by the function getDataPoints, available for TimeSeries references.

Here's how you can use it today:

  1. Define a query variable (like "unitSystem") and set it to "SI" for metric or "Imperial"
  2. Use this variable with the targetUnitSystem argument in your getDataPoints queries
  3. When you want to change all units, you only need to update the variable value once

This means you don't have to specify the unit system for each attribute separately. You can set it once and apply it everywhere in your query. Of course, you can still override this for specific attributes if needed.

See below an example, where I’m fetching data points from multiple sensors stored on a data model view all using the metric system.

 


  • Author
  • Committed
  • January 28, 2025

Hi ​@Everton Colling 

Thank you for your response.  

I believe there might have been a misunderstanding about my request.

The targetUnitSystem functionality for time series is indeed very useful, but my use case is slightly different. I am referring to the ability to specify a unit system for all attributes of a specific type in a data model.

For example, let’s take the case of a wellbore type in a data model that includes attributes like topDepth and bottomDepth. My goal is to retrieve these attributes while specifying the desired unit system (metric or imperial) once at the type level, without having to define it individually for each attribute.

Desired Example Query:

query {
  wellbores(unitSystem: "metric") {
    id
    name
    topDepth
    bottomDepth
  }
}

 

Here, the unitSystem parameter would apply automatically to both topDepth and bottomDepth (and any other relevant attributes) without requiring individual overrides.

 

 


Everton Colling
Seasoned Practitioner
Forum|alt.badge.img
  • Seasoned Practitioner
  • January 29, 2025

Hi ​@Oussama ALLALI,

Thank you for the clarification. I now better understand your request, and I want to show you how this can be achieved with our GraphQL API, even for primitive data model attributes as in your example.

In a similar way as my previous example (which targeted time series datapoints), you’ll have to:

  1. Define a query variable (like "UnitSystem") and set it to "SI" for metric or "Imperial"
  2. Use this variable with the targetUnitSystem argument when writing the query for your properties
  3. When you want to change all units, you only need to update the variable value once

In your example, it would look something like this:

query MyQuery($UnitSystem: ID) {
listWellbores {
items {
id
name
topDepth(targetUnitSystem: $UnitSystem)
bottomDepth(targetUnitSystem: $UnitSystem)
}
}
}

with query variables set to:

{
"UnitSystem": "SI"
}

While the syntax is slightly different from your proposed example (targetUnitSystem instead of a top-level unitSystem parameter), it achieves the same goal: you only need to specify the unit system once in your variables, and you can apply it consistently across all desired numeric attributes. This gives the user flexibility to specify clearly which attributes to retrieve with unit conversion.

However, if you still believe the current syntax doesn't meet your needs, we can turn this idea back to the phase of gathering customer interest where we can observe if others face similar challenges with the current implementation.

In the meantime, I encourage you to try the current syntax with query variables as shown above - it's been designed to minimize repetition while following GraphQL best practices.


  • Author
  • Committed
  • January 30, 2025

it's very clear thank you for your answer !