IOF XML out-of-bound features

[EdoardoTona]

---------- Forwarded message ---------
From: Ludek Krticka

Dear Henning,
in last few years we can see big rise in use of artificial out-of-bound features in course setting, especially on sprint disciplines. Just recently my club organized championship in KO Sprint and course setter also used some artificial fences and out-of-bound areas to make route choices more interesting. After uploading IOF XML to Livelox he realized that there are only courses and all out-of-bound features are missing, so the tracking from competitor was not making any sense. I had to navigate course setter through OCAD to export out-of-bounds features from course setting project to separate OCD file, import this file into map file and re-export new map file with out-of-bounds information for Livelox.

I think that implementing support for storing out-of-bound features from course setting in IOF XML (especially 708 Out-of-bounds boundary and 709 Out-of-bounds area) would make organizers life more easier. Have you considered such option?

I shortly checked XSD file, found only GeoPosition and MapPosition tags for storing control locations. Is there any easy hack for storing coordinates for lines and polygons using extensions or implementing such feature would mean rebuild IOF XML to new version?

Sending this also to Helge as I think Foot-O would be also happy to see such feature implemented.

Best regards,

Ludek
IOF Map Commission

[EdoardoTona]

---------- Forwarded message ---------
From: Finn Arildsen

Originally, the XML course data model had only the courses’ control codes to support the punch checking use case. In version 3, each control’s location was added to support the simple route choice app use case.

Obviously, that is not sufficient for today’s tracking and route choice use cases. So that’s not what we use. 😊

At first SVG…
When we initially implemented the Condes/Livelox data exchange, this was based on exchanging a course overlay as graphics in an SVG file. This allowed the entire course image to be exchanged, including cutting of circles, placing of control numbers, bending of lines, and – indeed – out of bounds and other symbols belonging to the course layer. Even control descriptions are included. This ensures that the course image you see in Livelox is the same as you see on the competition mpa.

An SVG file is in essence an XML file, and the SVG file has metadata indicating object types and geo location etc. using a schema that can relatively easily be standardised.

… then KMZ
To simplify data exchange for an entire event, this concept was further developed into using one KMZ file to transfer the complete data set. The KMZ embeds SVG files for the courses, as well as one or more map images as needed. In addition to the metadata in the course (SVG) files, control locations for each course are included as sets of waypoints. The KML format georeferences the course images (SVG) and the maps (JPG). The tracking app combines the course (SVG) on top of the map (JPG) before or when rendering to the user.

This KMZ format is implemented by Livelox and by O-Track, and Loggator currently has (partial) support.

OCAD followed suit and implemented the same format, though using one bitmap file (course + map) for each course (potentially increasing the KMZ file size. KMZ doesn’t really help compressing JPG any further).

So why was the “old” XML used?
Coming back to Ludek’s case, I would have thought that the OCAD format also had course symbols (out of bounds), so I am a bit surprised that the Czech people used the XML format to transfer data to Livelox.

Should we standardize?
If we are to standardize this area, I would propose that we build on the existing KMZ implementations and possibly try to align the various dialects.

Regards,
Finn