

Due to popular demand, I've added the function;
distance(geometry,geometry)
: finds the minimum distance between the two geometries
now you can do things like;
select * from <table> where distance(<geometry col>,'POLYGON(0 0, 0 10,
10 10, 10 0, 0 0)') < 10.0;
which will find anything that is within 10 units of the given polygon.
This will greatly increase the complexity of spatial queries users will
be able to perform.
I'm still testing it; it should hit the CVS version in the next few
days.
dave
 Yahoo! Groups Sponsor ~>
Secure your servers with 128bit SSL encryption! Grab your copy of
VeriSign's FREE Guide "Securing Your Web Site for Business." Get it now!
http://www.verisign.com/cgibin/go.cgi?a=n094442340008000http://us.click.yahoo.com/6lIgYB/IWxCAA/yigFAA/PhFolB/TM~>
To unsubscribe from this group, send an email to:
[hidden email]
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/


I assume you mean euclidean distance. A lot of us keep our locations in
geodetic coordinates. It would be nice if geometries could reference a
particular datum so these things would be handled transparently.
(Postgis is nonetheless a very exciting development.)
Cheers,
Tim
Dave Blasby wrote:
>Due to popular demand, I've added the function;
>
>distance(geometry,geometry)
> : finds the minimum distance between the two geometries
>
>now you can do things like;
>
>select * from <table> where distance(<geometry col>,'POLYGON(0 0, 0 10,
>10 10, 10 0, 0 0)') < 10.0;
>
>which will find anything that is within 10 units of the given polygon.
>
>This will greatly increase the complexity of spatial queries users will
>be able to perform.
>
>I'm still testing it; it should hit the CVS version in the next few
>days.
>
>dave
>
>
>To unsubscribe from this group, send an email to:
> [hidden email]
>
>
>
>Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

Timothy H. Keitt
Department of Ecology and Evolution
State University of New York at Stony Brook
Stony Brook, New York 11794 USA
Phone: 6316321101, FAX: 6316327626
http://life.bio.sunysb.edu/ee/keitt/To unsubscribe from this group, send an email to:
[hidden email]
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/


> I assume you mean euclidean distance. A lot of us keep our locations in
> geodetic coordinates. It would be nice if geometries could reference a
> particular datum so these things would be handled transparently.
> (Postgis is nonetheless a very exciting development.)
Yes, these are euclidean distances. The calculations in geodetic
coordinates are complex.
We have a function that, given a spheroid and 2 geodetic points, will
calculate the distance between them. In order to do distance() in
generality, I need to be able to;
1. Given a spheroid and the points A, B, and C. AB define a line in
geodetic space (a great circle). Find the minimum distance (also a
great circle) between the line AB and C.
2. Given a spheroid and the points A, B and U, V. AB and UV define
lines in geodetic space. Tell me if they intersect or the minimum
distance between then.
3. Given a spherioid, the point A, and the polygon P tell me if point A
is inside the polygon P.
Then I'd need to dust off my spherical geometry and make sure my
euclidean assumptions will hold on an ellipsoid.
Does anyone know how to calculate these things?
dave
To unsubscribe from this group, send an email to:
[hidden email]
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/


Dave Blasby wrote:
>> I assume you mean euclidean distance. A lot of us keep our locations in
>> geodetic coordinates. It would be nice if geometries could reference a
>> particular datum so these things would be handled transparently.
>> (Postgis is nonetheless a very exciting development.)
>
>
>
> Yes, these are euclidean distances. The calculations in geodetic
> coordinates are complex.
>
> We have a function that, given a spheroid and 2 geodetic points, will
> calculate the distance between them. In order to do distance() in
> generality, I need to be able to;
>
> 1. Given a spheroid and the points A, B, and C. AB define a line in
> geodetic space (a great circle). Find the minimum distance (also a
> great circle) between the line AB and C.
>
> 2. Given a spheroid and the points A, B and U, V. AB and UV define
> lines in geodetic space. Tell me if they intersect or the minimum
> distance between then.
>
> 3. Given a spherioid, the point A, and the polygon P tell me if point A
> is inside the polygon P.
>
> Then I'd need to dust off my spherical geometry and make sure my
> euclidean assumptions will hold on an ellipsoid.
>
Dave,
PROJ.4 does include a geodetic great circle distance calculation program.
I wonder if it would be best putting off such advanced services untill
you can build an entire
projections library into PostGIS. I would certainly promote PROJ.4 as
an option. However,
I would assume this (building in full OGC projection support) would be a
ways down the road
for PostGIS.
Best regards,

