wiki:GoogleSummerCode

Version 19 (modified by robe, 11 years ago) ( diff )

--

Google Summer of Code 2014

If you are interested in working on any of these or have thoughts of your own, please subscribe to PostGIS developer list

PostGIS Raster

1) Implement write support for the PostGIS raster GDAL driver.

Mentor: Jorge Arevalo (jorgearevalo at libregis.org) or David Zwarg.

A GDAL driver allows reading/writing of raster (or images) data from/to formats like TIFF, PNG or JPEG.

The current GDAL PostGIS raster driver supports reading of PostGIS rasters objects from a PostgreSQL/PostGIS database but does not support writing. The project includes proposing a driver writer design and implementing it. You will familiarize yourself with GDAL-OGR development (one of the most used open source geospatial package), geospatial imagery concepts, open source development tools and code in C.

Might be able to reuse some logic already present in the packaged PostGIS raster2pgsql loader.

More information about GDAL PostGIS Raster driver here

2) Implement a set of geometry to raster functions

Mentor: Not decided yet

With the ability to store geometries and rasters in postgis, there is now a gap to fill by implementing geometry to raster algorithms to allow transition from one type to the other.

1) ST_Interpolate should be an aggregate taking a set of points (e.g. filtered lidar points) or line geometries (e.g. digitized topo lines) and their associated values and returning a raster representing a surface interpolated from those values. There are numerous methods of interpolation and it would nice to have a generic method so we can use all of them, but we’re first targeting bilinear interpolation, which will fill most needs and lay the ground for other methods. For reference, you might want to check an implementation in Numerical Recipes (chap. 3) or in CGAL. Converting a point table to a TIN and then to a raster is also a way to go. A Delaunay triangulation can be produced with the Triangle library (copyright issues should be checked first). See also here and here.

2) ST_AsDensity takes a point or line geometry coverage and first assign a count of those features to every pixels of a raster coverage and then apply a smoothing filter (using the existing one raster version of neighbour ST_MapAlgebra). Density functions allow summarizing or simplifying a point or line dataset.

3) ST_Distance takes a point or a geometry coverage and compute a raster representing the distance to the nearest geometry. Another function ST_CostDistance() compute the smallest distance to the geometry following a cost raster. This project was proposed by Qing Liu and accepted by the GSoC program.

PostGIS geometry

1) Implementation of ST_Voronoi function in PostGIS

Mentor: not decided yet

Skills required: C/C++, PL/pgSQL, knowledge of GEOS and PostGIS libraries, knowledge of Voronoi algorithm

As Voronoi porting from JTS to GEOS was done in GEOS GSoC 2013, this functionality should be tested in order to have an implementation of ST_Voronoi function in PostGIS 2.2. Check #2259 for more information

2) Add tolerance option to ST_Split function

Mentor: not decided yet

Skills required: C/C++, PL/pgSQL, knowledge of PostGIS library

ST_Split does not work well when splitting a line by a point. Consider the following example where the line is not split even though the blade is supposed to be a point on the line:

SELECT ST_AsText((ST_Dump(ST_Split(lin.geom, ST_Line_Interpolate_Point(lin.geom, 0.5)))).geom) AS geom
FROM (SELECT ST_GeomFromText('LINESTRING(604630.408 5792499.778,604623.849 5792500.886)') AS geom) AS lin

For the case of a line split by a point some kind of tolerance parameter would help. Until now I it is necessary first to ST_Snap your line to that interpolated point before splitting it by the point, which is not straightforward. Check #2192 fore more information.

PostGIS Topology

1) Implement ST_EstimatedExtent function for topology

Mentor: not decided yet

Skills required: C/C++, PL/pgSQL, knowledge of PostGIS and PostGIS topology

When the schema.table.col passed to st_estimated_extent refers to a layer registered in topology.layers the function could do something smart to return an estimate of what's the layer extent. It currently throws an exception due to "null statistics" for the table/column.

Check #2074 for more information.

2) Implement ability to load topogeoms using shp2pgsql

Mentor: not decided yet

Skills required: C/C++, PL/pgSQL, knowledge of PostGIS and PostGIS topology

In writing chapters of the book, one exercise is to load the data with shp2pgsql and then a second step to load into a specific topology. Aside from speed issues, we could just go straight to a topogeom column much like we do with geography is -G is chosen. This would require another switch for topology name and name of topology. The only tricky part is that for the toTopogeom calls we need the generated layer id, which would require a connection to the database to get unless we have a lookup function of some sort that can lookup the layerid based on topo column table/name.

Check #2103 for more information

3) Add an extra arg to toTopoGeom function to prevent addition of primitives to topology

Mentor: not decided yet

Skills required: C/C++, PL/pgSQL, knowledge of PostGIS and PostGIS topology

The scenario: You are the master maintainer of a topology for say a city or something and have meticulously laid out the topology that should account for all department topogeometry needs.

Some reckless person in department A, comes by and creates a topogeometry with toTopoGeom because his/her topogeometry which should have snapped to existing edges, did not. Now you have extra annoying nodes in your topology. That reckless person may very well be you. You want the totopoGeom not to do you favors by creating new primitives if you know all the topos you are adding should be able to use the edges,nodes, and faces already existing in your topology.

So after discussion, proposed solution is to add an extra proto to toTopoGeom that prevents creation of new primitives and if a topogeometry can't be created without adding a primitive, it should throw an error. So basically: change this existing proto:

toTopoGeom(geometry geom, varchar toponame, integer layer_id, float8 tolerance);

to this other one

toTopoGeom(geometry geom, varchar toponame, integer layer_id, float8 tolerance, allow_primitive_creation = true);

Check #2144 for more information.

PostGIS pgsql2shp dumper

Each change to the loader and dumper should be done as a single GSoc by same developer

1) pgsql2shp should not require temp table creation privs when dumping a query

Mentor: Regina Obe

Skills required: C/C++, knowledge of PostGIS library, knowledge of PostgreSQL SQL

If you can't create a temporary table, then you can't get a shapefile out of a query using pgsql2shp. You can by using ogr2ogr.

Check #2045 for more information

PostGIS shp2pgsql /shp2pgsql-gui loader

1) Modify shp2pgsql to emit DROP TABLE IF EXISTS insted of just DROP TABLE

Mentor: Regina Obe

Skills required: C/C++, knowledge of PostGIS library

Just when -d flag is passed

Check #2236 for more information

2) Specify command line options for shp2pgsql-gui in the About box

Mentor: Regina Obe

Skills required: C/C++, GTK, knowledge of PostGIS library

Right now a user has no way of knowing what options are available in shp2pgsql-gui.

Check #528 for more information.

3) Modify shp2pgsql-gui to avoid attempt of spatial index creation when only dbf available

Mentor: Regina Obe

Skills required: C/C++, GTK, knowledge of PostGIS library

If you try to load shapefiles with only dbf available and select spatial index option, you will see an error

Check #2473 for more information


Want more details? Check the OSGeo GSoC 2014 page or write to the PostGIS developer list.

Note: See TracWiki for help on using the wiki.