#  Data Summary

**What is the purpose of the data collection/generation and its relation to
the objectives of the project?**

The overall objective of 3D-Forensics/FTI is to launch a product based upon
research and development results delivered in the previous Framework 7 (FP7)
3D-Forensics project, in which the consortium developed a 3D scanner and
analysis software to improve the capturing and investigation of footwear and
tyre traces left at crime scenes. This will require taking the already
demonstrated prototype from the Technology Readiness Level (TRL) 6 to TRL9 and
product launch.

Three of the project’s specific objectives (SO) are related to the purpose of
data collection/generation:

  * Complete last development step for the hard- and software to enable the marketing of the forensic product. (SO3 in the Description of the Action (DoA)) 

  

  * Testing and evaluation of advanced product prototypes with 6 forensic public end users  1  , including reproducibility “round robin” testing and pilot testing. (SO4 in DoA) 

  

  * A body of evidence (data and its analysis) demonstrating the validity of the 3D-system for the purpose of providing evidence to criminal justice systems. (SO5 in DoA) 

  

Experimental tests by the consortium and pilot testing by end users are
foreseen to provide feedback on how to further improve the forensic product
and to complete the last development steps before market launch. “Round robin”
testing and validation of the 3D-Forensics system are foreseen to prove the
system’s reproducibility of results and to support the acceptance of evidence
based on results from the system in court. The validation in an accredited
process will be a selling point when the product is launched to the market.

There are the following tasks for data collection/generation in
3D-Forensics/FTI:

**Table 1:** Purposes of data collection/generation in 3D-Forensics/FTI  
  
<table>  
<tr>  
<th>

**Task**

</th>  
<th>

**Tasks (DoA)**

</th>  
<th>

**Who**

</th>  
<th>

**Time**

**(_plan_ ) **

</th>  
<th>

**Purpose**

</th>  
<th>

**Open access**

</th> </tr>  
<tr>  
<td>

**Technical development**

</td>  
<td>

2200

3300

</td>  
<td>

Consortium participants

</td>  
<td>

Month 1

–

Month 18

</td>  
<td>

Evaluate the progress in the technical development of the system and
production of demo datasets

</td>  
<td>

Partly

</td> </tr>  
<tr>  
<td>

**Familiarisatio n Testing**

</td>  
<td>

4200

</td>  
<td>

End users

</td>  
<td>

Month 5

–

Month 10

</td>  
<td>

Initial training and familiarisation with the new technology and identifying
of improvements

</td>  
<td>

No

</td> </tr>  
<tr>  
<td>

**Round Robin Testing**

</td>  
<td>

4300

</td>  
<td>

End users

</td>  
<td>

Month 8

–

Month 13

</td>  
<td>

Verify the performance and demonstrate the reproducibility of the technology
in a controlled situation (test bed)

</td>  
<td>

Partly

</td> </tr>  
<tr>  
<td>

**Pilot testing**

</td>  
<td>

4400

</td>  
<td>

End users

</td>  
<td>

Month 14

–

Month 20

</td>  
<td>

Evaluate the system in (nearly) real crime scene situations and identify
further improvements

</td>  
<td>

No

</td> </tr>  
<tr>  
<td>

**Validation I**

</td>  
<td>

4500

</td>  
<td>

End users

</td>  
<td>

Month 14

–

Month 25

</td>  
<td>

Evaluate the usability and underpin the performance of the

system as well as its judicial acceptance

</td>  
<td>

Partly

</td> </tr>  
<tr>  
<td>

**Validation II**

</td>  
<td>

4600

</td>  
<td>

End users

(at least one)

</td>  
<td>

Month 20

–

Month 27

</td>  
<td>

Evaluate the usability and performance of the system as well as its judicial
acceptance in an accredited process

</td>  
<td>

Yes

</td> </tr> </table>

The consortium wants to publish results illustrating the performance of the
system and its validation in an accredited process. Data generated for this
purpose is planned to be completely openly accessible. This data collection is
foreseen to take place in the last part of the project ca. middle 2018. Other
data collections are planned to be opened in parts, mainly for demonstration
purposes.