+
I set the clouds in motion  turn up  Frank Warmerdam, [hidden email]
light and sound  activate the windows  http://pobox.com/~warmerdamand 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.cgihttp://us.click.yahoo.com/vO1FAB/txzCAA/ySSFAA/PhFolB/TM~>
To unsubscribe from this group, send an email to:
[hidden email]
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/


Dave Blasby wrote:
>Yes, these are euclidean distances. The calculations in geodetic
>coordinates are complex.
>
>We have a function that, given a spheroid and 2 geodetic points, will
>calculate the distance between them. In order to do distance() in
>generality, I need to be able to;
>
>1. Given a spheroid and the points A, B, and C. AB define a line in
>geodetic space (a great circle). Find the minimum distance (also a
>great circle) between the line AB and C.
>
>2. Given a spheroid and the points A, B and U, V. AB and UV define
>lines in geodetic space. Tell me if they intersect or the minimum
>distance between then.
>
>3. Given a spherioid, the point A, and the polygon P tell me if point A
>is inside the polygon P.
>
>Then I'd need to dust off my spherical geometry and make sure my
>euclidean assumptions will hold on an ellipsoid.
>
>
>Does anyone know how to calculate these things?
>
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 builtin postgresql geometry types? Come
to think of it, I'm not sure what postgis provides that the builtin
types don't (except maybe much faster queries?).
I agree with Frank that a quick wrapper around PROJ.4 would be a good
shortterm solution for handling datum projections.
Tim

Timothy H. Keitt
Department of Ecology and Evolution
State University of New York at Stony Brook
Stony Brook, New York 11794 USA
Phone: 6316321101, FAX: 6316327626
http://life.bio.sunysb.edu/ee/keitt/ Yahoo! Groups Sponsor ~>
Small business owners...
Tell us what you think! http://promo2.yahoo.com/sbin/Yahoo!_BusinessNewsletter/survey.cgihttp://us.click.yahoo.com/vO1FAB/txzCAA/ySSFAA/PhFolB/TM~>
To unsubscribe from this group, send an email to:
[hidden email]
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/


"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 builtin postgresql geometry types?
Tim,
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 builtin
> 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, [hidden email]
light and sound  activate the windows  http://pobox.com/~warmerdamand 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.cgihttp://us.click.yahoo.com/vO1FAB/txzCAA/ySSFAA/PhFolB/TM~>
To unsubscribe from this group, send an email to:
[hidden email]
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/


> 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 builtin postgresql geometry types? Come
> to think of it, I'm not sure what postgis provides that the builtin
> types don't (except maybe much faster queries?).
I've actually been thinking of making types like GEOMETRY_POINT and
GEOMETRY_MULTIPOLYGON available (leaving the current GEOMETRY as
GEOMETRY_GENERIC). It just means a whole lot of extra functions for
handling all the operators and indexing. I think I've come up with a
plan that will make this much easier than writing a HUGE number of
support functions. I just need the time to do it. There's been some
dissention in the ranks arguing that it doesnt actually give you much
extra than whats already there.
As far as having more complex functions, since openGIS defines a
geometrycollection type, all those functions still have to provided.
Besides, its still legal to say distance(polygon, line) so all the
support functions need to be written anyways. Once they're written its
trivial to write the generic case (just pass smaller parts off to the
support functions).
The PostGIS geometry type is different from the standard PostgreSQL
geometry types in that (1) we support 3D (2) indexing on all types (3)
more advanced geometries (like polygons with holes) (4) collectiontype
geometries (multi* and geometrycollection) and (5) no size limit.
dave
 Yahoo! Groups Sponsor ~>
Small business owners...
Tell us what you think! http://promo2.yahoo.com/sbin/Yahoo!_BusinessNewsletter/survey.cgihttp://us.click.yahoo.com/vO1FAB/txzCAA/ySSFAA/PhFolB/TM~>
To unsubscribe from this group, send an email to:
[hidden email]
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/


> PROJ.4 does include a geodetic great circle distance calculation program.
>
> I wonder if it would be best putting off such advanced services untill
> you can build an entire
> projections library into PostGIS. I would certainly promote PROJ.4 as
> an option. However,
> I would assume this (building in full OGC projection support) would be a
> ways down the road
> for PostGIS.
I agree 100%  I dont want to do anything to do with projections for a
while.
And I'm almost certainly going to integrate PROJ.4. In fact I'll
probably steal your code since you use the WKT projection
representation.
Right now geodetic coordinates are dangerous since they represent
"nonstraightline" geometries.
I know PROJ allows one to calculate the greatcircle distance between
two point, but does it calculate the point of closest approach between
two lines?
dave
 Yahoo! Groups Sponsor ~>
