Difference between revisions of "PostGIS SoC Ideas 2007"

From OSGeo
Jump to navigation Jump to search
Line 15: Line 15:
 
tasks such as least cost path finding.
 
tasks such as least cost path finding.
  
 +
==== Linking to CGAL Library ====
 +
 +
The [http://www.cgal.org/ Computational Geometry Algorithms Library] supports many algorithms for spatial analysis. Voronois, delaunays, etc.
 
==== Linking to Boost Graph Library ====
 
==== Linking to Boost Graph Library ====
  

Revision as of 12:53, 8 March 2007

Ideas for Google Summer of Code students wanting to work on PostGIS

Topology model and operations

The project consists in providing a standardized interface for storing topology information, that is sets of Edges, Nodes, Areas and their relations in constituting a Feature. There's already a draft implementation of the model, what can be done is (in random order):

  • Implementing topological operation directly using the topology model rather then converting input to simple Geometries.
  • Import from / export to popular topology data formats (ie: TIGER)

Network model and operations

The project is aimed at providing a standardized interface for topological network information storage and operations. Tipical use would be modeling communication networks, composed by Links and Nodes, and performing tasks such as least cost path finding.

Linking to CGAL Library

The Computational Geometry Algorithms Library supports many algorithms for spatial analysis. Voronois, delaunays, etc.

Linking to Boost Graph Library

The Boost Graph Library supports many algorithms for graph and network analysis. Because it uses a generic iterator-based interface, it can easily be grafted into other frameworks simply by providing the appropriate iterator classes.

Coverage model and operations

Allow storage and operations on coverage (raster-like) data.

GEOS performance improvements

The GEOS C++ library suffers from a design too closely bound to it's Java-implemented parent, JTS. This approach has introduced an unnecessary overhead throughout the whole operations flow due to excessive dynamic polymorphism and heap allocations. Redesigning the most used subsystems could improve the overall performance. Random ideas:

  • Redesign index classes using a templated approach.
  • Enforce use of standard algorithms wherever appropriate.

Potential Mentors

Developers in the PostGIS community who would be interested in supporting one of the above projects:

  • Mateusz Loskot - I'm strongly interested in supporting GEOS performance improvements task
  • Tim Keitt - I'm interested in supporting "Linking PostGIS to the Boost Graph Library"

Other projects

Please see Google Summer of Code