PostGIS Wish List

This is a place to store ideas for future functionality that might be useful. New developers might want to try the easier ones as practice projects to get a feel for the code base.

• Distance Function - Simple Units
  • If geo ponts are stored in lat/long format, enable DISTANCE() to query other points within X feet/meters/miles etc…, not in latlon units.
    • Note: doing "magic srid support" requires constantly going back to the spatial_ref_sys column for information about what srs the srid maps to. One way to make "magic latlon support" work would be to have a single "islatlon" flag on the geometry object in addition to the srid number, which would be set by setsrid (again, through a lookup to spatial_ref_sys, but just once, instead of every time).

* Geodetic Support (DONE PostGIS 1.5)

• At the most basic level, geodetic support would enable the database to handle global lat/lon data transparently do a number of issues. As above, functions like Distance() and Area() would return in metric units even though the base data is in spherical coordinates. More importantly, the -180/180 wraparound and the poles would be transparently handled by such functions and by the index. pg_sphere may have some lessons to teach us here. The trick is to handle spherical coordinates without having to re-write a whole second system.

• Improve programming language support
  • Add some good documentation for the JAVA API!
  • Include PLJava support for back-end side scripting, and Python Geotypes for PLPython backend.
  • Add client-side C / C++ library for libpq/libpqxx users, like the included java support, or Python Geotypes
  • Separate packaging of java and C code

• More Validation Feedback
  • The isValid() function can tell me if a geometry is not valid, but it cannot tell me why (DONE by IsValidReason).
  • Perhaps an isValidLocation() (DONE in PostGIS 2.0, ST_IsValidDetail) or isValidReason() (DONE in PostGIS 1.4, GEOS 3.1.0 — but would be nice if gave all invalid locations — just gives first ) to show where and why the geometry is not correct. The JTS workbench has some of this functionality, so hopefully it is hiding in GEOS somewhere.
  • Also, by combining snapToGrid, buffer(0.0) and some other evil stuff, it should be possible to write a cleanGeometry() (DONE in PostGIS 2.0.0, naed ST_MakeValid) function that "mostly" works, and "mostly" is better than nothing at all.

• Install in Schema
  • Should be able to install PostGIS in its own separate schema to make administration easier.
  • This may be nice, but we should first recommend to users that to ease upgradability, it's highly recommend to never use the public schema for user data. Rather, store custom data, functions, etc, in user schemas. Then for upgrading, a DBA simply has to copy the schema over to a new PostGIS installation.

• AsGeoJSON() Function * Since Neogeographers love JSON and converting geometries into alternate formats is busywork that the database should do. Any other common geometry formats would be useful. ArcXML geometries? The new ESRI NMF format geometries? (Inspired by the utility of AsKML()). DONE in 1.3.4

• Added functionality for AsKML() Function
  • Because KML supports a variety of style elements that exist as tags inside the geometry, or extends the <geometry>, the ability to add such tags as Extrude, Tesselate, and Altitudemode would be useful. A proposal and work towards this item can be found at ​http://code.google.com/p/postexperiments/wiki/Extrude_Tesselate_and_Altitudemode_Support.

• E00 Import Into Topology
  • Since E00/Coverage have some implicit topology already built, load them into the Topology model without having to build topology ourselves. An interesing early step to full topology support and a chance to experience with what topology can do.

• Analytical Raster in the Database
  • Bind in some GRASS functionality and allow vectors to be rasterized to a grid, grid operations, and so on.

• Network Model in the Database
  • Bring PgRouting functionality into the PostGIS mainline.
  • CREATE_NETWORK DROP_NETWORK function to build / delete network tables

• Cascaded Union to improve MemUnion() performance — DONE in 1.4.0 and GEOS 3.1.0 * Cascaded union is generally better than buffer(0), and fairly simple to implement (see JTS 1.9)

• Add better deconstructors / deaggregates
  • st_dump is not currently an aggregate, nor will it breakdown a primitive geometry type, ie. give all the points in a linestring, or give all the lines in a polygon. Generate_series() can be used to accomplish this, but it does not scale well.

• Add a geometry-cleaner function
  • Kind of like buffer(0.0), but one designed for the task of cleaning in *all* cases.

• Add the concept of a geometry feature stream
  • Currently, using aggregates is extremely slow (ie. union() will slowly add geometries to a new union-ed geometry one at a time). A feature stream, perhaps ordered by a spatial index, may be able to stream features through such an aggregate, outputing features that will no longer be affected by incoming features. Example use cases:
  • node a large set of linestrings - we can currently do this efficiently on small sets by collecting and union with a single point already in the set. But this won't work on large datasets, ie ~16million,
  • create a polygonal coverage on input linework.
  • create a TIN from a large collection of DEM points.

• Finish Topology Support
  * Includes (assuming this referred to cpp #include directives, was done in 2.0.0dev)
  • loading existing topology data into postgis
  • loading raw linework and have the db automatically enforce topological correctness
  • add topological prototype alternatives for all spatial operations. IE contains() can be made significantly more efficient by simply looking at topological relationships between two polygons - no spatial operations are needed.
  • add editing support as in Oracle spatial - permit a user to lock a set of geometries in some bounding box for editing, allow inserts, deletes, updates of lines and nodes, automatically updating the underlying topology model.
  • Function to planarize a linestring dataset similiar to ArcGIS Planarize topology tool. Current solution is using GRASS v.clean then use v.to.db in GRASS
  • Functions to help with copying a topology (see TopologyCopy)

• Add Unit Tests for every function
  • we don't need to a repeat performance as with what happened with !ST_EndPoint() in 1.3.1

• Better (faster) calculation of which geometries are actually within others
  • Manifests itself in cases where one has a large polygon defining an area of interest whose bounding box covers an enormously greater area than the actual polygon (think of an elongated C shape overlaid on many smaller rectangular tiles).

• Add support for 3D point cloud data…
  • Index specific points of a cloud and/or groups of points.

• Add support for Google Encoded Polyline Algorithm Format
  • By adding a new function ST_AsGEncoded(geom) for using geometries directly with Google Maps APIs. ​http://code.google.com/intl/en/apis/maps/documentation/polylinealgorithm.html

• GRASS Vector Functionality…
  • Such as geometry=Delaunay(geometry), Voronoi, Extrude, Drape, etc

• AsX3D
  • Slated for PostGIS 2.0 or 2.1 see ticket #854

• Add a new idea here...
  • Please!