Wednesday, May 7, 2014

Model in action #1. Building network

In this post I would like to tell about the current status of the building and storing network capabilities in the GDAL/OGR network model. To show the progress I will use my small test application and QGIS to visualize the spatial data.

Manual network creation

We start from creating a network with defining the GIS format, in which the spatial data along with all its network data will be stored. I chose a PostGIS. Though the created void network has neither spatial nor network data there are already all system tables. We add a new point layer called "tanks" and create some features in it. The network_features table will be updated with new Global Feature Identifers (GFIDs) for these features, which were assigned automatically. Now we have a set of spatial data, but don't have any topological relations among the features.

As for code - all the time before we used only the generic methods of the OGRGnmDataSource and OGRGnmLayer, such as OGRDataSource::createLayer() or OGRLayer::createFeature(). When it's time to call the specific network's behavior we need to use a type cast. For connection we call for example OGRGnmDataSource::connectFeatures(0, 1, -1, 0.0, 0.0, 2), where parameters are:

1), 2) Source and target feature GFIDs. Now these features are vertexes in a graph.
3) Connector feature GFID. If we pass -1 it means that there is no physical feature between source and target and the connection is logical. This is an edge in a graph.
4), 5) The cost of edge from source to target (direct) and from target to source (inverse).
6) Direction of edge. 2 equals to bi-directional edge.

Now the network's graph is formed. We can see in pgAdmin that there were automatically created two system edges between the connected vertexes in the network_sysedges table.


Automatic network creation

Now we are going to build a network over the existing set of spatial data. Let's take a piece of the city's drain network, which includes one line Shapefile with pipes and two point Shapefiles with wells.


Firstly we open the created on the first step network and then import this data. An importing is similar to ogr2ogr utility, while it copies all features of the layer from the external data source to our one. The coordinates of the imported features are transformed to the global network SRS. After the successful importing there is no built network yet. We must connect the required features manually (for such big amount of features it can be too difficult) or use the automatic graph building capability. In our example set of data each line feature starts and ends geographically right at the point features (or very close to them). So we can use the GNMLinePointBuilder strategy to build the graph. We define the snap tolerance (in our case it will equal 0.00005) and pass it with the layers' ids to the strategy constructor. After the successful building we get the ready graph. Note, that during the graph building the specific cost assignment behavior was used. Thus, GNMGeometryCostConnection decorator is responsible for measuring the length of the edge feature.



Conclusion

Though, there is already some network functionality in OGR there is still much work. First of all the driver is not included in GDAL. There are also many small unfinished points in the code which must be completed, such as the correct network deletion behavior or correct working with SpatiaLite format.

But by this time we can see the following: with the help of the network model based on the OGR driver it is possible to create networks. The network is a set of layers (for PostGIS it is a set of DB tables) which exist along with spatial layers. The basis of network is a graph. It can be built over spatial data manually or automatically. In the next post I would like to show what can be done from network analysis with the built network.

No comments:

Post a Comment