Week #13. GNM finished

At this week I've completed all that I planed to do for the last week:

1) Fixed all makefiles (GNUMakefile and makefile.vc) and built on Linux and Windows accordingly. I also tested all my apps (which use the most of GNM functionality) on these platforms and they worked fine;
2)  Complete GNM Python tests. Now the direct GNM tests and tests of gnmmanage app are available;
3) And finally I've completed all documentation:
       *  Doxyfile for GNM;
       * All public methods are commented in code for Doxygen accordingly;
       * GNM architecture;
       * GNM tutorial;
       * gnmanalyse description in .dox form;
       * gnmmanage description in .dox form.

Week #12. GNM is almost finished

What I've complete in GNM at this week:
1. Implemented the second algorithm: Connected components search and according capability in gnmanalyse app;
2. Implemented blocking capabilities for networks. Now you can calculate paths and resource distribution via gnmanalyse app as the folowing:

>gnmanalyse.exe resource -bl 12 -bl 235 -unbl 740 

// This will analyse the resource distribution (water, electricity) during the commutations of features in network: the features 12, 235 are blocked (will not be regarded during the routing process) and 740 is unblocked. All blocking features will be saved in a separate system layer. The resource will spread over the network from the features which are marked as emitters (via rules). The emitter features can also be blocked so not to 'emit' the resource. 

>gnmanalyse.exe dijkstra 718 740 -unblall

// This will calculate the shortest path between 718 and 740 when all features (saved in previous calculations) are become unblocked.

3. Now it is possible to connect features without geometries - the according system features will serve as graph edges;
4. Fixed some bugs/issues.

All these capabilities I've also previously described in my older posts.

What I need to do in order to finish my work on GNM:
1. Fix GNUMakefile-s according to some new changes
2. Make a bit more python tests
3. Complete docs: some new comments in code and finish architecture & tutorial

Week #11. Network's business logic

At this week I've implemented a support of network's business logic (commit) as I described in my previous posts which is based on the concept of string rules. More general, for the future subclasses of GNMNetwork the method CreateRule(const char *pszRuleStr) can be used to create a some kind of rule/constraint/restriction in the concrete network format. In GNMGdalNetwork it is used to determine how the costs or directions or for the graph edges can be extracted during the connection of features and how the features can be connected with each other. GNMGdalNetwork::CreateRule() parses the given string according to the special syntax (see my first post about rules). I've added to the gnmmanage utility some new commands, so now it can be used like the following:

>gnmmanage --long-usage

Usage: gnmmanage [--help][-q][-quiet][--utility_version][--long-usage]

[create [-f format_name] [-t_srs srs_name] [-dsco NAME=VALUE]... ]

[import src_dataset_name] [-l layer_name]

[connect gfid_src gfid_tgt gfid_con [-c cost] [-ic inv_cost] [-dir dir]]

[rule rule_str]

[autoconnect tolerance]

[remove]

[-nt]

gnm_name

create: create connectivity or the full network, depending on native format support (-nt)

-f format_name: output file format name, possible values are:

[ESRI Shapefile]

-t_srs srs_name: spatial reference input

-dsco NAME=VALUE: dataset creation option (format specific)

import src_dataset_name: dataset name to copy

-l layer_name: layer name in dataset (optional)

connect gfid_src gfid_tgt gfid_con: make a topological connection, where the gfid_src and gfid_tgt are vertexes and gfid_con is edge

-c cost -ic inv_cost -dir dir: manually assign the following values: the cost (weight), inverse cost and direction of the edge (optional)

rule rule_str: creates a rule/constraint in the network by the given rule_str string

autoconnect tolerance: create topology automatically with the given double tolerance

remove: remove connectivity or network, depending on native format support (-nt)

-nt: use native network format (now unavailable)

So lets use the gnmmanage in combination with gnmanalyse to see the new functionality. For example we need to calculate the shortest path between two points. The layer lines has the special field called "L" where the length of the feature is stored. We must create network, import layers and create some rules before the automatic connection will be called in order to put in the graph the "L" field values as costs. For example for bat windows file:

gnmmanage.exe create -f "ESRI Shapefile" -t_srs "EPSG:4326" -dsco "net_name=my_network_1" ..\network_data

gnmmanage.exe import ..\in_data\krasnogorsk -l lines ..\network_data

gnmmanage.exe import ..\in_data\krasnogorsk -l kolodci ..\network_data

gnmmanage.exe import ..\in_data\krasnogorsk -l reshetki ..\network_data

gnmmanage.exe rule "CLASS gnm_lines_line COSTS L" ..\network_data

gnmmanage.exe rule "CLASS gnm_lines_line INVCOSTS L" ..\network_data

gnmmanage.exe rule "CLASS gnm_lines_line DIRECTS my_dir" ..\network_data

gnmmanage.exe autoconnect 0.00005 ..\network_data

The piece of network looks like the following:

The 717 and 744 have not been connected during the automatic connection because they are far from each other. We can connect them manually in order to create the alternative path for routing.

gnmmanage.exe connect 717 744 231 ..\network_data

After that we use Dijkstra algorithm several times to calculate a path between the points: 1) 716->740; 2) 715->740; 3) 711->740. The shortest path is calculated properly, according to the summary length in each case.

During our work with network the connection rules have not been set. The concept of rules considers that if no NETWORK rules for particular classes have been set than the connections of all features with each other are allowed by default. So there were no problems. If we set at least one connection rule for the class, then during the ConnectFeatures() method the permission of the connection will be checked anytime.

We create the following rules and autoconnect the newly created network:

...

gnmmanage.exe rule "NETWORK CONNECTS gnm_reshetki_point WITH gnm_kolodci_point VIA gnm_lines_line" ..\network_data

gnmmanage.exe rule "NETWORK CONNECTS gnm_kolodci_point WITH gnm_kolodci_point VIA gnm_lines_line" ..\network_data

gnmmanage.exe autoconnect 0.00005 ..\network_data

After the automatic connection all kolodci features have been connected with reshetki features and with themselves, as opposite to reshetki & reshetki features because such rule has not been set.
 So the shortest path will not be found between 1100 and 1341 features (1). After the creation of corresponding rule two reshetki features can be connected manually and the path will be found (2). In the picture: kolodci: circle with dots, reshetki: stars, lines: lines.