**What types and formats of data will the project generate/collect?**

The 3D-Forensics system consists of a mobile 3D-scanner to capture footwear
and tyre traces and 3D analysis software to investigate the datasets.

**First** , data generation means the production of 3D scans of the following
kinds of objects:

  * Footwear impressions in different undergrounds 

  

  * Tyre impressions in different undergrounds 

  

  * Soles of footwear 

  

  * Profile of tyres 

  

  * Specimens for 3D sensors 

  

This data will contain a set of raw 3D scan results captured by the mobile
3D-scanner. Each raw scan will contain the following output data:

**Table 2:** Raw output data for each acquired dataset  
  
<table>  
<tr>  
<th>

**Raw output data**

</th>  
<th>

**Details**

</th> </tr>  
<tr>  
<td>

**1**

</td>  
<td>

_Ordered 3D-pointcloud_

</td> </tr>  
<tr>  
<td>

**1a**

</td>  
<td>

3D-coordinates of points

</td>  
<td>

XYZ-coordinates in unit meter

</td> </tr>  
<tr>  
<td>

**1b**

</td>  
<td>

Row and column index of 3D-points

</td>  
<td>

Each 3D-point is dedicated to a pixel

</td> </tr>  
<tr>  
<td>

**2**

</td>  
<td>

_Textures of 3D-pointcloud mapped by row/column index_

</td> </tr>  
<tr>  
<td>

**2a**

</td>  
<td>

Quality values

</td>  
<td>

Each 3D-point has a quality based on the brightness and reflectivity of the
scanned surface at this point

</td> </tr>  
<tr>  
<td>

**2b**

</td>  
<td>

Grey image

</td>  
<td>

8-Bit grey values

</td> </tr>  
<tr>  
<td>

**3**

</td>  
<td>

_Textures of 3D-pointcloud mapped by relative calibration_

</td> </tr>  
<tr>  
<td>

**3a**

</td>  
<td>

Colour image of external colour camera

</td>  
<td>

24-Bit colour values

</td> </tr>  
<tr>  
<td>

**3b**

</td>  
<td>

Calibration parameters

of external camera in OpenCV format

</td>  
<td>

Extrinsic and intrinsic calibration parameters relative to 3D-point cloud
(including distortion)

</td> </tr> </table>

The raw data is saved in ASCII format (row, column, X, Y, Z, quality, grey
value) as txt-file and as a separate image file (jpg or cr2) with calibration
parameters in xml format (camera calibration model by OpenCV  2  ). For those
datasets, which will be openly accessible, the output data can be converted
into format E57 which is a more common standard and can be imported by most 3D
software packages.

**Second** , data generation means the processing and analysis of 3D raw data
with the 3DForensics’ software “R3 Forensic”. The software includes the
following tools (the raw data itself is never changed hereby):

  * Shading of scans 

  

  * Alignment of single scans, e.g. tyre tracks 

  

  * Cropping / Masking of points 

  

  * Meshing of points 

  

  * Colour mapping of external camera image onto 3D-pointcloud and/or mesh 

  

  * Determination of reference plane 

  

  * Flipping 

  

  * Extraction of solid images 

  

  * Determination of linear measures 

  

  * Assignment of class characteristics, e.g. shoe type 

  

  * Assignment of identification marks 

  

  * Extraction of sections through 3D-pointcloud 

  

  * Determination of a colour coded height map 

  

Throughout this processing additional data to the original raw scan data may
be produced: **Table 3:** Processed output data  
  
<table>  
<tr>  
<th>

**Processed output data**

</th>  
<th>

**Details**

</th> </tr>  
<tr>  
<td>

**1**

</td>  
<td>

_Transformation matrixes_

</td>  
<td>

Rotation and translation parameters and information on mirroring along one
coordinate axis (4 x 4 matrix for each 3Dpointcloud)

</td> </tr>  
<tr>  
<td>

**2**

</td>  
<td>

_Meshes_

</td>  
<td>

Mesh of a 3D-pointcloud, may include colour mapping

</td> </tr>  
<tr>  
<td>

**3**

</td>  
<td>

_Solid images_

</td>  
<td>

