[gdal-dev] GSoC 2014

[Stephen Woodbridge]

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 at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>