'''GDAL/OGR Geography Network support'''

 
'''Short description'''

 
An implementation of an GNM set of classes, which intends to operate with networks which are built over the spatial data of different GIS-formats.

 
'''Introduction'''

 
There are many network solutions in a GIS field today. Some technologies have routing functionality (pgRouting, GRASS GIS), some of them have a full network-model representation (ArcGIS). But there is still a lack of a universal network model that, on the one hand would support conversions for the existing network formats, and on the other hand would provide a network functionality to those products which does not have it at all.
 
According to some investigations such model can not be represent just as a simple graph which holds a topology. This task is more complex, because:
        - There are different types of networks (engineering, natural, road, etc), and each one has it's own features and behavior.
        - The final purpose in using such model may vary: from designing and simulating engineering networks to routing on the road networks.
The model should intend to consider all of these differences, or be a “platform” with extension capabilities.

 
'''Main idea'''

 
While OGR is already a model for spatial data and it generalizes work with different GIS formats, it can be possible to bring to it the same network functionality and to create the same model for network data, which will also generalize work with different network formats. This will be a layer of abstraction for networks, like OGR now is a layer of abstraction for spatial data. Technically the core of the model will be a new GNM set of classes. Together with additional classes and functions it will form a universal network model.

 
There is no aim now to cover all features and to consider all differences of network types in the model. But it is possible to make a “platform” which can be extended and configured to the user requirements. So the model will only provide a basic functionality and mechanisms to widen it.

 
Model features and capabilities:

 
1. Build network. It should be possible to build a network over any set of spatial data, which OGR supports.


        - New GNM set of classes will use all basic methods of OGRDataSource/OGRLayer to operate with data as usual and add new capabilities, such as connectFeatures() and disconnectFeatures() methods.

        - The model will provide a mechanism to implement some algorithms of automatic graph building, depending on  input data. The basic algorithm will use several point and line OGRLayers to build a network.

        - Built graph is only the basis of the network and in the context of GIS the network is full of real-world objects (pipes, roads) which attributes must be considered during the building process. E.g. some objects can not be connected with others; object attributes can affect the graph costs. So the network will have a mechanism (based on string-like rules), which will describe such behavior.

 
2. Store network. Built network data is stored along with it's spatial data (e.g. for shapefiles it will be several shapes, for PostGIS – several tables). There is no need to invent some new network storing format. The model will define the set of essential layers and maintain the work with them.

 
3. Import/export network. The model will have a mechanism to implement small drivers to convert for example pgRouting or SpatiaLite VirtualNetwork networks from/to the GNM.

 
4. Analyse network. The model will be equipped with the basic analysis methods (connected component search, Dijkstra shortest path search, K-shortest path) which have a wide use. This list can be extended anytime.


'''Plan & Timeline'''

 
As a matter of fact I've been working with this project during the work on my Master's thesis, and though I will not include all my work to the defense this June, I've already implement the most part of driver and some algorithms.

 
May 19 – May 31. Complete rule string syntax analysis and some parts which I've leaved before, during my previous development.

 
June 1 – June 14. Test driver and build it into GDAL. At this point the driver will be fully implemented. But it's improving and debugging will continue during all summer.

 
June 15 – Jule 15. Get familiar with pgRouting and implement import and export from/to the model as an example of using a network conversion mechanism.

 
Jule 16 – Jule 31. As I need some application to test and demonstrate the capabilities of the model I either get familiar with QGIS development and make a small useful plugin (e.g. for building simple engineering networks), or complete my old testing application.

 
August 1 – August 18. Documentation and testing. Try to build the model on different platforms.

 
'''Future ideas'''

 
As the model intends to be a “platform”, the future is to widen it with the support of new network formats and analysis methods. Especially interesting will be an opportunity to add a support of some specific engineering calculations for water supply or electrical networks for example.

 
'''Project progress'''

 
Github:  https://github.com/MikhanGusev/gdal

Blog: http://gsoc2014gnm.blogspot.ru/