$Id: TODO 5159 2010-01-23 23:29:07Z nicklas $

== Simple Projects ==

* ST_CleanGeometry(geometry)
  Attempt to make invalid geometry valid
* ST_SplitGeometry(polygon, line) returns components of polygon
* ST_SplitGeometry(lineA, lineB) returns components of lineA
* ST_SplitGeometry(line, point) returns components of line 
* ST_AverageDistance(g1 geometry, g2 geometry, nsamples integer) returns double
  Sum of minimum distances at regular intervals up two geometries, 
  divided by the number of samples.  
* ST_GeomFromGeoJSON(string) returns geometry. Ingests JSON geometry parts only.
* ST_LatitudeFromText(string) returns float, 
  LongitudeFromText(string) returns float 
  for things like 132W 23' 23", or 45N 23.41232', or 123.14123W, etc, etc, etc.
* ST_AsLatLonText(<point>, [formatstring]) returns string.  
  Format string could use DD DD.DD MM MM.MM SS SSSS.SSS style 
  tokens and allow anything else (E, W, ", ', degree sign) 
  to be interleaved within.
* ST_DumpPoints(g1 geometry) returns setof geometry_dump 
  Similar in concept to ST_Dump and ST_DumpRings will output a 
  geometry_dump array for any geometry where each geometry is a point 
  and path info to denote the locaiton/subgeometry it is located in.
  (C-version TODO)

== Larger projects ==

-- Complete Curve support --

The LWGEOM construct does not have quite enough space to hold all the 
typology variants of curves. And it certainly doesn't have enough space
for encoding the line interpolation type.

Complete curve support would require re-working all the way back into
GEOS to support non-linear interpolations in all GEOS calculations,
and may never get done.

Intermediate curve support requires handling all curve types and stroking
them into linear interpolations for hand-off to GEOS functions. Inexact
but providing some utility.

Current curve support does include indexing and in/out functions but needs
much better documentation, particularly about the valid WKT and WKB forms.

-- Data Mangling for Performance --

Often geofeatures will be very large, 1000s of vertices, but the use case
for the features will only be using a few vertices at a time. For example,
an ocean polygon could be huge, but if a map is only zoomed into the coastline,
a small portion will be needed. Nonetheless, the database will have to 
retrieve the whole feature. Similarly, when carrying out spatial joins,
retrieving very large features and matching against small features is a bad
performance bargain, particularly since large features tend to reside in 
the TOAST tables, for yet more performance pain.

The solution is to cut up the large features into smaller features. 
Some standard utilities for doing so are required.

-- Topology --

Expand on the existing topology experiment, in particular buiding topologies
from existing POLYGON and MULTIPOLYGON "coverages" (simple feature collections
that have an expectation of no overlaps or gaps).

-- GEOMETRY_COLUMNS --

Add the maintenance of GEOMETRY_COLUMNS to the "ANALYZE" operation, so that
an ANALYZE automatically removes orphaned rows from GEOMETRY_COLUMNS and
adds entries for new rows.

-- typmod support --

Allow geometry(srid, type) constructors to automatically fill out GEOMETRY_COLUMNS and constraints.

-- Estimated Extent --

Fast extent estimation based on reading the head of the R-Tree.

-- Nearest Neighbor --

Fast nearest neighbor searching based on traversing the R-Tree.
See,
  http://citeseer.ist.psu.edu/roussopoulos95nearest.html
  http://citeseer.ist.psu.edu/91356.html

-- Heat Map / Clustering --

Given a set of points, generate a heat map output. Or, given a set of points, generate a clustering and set of representative points. In general, extract a trend from a collection.

-- LIDAR / Point Clouds --

A new object type to hold point cloud information in chunks < page size, filter functions to extract subsets of points from those types based on LIDAR-specific requests ("only return type 1"), and union functions to build complete sets from subsets.  Index bindings (likely 3d) for searching.  Potentially processing functions to extract surfaces or derived products like contours.

== Breaking Changes ==

* Consume and emit ISO standard WKT and WKB for extended dimensionality.
  Deprecate "EWKT" concept. Consuming is non-breaking change, emitting is 
  breaking change.
  WKT example: POINT Z (0 0 0), POINT M (0 0 0), POINT ZM (0 0 0 0)
  WKB uses different numbering for Z/M variants than EWKB does
* Convert the "default SRID" from -1 to 0
* Convert the LWGEOM struct(s) to have enough padding that the coordinates
  are double-aligned and can be accessed directly as doubles on all
  architectures
* Support all typologies of EMPTY (POINT EMPTY, LINESTRING EMPTY) instead
  of just using GEOMETRYCOLLECTION EMPTY all the time.