lgf.dox
author Peter Kovacs <kpeter@inf.elte.hu>
Mon, 15 Feb 2010 01:51:58 +0100
changeset 32 ef12f83752f6
parent 31 02083323ff2c
child 33 598cd0b266d3
permissions -rw-r--r--
Happy New Year + unify files
     1 /* -*- mode: C++; indent-tabs-mode: nil; -*-
     2  *
     3  * This file is a part of LEMON, a generic C++ optimization library.
     4  *
     5  * Copyright (C) 2003-2010
     6  * Egervary Jeno Kombinatorikus Optimalizalasi Kutatocsoport
     7  * (Egervary Research Group on Combinatorial Optimization, EGRES).
     8  *
     9  * Permission to use, modify and distribute this software is granted
    10  * provided that this copyright notice appears in all copies. For
    11  * precise terms see the accompanying LICENSE file.
    12  *
    13  * This software is provided "AS IS" with no warranty of any kind,
    14  * express or implied, and with no claim as to its suitability for any
    15  * purpose.
    16  *
    17  */
    18 
    19 namespace lemon {
    20 /**
    21 [PAGE]sec_lgf[PAGE] Input-Output for Graphs
    22 
    23 \todo Clarify this section.
    24 
    25 LEMON provides a versatile file format for storing graphs
    26 and related node and arc maps.
    27 Such a format should be really flexible, it should be able to store arbitrary
    28 number of maps of arbitrary value types.
    29 On the other hand, the file size and the ease of processing are also critical
    30 to support storing huge graphs, which is a major goal of LEMON.
    31 These requirements forbid using complicated and deeply structured formats
    32 like XML.
    33 That is why a compact file format is designed for LEMON instead of using
    34 hierarchical formats, such as GraphML, GXL or GML.
    35 
    36 The LEMON Graph Format (LGF) comprises different sections, for
    37 example a digraph is stored in a \c @nodes and an \c @arcs
    38 section. These parts use column oriented formats, each
    39 column belongs to a map in the graph. The first line of the section associate
    40 names to these maps, which can be used to refer them.
    41 Note that this simple idea makes it possible to extend the files with
    42 new maps (columns) at any
    43 position without having to modify the codes using these files.
    44 
    45 The \c label map has special role, it must store unique values, which in turn
    46 can be used to refer
    47 to the nodes and arcs in the file. Finally, the first two column of the
    48 \c @arcs section is anonymous, they indicate the source and target nodes,
    49 respectively.
    50 
    51 \code
    52   @nodes
    53   label coordinate
    54   0     (20,100)
    55   1     (40,120)
    56   ...
    57   41    (600,100)
    58   @arcs
    59             label length
    60   0    1    0     16
    61   0    2    1     12
    62   2    12   2     20
    63   ...
    64   36   41   123   21
    65   @attributes
    66   source 0
    67   target 41
    68   caption "A shortest path problem"
    69 \endcode
    70 
    71 The \ref DigraphReader and \ref DigraphWriter classes are used
    72 to read and write a digraph and corresponding maps. By default, a map
    73 can be used with these classes if its value type has standard I/O
    74 operators (\c operator<<(ostream&, T) and \c operator>>(istream&, T&)).
    75 Otherwise, a function object
    76 can be specified which converts the value type to \c std::string.
    77 The above LGF file can be scanned as follows.
    78 
    79 \code
    80   ListDigraph g;
    81   ListDigraph::NodeMap<dim2::Point<int> > coord(g);
    82   ListDigraph::ArcMap<int> length(g);
    83   ListDigraph::Node src;
    84   std::string title;
    85 
    86   digraphReader(g, std::cin)
    87     .nodeMap("coord", coord)
    88     .arcMap("length", length)
    89     .attribute("caption", title)
    90     .node("source", src)
    91     .run();
    92 \endcode
    93 
    94 Apart from LGF, the library can also interpret other graph
    95 formats, such as the well-known DIMACS format or the NAUTY graph6
    96 format.
    97 
    98 <hr>
    99 
   100 The \e LGF is a <em>column oriented</em>
   101 file format for storing graphs and associated data like
   102 node and edge maps.
   103 
   104 Each line with \c '#' first non-whitespace
   105 character is considered as a comment line.
   106 
   107 Otherwise the file consists of sections starting with
   108 a header line. The header lines starts with an \c '@' character followed by the
   109 type of section. The standard section types are \c \@nodes, \c
   110 \@arcs and \c \@edges
   111 and \@attributes. Each header line may also have an optional
   112 \e name, which can be use to distinguish the sections of the same
   113 type.
   114 
   115 The standard sections are column oriented, each line consists of
   116 <em>token</em>s separated by whitespaces. A token can be \e plain or
   117 \e quoted. A plain token is just a sequence of non-whitespace characters,
   118 while a quoted token is a
   119 character sequence surrounded by double quotes, and it can also
   120 contain whitespaces and escape sequences.
   121 
   122 The \c \@nodes section describes a set of nodes and associated
   123 maps. The first is a header line, its columns are the names of the
   124 maps appearing in the following lines.
   125 One of the maps must be called \c
   126 "label", which plays special role in the file.
   127 The following
   128 non-empty lines until the next section describes nodes of the
   129 graph. Each line contains the values of the node maps
   130 associated to the current node.
   131 
   132 \code
   133  @nodes
   134  label  coordinates  size    title
   135  1      (10,20)      10      "First node"
   136  2      (80,80)      8       "Second node"
   137  3      (40,10)      10      "Third node"
   138 \endcode
   139 
   140 The \c \@arcs section is very similar to the \c \@nodes section,
   141 it again starts with a header line describing the names of the maps,
   142 but the \c "label" map is not obligatory here. The following lines
   143 describe the arcs. The first two tokens of each line are
   144 the source and the target node of the arc, respectively, then come the map
   145 values. The source and target tokens must be node labels.
   146 
   147 \code
   148  @arcs
   149          capacity
   150  1   2   16
   151  1   3   12
   152  2   3   18
   153 \endcode
   154 
   155 The \c \@edges is just a synonym of \c \@arcs. The \@arcs section can
   156 also store the edge set of an undirected graph. In such case there is
   157 a conventional method for store arc maps in the file, if two columns
   158 has the same caption with \c '+' and \c '-' prefix, then these columns
   159 can be regarded as the values of an arc map.
   160 
   161 The \c \@attributes section contains key-value pairs, each line
   162 consists of two tokens, an attribute name, and then an attribute
   163 value. The value of the attribute could be also a label value of a
   164 node or an edge, or even an edge label prefixed with \c '+' or \c '-',
   165 which regards to the forward or backward directed arc of the
   166 corresponding edge.
   167 
   168 \code
   169  @attributes
   170  source 1
   171  target 3
   172  caption "LEMON test digraph"
   173 \endcode
   174 
   175 The \e LGF can contain extra sections, but there is no restriction on
   176 the format of such sections.
   177 
   178 */
   179 }