[postgis] distance(geometry,geometry) function

Frank Warmerdam warmerdam at pobox.com
Tue Jul 24 12:30:03 PDT 2001

"Timothy H. Keitt" wrote:
> Not in general, no.  This is all made more complex by the fact that
> postgis points and polygons are not seperate SQL types, but are instead
> mixed together within a single column of type "geometry", so you have to
> make your function accept all types of geometry objects.  I'm curious
> why you chose this path instead of making each geometric type a
> different SQL type as with the built-in postgresql geometry types?


Dave may want to add to this, but the approach of having a base geometry
type is essentially inherited from the OpenGIS simple features geometry
model.  In particular, for OGC simple features it is necessary to be
able to mix geometry types within a given column in a given table.  

If we implement the full Simple Features for SQL metadata (via auxilary
tables) there will be a mechanism to indicate that particular tables
are restricted to a particular subtype in the total set of possible
geometry types. 

>  Come
> to think of it, I'm not sure what postgis provides that the built-in
> types don't (except maybe much faster queries?).

Holes in polygons, geometry collections and 3d (really 2.5D) support
are the obvious extensions available in the PostGIS geometry model. 

Best regards,

I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent

------------------------ Yahoo! Groups Sponsor ---------------------~-->
Small business owners...
Tell us what you think! http://promo2.yahoo.com/sbin/Yahoo!_BusinessNewsletter/survey.cgi

To unsubscribe from this group, send an email to:
postgis-unsubscribe at yahoogroups.com


Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 

More information about the postgis-users mailing list