I've discussed output formats for openvoronoi (ovd) and opencamlib (ocl) with Kaben off-list. I'll try to summarize my thoughts here. Please feel free to comment.
I think it would make sense to try to come up with a common toolpath-representation format for ovd and ocl. I'm not sure it makes sense to reinvent the wheel again, so it would be preferable to use an existing standard, or maybe something very close to an existing standard. I envision this will be a c++ class with python bidings, and a possibility to write&read the toolpath to/from a file. It should be easy to write a post-processor that produces g-code from this toolpath-representation.
This representation should also be used internally, where we pass the result of one algorithm to another. A simple case is e.g. optimizing drilling-paths, or nesting&linking of offset loops, etc. where the basic shape of the toolpath is created in a low-level algorithm and we modify it somehow (re-order operations, modify lead-in/out, etc) in a downstream operation.
My long-term goal would be to have a "data flow" architecture where we have a bunch of algorithms that can be combined by the user in (almost) arbitrary ways. This means the inputs and outputs of algorithms should be standardized. VTKs visualization-pipeline is a good example of this.
I don't think we can foresee today all the data that an upstream algorithm might want to tag-along with a toolpath, a certain move, or a tool definition, for the downstream algorithm to use. So the format should somehow be flexible enough for future expansion.
All of the candidate formats basically seem to mimic simple G-code as far as I can tell (i.e. G0 rapid, G1 linear feed, G2/3 arcs). This is sufficient for most cases, but for example the medial-axis in ovd can contain quadratics (parabola, hyperbola, ellipse) - so a decision needs to be made if these should be natively supported, or approximated with lines/arcs. LinuxCNC now has G5-moves for conics/cubics/nurbs(?).
The commercial CAM-vendors seem to refer to a CLDATA-format, but there is no common standard. Most CLDATA-files look like APT.
The modern alternative seems to be STEP-NC?
I am less worried about input formats. ocl basically takes triangles. There are simple functions for reading STL-files, but otherwise I would leave it up to the library user to produce triangles and use the ocl interface.
ovd now has a slightly difficult interface where point-sites are input first separately from line-segments. A convenience class should be created to simplify this. It should take legal geometry in arbitrary order and store it in a queue, and then in 'batch' mode call the correct insert() functions on VoronoiDiagram. Small and simple readers of common 2D geometry formats (DXF. DWG?. SVG) could be written, but I would not invent a new 2D input data format for ovd.
Anders
