poggenhans
commented
5 years ago There is a couple of reasons why we use the osm xml format:
- The osm project offers a large amount of software tools and also server software that can be used to share, view and edit map data. Since we do not have nearly the resources to develop all this ourselves, it's a great help when dealing with map data.
- (partly) legacy reasons: liblanelet used this representation and we came to the conclusion that this worked very well
- You are right that the format is not clearly defined and can have unnecessary elements. However, as you will notice when looking at our example file, the there are actually only a few mandatory elements that are unnecessary. For an xml-file, I consider it quite slim. Even if I would specify a completely new format, it would not be very different from the existing one.
That said, Lanelet2 is not tied to a specific storage format. New formats could easily be included, either in the lanelet2_io package or in by a plugin. I agree that it might make sense to have a static format for the case that a future osm xml version is incompatible with our representation. But since there have not been any substantial changes to the osm representation, developing something like this is not our priority.
You are of course invited to help creating such a format. But I suppose that we will always have to be able to read and write to osm xml, since the comfort of using the osm ecosystem (e.g. the JOSM editor) will be hard to replace.
JWhitleyWork
In the document https://github.com/fzi-forschungszentrum-informatik/Lanelet2/tree/master/lanelet2_maps/README.md, it is described that lanelet2 uses the OSM XML format. However, the "OSM XML format" is not clearly defined. The format differs from version-to-version (currently on 0.6) and is a function of the API version that a server providing the document is using. Because the format changes from version-to-version and it was designed to be a document requested from a web API, a static definition of the format (XSD or DTD) is not available and/or provides many unnecessary elements which are not related to the driving task (API version, timeout values, etc.). In addition, you state that you are "converting" the lanelet2 primitives to OSM primitives. This brings me to my questions:
I think lanelet2 is a great project and would work well as the base structure for many applications (simulation, visualization, automated driving, etc.) but I think the lack of a well-supported, static storage format is a big drawback.