Annex 1. Metadata documentation template
This template assists test sites in thoroughly documenting their datasets. This documentation aids in evaluating aspects like safety, efficiency, and the environmental impact of new systems. Detailed metadata facilitates data re-use, even by individuals who were not involved in the original data collection.
Where applicable, the fields align with the Dublin Core Metadata Initiative. For more details, visit https://www.dublincore.org/specifications/dublin-core/dcmi-terms/.
1. Dataset Summary
Title: [A name given to the dataset]
Description: [Short public summary for data catalogues]
Persistent identifier, URL: [Unique identifier, hyperlink]
Country: [The country or countries where the data was collected or created]
Location(s): [Main coordinates for map searches]
Test start date: [Date associated with the start of data collection or generation]
Test end date: [Date associated with the end of data collection or generation]
Creator: [The name of the entity primarily responsible for creating the dataset. This can be a person, and organization, or a service.]
Owner: [Organization with ownership rights to the dataset]
Keywords: [Keywords for use in search]
2. Administrative metadata
Dataset version number: [Version]
Date: [Last update]
Publisher: [Person who last updated the dataset and made it available]
Contact person(s): [Contact details regarding general inquiries and requesting access]
Access and sharing conditions: [Summary about access requirements and data sharing conditions]
Language: [Languages used in the dataset and its documentation]
3. Dataset categories for search and select
Number of vehicles:
Number of test subjects:
Public anonymous sample data available: [yes/no]
Vehicle type:
- Passenger cars (e.g., sedans, SUVs, electric cars)
- Heavy vehicles (e.g., trucks, lorries)
- Industrial vehicles (e.g., forklifts, excavators, tractors)
- Public transport (e.g., buses, automated shuttle buses, trams)
- Motorcycles & Two-Wheelers (e.g., standard motorcycles, scooters)
- Other: [please specify]
Tested system(s):
- Automated driving
- Integrated driver support system
- Aftermarket System (e.g., add-on navigation, advanced parking systems)
- Remote operations & control
- Connectivity & Telematics
- Other: [please specify]
Data logs contain:
- Unrestricted driving in extensive areas (e.g., a city or district, allowing for dynamic route selection based on needs)
- Driving along multiple predetermined routes
- Driving on specific test routes
- Raw data from environmental sensors
- Processed data on surrounding elements (e.g., detected vehicles, identified lanes)
- High-precision positioning data (e.g., RTK-GPS or equivalent)
Locations:
- Dense urban centres (e.g., city downtown)
- Broader urban areas (e.g., city suburbs)
- Rural landscapes
- Motorways or highways
- Mountainous or hilly regions with notable slopes
Weather Conditions:
- Heavy rainfall
- Foggy environments
- Snow-covered roads
Driving Conditions:
- Night-time scenarios
- Traffic congestion
4. Structural metadata
4.1 Log data details
Data storage format: [Database, CSV file, H5 file, XML etc.]
Other file formats used: [Video, Excel etc.]
Data field descriptions: [see example]
ID | Field name | Description | Unit and type | Sample rate | Minimum value | Maximum value | Value, if not available |
1 | vehicle_speed | Wheel speed sensor | km/h, double precision | 10 Hz |
4.2 Manual annotations
Documentation of annotation process and details, e.g. a video annotation codebook in use
4.3 Self-reported data details
Data storage format: [Database, CSV file, H5 file, XML etc.]
Data description document: [Questionnaire template, diary template or similar]
4.4 Processed summary/aggregated data details
Documentation of several indicators and summaries that may have been processed and are provided with the data. For example, the data has been split automatically into trips and for each trip, average speed and maximum speed have been calculated.
4.5 Data quality
Describe how data quality has been ensured and checked, or describe the quality in general.
5. Study design and test execution as separate documentation
This or separate documentation should describe the study from test leader and evaluation perspectives. It is recommended to cover at least the following aspects:
- Summary information of the project and cooperation partners, duration, budget etc.
- Main goals and research questions
- Test site (if it was within a specified perimeter) and routes, including maps and photos
- Overall description of equipment used: vehicle fleet, functions, HMI, additional driver support in the vehicle (navigators, etc.) – preferably with links to videos demonstrating use. Please describe also infrastructure and communication elements.
- Users/operators, description of their selection criteria, recruitment processes and agreement templates
- How user contact was maintained during the study
- Possible grouping of participants (e.g., test groups 1 and 2 and a reference group)
- Test plan and execution. For example, what the participants were asked to do, how and when the briefing was given, when and what questionnaires were administered or what interviews were conducted? How many times some test run or route was repeated?
- Test diary including dates, study phases and commentary (it is possible to use the test diary template, see 5.1). The diary should note special events and changes that may affect data analysis (e.g., roadwork, strikes, economical changes, special weather).
- Information on how safety and privacy were ensured. Information on required permits to operate, if there were some.
5.1. Test diary example
Test site:
Contact:
Date | Planned hours | Actual hours | Test focus or route | Manual/Automated |
1.1.2023 | 10–14 | 10–14 | Mission 2 | Automated |
2.1.2023 | 10–14 | – | Mission 2 | Automated |
3.1.2023 | 10–14 | 10–13 | Mission 2 | Manual |
…
Weather | Road conditions (dry/wet/snow/icy) |
15 degrees, rainy and foggy | Wet |
13 degrees | Dry |
–2 degrees, snowfall | Snow |
…
Availability and maintenance | Notes (for example, stopped early, broken systems, accidents) |
Out of operation 15 minutes due to sensor recalibration | |
Out of operation 4 hours | Battery problems, tests cancelled |
Cleaning 15 minutes | Stopped 1 hour early due to X |