Define a database file (YAML) format

[corot]

On issue #8 we have implemented an initial, simplistic format. Study if we need an extended one more versatile and/or with additional information.

[corot]

At least we need to easily accommodate big chunks of data, as maps, meshes...

[stonier]

At least we need to easily accommodate big chunks of data, as maps, meshes...

Yep. That's the only tricky part here I think.

[corot]

I'm realizing this is not trivial, and we will need specialized converters for each type of big file, because we store ROS messages, not the native files the information comes from. So... options:

• We duplicate data and store both the file and the message. No way: duplicated data and complicated code.
• We store only the data. No way: this breaks the uniformity of service calls to the server.
• We store only the message, sacrificing the some information in the process (e.g. if I use a PNG to load a laser map, I transform the grayscale values into a matrix of -1, 0 and 1 values). So it would look like:
  • In the database file appears, instead of the message, a path to the file and some neccesary metadata.
  • Depending on the file time, the importer calls specialized process to transform the file into a ROS message (e.g. reuse map_server for 2D maps)
  • Reverse process for exporting, though some information can be lost
• Exclude these big object from the database import/export. At the end, it's not that clear how useful the import/export of the database can be. I did this as a easy way to create toy database for developing and start playing with WCF, so... worth it to make this big effort?

[corot]

Conclusion, point 4 chosen:
we should go for the final editing solution (with a GUI) to solve this problem, cause we use there ROS topics, what means that any annotation is a message, so we don’t worry about how big or complicated it is.

[corot]

However I let the issue opened cause database format is prone to suffer new changes.