Virtual view onto the 3D data

</td> </tr>  
<tr>  
<td>

**4**

</td>  
<td>

_Sections_

</td>  
<td>

2D data within one section place through the 3D data

</td> </tr>  
<tr>  
<td>

**5**

</td>  
<td>

_Annotations_

</td>  
<td>

Annotations onto class and identification characteristics as well as
distances, including their position within the 3D data

</td> </tr> </table>

The easiest way to access this data is the through the 3D-Forensics’ system
software “R3 Forensic”, which saves it all in one project. The consortium will
discuss the possibility to provide a demo version of “R3 Forensic” with
limited functionality for use with data made openly accessible. An alternative
is to convert the data in more common formats (e.g. xml-format for
transformations and annotations, vrml-format for meshes).

**Will you re-use any existing data and how?**

As a result of the previous FP7 3D-Forensics project a small data collection
already exists. The results of those experiments have been taken into account
for the further improvement of the system. However this existing data will not
reflect the final technical state of the system and will therefore not be
openly accessible.

**What is the origin of the data?**

The raw data will be captured using (advanced) prototypes of the 3D-Forensics
scanner (Figure 1) and the processed data will be produced by the (advanced)
prototype of the 3D analysis software. Both capturing and processing will be
performed by partners of the consortium as well as associated end users.

**Figure 1** : 3D-Forensics scanner and analysis software

The format conversion for openly accessible data will be made using the
analysis software “R3 Forensic”.

**What is the expected size of the data?**

The size of a single raw scan of the 3D-scanner is about 100 MB. The size of
an analysis project is very dependent on the used analysis tools in the range
of 100 MB to 500 MB per scan. It is expected that about 100 datasets (raw and
processed output data) will be openly accessible. The consortium expects an
overall size of <50 GB.

**To whom might it be useful ('data utility')?**

The data collection in the project 3D-Forensics/FTI has the main objectives of
verifying the performance of the 3D-Forensics system and of validating the new
technology under forensic aspects. All data is focussed on the trace types:
footwear and tyre impressions. Thus the data is foreseen to be primarily aimed
at crime scene investigators and forensic experts as well as public
prosecutors who handle evidence in court. The data collection is foreseen to
support the product launch on the market.

Further the data collection may be useful concerning the general usability of
3D data in forensic applications, such as 3D data of other trace types /
situations or 3D data captured by other 3Dscanners.

#  FAIR data

##  Making data findable, including provisions for metadata

**Are the data produced and/or used in the project discoverable with metadata,
identifiable and locatable by means of a standard identification mechanism
(e.g. persistent and unique identifiers such as Digital Object Identifiers)?**

Data captured by a 3D-Forensics scanner is foreseen to be also usable in
court. Thus, it respects already the necessity of metadata and unique
identification. For each raw scan the following metadata is saved
automatically:

  * Unique identification number for each single scan 

  

  * Unique identification number for groups of scans (e.g. scans that belong to one tyre track) 

  

  * Date and time of scan 

  

  * Scan settings (actual scan mode and brightness setting) 

  

  * User ID 

  

  * Device serial number 

  

Further additional information on the scans is saved separately:

  * Object type (e.g. underground material for the impression, type of shoe sole, etc.)  Optionally: Location of object 

  

During the processing and analysing of data the unique identification is still
traceable.

**What naming conventions do you follow?**

The files connected to raw scan datasets are named by the unique
identification number (+ file extension). All metadata connected to the raw
scans is saved in a separate project file in xml format. Processed data will
be named, so that the connection to the original raw data is clear.

**Figure 2:** Cut-out of the xml file containing meta data on raw scans

**Will search keywords be provided that optimize possibilities for re-use?**

Possible keywords could be: Type of object / underground, scan mode, time,
etc. Those are saved in the metadata xml file. However the size of the data
collection is probably not too large. The consortium will discuss the
necessity of a keyword search. An update on that question will be given in the
next update.

**Do you provide clear version numbers?**

Datasets belonging to one version will be grouped in one zipped file. The
version number is part of the zip file name.

**What metadata will be created? In case metadata standards do not exist**

