Getting started
Exploring and using data
Exploring catalogs and datasets
Exploring a catalog of datasets
What's in a dataset
Filtering data within a dataset
An introduction to the Explore API
An introduction to the Automation API
Introduction to the WFS API
Downloading a dataset
Search your data with AI (vector search)
The Explore data with AI feature
Creating maps and charts
Creating advanced charts with the Charts tool
Overview of the Maps interface
Configure your map
Manage your maps
Reorder and group layers in a map
Creating multi-layer maps
Share your map
Navigating maps made with the Maps interface
Rename and save a map
Creating pages with the Code editor
How to limit who can see your visualizations
Archiving a page
Managing a page's security
Creating a page with the Code editor
Content pages: ideas, tips & resources
How to insert internal links on a page or create a table of contents
Sharing and embedding a content page
How to troubleshoot maps that are not loading correctly
Creating content with Studio
Creating content with Studio
Adding a page
Publishing a page
Editing the page layout
Configuring blocks
Previewing a page
Adding text
Adding a chart
Adding an image block to a Studio page
Adding a map block in Studio
Adding a choropleth map block in Studio
Adding a points of interest map block in Studio
Adding a key performance indicator (KPI)
Configuring page information
Using filters to enhance your pages
Refining data
Managing page access
How to edit the url of a Studio page
Embedding a Studio page in a CMS
Visualizations
Managing saved visualizations
Configuring the calendar visualization
The basics of dataset visualizations
Configuring the images visualization
Configuring the custom view
Configuring the table visualization
Configuring the map visualization
Understanding automatic clustering in maps
Configuring the analyze visualization
Publishing data
Publishing datasets
Creating a dataset
Creating a dataset from a local file
Creating a dataset with multiple files
Creating a dataset from a remote source (URL, API, FTP)
Creating a dataset using dedicated connectors
Creating a dataset with media files
Federating an Opendatasoft dataset
Publishing a dataset
Publishing data from a CSV file
Publishing data in JSON format
Supported file formats
Promote mobility data thanks to GTFS and other formats
What is updated when publishing a remote file?
Configuring datasets
Automated removal of records
Configuring dataset export
Checking dataset history
Configuring the tooltip
Dataset actions and statuses
Dataset limits
Defining a dataset schema
How Opendatasoft manages dates
How and where Opendatasoft handles timezones
How to find your workspace's IP address
Keeping data up to date
Processing data
Translating a dataset
How to configure an HTTP connection to the France Travail API
Deciding what license is best for your dataset
Types of source files
OpenStreetMap files
Shapefiles
JSON files
XML files
Spreadsheet files
RDF files
CSV files
MapInfo files
GeoJSON files
KML/KMZ files
GeoPackage
Connectors
Saving and sharing connections
Airtable connector
Amazon S3 connector
ArcGIS connector
Azure Blob storage connector
Database connectors
Dataset of datasets (workspace) connector
Eco Counter connector
Feed connector
Google BigQuery connector
Google Drive connector
How to find the Open Agenda API Key and the Open Agenda URL
JCDecaux connector
Netatmo connector
OpenAgenda connector
Realtime connector
Salesforce connector
SharePoint connector
U.S. Census connector
WFS connector
Databricks connector
Connecteur Waze
Harvesters
Harvesting a catalog
ArcGIS harvester
ArcGIS Hub Portals harvester
CKAN harvester
CSW harvester
FTP with meta CSV harvester
Opendatasoft Federation harvester
Quandl harvester
Socrata harvester
data.gouv.fr harvester
data.json harvester
Processors
What is a processor and how to use one
Add a field processor
Compute geo distance processor
Concatenate text processor
Convert degrees processor
Copy a field processor
Correct geo shape processor
Create geo point processor
Decode HTML entities processor
Decode a Google polyline processor
Deduplicate multivalued fields processor
Delete record processor
Expand JSON array processor
Expand multivalued field processor
Expression processor
Extract HTML processor
Extract URLs processor
Extract bit range processor
Extract from JSON processor
Extract text processor
File processor
GeoHash to GeoJSON processor
GeoJoin processor
Geocode with ArcGIS processor
Geocode with BAN processor (France)
Geocode with PDOK processor
Geocode with the Census Bureau processor (United States)
Geomasking processor
Get coordinates from a three-word address processor
IP address to geo Coordinates processor
JSON array to multivalued processor
Join datasets processor
Meta expression processor
Nominatim geocoder processor
Normalize Projection Reference processor
Normalize URL processor
Normalize Unicode values processor
Normalize date processor
Polygon filtering processor
Replace text processor
Replace via regular expression processor
Retrieve Administrative Divisions processor
Set timezone processor
Simplify Geo Shape processor
Skip records processor
Split text processor
Transform boolean columns to multivalued field processor
Transpose columns to rows processor
WKT and WKB to GeoJson processor
what3words processor
Data Collection Form
About the Data Collection Form feature
Data Collection Forms associated with your Opendatasoft workspace
Create and manage your data collection forms
Sharing and moderating your data collection forms
Dataset metadata
Analyzing how your data is used
Getting involved: Sharing, Reusing and Reacting
Discovering & submitting data reuses
Sharing through social networks
Commenting via Disqus
Submitting feedback
Following dataset updates
Sharing and embedding data visualizations
Monitoring usage
An overview of monitoring your workspaces
Analyzing user activity
Analyzing actions
Detail about specific fields in the ods-api-monitoring dataset
How to count a dataset's downloads over a specific period
Analyzing data usage
Analyzing a single dataset with its monitoring dashboard
Analyzing back office activity
Using the data lineage feature
Managing your users
Managing limits
Managing users
Managing users
Setting quotas for individual users
Managing access requests
Inviting users to the portal
Managing workspaces
Managing your portal
Configuring your portal
Configure catalog and dataset pages
Configuring a shared catalog
Sharing, reusing, communicating
Customizing your workspace's URL
Managing legal information
Connect Google Analytics (GA4)
Regional settings
Pictograms reference
Managing tracking
Best practices for search engine optimization (SEO)
Look & Feel
Branding your portal
Customizing portal themes
How to customize my portal according to the current language
Managing the dataset themes
Configuring data visualizations
Configuring the navigation
Adding IGN basemaps
Adding images and fonts
Plans and quotas
Managing security
Configuring your portal's overall security policies
A dataset's Security tab
Mapping your directory to groups in Opendatasoft (with SSO)
Single sign-on with OpenID Connect
Single sign-on with SAML
Parameters
- Home
- Analyzing how your data is used
- Using the data lineage feature
- Data lineage: what it is and how it works
Data lineage: what it is and how it works
Updated by Audrey M.
What is data lineage?
The data lineage feature provides a visualization of your ODS objects (datasets, pages, maps, and charts), how they're related to others objects, where they're being used, and by whom.
Opendatasoft offers two levels of information:
- Business lineage: This describes relationships between objects. It provides a high-level view of dependencies between these objects, offering a broad understanding of how different datasets or objects are connected within the platform.
- Field-level lineage: This option provides a more detailed view of relationships between objects specifically focusing on the fields linked within these objects. This view emphasizes dependencies at the data field level, offering an in-depth understanding of specific connections between fields in different ODS objects.
You can:
- Keep track of your dataset lifecycle
- Understand how an object affects or is affected by changes to objects up or downstream from it
- Quickly see which datasets are used and how popular they are
Where do I go to use data lineage?
There are two ways data lineage allows you to examine your datasets and how they're related to other ODS objects. In the back office:
- Go to the dataset you wish to examine, and click on the Lineage tab. For more details on how to use lineage on a dataset, see here.
- Go to the Analytics menu in the sidebar and click on "Lineage." For more details on how to use the lineage dashboard, see here.
A few key concepts and vocabulary
Many Opendatasoft clients have veritable data ecosystems. Data lineage provides a view of where your data comes from and is being used. But to do this, it uses a few key concepts it will help to understand: Broadly, what are the fundamental pieces of your ecosystem, and especially how do they relate to each other?
Objects and relationships
An ODS object is a dataset, a page, or else a map or chart created with a map or chart builder. A third-party object refers to an external source (file, URL, or remote service) of a dataset. These are the various pieces of your data ecosystem.
A relationship refers to how two objects are linked to each other, where one is the origin and the other is the destination.
In this example, A is the origin object and B the destination object. B depends on A.
These relationships can be direct or indirect, as described below.
A direct relationship
A direct relationship is one in which two objects are linked without any transformation. One is identified as the origin and the other as the destination.
In this example, dataset A is the origin object and dataset B is the destination object.
An indirect relationship
An indirect relationship occurs when a destination ODS object depends on a chain of direct or indirect relationships with other objects.
In this example, Dataset E is the origin of dataset A. In turn, Dataset A is the origin of Dataset B. Datasets E and B therefore have an indirect relationship.
An invalid relationship
A relationship is invalid when the origin object is no longer available within the Opendatasoft ecosystem. This can occur due to the deletion of the dataset, the removal or unpublishing of the workspace, or the unavailability of the dataset's source.
Upstream and downstream relationships
An ODS object has an upstream relationship if it is the destination object of another object and uses other objects for its construction. An object has a downstream relationship if it is used by other objects.
In the example below, Dataset E is upstream from Dataset A. Page P is downstream from Dataset A.
Specific relationship types
These are the different types of relationships that are possible between objects:
- Uses a federation (public or private federation, federation by harvester, or federation by distribution)
- Has a file, URL or remote service as a source
- Is the result of a simple join (using the Join datasets processor) or a provided join (achieved using geographical processors)
- Is used on pages, in the Studio, or in the map and chart builders
Invalidity
A relationship can be considered invalid within the Opendatasoft ecosystem for several reasons, including:
- Deletion, unpublishing or inaccessible: When the original ODS object is deleted or unpublished or when a third-party object becomes inaccessible, it disrupts the relationship and renders it invalid.
- Workspace dissolution: If the workspace associated with the relationship no longer exists, the relationship becomes invalid, as the environment where the data was structured is no longer available.
- Linked field alterations: Changes in linked fields such as deletion, renaming, or updates in their type can also invalidate relationships, as the reference points or connections are altered or are no longer accessible.
Declared and incognito modes
For the data lineage feature to be able to visualize the relationships between different objects, it's necessary to share usage metadata with other clients who own workspaces.
We want our clients to fully understand what data of theirs is collected and where it's being used. And notably, if their organization has special confidentiality requirements, to be able to opt-out of sharing the names of their workspaces.
Sharing modes are available to prevent sharing the identity of the destination ODS object with the owners of the origin objects.
Two modes are available:
- Declared mode
This is the default mode. Everyone will see the workspace name and the type of the destination object, but only authenticated users with relevant permissions will be able to see the name of the destination object. We encourage this mode because it gives other users the highest visibility on their data usage. In the lineage tab, you will see a locked icon on the ODS objects if you don’t have permissions. - Incognito mode
This is the restricted mode for lineage, where the name of the workspace, and the type and the name of the destination object are hidden from other users. Only the information about the type of the relationship will be shared with the relevant workspaces. This mode is indicated with a incognito icon.
Declared mode
This is the default mode. The relationship type, the title or name of the destination workspace are shared.
Other information is shared only if the user has the necessary permissions for the destination object:
The user doesn't have the necessary permissions
In this case, the Opendatasoft object has restricted access, and the user does not have the specific permissions to see it. The user can see the title or name of the destination workspace and the type of the destination object, but not its identity.
The ODS object is public, or else the user does have the necessary permissions
In this case, the ODS object has public access, or else has restricted access but the user does have the specifc permissions or role necessary to view it (they can view a dataset or page, browse all datasets, view all pages, browse statistics). In this case the user can also see the identifier, title and the linked fields of the destination object.
Incognito mode
This is the minimum level of information required to provide a lineage for ODS objects. By default and for each relationship, its type and information about the nature of the destination ODS object are shared with the origin workspace. Third-party objects are not affected and are not visible.
A summary of what is shared in each mode
Incognito mode | Declared mode (default) | |
Relation type | ✅ | ✅ |
ODS object type | ❌ | ✅ |
Name or title of the workspace | ❌ | ✅ |
Identifier or title of the ODS object | ❌ | Depends on the user's access. |
Linked fields of the ODS object | ❌ | Depends on the user's access. |
Third-party object | ❌ | Depends on the user's access. Not transmitted outside the current workspace. |