Mainly for some demo applet we did some alternative to the database import/export.
java org.xistrat.util.d3.XMLGraphExport graph [variant]and
java org.xistrat.util.d3.XMLGraphLoader fileHave a look at
*.xml
and polyhedron.dtd
within XISTRAT_HOME]/data/xml
. Of course the established VRML and X3D loaders would be an alternative for the future. For now this was the fastest possible hack for us to do it ourselves.
For example you want to dump some group generators or matrices out of XiStrat™, so another software, let's say the computer algebra system GAP™, can easily import them. Or you wish to autocreate infiles for graphs resulting from Rubik™-like moves or (in the field of quasicrystals) constructed by other rules.
java org.xistrat.util.ExportData -g graph [-v variant] -o outfile [-s s] [-m|-q|-rf new_variant|-rg|-ra|[-kd|-kp] link] [-c new_variant] [-f type party role]*The command line options are about the graph (and optionally its variant version to start from), the outfile, telling if flip/rot group generators (is default) (and if using the 'double', fixing labels pointing towards holes, treating holes as valid, or switches, or even more sophisticated labels (from faces plus points) are used), adjacency matrices of the graph and its dual, 'vector' groups (standard translation, with proj, local rot, relations, covers or atlas), "Rubik"'s autogenerated infiles, cross groups, full morph group, knot data or polynomials, or a new quasicrystals iteration are wanted, or optionally some (Chess) pieces can be specified (but at the moment most options are only usable without this). It seems that this vast amount of command line arguments could be arranged somehow in a cleaner way?!
Import the exported data into GAP™ by
gap> Read(infile);
And now you can play with it (examples are in Chapter 7, Case Studies). See references for further information.