There exists no standard for the kind of metadata described. Please see the
answer on the previous page.

##  Making data openly accessible

**Which data produced and/or used in the project will be made openly available
as the default? If certain datasets cannot be shared (or need to be shared
under restrictions), explain why, clearly separating legal and contractual
reasons from voluntary restrictions.**

In relation to Table 1, there are the following reasons for sharing / not
sharing the data: **Table 4:** Reasons for sharing / not sharing data in
3D-Forensics/FTI  
  
<table>  
<tr>  
<th>

**Task**

</th>  
<th>

**Open access**

</th>  
<th>

**Reason for sharing / not sharing**

</th> </tr>  
<tr>  
<td>

**Technical development**

</td>  
<td>

Partly

</td>  
<td>

 Voluntary restriction

</td> </tr>  
<tr>  
<td>

**Familiarisation Testing**

</td>  
<td>

No

</td>  
<td>

 Voluntary restriction

</td> </tr>  
<tr>  
<td>

**Round Robin Testing**

</td>  
<td>

Partly

</td>  
<td>

 Voluntary restriction

</td> </tr>  
<tr>  
<td>

**Pilot testing**

</td>  
<td>

No

</td>  
<td>

 Voluntary restriction

</td> </tr>  
<tr>  
<td>

**Validation I**

</td>  
<td>

Partly

</td>  
<td>

 Voluntary restriction

</td> </tr>  
<tr>  
<td>

**Validation II**

</td>  
<td>

Yes

</td>  
<td>

 No restriction

</td> </tr> </table>

**Note that in multi-beneficiary projects it is also possible for specific
beneficiaries to keep their data closed if relevant provisions are made in the
consortium agreement and are in line with the reasons for opting out.**

This is not relevant for 3D-Forensics/FTI because all generated data is
foreseen to be common property of the consortium

**How will the data be made accessible (e.g. by deposition in a repository)?**

To make the data accessible the consortium will evaluate two options until the
next update:

  * Deposition on the project website  _www.3D-Forensics.eu_

  

  * Deposition in a repository (which specific one would be chosen later) 

  

**What methods or software tools are needed to access the data?**

To access the data it is recommended to use the 3D analysis software R3
Forensic. The raw scan data is given in format E57 which can be imported into
other 3D software packages as well (including free software). The processed
scan data can be imported partly in other software packages (including free
software). The metadata of the raw scans and parts of the processed data can
be accessed by a simple text editor.

Data Management Report

**Is documentation about the software needed to access the data included?**

