This section explains the core objects and concepts used throughout LuData.
Understanding these concepts is essential before using the platform, whether through the web interface or APIs.
They define how data is requested, processed, delivered, and accounted for.
A site represents a physical geographic location.
It is defined by:
- Geographic coordinates (latitude, longitude)
- Optional contextual information (name, reference, country)
A site is the fundamental spatial unit in LuData.
All data services, models, and analyses are always executed in the context of a site.
LuData pricing and usage are intentionally structured around sites, as they correspond to real engineering studies and real-world assets.
A Scenario represents a specific analysis configuration applied to a site.
A scenario defines:
- Which services are requested
- Over which time period
- With which parameters and assumptions
- under different other potential conditions
A single site can have multiple scenarios, for example:
- Different time periods
- Different datasets or services
- Updated assumptions
- Different scenario names or site naming conventions
Scenarios ensure:
- Reproducibility
- Traceability
- Clear separation between analyses
All results generated by LuData are always attached to a scenario and accessible through the LuData user interface if they are requested via the UI of Ludata.
Through the API, we leave the user the choice to cache the request optimally on his/her side.
A Service is a functional capability provided by LuData.
Examples include:
- Historical Time Series Data (HTSD)
- Typical Meteorological Year (TMY) generation and custom PXX products
- Digital Elevation and Horizon services
Services encapsulate:
- Data source selection
- Processing logic
- Conventions and assumptions
A Dataset refers to an underlying data source used by a service.
Datasets may originate from:
- Satellite missions
- Reanalysis products (e.g. ERA5)
- Derived or post-processed data (e.g. transposition of horizontal irradiance, decomposition into different irradiance components, etc)
Dataset selection is handled automatically by LuData based on:
- Geographic location
- Time period
- Availability
- Spatial and temporal resolution
- Data continuity
Internally, LuData executes requests to deliver services.
A request is a technical execution unit used to orchestrate and optimise how raw data is processed and exposed to users.
Depending on the product and service, a request may be defined by:
- One service
- One site
- One scenario
- One time range (typically within a year of data)
- One variable
Requests are used internally for:
- Platform orchestration and optimization of delivery
- Usage tracking
- Fair resource allocation
¶ Capacity and usage units
Externally, users do not purchase requests.
Instead, users purchase capacity, expressed in business-friendly units such as:
- Number of sites per year
- Portfolio size
- Platform or application usage bundles
This abstraction:
- Avoids complex technical accounting
- Aligns pricing with real engineering workflows
- Provides predictable and transparent budgeting
Internally, LuData maps capacity consumption to technical execution units in a transparent manner.
For clarity to our users, the notion of site unit is equivalent to ~800 requests.
This number is the normalization that we use in order to simplify couting for our users.
Results are the outputs produced by a scenario.
They may include:
- Time series data (CSV, TXT, JSON, other requested format by customers etc.)
- Aggregated indicators
- PDF reports
- Digitally rendered reports (e.g. HTML)
- Other data assets
Results are:
- Stored and associated with the scenario
- Accessible via the web interface and APIs
- Traceable in terms of inputs and usage
Results remain available according to the user’s contract and data retention rules.
¶ UI and API equivalence
LuData offers two access modes:
- Web user interface
- Programmatic APIs
Both access modes:
- Expose the same services
- Follow the same usage rules
- Consume the same capacity
- Produce identical results
When using the web interface, scenarios and results are stored and managed within LuData.
When using the APIs, users are responsible for handling caching and persistence on their own systems.
The choice between UI and API depends on the user’s workflow, not on feature availability.
At a high level, LuData operates as follows:
- A Site defines where
- A Scenario defines what and how
- Services define which data or model
- Requests execute internally
- Capacity defines what users are entitled to consume
- Results are delivered and stored
All other parts of the documentation build upon these concepts.