Mikhail,
This is a very interesting idea.
You might want to add specific support pgRouting which already supports
building graphs, creating routing topology and solving various graph
problem using postgis for geometry and tables for building and linking
the topology.
You might also want to look at:
https://github.com/woodbri/osrm-tools
- a tool to move pgrouting data to Project-OSRM
https://github.com/DennisOSRM/Project-OSRM
- a high performance routing engine
A tool like you are describing that can load data and prepare a graph or
move data between these projects would be extremely useful.
I look forward to hearing more about your ideas.
Thanks,
-Steve Woodbridge
On 2/17/2014 5:13 AM, Михаил Гусев wrote:
Hello everyone.
I am a last year student at Moscow Power Engineering Institute, Russia.
For GSoC 2014 I would like to work on networking capabilities in GDAL/OGR.
_
_
_Overall idea_
I would like to try to implement a universal network model. The
universality of the model would reflect not only in the ability to use
different GIS formats to store and transfer network data (which OGR is a
grate basis for), but also to be able to design and simulate different
types of network applications (engineering, natural, etc). I understand
that it is rather ambitious to consider all possible aspects of all
network types. But as a first step I would like to cover only the basic
aspects, that can be generalized and to provide a “platform” which can
be used by other developers to create their own extensions which are
specific to the concrete network type.
_Target scope for GSoC 2014_
Today none of OGR drivers supports network functionality. The idea is to
implement a new OGR driver, which will deal with networks built over the
spatial data. The spatial data together with the network data will be
stored in one of the OGR-supported formats, which would be specified
during the creation of the network.
Planned features of the new driver:
1. Reading/writing data from/to the source, creating layers, editing
attributes, etc (as any new OGR driver must provide);
2. The user would also be able to do the following, assuming that all
the special network data is the data of the current GIS-format:
- Read/Write the information about the whole network (network metadata);
- Edit special network objects parameters such as blocking state, or
direction of the flow;
- Import objects from the external sources (the driver adds missing
network parameters to them);
- Set/unset connections among network objects;
- Edit the sets of the network rules.
3. Each object in the network will have a set of relations with other
objects, which are stored separately and form a network graph;
4. The whole network will have a set of rules that describes the
connection possibilities of different object types in the network. The
network will also have a set of rules that describes the influence of
each type of object to the state of the whole network and to the other
types of objects. It can also be called as a behavior of the object in
the context of the network specialization (engineering purpose).
_Current status_
https://github.com/MikhanGusev/gnm
As a matter of fact I've been working on this for a while, and I've
already completed few things. Here is what I've accomplished already:
1. Complete. The driver and most of the required virtual interfaces are
already implemented;
2. Complete. All data from the external source is wrapped with the
network proxy and the user can edit it.
3. Currently, I'm thinking about the way, how the network graph will be
stored.
Best regards,
Mikhail Gusev.
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