The documentation of the used standard formats are public available (e.g. E57
on  _http://www.libe57.org_ )  . However most 3D software packages allow
importing this format without the need of any documentation. Documentation
about the metadata (given in xml format) and the processed data will be given.

**Is it possible to include the relevant software (e.g. in open source
code)?**

There is the possibility to provide the software R3 Forensic as binary (not
open source code) in trial mode. The consortium will decide until the next
update which software tool is provided. Open source code will not be provided.

**Where will the data and associated metadata, documentation and code be
deposited? Preference should be given to certified repositories which support
open access where possible.**

Please see the answer on the previous page.

**Have you explored appropriate arrangements with the identified repository?**

The consortium has understood the possibilities offered by its project website
well. The consortium has not explored potential appropriate external
arrangements yet. This will be done after the deposition location is decided.

**If there are restrictions on use, how will access be provided?**

Restriction on use of the data will be discussed by the consortium and will be
reported in the next update.

**Is there a need for a data access committee?**

There is the need of a data access committee which decides what data will be
openly accessible. This data access committee is given by the General Assembly
of the project consortium.

**Are there well described conditions for access (i.e. a machine readable
license)?**

There are no conditions for access defined yet.

**How will the identity of the person accessing the data be ascertained?**

This will be done after the deposition location is decided.

##  Making data interoperable

**Are the data produced in the project interoperable, that is allowing data
exchange and reuse between researchers, institutions, organisations,
countries, etc. (i.e. adhering to standards for formats, as much as possible
compliant with available (open) software applications, and in particular
facilitating re-combinations with different datasets from different
origins)?**

The raw scan data is provided in the standard format E57 which can be imported
by most 3D software packages. Also parts of the processed scan data will be in
standard formats. The interoperability of the data is assured.

**What data and metadata vocabularies, standards or methodologies will you
follow to make your data interoperable?**

The raw scan data itself is provided in the standard format E57. Parts of the
processed data will be in standard formats, too. For the metadata no standard
exists. It will be given in a xml file format.

**Will you be using standard vocabularies for all data types present in your
data set, to allow inter-disciplinary interoperability?**

There exists no standard vocabulary for the accessible data types.

**In case it is unavoidable that you use uncommon or generate project specific
ontologies or vocabularies, will you provide mappings to more commonly used
ontologies?**

The consortium will try to provide mappings to more commonly used ontologies.

##  Increase data re-use (through clarifying licences)

**How will the data be licensed to permit the widest re-use possible?**

The consortium will discuss the licensing of the permission and report its
policy in the next update.

**When will the data be made available for re-use? If an embargo is sought to
give time to publish or seek patents, specify why and how long this will
apply, bearing in mind that research data should be made available as soon as
possible.**

There is in principle no need of any embargo for a specific time. However, the
consortium and its user testers will first analyse all data themselves before
making it openly accessible

**Are the data produced and/or used in the project useable by third parties,
in particular after the end of the project? If the re-use of some data is
restricted, explain why.**

The generated data is important to underpin the performance of the
3D-Forensics system and to demonstrate the validity of the data regarding
aspects, connected with its admissibility in court as a basis for expert
opinion evidence. Those issues are important for the time after the product
launch as well. Under these considerations, no restriction after the end of
the project is necessary.

**How long is it intended that the data remains re-usable?**

The data needs to be re-usable at least for the product lifetime of the
3D-Forensics system, which is expected to be >5 year after end of the project.

**Are data quality assurance processes described?**

All consortium partners will review the openly accessible data and assure its
quality. This quality assurance process will be described in detail in the
documentation of the openly accessible data.

#  Allocation of resources

**What are the costs for making data FAIR in your project?**

Costs are foreseen to arise mainly in the form of personnel time to collect,
convert and document the open data. The costs are estimated to be not less
than one person month.

**How will these be covered? Note that costs related to open access to
research data are eligible as part of the Horizon 2020 grant (if compliant
with the Grant Agreement conditions).**

The costs will be covered as personnel costs in the WPs given in Table 1.

**Who will be responsible for data management in your project?**

All consortium partners are involved in the data management. The partner
Fraunhofer IOF has the main responsibility.

**Are the resources for long term preservation discussed (costs and potential
value, who decides and how what data will be kept and for how long)?**

The topic of long term preservation was not yet discussed. This will reported
in a future update.

#  Data security

**What provisions are in place for data security (including data recovery as
well as secure storage and transfer of sensitive data)?**

At least one backup copy of all data will be stored by the consortium to avoid
any data loss. No sensitive data is foreseen to be generated.

**Is the data safely stored in certified repositories for long term
preservation and curation?**

The data will be stored safely with the own resources of the consortium.
However, the option of long term preservation and curation in a certified
repository will be discussed by the consortium and reported in a future
updated.

#  Ethical aspects

**Are there any ethical or legal issues that can have an impact on data
sharing? These can also be discussed in the context of the ethics review. If
relevant, include references to ethics deliverables and ethics chapter in the
Description of the Action (DoA).**

The data collection covers scans of footwear and tyre impressions of anonymous
shoes and tyres. No personnel data is foreseen to be acquired and as such no
ethical issues should arise

**Is informed consent for data sharing and long term preservation included in
questionnaires dealing with personal data?**

As stated above, informed consent is foreseen to be not necessary as no
personnel data is foreseen to be generated. However the project will prepare
an informed consent form to as part of deliverable D6.1, so it is available in
case there is unexpected need and the above issues are foreseen to be taken
into consideration.

#  Other issues

**Do you make use of other national/funder/sectorial/departmental procedures
for data management? If yes, which ones?**

At the time of writing, no national/funder/sectorial/departmental procedures
are foreseen to be applied for data management in this project.