PostGIS

I think we need a strategy for handling precision and tolerance in a lot of functions I opened a wiki page to get a list of functions that should be tolerance/precision aware. ToleranceDiscussion

I think we need a strategy for handling precision and tolerance in a lot of functions I opened a wiki page to get a list of functions that should be tolerance/precision aware. ToleranceDiscussion

It is common for shapefiles to be distributed as .zip packages, so it may be nice to make shp2pgsql able to read them directly from there (or some other package format too) in an automagical way.

It is common for shapefiles to be distributed as .zip packages, so it may be nice to make shp2pgsql able to read them directly from there (or some other package format too) in an automagical way.

ST_LocatePoint returns a value which you can't easily convert to a vertex number. This isn't helpful if what you're looking for is a substring formed by pre-existing vertices rather than formed by arbitrarily interpolated points. In turn, re-using ... [More] existing vertices is required to avoid introducing coordinates drifts when willing to analize subportions of lines. GEOS/JTS, for comparison, uses a pair of (SEG_NUM/SEG_FRACTION) representing in turn the segment index and the fraction of next segment. [Less]

ST_LocatePoint returns a value which you can't easily convert to a vertex number. This isn't helpful if what you're looking for is a substring formed by pre-existing vertices rather than formed by arbitrarily interpolated points. In turn, re-using ... [More] existing vertices is required to avoid introducing coordinates drifts when willing to analize subportions of lines. GEOS/JTS, for comparison, uses a pair of (SEG_NUM/SEG_FRACTION) representing in turn the segment index and the fraction of next segment. [Less]

How topology starts making sense in PostGIS 2.0.0

How topology starts making sense in PostGIS 2.0.0

The geometric equality operator we used to have in 1.3 (~=) would be even more useful now. We can't call it ~= since that has already changed definition so much and is now just a bounding box equality (and not even that much because our bounding ... [More] boxes are floats instead of the double precision of the geometry) Something like == might be a possible choice for bringing back the good old geometric equality ~= (NOTE this requies it have a RECHECK on it. The main benefit would be to be able to use exclusion constraints (introduced in PostgreSQL 9.0) to enforce geometry uniqueness. Right now there is no guaranteed way of doing this and EXCLUSION CONSTRAINTS won't work with functions (so ST_OrderingEquals is out of the question) -- they have to be operators. ​http://www.postgresql.org/docs/9.0/static/ddl-constraints.html ​http://thoughts.j-davis.com/2010/09/25/exclusion-constraints-are-generalized-sql-unique/ [Less]

The geometric equality operator we used to have in 1.3 (~=) would be even more useful now. We can't call it ~= since that has already changed definition so much and is now just a bounding box equality (and not even that much because our bounding ... [More] boxes are floats instead of the double precision of the geometry) Something like == might be a possible choice for bringing back the good old geometric equality ~= (NOTE this requies it have a RECHECK on it. The main benefit would be to be able to use exclusion constraints (introduced in PostgreSQL 9.0) to enforce geometry uniqueness. Right now there is no guaranteed way of doing this and EXCLUSION CONSTRAINTS won't work with functions (so ST_OrderingEquals is out of the question) -- they have to be operators. ​http://www.postgresql.org/docs/9.0/static/ddl-constraints.html ​http://thoughts.j-davis.com/2010/09/25/exclusion-constraints-are-generalized-sql-unique/ [Less]