1.1 --- a/doc/graph_io.dox Mon Jul 04 17:51:07 2005 +0000
1.2 +++ b/doc/graph_io.dox Tue Jul 05 14:36:10 2005 +0000
1.3 @@ -4,8 +4,10 @@
1.4
1.5 \page graph-io-page Graph Input-Output
1.6
1.7 -The standard graph IO enables to store graphs and additional maps
1.8 -in a flexible and efficient way.
1.9 +The standard graph IO enables one to store graphs and additional maps
1.10 +(i.e. functions on the nodes or edges) in a flexible and efficient way.
1.11 +Before you read this page you should be familiar with LEMON
1.12 +\ref graphs "graphs" and \ref maps-page "maps".
1.13
1.14 \section format The general file format
1.15
1.16 @@ -17,14 +19,21 @@
1.17 \li edges
1.18 \li attributes
1.19
1.20 -The nodeset section starts with the following line:
1.21 +Some of these sections can be omitted, but you will basicly need the nodeset
1.22 +section (unless your graph has no nodes at all) and the edgeset section
1.23 +(unless your graph has no edges at all).
1.24 +
1.25 +The nodeset section describes the nodes of your graph: it identifies the nodes
1.26 +and gives the maps defined on them, if any. It starts with the
1.27 +following line:
1.28
1.29 <tt>\@nodeset</tt>
1.30
1.31 The next line contains the names of the nodemaps, separated by whitespaces. Each
1.32 following line describes a node in the graph: it contains the values of the
1.33 maps in the right order. The map named "id" should contain unique values
1.34 -because it is regarded as an ID-map. For example:
1.35 +because it is regarded as an ID-map. These ids need not be numbers but they
1.36 +must identify the nodes uniquely for later reference. For example:
1.37
1.38 \code
1.39 @nodeset
1.40 @@ -39,10 +48,12 @@
1.41
1.42 <tt>\@edgeset</tt>
1.43
1.44 -The next line contains the whitespace separated list of names of the maps.
1.45 -Each of the next lines describes one edge. The first two elements in the line
1.46 -are the IDs of the source and target (or tail and head) node of the edge as they occur in the ID node
1.47 -map. You can also have an optional ID map on the edges for later reference.
1.48 +The next line contains the whitespace separated list of names of the edge
1.49 +maps. Each of the next lines describes one edge. The first two elements in
1.50 +the line are the IDs of the source and target (or tail and head) nodes of the
1.51 +edge as they occur in the ID node map of the nodeset section. You can also
1.52 +have an optional ID map on the edges for later reference (which has to be
1.53 +unique in this case).
1.54
1.55 \code
1.56 @edgeset
1.57 @@ -52,13 +63,14 @@
1.58 3 12 g 3.4 g-edge
1.59 \endcode
1.60
1.61 -The next section contains <em>labeled nodes</em> (i.e. nodes having a special
1.62 +The \e nodes section contains <em>labeled (distinguished) nodes</em>
1.63 +(i.e. nodes having a special
1.64 label on them). The section starts with
1.65
1.66 <tt> \@nodes </tt>
1.67
1.68 Each of the next lines contains a label for a node in the graph
1.69 -and then the ID described in the nodeset section.
1.70 +and then the ID as described in the \e nodeset section.
1.71
1.72 \code
1.73 @nodes
1.74 @@ -66,12 +78,12 @@
1.75 target 12
1.76 \endcode
1.77
1.78 -The last section describes the <em>labeled edges</em>
1.79 +The last section describes the <em>labeled (distinguished) edges</em>
1.80 (i.e. edges having a special label on them). It starts with \c \@edges
1.81 and then each line contains the name of the edge and the ID.
1.82
1.83 \code
1.84 -@nodes
1.85 +@edges
1.86 observed c
1.87 \endcode
1.88
1.89 @@ -80,8 +92,8 @@
1.90 start with an \c # character.
1.91
1.92 The attributes section can handle some information about the graph. It
1.93 -contains in each line an key and the mapped value to key. The key should
1.94 -be a string without whitespace, the value can be from various type.
1.95 +contains key-value pairs in each line (a key and the mapped value to key). The
1.96 +key should be a string without whitespaces, the value can be of various types.
1.97
1.98 \code
1.99 @attributes
1.100 @@ -91,27 +103,28 @@
1.101 version 12
1.102 \endcode
1.103
1.104 -\code
1.105 -@end
1.106 -\endcode
1.107 -=======
1.108 -The file ends with the
1.109 -
1.110 <tt> \@end </tt>
1.111
1.112 line.
1.113
1.114
1.115 \section use Using graph input-output
1.116 -The graph input and output is based on reading and writing commands. The user
1.117 -adds reading and writing commands to the reader or writer class, then he
1.118 -calls the \c run() method that executes all the given commands.
1.119 +
1.120 +The easiest way of using graph input and output is using the versions of the
1.121 + public \ref readGraph() and \ref writeGraph() functions; if you don't need
1.122 + very sophisticated behaviour then you might be satisfied with
1.123 + those. Otherwise go on reading this page.
1.124 +
1.125 +The graph input and output is based on <em> reading and writing
1.126 +commands</em>. The user gives reading and writing commands to the reader or
1.127 +writer class, then he calls the \c run() method that executes all the given
1.128 +commands.
1.129
1.130 \subsection write Writing a graph
1.131
1.132 The \c GraphWriter class provides the graph output. To write a graph
1.133 you should first give writing commands to the writer. You can declare
1.134 -write command as \c NodeMap or \c EdgeMap writing and labeled Node and
1.135 +writing command as \c NodeMap or \c EdgeMap writing and labeled Node and
1.136 Edge writing.
1.137
1.138 \code
1.139 @@ -119,9 +132,9 @@
1.140 \endcode
1.141
1.142 The \c writeNodeMap() function declares a \c NodeMap writing command in the
1.143 -\c GraphWriter. You should give a name of the map and the map
1.144 +\c GraphWriter. You should give a name to the map and the map
1.145 object as parameters. The NodeMap writing command with name "id" should write a
1.146 -unique map because it is regarded as ID map.
1.147 +unique map because it will be regarded as an ID map.
1.148
1.149 \see IdMap, DescriptorMap
1.150
1.151 @@ -174,7 +187,7 @@
1.152
1.153 \subsection reading Reading a graph
1.154
1.155 -The given file format may contain several maps and labeled nodes or edges.
1.156 +The file to be read may contain several maps and labeled nodes or edges.
1.157 If you read a graph you need not read all the maps and items just those
1.158 that you need. The interface of the \c GraphReader is very similar to
1.159 the GraphWriter but the reading method does not depend on the order of the
1.160 @@ -188,7 +201,7 @@
1.161 GraphReader<ListGraph> reader(std::cin, graph);
1.162 \endcode
1.163
1.164 -The \c readNodeMap() function reads a map from the \c \@nodeset section.
1.165 +The \c readNodeMap() function reads a map from the \c nodeset section.
1.166 If there is a map that you do not want to read from the file and there are
1.167 whitespaces in the string represenation of the values then you should
1.168 call the \c skipNodeMap() template member function with proper parameters.
1.169 @@ -239,14 +252,17 @@
1.170 reader.run();
1.171 \endcode
1.172
1.173 +\anchor rwbackground
1.174 \section types Background of Reading and Writing
1.175 +
1.176 +
1.177 To read a map (on the nodes or edges)
1.178 the \c GraphReader should know how to read a Value from the given map.
1.179 By the default implementation the input operator reads a value from
1.180 the stream and the type of the readed value is the value type of the given map.
1.181 When the reader should skip a value in the stream, because you do not
1.182 want to store it in a map, the reader skips a character sequence without
1.183 -whitespace.
1.184 +whitespaces.
1.185
1.186 If you want to change the functionality of the reader, you can use
1.187 template parameters to specialize it. When you give a reading
1.188 @@ -264,7 +280,7 @@
1.189 \endcode
1.190
1.191 For example, the \c "strings" nodemap contains strings and you do not need
1.192 -the value of the string just the length. Then you can implement own Reader
1.193 +the value of the string just the length. Then you can implement an own Reader
1.194 struct.
1.195
1.196 \code
1.197 @@ -284,21 +300,22 @@
1.198 The global functionality of the reader class can be changed by giving a
1.199 special template parameter to the GraphReader class. By default, the
1.200 template parameter is \c DefaultReaderTraits. A reader traits class
1.201 -should provide an inner template class Reader for each type, and an
1.202 +should provide an inner template class Reader for each type, and a
1.203 DefaultReader for skipping a value.
1.204
1.205 -The specialization of writing should be very similar to that of reading.
1.206 +The specialization of writing is very similar to that of reading.
1.207
1.208 -\section undir Undir graphs
1.209 +\section undir Undirected graphs
1.210
1.211 -In the undir graph format there is an \c undiredgeset section instead of
1.212 -the \c edgeset section. The first line of the section describes the
1.213 -undirected egdes' names and all next lines describes one undirected edge
1.214 -with the the incident nodes and the values of the map.
1.215 +In a file describing an undirected graph (undir graph, for short) you find an
1.216 +\c undiredgeset section instead of the \c edgeset section. The first line of
1.217 +the section describes the names of the maps on the undirected egdes and all
1.218 +next lines describe one undirected edge with the the incident nodes and the
1.219 +values of the map.
1.220
1.221 -The format handles the directed edge maps as a syntactical sugar, if there
1.222 -is two map which names are the same with a \c '+' and a \c '-' prefix
1.223 -then it can be read as an directed map.
1.224 +The format handles directed edge maps as a syntactical sugar???, if there
1.225 +are two maps with names being the same with a \c '+' and a \c '-' prefix
1.226 +then this will be read as a directed map.
1.227
1.228 \code
1.229 @undiredgeset
1.230 @@ -308,9 +325,9 @@
1.231 21 12 8 3.4 0.0 0.0
1.232 \endcode
1.233
1.234 -The \c edges section changed to \c undiredges section. This section
1.235 +The \c edges section is changed to \c undiredges section. This section
1.236 describes labeled edges and undirected edges. The directed edge label
1.237 -should start with a \c '+' and a \c '-' prefix what decide the direction
1.238 +should start with a \c '+' or a \c '-' prefix to decide the direction
1.239 of the edge.
1.240
1.241 \code
1.242 @@ -337,12 +354,13 @@
1.243
1.244 \section advanced Advanced features
1.245
1.246 -The graph reader and writer classes gives an easy way to read and write
1.247 -graphs. But sometimes we want more advanced features. This way we can
1.248 -use the more general lemon reader and writer interface.
1.249 +The graph reader and writer classes give an easy way to read and write
1.250 +graphs. But sometimes we want more advanced features. In this case we can
1.251 +use the more general <tt>lemon reader and writer</tt> interface.
1.252
1.253 -The lemon format is an section oriented file format. It contains one or
1.254 -more section, each starts with a line with \c \@ first character.
1.255 +The LEMON file format is a section oriented file format. It contains one or
1.256 +more sections, each starting with a line identifying its type
1.257 +(the word starting with the \c \@ character).
1.258 The content of the section this way cannot contain line with \c \@ first
1.259 character. The file may contains comment lines with \c # first character.
1.260
1.261 @@ -351,7 +369,7 @@
1.262 classes which can be attached to a \c LemonReader or a \c LemonWriter.
1.263
1.264 There are default section readers and writers for reading and writing
1.265 -item sets, and labeled items in the graph. These reads and writes
1.266 +item sets, and labeled items in the graph. These read and write
1.267 the format described above. Other type of data can be handled with own
1.268 section reader and writer classes which are inherited from the
1.269 \c LemonReader::SectionReader or the \c LemonWriter::SectionWriter classes.
1.270 @@ -392,11 +410,11 @@
1.271
1.272 The other advanced stuff of the generalized file format is that
1.273 multiple edgesets can be stored to the same nodeset. It can be used
1.274 -by example as a network traffic matrix.
1.275 +for example as a network traffic matrix.
1.276
1.277 -In example there is a network with symmetric links and there are assymetric
1.278 +In our example there is a network with symmetric links and there are assymetric
1.279 traffic request on the network. This construction can be stored in an
1.280 -undirected graph and in an directed NewEdgeSetAdaptor class. The example
1.281 +undirected graph and in a directed NewEdgeSetAdaptor class. The example
1.282 shows the input with the LemonReader class:
1.283
1.284 \code
1.285 @@ -417,7 +435,7 @@
1.286
1.287 Because the GraphReader and the UndirGraphReader can be converted
1.288 to LemonReader and it can resolve the ID's of the items, the previous
1.289 -result can be achived with the UndirGraphReader class also.
1.290 +result can be achived with the UndirGraphReader class, too.
1.291
1.292
1.293 \code