Small business owners...
Tell us what you think! http://promo2.yahoo.com/sbin/Yahoo!_BusinessNewsletter/survey.cgihttp://us.click.yahoo.com/vO1FAB/txzCAA/ySSFAA/PhFolB/TM~>
To unsubscribe from this group, send an email to:
[hidden email]
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/


> The PostGIS geometry type is different from the standard PostgreSQL
> geometry types in that (1) we support 3D (2) indexing on all types (3)
> more advanced geometries (like polygons with holes) (4) collectiontype
> geometries (multi* and geometrycollection) and (5) no size limit.
And (6) support functions to make them actually useful in a GIS context.
The PostgreSQL base geometric types have been essentially rotting: none
of the core pgsql developers has a particular interest in supporting or
enhancing their use. We could have done support functionality against
the base types, but would then have been missing, as Dave notes, 3D,
holes, aggregates, indexing. Most importantly, we would have been
unable to exceed the page size limit (8Kb) for a given feature if we
used the base types.

__
/
 Paul Ramsey
 Refractions Research
 Email: [hidden email]
 Phone: (250) 8850632
\_
 Yahoo! Groups Sponsor ~>
Small business owners...
Tell us what you think! http://promo2.yahoo.com/sbin/Yahoo!_BusinessNewsletter/survey.cgihttp://us.click.yahoo.com/vO1FAB/txzCAA/ySSFAA/PhFolB/TM~>
To unsubscribe from this group, send an email to:
[hidden email]
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/


Frank Warmerdam wrote:
>
>Tim,
>
>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.
>
Sounds good. I suspected that postgis was following some standard way
of doing things. (I just didn't know what it was.)
T.

Timothy H. Keitt
Department of Ecology and Evolution
State University of New York at Stony Brook
Stony Brook, New York 11794 USA
Phone: 6316321101, FAX: 6316327626
http://life.bio.sunysb.edu/ee/keitt/ Yahoo! Groups Sponsor ~>
Secure your servers with 128bit SSL encryption! Grab your copy of
VeriSign's FREE Guide "Securing Your Web Site for Business." Get it now!
http://www.verisign.com/cgibin/go.cgi?a=n094442340008000http://us.click.yahoo.com/6lIgYB/IWxCAA/yigFAA/PhFolB/TM~>
To unsubscribe from this group, send an email to:
[hidden email]
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/


Dave Blasby wrote:
>I've actually been thinking of making types like GEOMETRY_POINT and
>GEOMETRY_MULTIPOLYGON available (leaving the current GEOMETRY as
>GEOMETRY_GENERIC). It just means a whole lot of extra functions for
>handling all the operators and indexing. I think I've come up with a
>
I like really compact, orthogonal interfaces, so don't add a bunch of
stuff on my account! ;) That said, I really like stronglytypes
languages, so that is probably why I was thinking about seperating the
geometry types as different sql types, e.g., "select cast((10,
12)::geodeticPoint as albersEqualArea, ...)" or something.
>
>plan that will make this much easier than writing a HUGE number of
>support functions. I just need the time to do it. There's been some
>dissention in the ranks arguing that it doesnt actually give you much
>extra than whats already there.
>
They may be right.
>
>
>As far as having more complex functions, since openGIS defines a
>geometrycollection type, all those functions still have to provided.
>Besides, its still legal to say distance(polygon, line) so all the
>support functions need to be written anyways. Once they're written its
>trivial to write the generic case (just pass smaller parts off to the
>support functions).
>
>The PostGIS geometry type is different from the standard PostgreSQL
>geometry types in that (1) we support 3D (2) indexing on all types (3)
>more advanced geometries (like polygons with holes) (4) collectiontype
>geometries(multi* and geometrycollection) and (5) no size limit.
>
>dave
>
This is great. As I said before, I'm really excited about postgis.
T.

Timothy H. Keitt
Department of Ecology and Evolution
State University of New York at Stony Brook
Stony Brook, New York 11794 USA
Phone: 6316321101, FAX: 6316327626
http://life.bio.sunysb.edu/ee/keitt/ Yahoo! Groups Sponsor ~>
Small business owners...
Tell us what you think! http://promo2.yahoo.com/sbin/Yahoo!_BusinessNewsletter/survey.cgihttp://us.click.yahoo.com/vO1FAB/txzCAA/ySSFAA/PhFolB/TM~>
To unsubscribe from this group, send an email to:
[hidden email]
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

