XML File Format

[dg0yt]

dg0yt reported on Sourceforge [tickets:#97]:

Mapper shall have an XML file format.

There already is an XML file format implementation in Mapper but it is outdated. That is why it is disabled by default. (It can be enable with setting Mapper_XML_FORMAT=1 in CMake.)

[dg0yt]

puzzlepaint posted on Sourceforge:

In current master, there is now a unit test which checks for every file format which supports import and export if maps stay the same when saved in this format and loaded again. The test is not 100% complete (for undo steps, currently only the number of steps is checked), but this will still be useful to test the XML format.

I also changed the importer / exporter interfaces a bit:

• Deleted the path parameter which was only necessary because libocad didn't support reading maps from memory. Now all file formats should use Qt's generic QIODevice interface to support files and memory, instead of accessing files directly.
• Instead of implementing public doImport(), importers must now implement protected import(). This way some common symbol import post-processing (converting symbol indices to pointers for symbols referenced in combined symbols), which previously was easy to forget when using importers directly, could be moved into doImport(). If the XML format does this differently, you'd need to change this again.

[dg0yt]

The current Mapper XML format implementation is based on QDomDocument and friends. "The QDom classes have a few issues of nonconformance with the XML specifications" (Qt 4.8 doc), and are in the deprecated Qt XML module in Qt 5. Mapper XML format shall be reimplemented with QXmlStreamReader and QXmlStreamWriter.

[dg0yt]

A preliminary implementation is now in master. It does not yet export/import all map features, but colors, symbols and objects are complete. This is for first experiments. The format may still receive some incompatible changes.

Enable the format with Mapper_XML_FORMAT=1 when running CMake.

• milestone: 1.0 --> 0.4

[dg0yt]

The implementation is completed, and the XML file format is no longer marked as lossy. Open issues:

• Thorough testing. Not all parts of the implementation have been tested yet. Especially different types of templates with different states of alignment/georeferencing need to be tested. There should be test files and unit tests.
• Review of the XML output. Some decisions on the structure might be less appropriate for what other developers have already planned.
• Disable autoformatting. Current XML output is pretty but increases XML file size by more than half. We could add some custom spaces and line breaks.
• Documentation, formal specification of the format.
• Interoperability improvements. The order of elements is important for many parts of the file. This could cause future trouble with files generated by other tools. At least for symbols, this has been solved by using true IDs.

Some minor TODOs have been marked in the source code.

[dg0yt]

• status: assigned --> fixed

[dg0yt]

puzzlepaint posted on Sourceforge:

I did some more manual tests now. Still to investigate: the position of a georeferenced template in my test files is slightly off when loaded from XML. Opening the georef dialog and clicking ok moves it into its correct position (half a meter away or so).

Regarding the format / implementation:

• Just a minor thing regarding the xml attribute naming: I think that for denoting the "number of" something, "count" is more common than just "number". However I might be totally wrong on that ;-)
• What is this supposed to do: object->coords.reserve(num_coords % 10); // 10 is not a limit It seems to me that for 9 coordinates it would reserve 9 spots, for 10 coordinates it would reserve zero. Where's the logic in that? Why not reserve the exact number?

[dg0yt]

puzzlepaint posted on Sourceforge:

Finished with manual checking now. The reason for the georeferenced template being off was that some digits were rounded off in the georeferencing settings because the default output precision of QString::number() is not high enough.

The two questions from the above comment are still open.

[dg0yt]

• "count" instead of "number" seems to fit better, unless used in a phrase as "number of items".
• These "a % b" shall be replaced by "qMin(a, b)". I wouldn't agree that the number/count attribute gives the exact number of elements. I would rather call it a "claimed number of elements". Never trust unknown files... It would be far to easy to construct a small file which causes Mapper to immediately consume all available memory. That's why a tried to put a reasonable limit on how much memory is allocated in advance.

[dg0yt]

puzzlepaint posted on Sourceforge:

Okay, I changed both. You're right, it's better not to trust the information in the file. However I think that the chance of very high numbers caused by programming errors is much higher than the chance of a maliciously crafted orienteering map ;-)

[dg0yt]

• status: fixed --> closed

[dg0yt]

Feature stabilizing. Received some fixes after 0.4.0. Closing feature request.

[dg0yt]

Somebody posted on Sourceforge:

(Moved to #182 - Kai.)