Geog/Geom Hack

[Paul Ramsey-4]

I'm interested to know what the general opinion is of the trick I've
used on ST_Buffer(geography):

http://trac.osgeo.org/postgis/browser/trunk/postgis/geography.sql.in.c#L541

I ask because I could apply the same idea to the larger suite of OGC
SFSQL predicates before release. Is half-a-loaf better than no loaf in
this case? (Note that there will be failure cases for really large
geometry, like a polygon of "Asia" or "Russia" that have polygons over
the dateline.)

P.
_______________________________________________
postgis-devel mailing list
postgis-devel@...
http://postgis.refractions.net/mailman/listinfo/postgis-devel

[Paragon Corporation-2]

Paul,
I would rather you didn't for 2 reasons

1) I'm lazy and for each of these things we'd have to apply the text
additional function proto hack to prevent from it breaking geometry.  which
we will probably end up taking out anyway.

2) I don't like the hiddenness of it since it becomes especially annoying if
you have your native in geometry and you are converting to geography for a
special usecase, then you end up with a slower implementation

as you would really end up doing accidentally

geometry -> geography -> geometry ->operation (and why do I want my calcs
done in UTM?)

Instead of the more efficient

geometry -> operation

Thanks,
Regina

-----Original Message-----
From: postgis-devel-bounces@...
[mailto:postgis-devel-bounces@...] On Behalf Of Paul
Ramsey
Sent: Friday, October 30, 2009 8:16 PM
To: PostGIS Development Discussion
Subject: [postgis-devel] Geog/Geom Hack

I'm interested to know what the general opinion is of the trick I've used on
ST_Buffer(geography):

http://trac.osgeo.org/postgis/browser/trunk/postgis/geography.sql.in.c#L541

I ask because I could apply the same idea to the larger suite of OGC SFSQL
predicates before release. Is half-a-loaf better than no loaf in this case?
(Note that there will be failure cases for really large geometry, like a
polygon of "Asia" or "Russia" that have polygons over the dateline.)

P.
_______________________________________________
postgis-devel mailing list
postgis-devel@...
http://postgis.refractions.net/mailman/listinfo/postgis-devel



_______________________________________________
postgis-devel mailing list
postgis-devel@...
http://postgis.refractions.net/mailman/listinfo/postgis-devel

[Paul Ramsey-3]

I'm not sure I understand why you would ever convert a geometry to a
geography as part of a query on a geometry table. I fully expect
geography to be used as a storage type, because of the utility of
having the correct spherical indexes, which are not available when
you're just converting in via a cast. Since there's no functions
available on geography that are not already available on geometry, why
would you ever do a geometry->geography cast unless you are (a)
testing geography or (b) bulk converting a table into geography for
storage in that type.

P.



On Fri, Oct 30, 2009 at 5:24 PM, Paragon Corporation <lr@...> wrote:

> Paul,
> I would rather you didn't for 2 reasons
>
> 1) I'm lazy and for each of these things we'd have to apply the text
> additional function proto hack to prevent from it breaking geometry.  which
> we will probably end up taking out anyway.
>
> 2) I don't like the hiddenness of it since it becomes especially annoying if
> you have your native in geometry and you are converting to geography for a
> special usecase, then you end up with a slower implementation
>
> as you would really end up doing accidentally
>
> geometry -> geography -> geometry ->operation (and why do I want my calcs
> done in UTM?)
>
> Instead of the more efficient
>
> geometry -> operation
>
> Thanks,
> Regina
>
> -----Original Message-----
> From: postgis-devel-bounces@...
> [mailto:postgis-devel-bounces@...] On Behalf Of Paul
> Ramsey
> Sent: Friday, October 30, 2009 8:16 PM
> To: PostGIS Development Discussion
> Subject: [postgis-devel] Geog/Geom Hack
>
> I'm interested to know what the general opinion is of the trick I've used on
> ST_Buffer(geography):
>
> http://trac.osgeo.org/postgis/browser/trunk/postgis/geography.sql.in.c#L541
>
> I ask because I could apply the same idea to the larger suite of OGC SFSQL
> predicates before release. Is half-a-loaf better than no loaf in this case?
> (Note that there will be failure cases for really large geometry, like a
> polygon of "Asia" or "Russia" that have polygons over the dateline.)
>
> P.
> _______________________________________________
> postgis-devel mailing list
> postgis-devel@...
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>
>
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel@...
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>

_______________________________________________
postgis-devel mailing list
postgis-devel@...
http://postgis.refractions.net/mailman/listinfo/postgis-devel

[Paragon Corporation-2]

Paul,
I can put a functional geography index on can't I and take advantage of
geography index bindings?

Lets say I have a large network of tables broken out by region so I know a
specific table has one srid.

For many queries, I may go to that table directly or if I'm doing single
geometry processing, really don't care what srid as long as its in utm or
whatever - so I can use the full power of GEOS.

For my across the board distance checks and so forth, I would want to use
geography and I could use a geography index if I put a functional geography
index on my geometry correct?  Though that needs some more testing.


So in short if 90% of my workload involves geometry processing, I will want
to keep my data in geometry

But the 10% I would want to convert to geography on the fly.

Thanks,
Regina

-----Original Message-----
From: postgis-devel-bounces@...
[mailto:postgis-devel-bounces@...] On Behalf Of Paul
Ramsey
Sent: Friday, October 30, 2009 8:34 PM
To: PostGIS Development Discussion
Subject: Re: [postgis-devel] Geog/Geom Hack

I'm not sure I understand why you would ever convert a geometry to a
geography as part of a query on a geometry table. I fully expect geography
to be used as a storage type, because of the utility of having the correct
spherical indexes, which are not available when you're just converting in
via a cast. Since there's no functions available on geography that are not
already available on geometry, why would you ever do a geometry->geography
cast unless you are (a) testing geography or (b) bulk converting a table
into geography for storage in that type.

P.



On Fri, Oct 30, 2009 at 5:24 PM, Paragon Corporation <lr@...> wrote:

> Paul,
> I would rather you didn't for 2 reasons
>
> 1) I'm lazy and for each of these things we'd have to apply the text
> additional function proto hack to prevent from it breaking geometry.  
> which we will probably end up taking out anyway.
>
> 2) I don't like the hiddenness of it since it becomes especially
> annoying if you have your native in geometry and you are converting to
> geography for a special usecase, then you end up with a slower
> implementation
>
> as you would really end up doing accidentally
>
> geometry -> geography -> geometry ->operation (and why do I want my
> calcs done in UTM?)
>
> Instead of the more efficient
>
> geometry -> operation
>
> Thanks,
> Regina
>
> -----Original Message-----
> From: postgis-devel-bounces@...
> [mailto:postgis-devel-bounces@...] On Behalf Of
> Paul Ramsey
> Sent: Friday, October 30, 2009 8:16 PM
> To: PostGIS Development Discussion
> Subject: [postgis-devel] Geog/Geom Hack
>
> I'm interested to know what the general opinion is of the trick I've
> used on
> ST_Buffer(geography):
>
> http://trac.osgeo.org/postgis/browser/trunk/postgis/geography.sql.in.c
> #L541
>
> I ask because I could apply the same idea to the larger suite of OGC
> SFSQL predicates before release. Is half-a-loaf better than no loaf in

this case?

> (Note that there will be failure cases for really large geometry, like
> a polygon of "Asia" or "Russia" that have polygons over the dateline.)
>
> P.
> _______________________________________________
> postgis-devel mailing list
> postgis-devel@...
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>
>
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel@...
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>

_______________________________________________
postgis-devel mailing list
postgis-devel@...
http://postgis.refractions.net/mailman/listinfo/postgis-devel



_______________________________________________
postgis-devel mailing list
postgis-devel@...
http://postgis.refractions.net/mailman/listinfo/postgis-devel

[Paul Ramsey-3]

You *can*, but I strongly doubt you *will*. Because there's nothing in
geography that isn't already in geometry. So you as a primary geometry
user are going to have no working need to cast things to geography.

On the other hand, the very first question from users of geography
will be "how can I access <geometry function N>?" So having a
relatively full set of functions already available in geography makes
sense to me, even if they are hacked in with a planar trick.

P.

On Fri, Oct 30, 2009 at 5:46 PM, Paragon Corporation <lr@...> wrote:

> Paul,
> I can put a functional geography index on can't I and take advantage of
> geography index bindings?
>
> Lets say I have a large network of tables broken out by region so I know a
> specific table has one srid.
>
> For many queries, I may go to that table directly or if I'm doing single
> geometry processing, really don't care what srid as long as its in utm or
> whatever - so I can use the full power of GEOS.
>
> For my across the board distance checks and so forth, I would want to use
> geography and I could use a geography index if I put a functional geography
> index on my geometry correct?  Though that needs some more testing.
>
>
> So in short if 90% of my workload involves geometry processing, I will want
> to keep my data in geometry
>
> But the 10% I would want to convert to geography on the fly.
>
> Thanks,
> Regina
>
> -----Original Message-----
> From: postgis-devel-bounces@...
> [mailto:postgis-devel-bounces@...] On Behalf Of Paul
> Ramsey
> Sent: Friday, October 30, 2009 8:34 PM
> To: PostGIS Development Discussion
> Subject: Re: [postgis-devel] Geog/Geom Hack
>
> I'm not sure I understand why you would ever convert a geometry to a
> geography as part of a query on a geometry table. I fully expect geography
> to be used as a storage type, because of the utility of having the correct
> spherical indexes, which are not available when you're just converting in
> via a cast. Since there's no functions available on geography that are not
> already available on geometry, why would you ever do a geometry->geography
> cast unless you are (a) testing geography or (b) bulk converting a table
> into geography for storage in that type.
>
> P.
>
>
>
> On Fri, Oct 30, 2009 at 5:24 PM, Paragon Corporation <lr@...> wrote:
>> Paul,
>> I would rather you didn't for 2 reasons
>>
>> 1) I'm lazy and for each of these things we'd have to apply the text
>> additional function proto hack to prevent from it breaking geometry.
>> which we will probably end up taking out anyway.
>>
>> 2) I don't like the hiddenness of it since it becomes especially
>> annoying if you have your native in geometry and you are converting to
>> geography for a special usecase, then you end up with a slower
>> implementation
>>
>> as you would really end up doing accidentally
>>
>> geometry -> geography -> geometry ->operation (and why do I want my
>> calcs done in UTM?)
>>
>> Instead of the more efficient
>>
>> geometry -> operation
>>
>> Thanks,
>> Regina
>>
>> -----Original Message-----
>> From: postgis-devel-bounces@...
>> [mailto:postgis-devel-bounces@...] On Behalf Of
>> Paul Ramsey
>> Sent: Friday, October 30, 2009 8:16 PM
>> To: PostGIS Development Discussion
>> Subject: [postgis-devel] Geog/Geom Hack
>>
>> I'm interested to know what the general opinion is of the trick I've
>> used on
>> ST_Buffer(geography):
>>
>> http://trac.osgeo.org/postgis/browser/trunk/postgis/geography.sql.in.c
>> #L541
>>
>> I ask because I could apply the same idea to the larger suite of OGC
>> SFSQL predicates before release. Is half-a-loaf better than no loaf in
> this case?
>> (Note that there will be failure cases for really large geometry, like
>> a polygon of "Asia" or "Russia" that have polygons over the dateline.)
>>
>> P.
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel@...
>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>
>>
>>
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel@...
>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel@...
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>
>
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel@...
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>

_______________________________________________
postgis-devel mailing list
postgis-devel@...
http://postgis.refractions.net/mailman/listinfo/postgis-devel

[Paragon Corporation-2]

Paul,
Hmm when I am comparing distance of two geometries in different spatial refs
which I do a lot.

I still don't like the hack even if you disregard the above or if you must
hack -- don't give it the same name as the non-hacked functions.

the whole idea of picking BestSRID for a person to cater to less technical
users I find extremely annoying as I can think of 20 "BestSRID" depending on
what I am doing.  If they get to that level of sophistication, I would
rather have them think a little more  and understand the implications of
those decisions.

We must learn to crawl before we can learn to walk,because walking without
understanding will just get you into trouble in the long run.


 Thanks,
Regina

-----Original Message-----
From: postgis-devel-bounces@...
[mailto:postgis-devel-bounces@...] On Behalf Of Paul
Ramsey
Sent: Friday, October 30, 2009 9:47 PM
To: PostGIS Development Discussion
Subject: Re: [postgis-devel] Geog/Geom Hack

You *can*, but I strongly doubt you *will*. Because there's nothing in
geography that isn't already in geometry. So you as a primary geometry user
are going to have no working need to cast things to geography.

On the other hand, the very first question from users of geography will be
"how can I access <geometry function N>?" So having a relatively full set of
functions already available in geography makes sense to me, even if they are
hacked in with a planar trick.

P.

On Fri, Oct 30, 2009 at 5:46 PM, Paragon Corporation <lr@...> wrote:

> Paul,
> I can put a functional geography index on can't I and take advantage
> of geography index bindings?
>
> Lets say I have a large network of tables broken out by region so I
> know a specific table has one srid.
>
> For many queries, I may go to that table directly or if I'm doing
> single geometry processing, really don't care what srid as long as its
> in utm or whatever - so I can use the full power of GEOS.
>
> For my across the board distance checks and so forth, I would want to
> use geography and I could use a geography index if I put a functional
> geography index on my geometry correct?  Though that needs some more

testing.

>
>
> So in short if 90% of my workload involves geometry processing, I will
> want to keep my data in geometry
>
> But the 10% I would want to convert to geography on the fly.
>
> Thanks,
> Regina
>
> -----Original Message-----
> From: postgis-devel-bounces@...
> [mailto:postgis-devel-bounces@...] On Behalf Of
> Paul Ramsey
> Sent: Friday, October 30, 2009 8:34 PM
> To: PostGIS Development Discussion
> Subject: Re: [postgis-devel] Geog/Geom Hack
>
> I'm not sure I understand why you would ever convert a geometry to a
> geography as part of a query on a geometry table. I fully expect
> geography to be used as a storage type, because of the utility of
> having the correct spherical indexes, which are not available when
> you're just converting in via a cast. Since there's no functions
> available on geography that are not already available on geometry, why
> would you ever do a geometry->geography cast unless you are (a)
> testing geography or (b) bulk converting a table into geography for

storage in that type.

>
> P.
>
>
>
> On Fri, Oct 30, 2009 at 5:24 PM, Paragon Corporation <lr@...> wrote:
>> Paul,
>> I would rather you didn't for 2 reasons
>>
>> 1) I'm lazy and for each of these things we'd have to apply the text
>> additional function proto hack to prevent from it breaking geometry.
>> which we will probably end up taking out anyway.
>>
>> 2) I don't like the hiddenness of it since it becomes especially
>> annoying if you have your native in geometry and you are converting
>> to geography for a special usecase, then you end up with a slower
>> implementation
>>
>> as you would really end up doing accidentally
>>
>> geometry -> geography -> geometry ->operation (and why do I want my
>> calcs done in UTM?)
>>
>> Instead of the more efficient
>>
>> geometry -> operation
>>
>> Thanks,
>> Regina
>>
>> -----Original Message-----
>> From: postgis-devel-bounces@...
>> [mailto:postgis-devel-bounces@...] On Behalf Of
>> Paul Ramsey
>> Sent: Friday, October 30, 2009 8:16 PM
>> To: PostGIS Development Discussion
>> Subject: [postgis-devel] Geog/Geom Hack
>>
>> I'm interested to know what the general opinion is of the trick I've
>> used on
>> ST_Buffer(geography):
>>
>> http://trac.osgeo.org/postgis/browser/trunk/postgis/geography.sql.in.
>> c
>> #L541
>>
>> I ask because I could apply the same idea to the larger suite of OGC
>> SFSQL predicates before release. Is half-a-loaf better than no loaf
>> in
> this case?
>> (Note that there will be failure cases for really large geometry,
>> like a polygon of "Asia" or "Russia" that have polygons over the
>> dateline.)
>>
>> P.
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel@...
>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>
>>
>>
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel@...
>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel@...
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>
>
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel@...
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>

_______________________________________________
postgis-devel mailing list
postgis-devel@...
http://postgis.refractions.net/mailman/listinfo/postgis-devel


_______________________________________________
postgis-devel mailing list
postgis-devel@...
http://postgis.refractions.net/mailman/listinfo/postgis-devel

[Paul Ramsey-3]

We're going to have to agree to disagree on this one, Regina. Catering
to the less technical users is what this exercise is all about, to my
mind, and that includes allowing easy flipping into geometry for
calculations that aren't supported in geography yet. Oracle does this
too.

What do other folks think?

P.

On Fri, Oct 30, 2009 at 7:06 PM, Paragon Corporation <lr@...> wrote:

> Paul,
> Hmm when I am comparing distance of two geometries in different spatial refs
> which I do a lot.
>
> I still don't like the hack even if you disregard the above or if you must
> hack -- don't give it the same name as the non-hacked functions.
>
> the whole idea of picking BestSRID for a person to cater to less technical
> users I find extremely annoying as I can think of 20 "BestSRID" depending on
> what I am doing.  If they get to that level of sophistication, I would
> rather have them think a little more  and understand the implications of
> those decisions.
>
> We must learn to crawl before we can learn to walk,because walking without
> understanding will just get you into trouble in the long run.
>
>
>  Thanks,
> Regina
>
> -----Original Message-----
> From: postgis-devel-bounces@...
> [mailto:postgis-devel-bounces@...] On Behalf Of Paul
> Ramsey
> Sent: Friday, October 30, 2009 9:47 PM
> To: PostGIS Development Discussion
> Subject: Re: [postgis-devel] Geog/Geom Hack
>
> You *can*, but I strongly doubt you *will*. Because there's nothing in
> geography that isn't already in geometry. So you as a primary geometry user
> are going to have no working need to cast things to geography.
>
> On the other hand, the very first question from users of geography will be
> "how can I access <geometry function N>?" So having a relatively full set of
> functions already available in geography makes sense to me, even if they are
> hacked in with a planar trick.
>
> P.
>
> On Fri, Oct 30, 2009 at 5:46 PM, Paragon Corporation <lr@...> wrote:
>> Paul,
>> I can put a functional geography index on can't I and take advantage
>> of geography index bindings?
>>
>> Lets say I have a large network of tables broken out by region so I
>> know a specific table has one srid.
>>
>> For many queries, I may go to that table directly or if I'm doing
>> single geometry processing, really don't care what srid as long as its
>> in utm or whatever - so I can use the full power of GEOS.
>>
>> For my across the board distance checks and so forth, I would want to
>> use geography and I could use a geography index if I put a functional
>> geography index on my geometry correct?  Though that needs some more
> testing.
>>
>>
>> So in short if 90% of my workload involves geometry processing, I will
>> want to keep my data in geometry
>>
>> But the 10% I would want to convert to geography on the fly.
>>
>> Thanks,
>> Regina
>>
>> -----Original Message-----
>> From: postgis-devel-bounces@...
>> [mailto:postgis-devel-bounces@...] On Behalf Of
>> Paul Ramsey
>> Sent: Friday, October 30, 2009 8:34 PM
>> To: PostGIS Development Discussion
>> Subject: Re: [postgis-devel] Geog/Geom Hack
>>
>> I'm not sure I understand why you would ever convert a geometry to a
>> geography as part of a query on a geometry table. I fully expect
>> geography to be used as a storage type, because of the utility of
>> having the correct spherical indexes, which are not available when
>> you're just converting in via a cast. Since there's no functions
>> available on geography that are not already available on geometry, why
>> would you ever do a geometry->geography cast unless you are (a)
>> testing geography or (b) bulk converting a table into geography for
> storage in that type.
>>
>> P.
>>
>>
>>
>> On Fri, Oct 30, 2009 at 5:24 PM, Paragon Corporation <lr@...> wrote:
>>> Paul,
>>> I would rather you didn't for 2 reasons
>>>
>>> 1) I'm lazy and for each of these things we'd have to apply the text
>>> additional function proto hack to prevent from it breaking geometry.
>>> which we will probably end up taking out anyway.
>>>
>>> 2) I don't like the hiddenness of it since it becomes especially
>>> annoying if you have your native in geometry and you are converting
>>> to geography for a special usecase, then you end up with a slower
>>> implementation
>>>
>>> as you would really end up doing accidentally
>>>
>>> geometry -> geography -> geometry ->operation (and why do I want my
>>> calcs done in UTM?)
>>>
>>> Instead of the more efficient
>>>
>>> geometry -> operation
>>>
>>> Thanks,
>>> Regina
>>>
>>> -----Original Message-----
>>> From: postgis-devel-bounces@...
>>> [mailto:postgis-devel-bounces@...] On Behalf Of
>>> Paul Ramsey
>>> Sent: Friday, October 30, 2009 8:16 PM
>>> To: PostGIS Development Discussion
>>> Subject: [postgis-devel] Geog/Geom Hack
>>>
>>> I'm interested to know what the general opinion is of the trick I've
>>> used on
>>> ST_Buffer(geography):
>>>
>>> http://trac.osgeo.org/postgis/browser/trunk/postgis/geography.sql.in.
>>> c
>>> #L541
>>>
>>> I ask because I could apply the same idea to the larger suite of OGC
>>> SFSQL predicates before release. Is half-a-loaf better than no loaf
>>> in
>> this case?
>>> (Note that there will be failure cases for really large geometry,
>>> like a polygon of "Asia" or "Russia" that have polygons over the
>>> dateline.)
>>>
>>> P.
>>> _______________________________________________
>>> postgis-devel mailing list
>>> postgis-devel@...
>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>
>>>
>>>
>>> _______________________________________________
>>> postgis-devel mailing list
>>> postgis-devel@...
>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel@...
>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>
>>
>>
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel@...
>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel@...
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel@...
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>

_______________________________________________
postgis-devel mailing list
postgis-devel@...
http://postgis.refractions.net/mailman/listinfo/postgis-devel

[Paragon Corporation-2]

Paul,
I suppose we can't just put this decision off till 2.0.  Isn't this a bit of
scope creep?  I'm not absolutely sure which way is better,
but I know the cost of rolling back the change is more.

If you are going to do this, how many functions are you planning to do this
for?

I'm cc'ing the postgis users group too to get more of an opinion on this
topic.

So the question is it it a good idea to introduce a hack that transforms a
geography into what we call BestSRID to perform geometry operations on and
then transform back.  My concern is that this is a silent operation that
gives the impression that these functions are natively done in spheroid
space just for the benefit of  catering to less technical users.

http://trac.osgeo.org/postgis/browser/trunk/postgis/geography.sql.in.c#L541

So you can't really tell by looking the penalty

Main examples of this as shown for ST_Buffer

CREATE OR REPLACE FUNCTION _ST_BestSRID(geography, geography)
530         RETURNS integer
531         AS 'MODULE_PATHNAME','geography_bestsrid'
532         LANGUAGE 'C' IMMUTABLE STRICT;
533  
534 -- Availability: 1.5.0
535 CREATE OR REPLACE FUNCTION _ST_BestSRID(geography)
536         RETURNS integer
537         AS 'SELECT _ST_BestSRID($1,$1)'
538         LANGUAGE 'SQL' IMMUTABLE STRICT;
539  
540 -- Availability: 1.5.0
541 CREATE OR REPLACE FUNCTION ST_Buffer(geography, float8)
542         RETURNS geography
543         AS 'SELECT
geography(ST_Transform(ST_Buffer(ST_Transform(geometry($1),
_ST_BestSRID($1)), $2), 4326))'
544         LANGUAGE 'SQL' IMMUTABLE STRICT;
545



Thanks,
Regina

-----Original Message-----
From: postgis-devel-bounces@...
[mailto:postgis-devel-bounces@...] On Behalf Of Paul
Ramsey
Sent: Friday, October 30, 2009 11:07 PM
To: PostGIS Development Discussion
Subject: Re: [postgis-devel] Geog/Geom Hack

We're going to have to agree to disagree on this one, Regina. Catering to
the less technical users is what this exercise is all about, to my mind, and
that includes allowing easy flipping into geometry for calculations that
aren't supported in geography yet. Oracle does this too.

What do other folks think?

P.

On Fri, Oct 30, 2009 at 7:06 PM, Paragon Corporation <lr@...> wrote:

> Paul,
> Hmm when I am comparing distance of two geometries in different
> spatial refs which I do a lot.
>
> I still don't like the hack even if you disregard the above or if you
> must hack -- don't give it the same name as the non-hacked functions.
>
> the whole idea of picking BestSRID for a person to cater to less
> technical users I find extremely annoying as I can think of 20
> "BestSRID" depending on what I am doing.  If they get to that level of
> sophistication, I would rather have them think a little more  and
> understand the implications of those decisions.
>
> We must learn to crawl before we can learn to walk,because walking
> without understanding will just get you into trouble in the long run.
>
>
>  Thanks,
> Regina
>
> -----Original Message-----
> From: postgis-devel-bounces@...
> [mailto:postgis-devel-bounces@...] On Behalf Of
> Paul Ramsey
> Sent: Friday, October 30, 2009 9:47 PM
> To: PostGIS Development Discussion
> Subject: Re: [postgis-devel] Geog/Geom Hack
>
> You *can*, but I strongly doubt you *will*. Because there's nothing in
> geography that isn't already in geometry. So you as a primary geometry
> user are going to have no working need to cast things to geography.
>
> On the other hand, the very first question from users of geography
> will be "how can I access <geometry function N>?" So having a
> relatively full set of functions already available in geography makes
> sense to me, even if they are hacked in with a planar trick.
>
> P.
>
> On Fri, Oct 30, 2009 at 5:46 PM, Paragon Corporation <lr@...> wrote:
>> Paul,
>> I can put a functional geography index on can't I and take advantage
>> of geography index bindings?
>>
>> Lets say I have a large network of tables broken out by region so I
>> know a specific table has one srid.
>>
>> For many queries, I may go to that table directly or if I'm doing
>> single geometry processing, really don't care what srid as long as
>> its in utm or whatever - so I can use the full power of GEOS.
>>
>> For my across the board distance checks and so forth, I would want to
>> use geography and I could use a geography index if I put a functional
>> geography index on my geometry correct?  Though that needs some more
> testing.
>>
>>
>> So in short if 90% of my workload involves geometry processing, I
>> will want to keep my data in geometry
>>
>> But the 10% I would want to convert to geography on the fly.
>>
>> Thanks,
>> Regina
>>
>> -----Original Message-----
>> From: postgis-devel-bounces@...
>> [mailto:postgis-devel-bounces@...] On Behalf Of
>> Paul Ramsey
>> Sent: Friday, October 30, 2009 8:34 PM
>> To: PostGIS Development Discussion
>> Subject: Re: [postgis-devel] Geog/Geom Hack
>>
>> I'm not sure I understand why you would ever convert a geometry to a
>> geography as part of a query on a geometry table. I fully expect
>> geography to be used as a storage type, because of the utility of
>> having the correct spherical indexes, which are not available when
>> you're just converting in via a cast. Since there's no functions
>> available on geography that are not already available on geometry,
>> why would you ever do a geometry->geography cast unless you are (a)
>> testing geography or (b) bulk converting a table into geography for
> storage in that type.
>>
>> P.
>>
>>
>>
>> On Fri, Oct 30, 2009 at 5:24 PM, Paragon Corporation <lr@...> wrote:
>>> Paul,
>>> I would rather you didn't for 2 reasons
>>>
>>> 1) I'm lazy and for each of these things we'd have to apply the text
>>> additional function proto hack to prevent from it breaking geometry.
>>> which we will probably end up taking out anyway.
>>>
>>> 2) I don't like the hiddenness of it since it becomes especially
>>> annoying if you have your native in geometry and you are converting
>>> to geography for a special usecase, then you end up with a slower
>>> implementation
>>>
>>> as you would really end up doing accidentally
>>>
>>> geometry -> geography -> geometry ->operation (and why do I want my
>>> calcs done in UTM?)
>>>
>>> Instead of the more efficient
>>>
>>> geometry -> operation
>>>
>>> Thanks,
>>> Regina
>>>
>>> -----Original Message-----
>>> From: postgis-devel-bounces@...
>>> [mailto:postgis-devel-bounces@...] On Behalf Of
>>> Paul Ramsey
>>> Sent: Friday, October 30, 2009 8:16 PM
>>> To: PostGIS Development Discussion
>>> Subject: [postgis-devel] Geog/Geom Hack
>>>
>>> I'm interested to know what the general opinion is of the trick I've
>>> used on
>>> ST_Buffer(geography):
>>>
>>> http://trac.osgeo.org/postgis/browser/trunk/postgis/geography.sql.in.
>>> c
>>> #L541
>>>
>>> I ask because I could apply the same idea to the larger suite of OGC
>>> SFSQL predicates before release. Is half-a-loaf better than no loaf
>>> in
>> this case?
>>> (Note that there will be failure cases for really large geometry,
>>> like a polygon of "Asia" or "Russia" that have polygons over the
>>> dateline.)
>>>
>>> P.
>>> _______________________________________________
>>> postgis-devel mailing list
>>> postgis-devel@...
>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>
>>>
>>>
>>> _______________________________________________
>>> postgis-devel mailing list
>>> postgis-devel@...
>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel@...
>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>
>>
>>
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel@...
>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel@...
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel@...
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>

_______________________________________________
postgis-devel mailing list
postgis-devel@...
http://postgis.refractions.net/mailman/listinfo/postgis-devel


_______________________________________________
postgis-devel mailing list
postgis-devel@...
http://postgis.refractions.net/mailman/listinfo/postgis-devel

[Paragon Corporation-2]

Paul,
For what its worth, here is another reason why I don't like this idea and I
think we should at least think about its ramifications more so should put it
off for consideration until 2.0.

In geometry processing, its common practice to apply a lot of functions in
succession

process1(process2(process3(geometry/geography)

With your hackish approach -- the unsuspecting novice user will be incurring
a lot of transformation rounding errors with each process

The advanced user, won't know if this is okay or not -- because they can't
tell by looking at the function call the hidden transformations going on.  

If these did not exist, they would transform once before the processes and
once after) and incurr much less penalty

But if they both exist, they will treat them as being on equal footing

ST_Buffer(geometry)  and ST_Buffer(geography)


So your approach while well-meaning gives a questionable benefit to novices
and is putting experienced users at a disadvantage.

Thanks,
Regina

-----Original Message-----
From: postgis-devel-bounces@...
[mailto:postgis-devel-bounces@...] On Behalf Of Paragon
Corporation
Sent: Friday, October 30, 2009 11:54 PM
To: 'PostGIS Development Discussion'
Cc: 'PostGIS Users Discussion'
Subject: Re: [postgis-devel] Geog/Geom Hack

Paul,
I suppose we can't just put this decision off till 2.0.  Isn't this a bit of
scope creep?  I'm not absolutely sure which way is better, but I know the
cost of rolling back the change is more.

If you are going to do this, how many functions are you planning to do this
for?

I'm cc'ing the postgis users group too to get more of an opinion on this
topic.

So the question is it it a good idea to introduce a hack that transforms a
geography into what we call BestSRID to perform geometry operations on and
then transform back.  My concern is that this is a silent operation that
gives the impression that these functions are natively done in spheroid
space just for the benefit of  catering to less technical users.

http://trac.osgeo.org/postgis/browser/trunk/postgis/geography.sql.in.c#L541

So you can't really tell by looking the penalty

Main examples of this as shown for ST_Buffer

CREATE OR REPLACE FUNCTION _ST_BestSRID(geography, geography)
530         RETURNS integer
531         AS 'MODULE_PATHNAME','geography_bestsrid'
532         LANGUAGE 'C' IMMUTABLE STRICT;
533
534 -- Availability: 1.5.0
535 CREATE OR REPLACE FUNCTION _ST_BestSRID(geography)
536         RETURNS integer
537         AS 'SELECT _ST_BestSRID($1,$1)'
538         LANGUAGE 'SQL' IMMUTABLE STRICT;
539
540 -- Availability: 1.5.0
541 CREATE OR REPLACE FUNCTION ST_Buffer(geography, float8)
542         RETURNS geography
543         AS 'SELECT
geography(ST_Transform(ST_Buffer(ST_Transform(geometry($1),
_ST_BestSRID($1)), $2), 4326))'
544         LANGUAGE 'SQL' IMMUTABLE STRICT;
545



Thanks,
Regina

-----Original Message-----
From: postgis-devel-bounces@...
[mailto:postgis-devel-bounces@...] On Behalf Of Paul
Ramsey
Sent: Friday, October 30, 2009 11:07 PM
To: PostGIS Development Discussion
Subject: Re: [postgis-devel] Geog/Geom Hack

We're going to have to agree to disagree on this one, Regina. Catering to
the less technical users is what this exercise is all about, to my mind, and
that includes allowing easy flipping into geometry for calculations that
aren't supported in geography yet. Oracle does this too.

What do other folks think?

P.

On Fri, Oct 30, 2009 at 7:06 PM, Paragon Corporation <lr@...> wrote:

> Paul,
> Hmm when I am comparing distance of two geometries in different
> spatial refs which I do a lot.
>
> I still don't like the hack even if you disregard the above or if you
> must hack -- don't give it the same name as the non-hacked functions.
>
> the whole idea of picking BestSRID for a person to cater to less
> technical users I find extremely annoying as I can think of 20
> "BestSRID" depending on what I am doing.  If they get to that level of
> sophistication, I would rather have them think a little more  and
> understand the implications of those decisions.
>
> We must learn to crawl before we can learn to walk,because walking
> without understanding will just get you into trouble in the long run.
>
>
>  Thanks,
> Regina
>
> -----Original Message-----
> From: postgis-devel-bounces@...
> [mailto:postgis-devel-bounces@...] On Behalf Of
> Paul Ramsey
> Sent: Friday, October 30, 2009 9:47 PM
> To: PostGIS Development Discussion
> Subject: Re: [postgis-devel] Geog/Geom Hack
>
> You *can*, but I strongly doubt you *will*. Because there's nothing in
> geography that isn't already in geometry. So you as a primary geometry
> user are going to have no working need to cast things to geography.
>
> On the other hand, the very first question from users of geography
> will be "how can I access <geometry function N>?" So having a
> relatively full set of functions already available in geography makes
> sense to me, even if they are hacked in with a planar trick.
>
> P.
>
> On Fri, Oct 30, 2009 at 5:46 PM, Paragon Corporation <lr@...> wrote:
>> Paul,
>> I can put a functional geography index on can't I and take advantage
>> of geography index bindings?
>>
>> Lets say I have a large network of tables broken out by region so I
>> know a specific table has one srid.
>>
>> For many queries, I may go to that table directly or if I'm doing
>> single geometry processing, really don't care what srid as long as
>> its in utm or whatever - so I can use the full power of GEOS.
>>
>> For my across the board distance checks and so forth, I would want to
>> use geography and I could use a geography index if I put a functional
>> geography index on my geometry correct?  Though that needs some more
> testing.
>>
>>
>> So in short if 90% of my workload involves geometry processing, I
>> will want to keep my data in geometry
>>
>> But the 10% I would want to convert to geography on the fly.
>>
>> Thanks,
>> Regina
>>
>> -----Original Message-----
>> From: postgis-devel-bounces@...
>> [mailto:postgis-devel-bounces@...] On Behalf Of
>> Paul Ramsey
>> Sent: Friday, October 30, 2009 8:34 PM
>> To: PostGIS Development Discussion
>> Subject: Re: [postgis-devel] Geog/Geom Hack
>>
>> I'm not sure I understand why you would ever convert a geometry to a
>> geography as part of a query on a geometry table. I fully expect
>> geography to be used as a storage type, because of the utility of
>> having the correct spherical indexes, which are not available when
>> you're just converting in via a cast. Since there's no functions
>> available on geography that are not already available on geometry,
>> why would you ever do a geometry->geography cast unless you are (a)
>> testing geography or (b) bulk converting a table into geography for
> storage in that type.
>>
>> P.
>>
>>
>>
>> On Fri, Oct 30, 2009 at 5:24 PM, Paragon Corporation <lr@...> wrote:
>>> Paul,
>>> I would rather you didn't for 2 reasons
>>>
>>> 1) I'm lazy and for each of these things we'd have to apply the text
>>> additional function proto hack to prevent from it breaking geometry.
>>> which we will probably end up taking out anyway.
>>>
>>> 2) I don't like the hiddenness of it since it becomes especially
>>> annoying if you have your native in geometry and you are converting
>>> to geography for a special usecase, then you end up with a slower
>>> implementation
>>>
>>> as you would really end up doing accidentally
>>>
>>> geometry -> geography -> geometry ->operation (and why do I want my
>>> calcs done in UTM?)
>>>
>>> Instead of the more efficient
>>>
>>> geometry -> operation
>>>
>>> Thanks,
>>> Regina
>>>
>>> -----Original Message-----
>>> From: postgis-devel-bounces@...
>>> [mailto:postgis-devel-bounces@...] On Behalf Of
>>> Paul Ramsey
>>> Sent: Friday, October 30, 2009 8:16 PM
>>> To: PostGIS Development Discussion
>>> Subject: [postgis-devel] Geog/Geom Hack
>>>
>>> I'm interested to know what the general opinion is of the trick I've
>>> used on
>>> ST_Buffer(geography):
>>>
>>> http://trac.osgeo.org/postgis/browser/trunk/postgis/geography.sql.in.
>>> c
>>> #L541
>>>
>>> I ask because I could apply the same idea to the larger suite of OGC
>>> SFSQL predicates before release. Is half-a-loaf better than no loaf
>>> in
>> this case?
>>> (Note that there will be failure cases for really large geometry,
>>> like a polygon of "Asia" or "Russia" that have polygons over the
>>> dateline.)
>>>
>>> P.
>>> _______________________________________________
>>> postgis-devel mailing list
>>> postgis-devel@...
>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>
>>>
>>>
>>> _______________________________________________
>>> postgis-devel mailing list
>>> postgis-devel@...
>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel@...
>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>
>>
>>
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel@...
>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel@...
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel@...
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>

_______________________________________________
postgis-devel mailing list
postgis-devel@...
http://postgis.refractions.net/mailman/listinfo/postgis-devel


_______________________________________________
postgis-devel mailing list
postgis-devel@...
http://postgis.refractions.net/mailman/listinfo/postgis-devel


_______________________________________________
postgis-devel mailing list
postgis-devel@...
http://postgis.refractions.net/mailman/listinfo/postgis-devel

[Paul Ramsey-3]

I still think I'm right :) Honestly, I've got to a lot of trouble to
make this stuff for newbies, and I don't think "learn how it works" is
the right answer for them. They had that option before, but taking GIS
101 is not an option for these people, they need something that "just
works". It's easier to teach the experienced people the pitfalls than
the inexperienced people the basics.

BTW, I just upgraded distance_sphere and distance_spheroid to be as
powerful (handling point/line/polygon) as the geography variants,
removing excuses for transforming geometries into geographies for
processing purposes.

P.

On Fri, Oct 30, 2009 at 9:15 PM, Paragon Corporation <lr@...> wrote:

> Paul,
> For what its worth, here is another reason why I don't like this idea and I
> think we should at least think about its ramifications more so should put it
> off for consideration until 2.0.
>
> In geometry processing, its common practice to apply a lot of functions in
> succession
>
> process1(process2(process3(geometry/geography)
>
> With your hackish approach -- the unsuspecting novice user will be incurring
> a lot of transformation rounding errors with each process
>
> The advanced user, won't know if this is okay or not -- because they can't
> tell by looking at the function call the hidden transformations going on.
>
> If these did not exist, they would transform once before the processes and
> once after) and incurr much less penalty
>
> But if they both exist, they will treat them as being on equal footing
>
> ST_Buffer(geometry)  and ST_Buffer(geography)
>
>
> So your approach while well-meaning gives a questionable benefit to novices
> and is putting experienced users at a disadvantage.
>
> Thanks,
> Regina
>
> -----Original Message-----
> From: postgis-devel-bounces@...
> [mailto:postgis-devel-bounces@...] On Behalf Of Paragon
> Corporation
> Sent: Friday, October 30, 2009 11:54 PM
> To: 'PostGIS Development Discussion'
> Cc: 'PostGIS Users Discussion'
> Subject: Re: [postgis-devel] Geog/Geom Hack
>
> Paul,
> I suppose we can't just put this decision off till 2.0.  Isn't this a bit of
> scope creep?  I'm not absolutely sure which way is better, but I know the
> cost of rolling back the change is more.
>
> If you are going to do this, how many functions are you planning to do this
> for?
>
> I'm cc'ing the postgis users group too to get more of an opinion on this
> topic.
>
> So the question is it it a good idea to introduce a hack that transforms a
> geography into what we call BestSRID to perform geometry operations on and
> then transform back.  My concern is that this is a silent operation that
> gives the impression that these functions are natively done in spheroid
> space just for the benefit of  catering to less technical users.
>
> http://trac.osgeo.org/postgis/browser/trunk/postgis/geography.sql.in.c#L541
>
> So you can't really tell by looking the penalty
>
> Main examples of this as shown for ST_Buffer
>
> CREATE OR REPLACE FUNCTION _ST_BestSRID(geography, geography)
> 530         RETURNS integer
> 531         AS 'MODULE_PATHNAME','geography_bestsrid'
> 532         LANGUAGE 'C' IMMUTABLE STRICT;
> 533
> 534 -- Availability: 1.5.0
> 535 CREATE OR REPLACE FUNCTION _ST_BestSRID(geography)
> 536         RETURNS integer
> 537         AS 'SELECT _ST_BestSRID($1,$1)'
> 538         LANGUAGE 'SQL' IMMUTABLE STRICT;
> 539
> 540 -- Availability: 1.5.0
> 541 CREATE OR REPLACE FUNCTION ST_Buffer(geography, float8)
> 542         RETURNS geography
> 543         AS 'SELECT
> geography(ST_Transform(ST_Buffer(ST_Transform(geometry($1),
> _ST_BestSRID($1)), $2), 4326))'
> 544         LANGUAGE 'SQL' IMMUTABLE STRICT;
> 545
>
>
>
> Thanks,
> Regina
>
> -----Original Message-----
> From: postgis-devel-bounces@...
> [mailto:postgis-devel-bounces@...] On Behalf Of Paul
> Ramsey
> Sent: Friday, October 30, 2009 11:07 PM
> To: PostGIS Development Discussion
> Subject: Re: [postgis-devel] Geog/Geom Hack
>
> We're going to have to agree to disagree on this one, Regina. Catering to
> the less technical users is what this exercise is all about, to my mind, and
> that includes allowing easy flipping into geometry for calculations that
> aren't supported in geography yet. Oracle does this too.
>
> What do other folks think?
>
> P.
>
> On Fri, Oct 30, 2009 at 7:06 PM, Paragon Corporation <lr@...> wrote:
>> Paul,
>> Hmm when I am comparing distance of two geometries in different
>> spatial refs which I do a lot.
>>
>> I still don't like the hack even if you disregard the above or if you
>> must hack -- don't give it the same name as the non-hacked functions.
>>
>> the whole idea of picking BestSRID for a person to cater to less
>> technical users I find extremely annoying as I can think of 20
>> "BestSRID" depending on what I am doing.  If they get to that level of
>> sophistication, I would rather have them think a little more  and
>> understand the implications of those decisions.
>>
>> We must learn to crawl before we can learn to walk,because walking
>> without understanding will just get you into trouble in the long run.
>>
>>
>>  Thanks,
>> Regina
>>
>> -----Original Message-----
>> From: postgis-devel-bounces@...
>> [mailto:postgis-devel-bounces@...] On Behalf Of
>> Paul Ramsey
>> Sent: Friday, October 30, 2009 9:47 PM
>> To: PostGIS Development Discussion
>> Subject: Re: [postgis-devel] Geog/Geom Hack
>>
>> You *can*, but I strongly doubt you *will*. Because there's nothing in
>> geography that isn't already in geometry. So you as a primary geometry
>> user are going to have no working need to cast things to geography.
>>
>> On the other hand, the very first question from users of geography
>> will be "how can I access <geometry function N>?" So having a
>> relatively full set of functions already available in geography makes
>> sense to me, even if they are hacked in with a planar trick.
>>
>> P.
>>
>> On Fri, Oct 30, 2009 at 5:46 PM, Paragon Corporation <lr@...> wrote:
>>> Paul,
>>> I can put a functional geography index on can't I and take advantage
>>> of geography index bindings?
>>>
>>> Lets say I have a large network of tables broken out by region so I
>>> know a specific table has one srid.
>>>
>>> For many queries, I may go to that table directly or if I'm doing
>>> single geometry processing, really don't care what srid as long as
>>> its in utm or whatever - so I can use the full power of GEOS.
>>>
>>> For my across the board distance checks and so forth, I would want to
>>> use geography and I could use a geography index if I put a functional
>>> geography index on my geometry correct?  Though that needs some more
>> testing.
>>>
>>>
>>> So in short if 90% of my workload involves geometry processing, I
>>> will want to keep my data in geometry
>>>
>>> But the 10% I would want to convert to geography on the fly.
>>>
>>> Thanks,
>>> Regina
>>>
>>> -----Original Message-----
>>> From: postgis-devel-bounces@...
>>> [mailto:postgis-devel-bounces@...] On Behalf Of
>>> Paul Ramsey
>>> Sent: Friday, October 30, 2009 8:34 PM
>>> To: PostGIS Development Discussion
>>> Subject: Re: [postgis-devel] Geog/Geom Hack
>>>
>>> I'm not sure I understand why you would ever convert a geometry to a
>>> geography as part of a query on a geometry table. I fully expect
>>> geography to be used as a storage type, because of the utility of
>>> having the correct spherical indexes, which are not available when
>>> you're just converting in via a cast. Since there's no functions
>>> available on geography that are not already available on geometry,
>>> why would you ever do a geometry->geography cast unless you are (a)
>>> testing geography or (b) bulk converting a table into geography for
>> storage in that type.
>>>
>>> P.
>>>
>>>
>>>
>>> On Fri, Oct 30, 2009 at 5:24 PM, Paragon Corporation <lr@...> wrote:
>>>> Paul,
>>>> I would rather you didn't for 2 reasons
>>>>
>>>> 1) I'm lazy and for each of these things we'd have to apply the text
>>>> additional function proto hack to prevent from it breaking geometry.
>>>> which we will probably end up taking out anyway.
>>>>
>>>> 2) I don't like the hiddenness of it since it becomes especially
>>>> annoying if you have your native in geometry and you are converting
>>>> to geography for a special usecase, then you end up with a slower
>>>> implementation
>>>>
>>>> as you would really end up doing accidentally
>>>>
>>>> geometry -> geography -> geometry ->operation (and why do I want my
>>>> calcs done in UTM?)
>>>>
>>>> Instead of the more efficient
>>>>
>>>> geometry -> operation
>>>>
>>>> Thanks,
>>>> Regina
>>>>
>>>> -----Original Message-----
>>>> From: postgis-devel-bounces@...
>>>> [mailto:postgis-devel-bounces@...] On Behalf Of
>>>> Paul Ramsey
>>>> Sent: Friday, October 30, 2009 8:16 PM
>>>> To: PostGIS Development Discussion
>>>> Subject: [postgis-devel] Geog/Geom Hack
>>>>
>>>> I'm interested to know what the general opinion is of the trick I've
>>>> used on
>>>> ST_Buffer(geography):
>>>>
>>>> http://trac.osgeo.org/postgis/browser/trunk/postgis/geography.sql.in.
>>>> c
>>>> #L541
>>>>
>>>> I ask because I could apply the same idea to the larger suite of OGC
>>>> SFSQL predicates before release. Is half-a-loaf better than no loaf
>>>> in
>>> this case?
>>>> (Note that there will be failure cases for really large geometry,
>>>> like a polygon of "Asia" or "Russia" that have polygons over the
>>>> dateline.)
>>>>
>>>> P.
>>>> _______________________________________________
>>>> postgis-devel mailing list
>>>> postgis-devel@...
>>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> postgis-devel mailing list
>>>> postgis-devel@...
>>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>>
>>> _______________________________________________
>>> postgis-devel mailing list
>>> postgis-devel@...
>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>
>>>
>>>
>>> _______________________________________________
>>> postgis-devel mailing list
>>> postgis-devel@...
>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel@...
>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>
>>
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel@...
>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel@...
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel@...
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel@...
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>

_______________________________________________
postgis-devel mailing list
postgis-devel@...
http://postgis.refractions.net/mailman/listinfo/postgis-devel

[Nicklas Avén]

Hallo

 

I can see the points from both of you. I think the most important argument from you Regina is that it is not transparent enough. A skillfull user trying postgis might be disapointed when realizing that the nested functions caused an unnecessary big rounding-error.

But if it is obvious that it is a "special" function at least for the experienced user knowing about common function-names I don't think it is a big problem and might work as an easy shortcut at least during the process of learning.

 

As I understand it this could be a solution for using many functions against geography so, why not  note it in the function name like:

ST_tBuffer for transformed buffer. Then when time is to introduse a "real" variant of the function they can coexist and it will not change the bahavior inside an application without someone consciously changes the function name and remove the t.

 

the t would be independent of geography-geometry in semantics and just indicate that it is a lower-precision variant. I fit was commonly used it would work as a warning to experienced users.

 

I have a similar question about st_max_distance. The function gets very much more effective when ran together with convexhull. I saw the trick in ST_MinimumBoundingCircle and id makes a big difference to do :

st_max_distance(st_convexhull(the_geom)) instead of just st_max_distance(the_geom).

The question is: Should that be put in the sql-function?

My opinion now is that we just tell about it in the documentation and aims at doing that trick internally in C in the future. Maybe together with moving the whole convexhull to postgis-native from geos. It didn't look that impossible fromthe JTS-code.

 

/Nicklas

 

2009-10-31 Paul Ramsey wrote:

I still think I'm right :) Honestly, I've got to a lot of trouble to
>make this stuff for newbies, and I don't think "learn how it works" is
>the right answer for them. They had that option before, but taking GIS
>101 is not an option for these people, they need something that "just
>works". It's easier to teach the experienced people the pitfalls than
>the inexperienced people the basics.
>
>BTW, I just upgraded distance_sphere and distance_spheroid to be as
>powerful (handling point/line/polygon) as the geography variants,
>removing excuses for transforming geometries into geographies for
>processing purposes.
>
>P.
>
>On Fri, Oct 30, 2009 at 9:15 PM, Paragon Corporation wrote:
>> Paul,
>> For what its worth, here is another reason why I don't like this idea and I
>> think we should at least think about its ramifications more so should put it
>> off for consideration until 2.0.
>>
>> In geometry processing, its common practice to apply a lot of functions in
>> succession
>>
>> process1(process2(process3(geometry/geography)
>>
>> With your hackish approach -- the unsuspecting novice user will be incurring
>> a lot of transformation rounding errors with each process
>>
>> The advanced user, won't know if this is okay or not -- because they can't
>> tell by looking at the function call the hidden transformations going on.
>>
>> If these did not exist, they would transform once before the processes and
>> once after) and incurr much less penalty
>>
>> But if they both exist, they will treat them as being on equal footing
>>
>> ST_Buffer(geometry)  and ST_Buffer(geography)
>>
>>
>> So your approach while well-meaning gives a questionable benefit to novices
>> and is putting experienced users at a disadvantage.
>>
>> Thanks,
>> Regina
>>
>> -----Original Message-----
>> From: postgis-devel-bounces@...
>> [mailto:postgis-devel-bounces@...] On Behalf Of Paragon
>> Corporation
>> Sent: Friday, October 30, 2009 11:54 PM
>> To: 'PostGIS Development Discussion'
>> Cc: 'PostGIS Users Discussion'
>> Subject: Re: [postgis-devel] Geog/Geom Hack
>>
>> Paul,
>> I suppose we can't just put this decision off till 2.0.  Isn't this a bit of
>> scope creep?  I'm not absolutely sure which way is better, but I know the
>> cost of rolling back the change is more.
>>
>> If you are going to do this, how many functions are you planning to do this
>> for?
>>
>> I'm cc'ing the postgis users group too to get more of an opinion on this
>> topic.
>>
>> So the question is it it a good idea to introduce a hack that transforms a
>> geography into what we call BestSRID to perform geometry operations on and
>> then transform back.  My concern is that this is a silent operation that
>> gives the impression that these functions are natively done in spheroid
>> space just for the benefit of  catering to less technical users.
>>
>> http://trac.osgeo.org/postgis/browser/trunk/postgis/geography.sql.in.c#L541
>>
>> So you can't really tell by looking the penalty
>>
>> Main examples of this as shown for ST_Buffer
>>
>> CREATE OR REPLACE FUNCTION _ST_BestSRID(geography, geography)
>> 530         RETURNS integer
>> 531         AS 'MODULE_PATHNAME','geography_bestsrid'
>> 532         LANGUAGE 'C' IMMUTABLE STRICT;
>> 533
>> 534 -- Availability: 1.5.0
>> 535 CREATE OR REPLACE FUNCTION _ST_BestSRID(geography)
>> 536         RETURNS integer
>> 537         AS 'SELECT _ST_BestSRID($1,$1)'
>> 538         LANGUAGE 'SQL' IMMUTABLE STRICT;
>> 539
>> 540 -- Availability: 1.5.0
>> 541 CREATE OR REPLACE FUNCTION ST_Buffer(geography, float8)
>> 542         RETURNS geography
>> 543         AS 'SELECT
>> geography(ST_Transform(ST_Buffer(ST_Transform(geometry($1),
>> _ST_BestSRID($1)), $2), 4326))'
>> 544         LANGUAGE 'SQL' IMMUTABLE STRICT;
>> 545
>>
>>
>>
>> Thanks,
>> Regina
>>
>> -----Original Message-----
>> From: postgis-devel-bounces@...
>> [mailto:postgis-devel-bounces@...] On Behalf Of Paul
>> Ramsey
>> Sent: Friday, October 30, 2009 11:07 PM
>> To: PostGIS Development Discussion
>> Subject: Re: [postgis-devel] Geog/Geom Hack
>>
>> We're going to have to agree to disagree on this one, Regina. Catering to
>> the less technical users is what this exercise is all about, to my mind, and
>> that includes allowing easy flipping into geometry for calculations that
>> aren't supported in geography yet. Oracle does this too.
>>
>> What do other folks think?
>>
>> P.
>>
>> On Fri, Oct 30, 2009 at 7:06 PM, Paragon Corporation wrote:
>>> Paul,
>>> Hmm when I am comparing distance of two geometries in different
>>> spatial refs which I do a lot.
>>>
>>> I still don't like the hack even if you disregard the above or if you
>>> must hack -- don't give it the same name as the non-hacked functions.
>>>
>>> the whole idea of picking BestSRID for a person to cater to less
>>> technical users I find extremely annoying as I can think of 20
>>> "BestSRID" depending on what I am doing.  If they get to that level of
>>> sophistication, I would rather have them think a little more  and
>>> understand the implications of those decisions.
>>>
>>> We must learn to crawl before we can learn to walk,because walking
>>> without understanding will just get you into trouble in the long run.
>>>
>>>
>>>  Thanks,
>>> Regina
>>>
>>> -----Original Message-----
>>> From: postgis-devel-bounces@...
>>> [mailto:postgis-devel-bounces@...] On Behalf Of
>>> Paul Ramsey
>>> Sent: Friday, October 30, 2009 9:47 PM
>>> To: PostGIS Development Discussion
>>> Subject: Re: [postgis-devel] Geog/Geom Hack
>>>
>>> You *can*, but I strongly doubt you *will*. Because there's nothing in
>>> geography that isn't already in geometry. So you as a primary geometry
>>> user are going to have no working need to cast things to geography.
>>>
>>> On the other hand, the very first question from users of geography
>>> will be "how can I access ?" So having a
>>> relatively full set of functions already available in geography makes
>>> sense to me, even if they are hacked in with a planar trick.
>>>
>>> P.
>>>
>>> On Fri, Oct 30, 2009 at 5:46 PM, Paragon Corporation wrote:
>>>> Paul,
>>>> I can put a functional geography index on can't I and take advantage
>>>> of geography index bindings?
>>>>
>>>> Lets say I have a large network of tables broken out by region so I
>>>> know a specific table has one srid.
>>>>
>>>> For many queries, I may go to that table directly or if I'm doing
>>>> single geometry processing, really don't care what srid as long as
>>>> its in utm or whatever - so I can use the full power of GEOS.
>>>>
>>>> For my across the board distance checks and so forth, I would want to
>>>> use geography and I could use a geography index if I put a functional
>>>> geography index on my geometry correct?  Though that needs some more
>>> testing.
>>>>
>>>>
>>>> So in short if 90% of my workload involves geometry processing, I
>>>> will want to keep my data in geometry
>>>>
>>>> But the 10% I would want to convert to geography on the fly.
>>>>
>>>> Thanks,
>>>> Regina
>>>>
>>>> -----Original Message-----
>>>> From: postgis-devel-bounces@...
>>>> [mailto:postgis-devel-bounces@...] On Behalf Of
>>>> Paul Ramsey
>>>> Sent: Friday, October 30, 2009 8:34 PM
>>>> To: PostGIS Development Discussion
>>>> Subject: Re: [postgis-devel] Geog/Geom Hack
>>>>
>>>> I'm not sure I understand why you would ever convert a geometry to a
>>>> geography as part of a query on a geometry table. I fully expect
>>>> geography to be used as a storage type, because of the utility of
>>>> having the correct spherical indexes, which are not available when
>>>> you're just converting in via a cast. Since there's no functions
>>>> available on geography that are not already available on geometry,
>>>> why would you ever do a geometry->geography cast unless you are (a)
>>>> testing geography or (b) bulk converting a table into geography for
>>> storage in that type.
>>>>
>>>> P.
>>>>
>>>>
>>>>
>>>> On Fri, Oct 30, 2009 at 5:24 PM, Paragon Corporation wrote:
>>>>> Paul,
>>>>> I would rather you didn't for 2 reasons
>>>>>
>>>>> 1) I'm lazy and for each of these things we'd have to apply the text
>>>>> additional function proto hack to prevent from it breaking geometry.
>>>>> which we will probably end up taking out anyway.
>>>>>
>>>>> 2) I don't like the hiddenness of it since it becomes especially
>>>>> annoying if you have your native in geometry and you are converting
>>>>> to geography for a special usecase, then you end up with a slower
>>>>> implementation
>>>>>
>>>>> as you would really end up doing accidentally
>>>>>
>>>>> geometry -> geography -> geometry ->operation (and why do I want my
>>>>> calcs done in UTM?)
>>>>>
>>>>> Instead of the more efficient
>>>>>
>>>>> geometry -> operation
>>>>>
>>>>> Thanks,
>>>>> Regina
>>>>>
>>>>> -----Original Message-----
>>>>> From: postgis-devel-bounces@...
>>>>> [mailto:postgis-devel-bounces@...] On Behalf Of
>>>>> Paul Ramsey
>>>>> Sent: Friday, October 30, 2009 8:16 PM
>>>>> To: PostGIS Development Discussion
>>>>> Subject: [postgis-devel] Geog/Geom Hack
>>>>>
>>>>> I'm interested to know what the general opinion is of the trick I've
>>>>> used on
>>>>> ST_Buffer(geography):
>>>>>
>>>>> http://trac.osgeo.org/postgis/browser/trunk/postgis/geography.sql.in.
>>>>> c
>>>>> #L541
>>>>>
>>>>> I ask because I could apply the same idea to the larger suite of OGC
>>>>> SFSQL predicates before release. Is half-a-loaf better than no loaf
>>>>> in
>>>> this case?
>>>>> (Note that there will be failure cases for really large geometry,
>>>>> like a polygon of "Asia" or "Russia" that have polygons over the
>>>>> dateline.)
>>>>>
>>>>> P.
>>>>> _______________________________________________
>>>>> postgis-devel mailing list
>>>>> postgis-devel@...
>>>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> postgis-devel mailing list
>>>>> postgis-devel@...
>>>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>>>
>>>> _______________________________________________
>>>> postgis-devel mailing list
>>>> postgis-devel@...
>>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> postgis-devel mailing list
>>>> postgis-devel@...
>>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>>
>>> _______________________________________________
>>> postgis-devel mailing list
>>> postgis-devel@...
>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>
>>>
>>> _______________________________________________
>>> postgis-devel mailing list
>>> postgis-devel@...
>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel@...
>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>
>>
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel@...
>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>
>>
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel@...
>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>
>_______________________________________________
>postgis-devel mailing list
>postgis-devel@...
>http://postgis.refractions.net/mailman/listinfo/postgis-devel
>
>

_______________________________________________
postgis-devel mailing list
postgis-devel@...
http://postgis.refractions.net/mailman/listinfo/postgis-devel

[Paragon Corporation-2]

Nicklas and Paul,

 

Yap that's the main point.  To add

 

I'm not really in disagreement with Paul.  I see his point too.  I'm just prodding him to think about all his use cases a little more because I don't feel he has.

 

My feelings to sum up

1) We have not thought about the complete ramifications of this hack and I'm really concerned about the novice that transitions to an expert rather than just getting them hooked on PostGIS.  Perhaps I'm being overly silly with that and even said, Paul's approach might be an easier to transition solution.

 

2) My concern is the penalty of putting it in and having to take it out later might be very great (both from a code, testing,  as well as a mindset perspective).  I just feel it needs more thought and testing and really if we want to make our December deadline, I don't want it rushed in so lightly. 

 

Unless of course Paul -- you want to wait till January or February to release 1.5?

 

Now the ST_Max_Distance is a separate issue.  I would put in the ST_ConvexHull hack in place.  The reason being is that it just improves performance any way I can think you slice it and an experienced user would do exactly the same thing always and when you finally incorporate it into the core function,  there is no change in existing code just a speed improvement.  So to me its basically our ST_DWithin hack -- a very tried and trued obvious answer.  Its an implementation detail with no clear leaky effects.

 

With that said, there are some clear functions in geometry that are safe to put a geography cover over.  Those ones where there is clearly only one answer and don't involve transformation.

 

like ST_X, ST_Y etc.  That don't require transformation so no screw up in data.  Also observe that even the geometry(geography .... in these there is no penalty becuase the geometry/geography isn't changing so the planner can cache the geometry to geography conversion.  The ST_Transformation ones however, the geometry/geography is changing slightly at each step since ST_Tranformation is a lossy operation so you are not only incurring overhead (because these answers can't be cached), but also adding in extra errors .

 

To me this is a bleeding abstraction and that is the main reason I don't like it.

 

So getting back to you Paul,

 

What functions exactly are you planning to put a veil over?  ST_Buffer well that one is used so much and is not as exact anyway that I suppose I can grudgingly accept that as okay.

 

Thanks,

Regina

 

---

From: postgis-devel-bounces@... [mailto:postgis-devel-bounces@...] On Behalf Of nicklas.aven@...
Sent: Saturday, October 31, 2009 10:04 AM
To: PostGIS Development Discussion
Subject: Re: [postgis-devel] Geog/Geom Hack

Hallo

 

I can see the points from both of you. I think the most important argument from you Regina is that it is not transparent enough. A skillfull user trying postgis might be disapointed when realizing that the nested functions caused an unnecessary big rounding-error.

But if it is obvious that it is a "special" function at least for the experienced user knowing about common function-names I don't think it is a big problem and might work as an easy shortcut at least during the process of learning.

 

As I understand it this could be a solution for using many functions against geography so, why not  note it in the function name like:

ST_tBuffer for transformed buffer. Then when time is to introduse a "real" variant of the function they can coexist and it will not change the bahavior inside an application without someone consciously changes the function name and remove the t.

 

the t would be independent of geography-geometry in semantics and just indicate that it is a lower-precision variant. I fit was commonly used it would work as a warning to experienced users.

 

I have a similar question about st_max_distance. The function gets very much more effective when ran together with convexhull. I saw the trick in ST_MinimumBoundingCircle and id makes a big difference to do :

st_max_distance(st_convexhull(the_geom)) instead of just st_max_distance(the_geom).

The question is: Should that be put in the sql-function?

My opinion now is that we just tell about it in the documentation and aims at doing that trick internally in C in the future. Maybe together with moving the whole convexhull to postgis-native from geos. It didn't look that impossible fromthe JTS-code.

 

/Nicklas

 

2009-10-31 Paul Ramsey wrote:

I still think I'm right :) Honestly, I've got to a lot of trouble to

>make this stuff for newbies, and I don't think "learn how it works" is
>the right answer for them. They had that option before, but taking GIS
>101 is not an option for these people, they need something that "just
>works". It's easier to teach the experienced people the pitfalls than
>the inexperienced people the basics.
>
>BTW, I just upgraded distance_sphere and distance_spheroid to be as
>powerful (handling point/line/polygon) as the geography variants,
>removing excuses for transforming geometries into geographies for
>processing purposes.
>
>P.
>
>On Fri, Oct 30, 2009 at 9:15 PM, Paragon Corporation wrote:
>> Paul,
>> For what its worth, here is another reason why I don't like this idea and I
>> think we should at least think about its ramifications more so should put it
>> off for consideration until 2.0.
>>
>> In geometry processing, its common practice to apply a lot of functions in
>> succession
>>
>> process1(process2(process3(geometry/geography)
>>
>> With your hackish approach -- the unsuspecting novice user will be incurring
>> a lot of transformation rounding errors with each process
>>
>> The advanced user, won't know if this is okay or not -- because they can't
>> tell by looking at the function call the hidden transformations going on.
>>
>> If these did not exist, they would transform once before the processes and
>> once after) and incurr much less penalty
>>
>> But if they both exist, they will treat them as being on equal footing
>>
>> ST_Buffer(geometry)  and ST_Buffer(geography)
>>
>>
>> So your approach while well-meaning gives a questionable benefit to novices
>> and is putting experienced users at a disadvantage.
>>
>> Thanks,
>> Regina
>>
>> -----Original Message-----
>> From: postgis-devel-bounces@...
>> [mailto:postgis-devel-bounces@...] On Behalf Of Paragon
>> Corporation
>> Sent: Friday, October 30, 2009 11:54 PM
>> To: 'PostGIS Development Discussion'
>> Cc: 'PostGIS Users Discussion'
>> Subject: Re: [postgis-devel] Geog/Geom Hack
>>
>> Paul,
>> I suppose we can't just put this decision off till 2.0.  Isn't this a bit of
>> scope creep?  I'm not absolutely sure which way is better, but I know the
>> cost of rolling back the change is more.
>>
>> If you are going to do this, how many functions are you planning to do this
>> for?
>>
>> I'm cc'ing the postgis users group too to get more of an opinion on this
>> topic.
>>
>> So the question is it it a good idea to introduce a hack that transforms a
>> geography into what we call BestSRID to perform geometry operations on and
>> then transform back.  My concern is that this is a silent operation that
>> gives the impression that these functions are natively done in spheroid
>> space just for the benefit of  catering to less technical users.
>>
>> http://trac.osgeo.org/postgis/browser/trunk/postgis/geography.sql.in.c#L541
>>
>> So you can't really tell by looking the penalty
>>
>> Main examples of this as shown for ST_Buffer
>>
>> CREATE OR REPLACE FUNCTION _ST_BestSRID(geography, geography)
>> 530         RETURNS integer
>> 531         AS 'MODULE_PATHNAME','geography_bestsrid'
>> 532         LANGUAGE 'C' IMMUTABLE STRICT;
>> 533
>> 534 -- Availability: 1.5.0
>> 535 CREATE OR REPLACE FUNCTION _ST_BestSRID(geography)
>> 536         RETURNS integer
>> 537         AS 'SELECT _ST_BestSRID($1,$1)'
>> 538         LANGUAGE 'SQL' IMMUTABLE STRICT;
>> 539
>> 540 -- Availability: 1.5.0
>> 541 CREATE OR REPLACE FUNCTION ST_Buffer(geography, float8)
>> 542         RETURNS geography
>> 543         AS 'SELECT
>> geography(ST_Transform(ST_Buffer(ST_Transform(geometry($1),
>> _ST_BestSRID($1)), $2), 4326))'
>> 544         LANGUAGE 'SQL' IMMUTABLE STRICT;
>> 545
>>
>>
>>
>> Thanks,
>> Regina
>>
>> -----Original Message-----
>> From: postgis-devel-bounces@...
>> [mailto:postgis-devel-bounces@...] On Behalf Of Paul
>> Ramsey
>> Sent: Friday, October 30, 2009 11:07 PM
>> To: PostGIS Development Discussion
>> Subject: Re: [postgis-devel] Geog/Geom Hack
>>
>> We're going to have to agree to disagree on this one, Regina. Catering to
>> the less technical users is what this exercise is all about, to my mind, and
>> that includes allowing easy flipping into geometry for calculations that
>> aren't supported in geography yet. Oracle does this too.
>>
>> What do other folks think?
>>
>> P.
>>
>> On Fri, Oct 30, 2009 at 7:06 PM, Paragon Corporation wrote:
>>> Paul,
>>> Hmm when I am comparing distance of two geometries in different
>>> spatial refs which I do a lot.
>>>
>>> I still don't like the hack even if you disregard the above or if you
>>> must hack -- don't give it the same name as the non-hacked functions.
>>>
>>> the whole idea of picking BestSRID for a person to cater to less
>>> technical users I find extremely annoying as I can think of 20
>>> "BestSRID" depending on what I am doing.  If they get to that level of
>>> sophistication, I would rather have them think a little more  and
>>> understand the implications of those decisions.
>>>
>>> We must learn to crawl before we can learn to walk,because walking
>>> without understanding will just get you into trouble in the long run.
>>>
>>>
>>>  Thanks,
>>> Regina
>>>
>>> -----Original Message-----
>>> From: postgis-devel-bounces@...
>>> [mailto:postgis-devel-bounces@...] On Behalf Of
>>> Paul Ramsey
>>> Sent: Friday, October 30, 2009 9:47 PM
>>> To: PostGIS Development Discussion
>>> Subject: Re: [postgis-devel] Geog/Geom Hack
>>>
>>> You *can*, but I strongly doubt you *will*. Because there's nothing in
>>> geography that isn't already in geometry. So you as a primary geometry
>>> user are going to have no working need to cast things to geography.
>>>
>>> On the other hand, the very first question from users of geography
>>> will be "how can I access ?" So having a
>>> relatively full set of functions already available in geography makes
>>> sense to me, even if they are hacked in with a planar trick.
>>>
>>> P.
>>>
>>> On Fri, Oct 30, 2009 at 5:46 PM, Paragon Corporation wrote:
>>>> Paul,
>>>> I can put a functional geography index on can't I and take advantage
>>>> of geography index bindings?
>>>>
>>>> Lets say I have a large network of tables broken out by region so I
>>>> know a specific table has one srid.
>>>>
>>>> For many queries, I may go to that table directly or if I'm doing
>>>> single geometry processing, really don't care what srid as long as
>>>> its in utm or whatever - so I can use the full power of GEOS.
>>>>
>>>> For my across the board distance checks and so forth, I would want to
>>>> use geography and I could use a geography index if I put a functional
>>>> geography index on my geometry correct?  Though that needs some more
>>> testing.
>>>>
>>>>
>>>> So in short if 90% of my workload involves geometry processing, I
>>>> will want to keep my data in geometry
>>>>
>>>> But the 10% I would want to convert to geography on the fly.
>>>>
>>>> Thanks,
>>>> Regina
>>>>
>>>> -----Original Message-----
>>>> From: postgis-devel-bounces@...
>>>> [mailto:postgis-devel-bounces@...] On Behalf Of
>>>> Paul Ramsey
>>>> Sent: Friday, October 30, 2009 8:34 PM
>>>> To: PostGIS Development Discussion
>>>> Subject: Re: [postgis-devel] Geog/Geom Hack
>>>>
>>>> I'm not sure I understand why you would ever convert a geometry to a
>>>> geography as part of a query on a geometry table. I fully expect
>>>> geography to be used as a storage type, because of the utility of
>>>> having the correct spherical indexes, which are not available when
>>>> you're just converting in via a cast. Since there's no functions
>>>> available on geography that are not already available on geometry,
>>>> why would you ever do a geometry->geography cast unless you are (a)
>>>> testing geography or (b) bulk converting a table into geography for
>>> storage in that type.
>>>>
>>>> P.
>>>>
>>>>
>>>>
>>>> On Fri, Oct 30, 2009 at 5:24 PM, Paragon Corporation wrote:
>>>>> Paul,
>>>>> I would rather you didn't for 2 reasons
>>>>>
>>>>> 1) I'm lazy and for each of these things we'd have to apply the text
>>>>> additional function proto hack to prevent from it breaking geometry.
>>>>> which we will probably end up taking out anyway.
>>>>>
>>>>> 2) I don't like the hiddenness of it since it becomes especially
>>>>> annoying if you have your native in geometry and you are converting
>>>>> to geography for a special usecase, then you end up with a slower
>>>>> implementation
>>>>>
>>>>> as you would really end up doing accidentally
>>>>>
>>>>> geometry -> geography -> geometry ->operation (and why do I want my
>>>>> calcs done in UTM?)
>>>>>
>>>>> Instead of the more efficient
>>>>>
>>>>> geometry -> operation
>>>>>
>>>>> Thanks,
>>>>> Regina
>>>>>
>>>>> -----Original Message-----
>>>>> From: postgis-devel-bounces@...
>>>>> [mailto:postgis-devel-bounces@...] On Behalf Of
>>>>> Paul Ramsey
>>>>> Sent: Friday, October 30, 2009 8:16 PM
>>>>> To: PostGIS Development Discussion
>>>>> Subject: [postgis-devel] Geog/Geom Hack
>>>>>
>>>>> I'm interested to know what the general opinion is of the trick I've
>>>>> used on
>>>>> ST_Buffer(geography):
>>>>>
>>>>> http://trac.osgeo.org/postgis/browser/trunk/postgis/geography.sql.in.
>>>>> c
>>>>> #L541
>>>>>
>>>>> I ask because I could apply the same idea to the larger suite of OGC
>>>>> SFSQL predicates before release. Is half-a-loaf better than no loaf
>>>>> in
>>>> this case?
>>>>> (Note that there will be failure cases for really large geometry,
>>>>> like a polygon of "Asia" or "Russia" that have polygons over the
>>>>> dateline.)
>>>>>
>>>>> P.
>>>>> _______________________________________________
>>>>> postgis-devel mailing list
>>>>> postgis-devel@...
>>>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> postgis-devel mailing list
>>>>> postgis-devel@...
>>>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>>>
>>>> _______________________________________________
>>>> postgis-devel mailing list
>>>> postgis-devel@...
>>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> postgis-devel mailing list
>>>> postgis-devel@...
>>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>>
>>> _______________________________________________
>>> postgis-devel mailing list
>>> postgis-devel@...
>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>
>>>
>>> _______________________________________________
>>> postgis-devel mailing list
>>> postgis-devel@...
>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel@...
>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>
>>
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel@...
>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>
>>
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel@...
>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>
>_______________________________________________
>postgis-devel mailing list
>postgis-devel@...
>http://postgis.refractions.net/mailman/listinfo/postgis-devel
>
>

_______________________________________________
postgis-devel mailing list
postgis-devel@...
http://postgis.refractions.net/mailman/listinfo/postgis-devel

[Paragon Corporation-2]

Paul,

But I actually don't care about those functions as much as I care about
ST_DWithin so I'm still going to convert to geography thank you very much :)

Thanks,
Regina

-----Original Message-----
From: postgis-devel-bounces@...
[mailto:postgis-devel-bounces@...] On Behalf Of Paul
Ramsey
Sent: Saturday, October 31, 2009 12:56 AM
To: PostGIS Development Discussion
Subject: Re: [postgis-devel] Geog/Geom Hack

I still think I'm right :) Honestly, I've got to a lot of trouble to make
this stuff for newbies, and I don't think "learn how it works" is the right
answer for them. They had that option before, but taking GIS
101 is not an option for these people, they need something that "just
works". It's easier to teach the experienced people the pitfalls than the
inexperienced people the basics.

BTW, I just upgraded distance_sphere and distance_spheroid to be as powerful
(handling point/line/polygon) as the geography variants, removing excuses
for transforming geometries into geographies for processing purposes.

P.

On Fri, Oct 30, 2009 at 9:15 PM, Paragon Corporation <lr@...> wrote:

> Paul,
> For what its worth, here is another reason why I don't like this idea
> and I think we should at least think about its ramifications more so
> should put it off for consideration until 2.0.
>
> In geometry processing, its common practice to apply a lot of
> functions in succession
>
> process1(process2(process3(geometry/geography)
>
> With your hackish approach -- the unsuspecting novice user will be
> incurring a lot of transformation rounding errors with each process
>
> The advanced user, won't know if this is okay or not -- because they
> can't tell by looking at the function call the hidden transformations

going on.

>
> If these did not exist, they would transform once before the processes
> and once after) and incurr much less penalty
>
> But if they both exist, they will treat them as being on equal footing
>
> ST_Buffer(geometry)  and ST_Buffer(geography)
>
>
> So your approach while well-meaning gives a questionable benefit to
> novices and is putting experienced users at a disadvantage.
>
> Thanks,
> Regina
>
> -----Original Message-----
> From: postgis-devel-bounces@...
> [mailto:postgis-devel-bounces@...] On Behalf Of
> Paragon Corporation
> Sent: Friday, October 30, 2009 11:54 PM
> To: 'PostGIS Development Discussion'
> Cc: 'PostGIS Users Discussion'
> Subject: Re: [postgis-devel] Geog/Geom Hack
>
> Paul,
> I suppose we can't just put this decision off till 2.0.  Isn't this a
> bit of scope creep?  I'm not absolutely sure which way is better, but
> I know the cost of rolling back the change is more.
>
> If you are going to do this, how many functions are you planning to do
> this for?
>
> I'm cc'ing the postgis users group too to get more of an opinion on
> this topic.
>
> So the question is it it a good idea to introduce a hack that
> transforms a geography into what we call BestSRID to perform geometry
> operations on and then transform back.  My concern is that this is a
> silent operation that gives the impression that these functions are
> natively done in spheroid space just for the benefit of  catering to less

technical users.

>
> http://trac.osgeo.org/postgis/browser/trunk/postgis/geography.sql.in.c
> #L541
>
> So you can't really tell by looking the penalty
>
> Main examples of this as shown for ST_Buffer
>
> CREATE OR REPLACE FUNCTION _ST_BestSRID(geography, geography) 530        
> RETURNS integer
> 531         AS 'MODULE_PATHNAME','geography_bestsrid'
> 532         LANGUAGE 'C' IMMUTABLE STRICT;
> 533
> 534 -- Availability: 1.5.0
> 535 CREATE OR REPLACE FUNCTION _ST_BestSRID(geography)
> 536         RETURNS integer
> 537         AS 'SELECT _ST_BestSRID($1,$1)'
> 538         LANGUAGE 'SQL' IMMUTABLE STRICT;
> 539
> 540 -- Availability: 1.5.0
> 541 CREATE OR REPLACE FUNCTION ST_Buffer(geography, float8)
> 542         RETURNS geography
> 543         AS 'SELECT
> geography(ST_Transform(ST_Buffer(ST_Transform(geometry($1),
> _ST_BestSRID($1)), $2), 4326))'
> 544         LANGUAGE 'SQL' IMMUTABLE STRICT;
> 545
>
>
>
> Thanks,
> Regina
>
> -----Original Message-----
> From: postgis-devel-bounces@...
> [mailto:postgis-devel-bounces@...] On Behalf Of
> Paul Ramsey
> Sent: Friday, October 30, 2009 11:07 PM
> To: PostGIS Development Discussion
> Subject: Re: [postgis-devel] Geog/Geom Hack
>
> We're going to have to agree to disagree on this one, Regina. Catering
> to the less technical users is what this exercise is all about, to my
> mind, and that includes allowing easy flipping into geometry for
> calculations that aren't supported in geography yet. Oracle does this too.
>
> What do other folks think?
>
> P.
>
> On Fri, Oct 30, 2009 at 7:06 PM, Paragon Corporation <lr@...> wrote:
>> Paul,
>> Hmm when I am comparing distance of two geometries in different
>> spatial refs which I do a lot.
>>
>> I still don't like the hack even if you disregard the above or if you
>> must hack -- don't give it the same name as the non-hacked functions.
>>
>> the whole idea of picking BestSRID for a person to cater to less
>> technical users I find extremely annoying as I can think of 20
>> "BestSRID" depending on what I am doing.  If they get to that level
>> of sophistication, I would rather have them think a little more  and
>> understand the implications of those decisions.
>>
>> We must learn to crawl before we can learn to walk,because walking
>> without understanding will just get you into trouble in the long run.
>>
>>
>>  Thanks,
>> Regina
>>
>> -----Original Message-----
>> From: postgis-devel-bounces@...
>> [mailto:postgis-devel-bounces@...] On Behalf Of
>> Paul Ramsey
>> Sent: Friday, October 30, 2009 9:47 PM
>> To: PostGIS Development Discussion
>> Subject: Re: [postgis-devel] Geog/Geom Hack
>>
>> You *can*, but I strongly doubt you *will*. Because there's nothing
>> in geography that isn't already in geometry. So you as a primary
>> geometry user are going to have no working need to cast things to

geography.

>>
>> On the other hand, the very first question from users of geography
>> will be "how can I access <geometry function N>?" So having a
>> relatively full set of functions already available in geography makes
>> sense to me, even if they are hacked in with a planar trick.
>>
>> P.
>>
>> On Fri, Oct 30, 2009 at 5:46 PM, Paragon Corporation <lr@...> wrote:
>>> Paul,
>>> I can put a functional geography index on can't I and take advantage
>>> of geography index bindings?
>>>
>>> Lets say I have a large network of tables broken out by region so I
>>> know a specific table has one srid.
>>>
>>> For many queries, I may go to that table directly or if I'm doing
>>> single geometry processing, really don't care what srid as long as
>>> its in utm or whatever - so I can use the full power of GEOS.
>>>
>>> For my across the board distance checks and so forth, I would want
>>> to use geography and I could use a geography index if I put a
>>> functional geography index on my geometry correct?  Though that
>>> needs some more
>> testing.
>>>
>>>
>>> So in short if 90% of my workload involves geometry processing, I
>>> will want to keep my data in geometry
>>>
>>> But the 10% I would want to convert to geography on the fly.
>>>
>>> Thanks,
>>> Regina
>>>
>>> -----Original Message-----
>>> From: postgis-devel-bounces@...
>>> [mailto:postgis-devel-bounces@...] On Behalf Of
>>> Paul Ramsey
>>> Sent: Friday, October 30, 2009 8:34 PM
>>> To: PostGIS Development Discussion
>>> Subject: Re: [postgis-devel] Geog/Geom Hack
>>>
>>> I'm not sure I understand why you would ever convert a geometry to a
>>> geography as part of a query on a geometry table. I fully expect
>>> geography to be used as a storage type, because of the utility of
>>> having the correct spherical indexes, which are not available when
>>> you're just converting in via a cast. Since there's no functions
>>> available on geography that are not already available on geometry,
>>> why would you ever do a geometry->geography cast unless you are (a)
>>> testing geography or (b) bulk converting a table into geography for
>> storage in that type.
>>>
>>> P.
>>>
>>>
>>>
>>> On Fri, Oct 30, 2009 at 5:24 PM, Paragon Corporation <lr@...>

wrote:
>>>> Paul,
>>>> I would rather you didn't for 2 reasons
>>>>
>>>> 1) I'm lazy and for each of these things we'd have to apply the
>>>> text additional function proto hack to prevent from it breaking
geometry.

>>>> which we will probably end up taking out anyway.
>>>>
>>>> 2) I don't like the hiddenness of it since it becomes especially
>>>> annoying if you have your native in geometry and you are converting
>>>> to geography for a special usecase, then you end up with a slower
>>>> implementation
>>>>
>>>> as you would really end up doing accidentally
>>>>
>>>> geometry -> geography -> geometry ->operation (and why do I want my
>>>> calcs done in UTM?)
>>>>
>>>> Instead of the more efficient
>>>>
>>>> geometry -> operation
>>>>
>>>> Thanks,
>>>> Regina
>>>>
>>>> -----Original Message-----
>>>> From: postgis-devel-bounces@...
>>>> [mailto:postgis-devel-bounces@...] On Behalf Of
>>>> Paul Ramsey
>>>> Sent: Friday, October 30, 2009 8:16 PM
>>>> To: PostGIS Development Discussion
>>>> Subject: [postgis-devel] Geog/Geom Hack
>>>>
>>>> I'm interested to know what the general opinion is of the trick
>>>> I've used on
>>>> ST_Buffer(geography):
>>>>
>>>> http://trac.osgeo.org/postgis/browser/trunk/postgis/geography.sql.in.
>>>> c
>>>> #L541
>>>>
>>>> I ask because I could apply the same idea to the larger suite of
>>>> OGC SFSQL predicates before release. Is half-a-loaf better than no
>>>> loaf in
>>> this case?
>>>> (Note that there will be failure cases for really large geometry,
>>>> like a polygon of "Asia" or "Russia" that have polygons over the
>>>> dateline.)
>>>>
>>>> P.
>>>> _______________________________________________
>>>> postgis-devel mailing list
>>>> postgis-devel@...
>>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> postgis-devel mailing list
>>>> postgis-devel@...
>>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>>
>>> _______________________________________________
>>> postgis-devel mailing list
>>> postgis-devel@...
>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>
>>>
>>>
>>> _______________________________________________
>>> postgis-devel mailing list
>>> postgis-devel@...
>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel@...
>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>
>>
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel@...
>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel@...
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel@...
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel@...
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>

_______________________________________________
postgis-devel mailing list
postgis-devel@...
http://postgis.refractions.net/mailman/listinfo/postgis-devel


_______________________________________________
postgis-devel mailing list
postgis-devel@...
http://postgis.refractions.net/mailman/listinfo/postgis-devel

[Paragon Corporation-2]

Steve,
My sentiments exactly.  The only issue I can see with introducing STT is
that it does add potentially a lot of functions we would need to possibly
deprecate or remove in future versions.  Its almost better to just throw
these out there as contrib functions and let people pick the ones they need.

Here is yet another example of why I think Paul's hack is a bleeding
abstraction

Lets suppose you have a huge mass like a continent that no current spatial
ref effectively covers  

What exactly does the magical BestSRID function return?

In a true ST_buffer for geography its a non-issue, but since this is a hack,
the answer is clearly wrong and advanced users would approach it differently
perhaps by dicing it,buffer each add union the individual back to geography.


Of course I suppose you could say -- well It's clearly wrong now (for that
1% case), but we can fix it easily under the covers later without people
having to change their code -- which I can only guess is what Paul is
thinking thus my complaints of the effort to take it out he sees as a
non-issue.  To me its covering a baby horse in a big horse costume and
passing it off as a grown up.  You'll start showing it horse porn and it
will start doing ridiculous things with it :)

Then there is the agg ST_Union (how would you do that?) when you can span so
many BEST SRIDs.


Thanks,
Regina

-----Original Message-----
From: postgis-users-bounces@...
[mailto:postgis-users-bounces@...] On Behalf Of Stephen
Woodbridge
Sent: Saturday, October 31, 2009 12:47 PM
To: PostGIS Users Discussion
Cc: 'PostGIS Development Discussion'
Subject: Re: [postgis-users] [postgis-devel] Geog/Geom Hack

Hi All,

For whatever its worth:

1) I really like the fact that we are addressing usability for the masses.
Just making it do the intuitive thing is good.

2) As someone that has invested a lot of time to learn the ins and outs, I'm
not sure I like the fact that all my functions may start behaving
differently as this thread seems to be implying. I like having control over
how my queries are evaluated and optimized.

3) Without knowing all the nuances of this thread, I would be in favor of
Nicklas' suggestion of add new function names for the hacks. Before reading
his response, I was thinking we could name all these functions STT_... again
the extra T for transform.

Its all goodness in my book, and I appreciate all the work everyone is doing
on this and look forward to a future release where I can try it out.

Best regards,
   -Steve W

Paragon Corporation wrote:

>
> Nicklas and Paul,
>  
> Yap that's the main point.  To add
>  
> I'm not really in disagreement with Paul.  I see his point too.  I'm
> just prodding him to think about all his use cases a little more
> because I don't feel he has.
>  
> My feelings to sum up
> 1) We have not thought about the complete ramifications of this hack
> and I'm really concerned about the novice that transitions to an
> expert rather than just getting them hooked on PostGIS.  Perhaps I'm
> being overly silly with that and even said, Paul's approach might be
> an easier to transition solution.
>  
> 2) My concern is the penalty of putting it in and having to take it
> out later might be very great (both from a code, testing,  as well as
> a mindset perspective).  I just feel it needs more thought and testing
> and really if we want to make our December deadline, I don't want it
> rushed in so lightly.
>  
> Unless of course Paul -- you want to wait till January or February to
> release 1.5?
>  
> Now the ST_Max_Distance is a separate issue.  I would put in the
> ST_ConvexHull hack in place.  The reason being is that it just
> improves performance any way I can think you slice it and an
> experienced user would do exactly the same thing always and when you
> finally incorporate it into the core function,  there is no change in
> existing code just a speed improvement.  So to me its basically our
> ST_DWithin hack -- a very tried and trued obvious answer.  Its an
> implementation detail with no clear leaky effects.
>  
> With that said, there are some clear functions in geometry that are
> safe to put a geography cover over.  Those ones where there is clearly
> only one answer and don't involve transformation.
>  
> like ST_X, ST_Y etc.  That don't require transformation so no screw up
> in data.  Also observe that even the geometry(geography .... in these
> there is no penalty becuase the geometry/geography isn't changing so
> the planner can cache the geometry to geography conversion.  The
> ST_Transformation ones however, the geometry/geography is changing
> slightly at each step since ST_Tranformation is a lossy operation so
> you are not only incurring overhead (because these answers can't be
> cached), but also adding in extra errors .
>  
> To me this is a bleeding abstraction and that is the main reason I
> don't like it.
>  
> So getting back to you Paul,
>  
> What functions exactly are you planning to put a veil over?  ST_Buffer
> well that one is used so much and is not as exact anyway that I
> suppose I can grudgingly accept that as okay.
>  
> Thanks,
> Regina
>
>  
> *From:* postgis-devel-bounces@...
> [mailto:postgis-devel-bounces@...] *On Behalf Of
> *nicklas.aven@...
> *Sent:* Saturday, October 31, 2009 10:04 AM
> *To:* PostGIS Development Discussion
> *Subject:* Re: [postgis-devel] Geog/Geom Hack
>
> Hallo
>  
> I can see the points from both of you. I think the most important
> argument from you Regina is that it is not transparent enough. A
> skillfull user trying postgis might be disapointed when realizing that
> the nested functions caused an unnecessary big rounding-error.
> But if it is obvious that it is a "special" function at least for the
> experienced user knowing about common function-names I don't think it
> is a big problem and might work as an easy shortcut at least during
> the process of learning.
>  
> As I understand it this could be a solution for using many functions
> against geography so, why not  note it in the function name like:
> ST_tBuffer for transformed buffer. Then when time is to introduse a
> "real" variant of the function they can coexist and it will not change
> the bahavior inside an application without someone consciously changes
> the function name and remove the t.
>  
> the t would be independent of geography-geometry in semantics and just
> indicate that it is a lower-precision variant. I fit was commonly used
> it would work as a warning to experienced users.
>  
> I have a similar question about st_max_distance. The function gets
> very much more effective when ran together with convexhull. I saw the
> trick in ST_MinimumBoundingCircle and id makes a big difference to do :
> st_max_distance(st_convexhull(the_geom)) instead of just
> st_max_distance(the_geom).
> The question is: Should that be put in the sql-function?
> My opinion now is that we just tell about it in the documentation and
> aims at doing that trick internally in C in the future. Maybe together
> with moving the whole convexhull to postgis-native from geos. It
> didn't look that impossible fromthe JTS-code.
>  
> /Nicklas
>  
>
> 2009-10-31 Paul Ramsey wrote:
>
> I still think I'm right :) Honestly, I've got to a lot of trouble to  
> >make this stuff for newbies, and I don't think "learn how it works"
> is  >the right answer for them. They had that option before, but
> taking GIS
>  >101 is not an option for these people, they need something that
> "just  >works". It's easier to teach the experienced people the
> pitfalls than  >the inexperienced people the basics.
>  >
>  >BTW, I just upgraded distance_sphere and distance_spheroid to be as  
> >powerful (handling point/line/polygon) as the geography variants,  
> >removing excuses for transforming geometries into geographies for  
> >processing purposes.
>  >
>  >P.
>  >
>  >On Fri, Oct 30, 2009 at 9:15 PM, Paragon Corporation wrote:
>  >> Paul,
>  >> For what its worth, here is another reason why I don't like this
> idea and I  >> think we should at least think about its ramifications
> more so should put it  >> off for consideration until 2.0.
>  >>
>  >> In geometry processing, its common practice to apply a lot of
> functions in  >> succession  >>  >>
> process1(process2(process3(geometry/geography)
>  >>
>  >> With your hackish approach -- the unsuspecting novice user will be
> incurring  >> a lot of transformation rounding errors with each
> process  >>  >> The advanced user, won't know if this is okay or not
> -- because they can't  >> tell by looking at the function call the
> hidden transformations going on.
>  >>
>  >> If these did not exist, they would transform once before the
> processes and  >> once after) and incurr much less penalty  >>  >> But
> if they both exist, they will treat them as being on equal footing  >>  
> >> ST_Buffer(geometry)  and ST_Buffer(geography)  >>  >>  >> So your
> approach while well-meaning gives a questionable benefit to novices  
> >> and is putting experienced users at a disadvantage.
>  >>
>  >> Thanks,
>  >> Regina
>  >>
>  >> -----Original Message-----
>  >> From: postgis-devel-bounces@...
>  >> [mailto:postgis-devel-bounces@...] On Behalf
> Of Paragon  >> Corporation  >> Sent: Friday, October 30, 2009 11:54 PM  
> >> To: 'PostGIS Development Discussion'
>  >> Cc: 'PostGIS Users Discussion'
>  >> Subject: Re: [postgis-devel] Geog/Geom Hack  >>  >> Paul,  >> I
> suppose we can't just put this decision off till 2.0.  Isn't this a
> bit of  >> scope creep?  I'm not absolutely sure which way is better,
> but I know the  >> cost of rolling back the change is more.
>  >>
>  >> If you are going to do this, how many functions are you planning
> to do this  >> for?
>  >>
>  >> I'm cc'ing the postgis users group too to get more of an opinion
> on this  >> topic.
>  >>
>  >> So the question is it it a good idea to introduce a hack that
> transforms a  >> geography into what we call BestSRID to perform
> geometry operations on and  >> then transform back.  My concern is
> that this is a silent operation that  >> gives the impression that
> these functions are natively done in spheroid  >> space just for the
> benefit of  catering to less technical users.
>  >>
>  >>
> http://trac.osgeo.org/postgis/browser/trunk/postgis/geography.sql.in.c
> #L541
>  >>
>  >> So you can't really tell by looking the penalty  >>  >> Main
> examples of this as shown for ST_Buffer  >>  >> CREATE OR REPLACE
> FUNCTION _ST_BestSRID(geography, geography)
>  >> 530         RETURNS integer
>  >> 531         AS 'MODULE_PATHNAME','geography_bestsrid'
>  >> 532         LANGUAGE 'C' IMMUTABLE STRICT;
>  >> 533
>  >> 534 -- Availability: 1.5.0
>  >> 535 CREATE OR REPLACE FUNCTION _ST_BestSRID(geography)
>  >> 536         RETURNS integer
>  >> 537         AS 'SELECT _ST_BestSRID($1,$1)'
>  >> 538         LANGUAGE 'SQL' IMMUTABLE STRICT;
>  >> 539
>  >> 540 -- Availability: 1.5.0
>  >> 541 CREATE OR REPLACE FUNCTION ST_Buffer(geography, float8)
>  >> 542         RETURNS geography
>  >> 543         AS 'SELECT
>  >> geography(ST_Transform(ST_Buffer(ST_Transform(geometry($1),
>  >> _ST_BestSRID($1)), $2), 4326))'
>  >> 544         LANGUAGE 'SQL' IMMUTABLE STRICT;
>  >> 545
>  >>
>  >>
>  >>
>  >> Thanks,
>  >> Regina
>  >>
>  >> -----Original Message-----
>  >> From: postgis-devel-bounces@...
>  >> [mailto:postgis-devel-bounces@...] On Behalf
> Of Paul  >> Ramsey  >> Sent: Friday, October 30, 2009 11:07 PM  >> To:
> PostGIS Development Discussion  >> Subject: Re: [postgis-devel]
> Geog/Geom Hack  >>  >> We're going to have to agree to disagree on
> this one, Regina.
> Catering to
>  >> the less technical users is what this exercise is all about, to my
> mind, and  >> that includes allowing easy flipping into geometry for
> calculations that  >> aren't supported in geography yet. Oracle does
> this too.
>  >>
>  >> What do other folks think?
>  >>
>  >> P.
>  >>
>  >> On Fri, Oct 30, 2009 at 7:06 PM, Paragon Corporation wrote:
>  >>> Paul,
>  >>> Hmm when I am comparing distance of two geometries in different  
> >>> spatial refs which I do a lot.
>  >>>
>  >>> I still don't like the hack even if you disregard the above or if
> you  >>> must hack -- don't give it the same name as the non-hacked

functions.
>  >>>
>  >>> the whole idea of picking BestSRID for a person to cater to less  
> >>> technical users I find extremely annoying as I can think of 20  
> >>> "BestSRID" depending on what I am doing.  If they get to that
> level of  >>> sophistication, I would rather have them think a little
> more  and  >>> understand the implications of those decisions.
>  >>>
>  >>> We must learn to crawl before we can learn to walk,because
> walking  >>> without understanding will just get you into trouble in the
long run.

>  >>>
>  >>>
>  >>>  Thanks,
>  >>> Regina
>  >>>
>  >>> -----Original Message-----
>  >>> From: postgis-devel-bounces@...
>  >>> [mailto:postgis-devel-bounces@...] On Behalf
> Of  >>> Paul Ramsey  >>> Sent: Friday, October 30, 2009 9:47 PM  >>>
> To: PostGIS Development Discussion  >>> Subject: Re: [postgis-devel]
> Geog/Geom Hack  >>>  >>> You *can*, but I strongly doubt you *will*.
> Because there's nothing in  >>> geography that isn't already in
> geometry. So you as a primary geometry  >>> user are going to have no
> working need to cast things to geography.
>  >>>
>  >>> On the other hand, the very first question from users of
> geography  >>> will be "how can I access ?" So having a  >>>
> relatively full set of functions already available in geography makes  
> >>> sense to me, even if they are hacked in with a planar trick.
>  >>>
>  >>> P.
>  >>>
>  >>> On Fri, Oct 30, 2009 at 5:46 PM, Paragon Corporation wrote:
>  >>>> Paul,
>  >>>> I can put a functional geography index on can't I and take
> advantage  >>>> of geography index bindings?
>  >>>>
>  >>>> Lets say I have a large network of tables broken out by region
> so I  >>>> know a specific table has one srid.
>  >>>>
>  >>>> For many queries, I may go to that table directly or if I'm
> doing  >>>> single geometry processing, really don't care what srid as
> long as  >>>> its in utm or whatever - so I can use the full power of

GEOS.

>  >>>>
>  >>>> For my across the board distance checks and so forth, I would
> want to  >>>> use geography and I could use a geography index if I put
> a functional  >>>> geography index on my geometry correct?  Though
> that needs some more  >>> testing.
>  >>>>
>  >>>>
>  >>>> So in short if 90% of my workload involves geometry processing,
> I  >>>> will want to keep my data in geometry  >>>>  >>>> But the 10%
> I would want to convert to geography on the fly.
>  >>>>
>  >>>> Thanks,
>  >>>> Regina
>  >>>>
>  >>>> -----Original Message-----
>  >>>> From: postgis-devel-bounces@...
>  >>>> [mailto:postgis-devel-bounces@...] On Behalf
> Of  >>>> Paul Ramsey  >>>> Sent: Friday, October 30, 2009 8:34 PM  
> >>>> To: PostGIS Development Discussion  >>>> Subject: Re:
> [postgis-devel] Geog/Geom Hack  >>>>  >>>> I'm not sure I understand
> why you would ever convert a geometry to a  >>>> geography as part of
> a query on a geometry table. I fully expect  >>>> geography to be used
> as a storage type, because of the utility of  >>>> having the correct
> spherical indexes, which are not available when  >>>> you're just
> converting in via a cast. Since there's no functions  >>>> available
> on geography that are not already available on geometry,  >>>> why
> would you ever do a geometry->geography cast unless you are (a)  >>>>
> testing geography or (b) bulk converting a table into geography for  
> >>> storage in that type.
>  >>>>
>  >>>> P.
>  >>>>
>  >>>>
>  >>>>
>  >>>> On Fri, Oct 30, 2009 at 5:24 PM, Paragon Corporation wrote:
>  >>>>> Paul,
>  >>>>> I would rather you didn't for 2 reasons  >>>>>  >>>>> 1) I'm
> lazy and for each of these things we'd have to apply the text  >>>>>
> additional function proto hack to prevent from it breaking geometry.
>  >>>>> which we will probably end up taking out anyway.
>  >>>>>
>  >>>>> 2) I don't like the hiddenness of it since it becomes
> especially  >>>>> annoying if you have your native in geometry and you
> are converting  >>>>> to geography for a special usecase, then you end
> up with a slower  >>>>> implementation  >>>>>  >>>>> as you would
> really end up doing accidentally  >>>>>  >>>>> geometry -> geography
> -> geometry ->operation (and why do I want my  >>>>> calcs done in
> UTM?)  >>>>>  >>>>> Instead of the more efficient  >>>>>  >>>>>
> geometry -> operation  >>>>>  >>>>> Thanks,  >>>>> Regina  >>>>>  
> >>>>> -----Original Message-----  >>>>> From:
> postgis-devel-bounces@...
>  >>>>> [mailto:postgis-devel-bounces@...] On
> Behalf Of  >>>>> Paul Ramsey  >>>>> Sent: Friday, October 30, 2009
> 8:16 PM  >>>>> To: PostGIS Development Discussion  >>>>> Subject:
> [postgis-devel] Geog/Geom Hack  >>>>>  >>>>> I'm interested to know
> what the general opinion is of the trick I've  >>>>> used on  >>>>>
> ST_Buffer(geography):
>  >>>>>
>  >>>>>

http://trac.osgeo.org/postgis/browser/trunk/postgis/geography.sql.in.

>  >>>>> c
>  >>>>> #L541
>  >>>>>
>  >>>>> I ask because I could apply the same idea to the larger suite
> of OGC  >>>>> SFSQL predicates before release. Is half-a-loaf better
> than no loaf  >>>>> in  >>>> this case?
>  >>>>> (Note that there will be failure cases for really large
> geometry,  >>>>> like a polygon of "Asia" or "Russia" that have
> polygons over the  >>>>> dateline.)  >>>>>  >>>>> P.
>  >>>>> _______________________________________________
>  >>>>> postgis-devel mailing list
>  >>>>> postgis-devel@...
>  >>>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>  >>>>>
>  >>>>>
>  >>>>>
>  >>>>> _______________________________________________
>  >>>>> postgis-devel mailing list
>  >>>>> postgis-devel@...
>  >>>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>  >>>>>
>  >>>> _______________________________________________
>  >>>> postgis-devel mailing list
>  >>>> postgis-devel@...
>  >>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>  >>>>
>  >>>>
>  >>>>
>  >>>> _______________________________________________
>  >>>> postgis-devel mailing list
>  >>>> postgis-devel@...
>  >>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>  >>>>
>  >>> _______________________________________________
>  >>> postgis-devel mailing list
>  >>> postgis-devel@...
>  >>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>  >>>
>  >>>
>  >>> _______________________________________________
>  >>> postgis-devel mailing list
>  >>> postgis-devel@...
>  >>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>  >>>
>  >> _______________________________________________
>  >> postgis-devel mailing list
>  >> postgis-devel@...
>  >> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>  >>
>  >>
>  >> _______________________________________________
>  >> postgis-devel mailing list
>  >> postgis-devel@...
>  >> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>  >>
>  >>
>  >> _______________________________________________
>  >> postgis-devel mailing list
>  >> postgis-devel@...
>  >> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>  >>
>  >_______________________________________________
>  >postgis-devel mailing list
>  >postgis-devel@...
>  >http://postgis.refractions.net/mailman/listinfo/postgis-devel
>  >
>  >
>
>
> ----------------------------------------------------------------------
> --
>
> _______________________________________________
> postgis-users mailing list
> postgis-users@...
> http://postgis.refractions.net/mailman/listinfo/postgis-users

_______________________________________________
postgis-users mailing list
postgis-users@...
http://postgis.refractions.net/mailman/listinfo/postgis-users


_______________________________________________
postgis-devel mailing list
postgis-devel@...
http://postgis.refractions.net/mailman/listinfo/postgis-devel

[Paragon Corporation-2]

Jose,

Paul can answer this better than I can.

right now the functions we have published for geodetic (ST_Length,
ST_Distance, AT_Area etc) do not use shortest line along a plane like
GEOS/JTS or current PostGIS distance etc. -- they are genuinely measuring
along a sphere/spheroid.

So the only issue we are talking about as you said is the cases where we
don't have a true geodetic answer for right now.

Paul's approach is to find the best spatial ref for it (whatever that
means?) -- transform it to that and then do the JTS/GEOS operations and to
pass this off as a correct answer.

My point is yes that's generally the right thing to do, but not always - it
becomes wrong depending on how big of a thing you are talking about (and the
both good and bad thing about geography is that you can be talking about
bigger things than you can easily with a correct planar)  .  So while having
these functions makes peoples lives easier -- it also makes them difficult,
because now you can't distinguish the really good functions we have designed
specifically for sphere/spheroid from these hackish estimates. No novice or
advanced user would be able to do this without constantly referring to the
docs. How relevant this is to know is my question?

Thus came the other solution of just naming them differently that Nicklas
proposed so one can tell by the name that these are doing some questionable
(and possibly costly) things behind the scenes.

Thanks,
Regina



-----Original Message-----
From: postgis-users-bounces@...
[mailto:postgis-users-bounces@...] On Behalf Of Jose
Carlos Martinez Llario
Sent: Saturday, October 31, 2009 12:34 PM
To: PostGIS Users Discussion
Subject: Re: [postgis-users] [postgis-devel] Geog/Geom Hack

Hi everyone,
Maybe I did not understand all the chat about Geographic coordinates but if
you guys are planning to use geographic coordinates in PostGIS in a wide way
then what is going to happen with all the spatial predicates
(DE9IM) and the spatial operators based on GEOS/JTS?

Please correct me if I am wrong but I think GEOS/JTS are based on 'the
shortest line between 2 points is a line so they are using lineal
interpolation' and not a geodesic line (sphere or ellipsoid) as we need to
work with geographic coordinates. Theses libraries should be rewritten
taking into account this fact, dont you think so?..In fact right now if you
intersect two lines with GEOS/JTS (geographic
coordinates) the result is wrong (even if  GEOS had a sphere approach since
it would keep being wrong in rigorous point of view).

The approach about projecting the geographic coordinates before calling GEOS
to a projection with the smallest errors and choosing the right type
(equivalent projections, conforming projection) could be the 'only'
approach now?

Thanks,
Jose Carlos Martinez




Paragon Corporation wrote:

> Nicklas and Paul,
>  
> Yap that's the main point.  To add
>  
> I'm not really in disagreement with Paul.  I see his point too.  I'm
> just prodding him to think about all his use cases a little more
> because I don't feel he has.
>  
> My feelings to sum up
> 1) We have not thought about the complete ramifications of this hack
> and I'm really concerned about the novice that transitions to an
> expert rather than just getting them hooked on PostGIS.  Perhaps I'm
> being overly silly with that and even said, Paul's approach might be
> an easier to transition solution.
>  
> 2) My concern is the penalty of putting it in and having to take it
> out later might be very great (both from a code, testing,  as well as
> a mindset perspective).  I just feel it needs more thought and testing
> and really if we want to make our December deadline, I don't want it
> rushed in so lightly.
>  
> Unless of course Paul -- you want to wait till January or February to
> release 1.5?
>  
> Now the ST_Max_Distance is a separate issue.  I would put in the
> ST_ConvexHull hack in place.  The reason being is that it just
> improves performance any way I can think you slice it and an
> experienced user would do exactly the same thing always and when you
> finally incorporate it into the core function,  there is no change in
> existing code just a speed improvement.  So to me its basically our
> ST_DWithin hack -- a very tried and trued obvious answer.  Its an
> implementation detail with no clear leaky effects.
>  
> With that said, there are some clear functions in geometry that are
> safe to put a geography cover over.  Those ones where there is clearly
> only one answer and don't involve transformation.
>  
> like ST_X, ST_Y etc.  That don't require transformation so no screw up
> in data.  Also observe that even the geometry(geography .... in these
> there is no penalty becuase the geometry/geography isn't changing so
> the planner can cache the geometry to geography conversion.  The
> ST_Transformation ones however, the geometry/geography is changing
> slightly at each step since ST_Tranformation is a lossy operation so
> you are not only incurring overhead (because these answers can't be
> cached), but also adding in extra errors .
>  
> To me this is a bleeding abstraction and that is the main reason I
> don't like it.
>  
> So getting back to you Paul,
>  
> What functions exactly are you planning to put a veil over?  ST_Buffer
> well that one is used so much and is not as exact anyway that I
> suppose I can grudgingly accept that as okay.
>  
> Thanks,
> Regina
>
>  
> ----------------------------------------------------------------------
> --
> *From:* postgis-devel-bounces@...
> [mailto:postgis-devel-bounces@...] *On Behalf Of
> *nicklas.aven@...
> *Sent:* Saturday, October 31, 2009 10:04 AM
> *To:* PostGIS Development Discussion
> *Subject:* Re: [postgis-devel] Geog/Geom Hack
>
> Hallo
>  
> I can see the points from both of you. I think the most important
> argument from you Regina is that it is not transparent enough. A
> skillfull user trying postgis might be disapointed when realizing that
> the nested functions caused an unnecessary big rounding-error.
> But if it is obvious that it is a "special" function at least for the
> experienced user knowing about common function-names I don't think it
> is a big problem and might work as an easy shortcut at least during
> the process of learning.
>  
> As I understand it this could be a solution for using many functions
> against geography so, why not  note it in the function name like:
> ST_tBuffer for transformed buffer. Then when time is to introduse a
> "real" variant of the function they can coexist and it will not change
> the bahavior inside an application without someone consciously changes
> the function name and remove the t.
>  
> the t would be independent of geography-geometry in semantics and just
> indicate that it is a lower-precision variant. I fit was commonly used
> it would work as a warning to experienced users.
>  
> I have a similar question about st_max_distance. The function gets
> very much more effective when ran together with convexhull. I saw the
> trick in ST_MinimumBoundingCircle and id makes a big difference to do :
> st_max_distance(st_convexhull(the_geom)) instead of just
> st_max_distance(the_geom).
> The question is: Should that be put in the sql-function?
> My opinion now is that we just tell about it in the documentation and
> aims at doing that trick internally in C in the future. Maybe together
> with moving the whole convexhull to postgis-native from geos. It
> didn't look that impossible fromthe JTS-code.
>  
> /Nicklas
>  
>
> 2009-10-31 Paul Ramsey wrote:
>
> I still think I'm right :) Honestly, I've got to a lot of trouble to
> >make this stuff for newbies, and I don't think "learn how it works"
> >is the right answer for them. They had that option before, but taking
> >GIS
> >101 is not an option for these people, they need something that "just
> >works". It's easier to teach the experienced people the pitfalls than
> >the inexperienced people the basics.
> >
> >BTW, I just upgraded distance_sphere and distance_spheroid to be as
> >powerful (handling point/line/polygon) as the geography variants,
> >removing excuses for transforming geometries into geographies for
> >processing purposes.
> >
> >P.
> >
> >On Fri, Oct 30, 2009 at 9:15 PM, Paragon Corporation wrote:
> >> Paul,
> >> For what its worth, here is another reason why I don't like this
> idea and I
> >> think we should at least think about its ramifications more so
> should put it
> >> off for consideration until 2.0.
> >>
> >> In geometry processing, its common practice to apply a lot of
> functions in
> >> succession
> >>
> >> process1(process2(process3(geometry/geography)
> >>
> >> With your hackish approach -- the unsuspecting novice user will be
> incurring
> >> a lot of transformation rounding errors with each process
> >>
> >> The advanced user, won't know if this is okay or not -- because
> they can't
> >> tell by looking at the function call the hidden transformations
> going on.
> >>
> >> If these did not exist, they would transform once before the
> processes and
> >> once after) and incurr much less penalty
> >>
> >> But if they both exist, they will treat them as being on equal
> >> footing
> >>
> >> ST_Buffer(geometry)  and ST_Buffer(geography)
> >>
> >>
> >> So your approach while well-meaning gives a questionable benefit to
> novices
> >> and is putting experienced users at a disadvantage.
> >>
> >> Thanks,
> >> Regina
> >>
> >> -----Original Message-----
> >> From: postgis-devel-bounces@...
> >> [mailto:postgis-devel-bounces@...] On Behalf Of
> Paragon
> >> Corporation
> >> Sent: Friday, October 30, 2009 11:54 PM
> >> To: 'PostGIS Development Discussion'
> >> Cc: 'PostGIS Users Discussion'
> >> Subject: Re: [postgis-devel] Geog/Geom Hack
> >>
> >> Paul,
> >> I suppose we can't just put this decision off till 2.0.  Isn't this
> a bit of
> >> scope creep?  I'm not absolutely sure which way is better, but I
> know the
> >> cost of rolling back the change is more.
> >>
> >> If you are going to do this, how many functions are you planning to
> do this
> >> for?
> >>
> >> I'm cc'ing the postgis users group too to get more of an opinion on
> this
> >> topic.
> >>
> >> So the question is it it a good idea to introduce a hack that
> transforms a
> >> geography into what we call BestSRID to perform geometry operations
> on and
> >> then transform back.  My concern is that this is a silent operation
> that
> >> gives the impression that these functions are natively done in
> >> spheroid space just for the benefit of  catering to less technical

users.

> >>
> >>
> http://trac.osgeo.org/postgis/browser/trunk/postgis/geography.sql.in.c
> #L541
> >>
> >> So you can't really tell by looking the penalty
> >>
> >> Main examples of this as shown for ST_Buffer
> >>
> >> CREATE OR REPLACE FUNCTION _ST_BestSRID(geography, geography)
> >> 530         RETURNS integer
> >> 531         AS 'MODULE_PATHNAME','geography_bestsrid'
> >> 532         LANGUAGE 'C' IMMUTABLE STRICT;
> >> 533
> >> 534 -- Availability: 1.5.0
> >> 535 CREATE OR REPLACE FUNCTION _ST_BestSRID(geography)
> >> 536         RETURNS integer
> >> 537         AS 'SELECT _ST_BestSRID($1,$1)'
> >> 538         LANGUAGE 'SQL' IMMUTABLE STRICT;
> >> 539
> >> 540 -- Availability: 1.5.0
> >> 541 CREATE OR REPLACE FUNCTION ST_Buffer(geography, float8)
> >> 542         RETURNS geography
> >> 543         AS 'SELECT
> >> geography(ST_Transform(ST_Buffer(ST_Transform(geometry($1),
> >> _ST_BestSRID($1)), $2), 4326))'
> >> 544         LANGUAGE 'SQL' IMMUTABLE STRICT;
> >> 545
> >>
> >>
> >>
> >> Thanks,
> >> Regina
> >>
> >> -----Original Message-----
> >> From: postgis-devel-bounces@...
> >> [mailto:postgis-devel-bounces@...] On Behalf Of
> Paul
> >> Ramsey
> >> Sent: Friday, October 30, 2009 11:07 PM
> >> To: PostGIS Development Discussion
> >> Subject: Re: [postgis-devel] Geog/Geom Hack
> >>
> >> We're going to have to agree to disagree on this one, Regina.
> Catering to
> >> the less technical users is what this exercise is all about, to my
> mind, and
> >> that includes allowing easy flipping into geometry for calculations
> that
> >> aren't supported in geography yet. Oracle does this too.
> >>
> >> What do other folks think?
> >>
> >> P.
> >>
> >> On Fri, Oct 30, 2009 at 7:06 PM, Paragon Corporation wrote:
> >>> Paul,
> >>> Hmm when I am comparing distance of two geometries in different
> >>> spatial refs which I do a lot.
> >>>
> >>> I still don't like the hack even if you disregard the above or if
> >>> you must hack -- don't give it the same name as the non-hacked

functions.

> >>>
> >>> the whole idea of picking BestSRID for a person to cater to less
> >>> technical users I find extremely annoying as I can think of 20
> >>> "BestSRID" depending on what I am doing.  If they get to that
> >>> level of sophistication, I would rather have them think a little
> >>> more  and understand the implications of those decisions.
> >>>
> >>> We must learn to crawl before we can learn to walk,because walking
> >>> without understanding will just get you into trouble in the long run.
> >>>
> >>>
> >>>  Thanks,
> >>> Regina
> >>>
> >>> -----Original Message-----
> >>> From: postgis-devel-bounces@...
> >>> [mailto:postgis-devel-bounces@...] On Behalf
> >>> Of Paul Ramsey
> >>> Sent: Friday, October 30, 2009 9:47 PM
> >>> To: PostGIS Development Discussion
> >>> Subject: Re: [postgis-devel] Geog/Geom Hack
> >>>
> >>> You *can*, but I strongly doubt you *will*. Because there's
> >>> nothing in geography that isn't already in geometry. So you as a
> >>> primary geometry user are going to have no working need to cast things

to geography.

> >>>
> >>> On the other hand, the very first question from users of geography
> >>> will be "how can I access ?" So having a relatively full set of
> >>> functions already available in geography makes sense to me, even
> >>> if they are hacked in with a planar trick.
> >>>
> >>> P.
> >>>
> >>> On Fri, Oct 30, 2009 at 5:46 PM, Paragon Corporation wrote:
> >>>> Paul,
> >>>> I can put a functional geography index on can't I and take
> >>>> advantage of geography index bindings?
> >>>>
> >>>> Lets say I have a large network of tables broken out by region so
> >>>> I know a specific table has one srid.
> >>>>
> >>>> For many queries, I may go to that table directly or if I'm doing
> >>>> single geometry processing, really don't care what srid as long
> >>>> as its in utm or whatever - so I can use the full power of GEOS.
> >>>>
> >>>> For my across the board distance checks and so forth, I would
> >>>> want to use geography and I could use a geography index if I put
> >>>> a functional geography index on my geometry correct?  Though that
> >>>> needs some more
> >>> testing.
> >>>>
> >>>>
> >>>> So in short if 90% of my workload involves geometry processing, I
> >>>> will want to keep my data in geometry
> >>>>
> >>>> But the 10% I would want to convert to geography on the fly.
> >>>>
> >>>> Thanks,
> >>>> Regina
> >>>>
> >>>> -----Original Message-----
> >>>> From: postgis-devel-bounces@...
> >>>> [mailto:postgis-devel-bounces@...] On Behalf
> >>>> Of Paul Ramsey
> >>>> Sent: Friday, October 30, 2009 8:34 PM
> >>>> To: PostGIS Development Discussion
> >>>> Subject: Re: [postgis-devel] Geog/Geom Hack
> >>>>
> >>>> I'm not sure I understand why you would ever convert a geometry
> >>>> to a geography as part of a query on a geometry table. I fully
> >>>> expect geography to be used as a storage type, because of the
> >>>> utility of having the correct spherical indexes, which are not
> >>>> available when you're just converting in via a cast. Since
> >>>> there's no functions available on geography that are not already
> >>>> available on geometry, why would you ever do a
> >>>> geometry->geography cast unless you are (a) testing geography or
> >>>> (b) bulk converting a table into geography for
> >>> storage in that type.
> >>>>
> >>>> P.
> >>>>
> >>>>
> >>>>
> >>>> On Fri, Oct 30, 2009 at 5:24 PM, Paragon Corporation wrote:
> >>>>> Paul,
> >>>>> I would rather you didn't for 2 reasons
> >>>>>
> >>>>> 1) I'm lazy and for each of these things we'd have to apply the
> >>>>> text additional function proto hack to prevent from it breaking

geometry.

> >>>>> which we will probably end up taking out anyway.
> >>>>>
> >>>>> 2) I don't like the hiddenness of it since it becomes especially
> >>>>> annoying if you have your native in geometry and you are
> >>>>> converting to geography for a special usecase, then you end up
> >>>>> with a slower implementation
> >>>>>
> >>>>> as you would really end up doing accidentally
> >>>>>
> >>>>> geometry -> geography -> geometry ->operation (and why do I want
> >>>>> my calcs done in UTM?)
> >>>>>
> >>>>> Instead of the more efficient
> >>>>>
> >>>>> geometry -> operation
> >>>>>
> >>>>> Thanks,
> >>>>> Regina
> >>>>>
> >>>>> -----Original Message-----
> >>>>> From: postgis-devel-bounces@...
> >>>>> [mailto:postgis-devel-bounces@...] On Behalf
> >>>>> Of Paul Ramsey
> >>>>> Sent: Friday, October 30, 2009 8:16 PM
> >>>>> To: PostGIS Development Discussion
> >>>>> Subject: [postgis-devel] Geog/Geom Hack
> >>>>>
> >>>>> I'm interested to know what the general opinion is of the trick
> >>>>> I've used on
> >>>>> ST_Buffer(geography):
> >>>>>
> >>>>>
> http://trac.osgeo.org/postgis/browser/trunk/postgis/geography.sql.in.
> >>>>> c
> >>>>> #L541
> >>>>>
> >>>>> I ask because I could apply the same idea to the larger suite of
> >>>>> OGC SFSQL predicates before release. Is half-a-loaf better than
> >>>>> no loaf in
> >>>> this case?
> >>>>> (Note that there will be failure cases for really large
> >>>>> geometry, like a polygon of "Asia" or "Russia" that have
> >>>>> polygons over the
> >>>>> dateline.)
> >>>>>
> >>>>> P.
> >>>>> _______________________________________________
> >>>>> postgis-devel mailing list
> >>>>> postgis-devel@...
> >>>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
> >>>>>
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> postgis-devel mailing list
> >>>>> postgis-devel@...
> >>>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
> >>>>>
> >>>> _______________________________________________
> >>>> postgis-devel mailing list
> >>>> postgis-devel@...
> >>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
> >>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> postgis-devel mailing list
> >>>> postgis-devel@...
> >>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
> >>>>
> >>> _______________________________________________
> >>> postgis-devel mailing list
> >>> postgis-devel@...
> >>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
> >>>
> >>>
> >>> _______________________________________________
> >>> postgis-devel mailing list
> >>> postgis-devel@...
> >>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
> >>>
> >> _______________________________________________
> >> postgis-devel mailing list
> >> postgis-devel@...
> >> http://postgis.refractions.net/mailman/listinfo/postgis-devel
> >>
> >>
> >> _______________________________________________
> >> postgis-devel mailing list
> >> postgis-devel@...
> >> http://postgis.refractions.net/mailman/listinfo/postgis-devel
> >>
> >>
> >> _______________________________________________
> >> postgis-devel mailing list
> >> postgis-devel@...
> >> http://postgis.refractions.net/mailman/listinfo/postgis-devel
> >>
> >_______________________________________________
> >postgis-devel mailing list
> >postgis-devel@...
> >http://postgis.refractions.net/mailman/listinfo/postgis-devel
> >
> >
> ----------------------------------------------------------------------
> --
>
> _______________________________________________
> postgis-users mailing list
> postgis-users@...
> http://postgis.refractions.net/mailman/listinfo/postgis-users
>  

--
------------------------------
José Carlos Martínez Llario

Producción Cartográfica y SIG.
Dpto. Ingeniería Cartográfica.
Univ. Politécnica de Valencia.

E-mail: jomarlla@...
Telf: 963877007 ext. 75599
------------------------------

_______________________________________________
postgis-users mailing list
postgis-users@...
http://postgis.refractions.net/mailman/listinfo/postgis-users


_______________________________________________
postgis-devel mailing list
postgis-devel@...
http://postgis.refractions.net/mailman/listinfo/postgis-devel

[Paragon Corporation-2]

Jose,

For what its worth, I think the ST_Dwithin for geography takes care of the
ST_Intersects case nicely.  And that for example to me would be a no brainer
overload for ST_Intersects. It will be slower than the geometry
ST_Intersects, but would give the right answer.

The ST_Intersection example also brings up the point of what if the
projected srid you calculate to be the best for each geometry is different?
Or I suppose you would take both into consideration and figure out based on
area or something.  Though that would still not be quite right.

I'm thinking these things have to be analyzed on a per function basis
(rather than a sweeping answer of Yes lets overload everything people
commonly use).

So Paul -- what functions exactly did you have in mind?

Thanks,
Regina

-----Original Message-----
From: postgis-users-bounces@...
[mailto:postgis-users-bounces@...] On Behalf Of Jose
Carlos Martinez Llario
Sent: Saturday, October 31, 2009 2:17 PM
To: PostGIS Users Discussion
Subject: Re: [postgis-users] [postgis-devel] Geog/Geom Hack

Hi all,

Talking about this topics..maybe I can help a little bit to some users that
do not have clear this problem and then they can help about the topic you
are talking about the functions names, etc.

Lets get the intersection of two lines that use a geographic coordinate
system (GCS), this case: epsg 4230

The result 1) is the normal PostGIS behavior. But the point: POINT(-1.5
40) is a wrong result from a cartographic point of view (but if we use a GCS
then we are talking about cartography right?).
The result 2) (we transform the GCS to a Projected reference system valid
according to the study area (ED50UTM 30N -> EPSG 23030)  and of course using
the same ellipsoid (4230): This POINT(-1.50026115912186
40.0157573310178) has a little error but it is much better approach that 1)
3)
The perfect result would be to calculate the two geodetic lines and to
intersect them directly in 4230 but this is much more complicated.

I think PostGIS should avoid using the first behavior (I do not think the
result 1 is acceptable) and at least to transform to a correct Projected
coordinate system. This task can be done automatically by checking the SRID
and finding out if it corresponds to a GCS, that case just transform the
data  . Of course, still remain the tolerance problem that I tried to
explain in the previous post.


1)
sp3=# select st_asewkt(st_intersection(l0,l1)) from (select st_geomfromtext
('SRID=4230;LINESTRING (-2 39, -1 41)') as l0, st_geomfromtext
('SRID=4230;LINESTRING (-1 39, -2 41)') as l1) as foo;
        st_asewkt
--------------------------
 SRID=4230;POINT(-1.5 40)

2)
sp3=# select st_asewkt(st_transform (st_intersection(l0t, l1t),4230)) from
(select st_transform (l0,23030) as l0t, st_transform(l1,23030) as l1t from
(select st_geomfromtext ('SRID=4230;LINESTRING (-2 39, -1 41)') as l0,
st_geomfromtext ('SRID=4230;LINESTRING (-1 39, -2 41)') as l1) as
foo) as foo;
                      st_asewkt
-----------------------------------------------------
 SRID=4230;POINT(-1.50026115912186 40.0157573310178)
(1 row)

Cheers,
Jose



Jose Carlos Martinez Llario wrote:

> Thanks a lot Regina as you said it can be so confusing for users.
> I understood now the problem you guys are talking about.
>
> But I would like to go back again to the geodetic problem with not
> trivial method (ST_Intersects..., ST_Intersection.., etc.) I am
> reading the OGC 06-103r3 now..and for example OGC says in buffer:
> "Becaose of the limitations of linear interpolation, there will often
> be some relatively small error in this distance"
> They extends too this comment in general to any geometry operation so
> they are assuming that
>
> So I think they admit small errors (I do not how big..), anyways they
> talk just about LINEAR interpolation. Maybe the OGC didnt think a lot
> about geographic coordinates  when they wrote this specifications or
> maybe they are working in other specifications right now...no idea..
>
> Anyways if PostGIS transforms the coordinates from geographic to some
> projection before calling GEOS..then I think PostGIS/GEOS should use
> some coordinate tolerance inside the spatial operators and predicates,
> otherwise geometries that intersect, overlap, etc in the real world
> (real world is the ellipsoid or at least sphere) are not going to
> intersect, overlap,etc. in projected coordinates.
>
> Thanx,
> Best,
> Jose
>
> Paragon Corporation wrote:
>> Jose,
>>
>> Paul can answer this better than I can.
>> right now the functions we have published for geodetic (ST_Length,
>> ST_Distance, AT_Area etc) do not use shortest line along a plane like
>> GEOS/JTS or current PostGIS distance etc. -- they are genuinely
>> measuring along a sphere/spheroid.
>>
>> So the only issue we are talking about as you said is the cases where
>> we don't have a true geodetic answer for right now.
>>
>> Paul's approach is to find the best spatial ref for it (whatever that
>> means?) -- transform it to that and then do the JTS/GEOS operations
>> and to pass this off as a correct answer.
>>
>> My point is yes that's generally the right thing to do, but not
>> always - it becomes wrong depending on how big of a thing you are
>> talking about (and the both good and bad thing about geography is
>> that you can be talking about bigger things than you can easily with
>> a correct planar)  .  So while having these functions makes peoples
>> lives easier -- it also makes them difficult, because now you can't
>> distinguish the really good functions we have designed specifically
>> for sphere/spheroid from these hackish estimates. No novice or
>> advanced user would be able to do this without constantly referring
>> to the docs. How relevant this is to know is my question?
>>
>> Thus came the other solution of just naming them differently that
>> Nicklas proposed so one can tell by the name that these are doing
>> some questionable (and possibly costly) things behind the scenes.
>>
>> Thanks,
>> Regina
>>
>>
>>
>> -----Original Message-----
>> From: postgis-users-bounces@...
>> [mailto:postgis-users-bounces@...] On Behalf Of
>> Jose Carlos Martinez Llario
>> Sent: Saturday, October 31, 2009 12:34 PM
>> To: PostGIS Users Discussion
>> Subject: Re: [postgis-users] [postgis-devel] Geog/Geom Hack
>>
>> Hi everyone,
>> Maybe I did not understand all the chat about Geographic coordinates
>> but if you guys are planning to use geographic coordinates in PostGIS
>> in a wide way then what is going to happen with all the spatial
>> predicates
>> (DE9IM) and the spatial operators based on GEOS/JTS?
>>
>> Please correct me if I am wrong but I think GEOS/JTS are based on
>> 'the shortest line between 2 points is a line so they are using
>> lineal interpolation' and not a geodesic line (sphere or ellipsoid)
>> as we need to work with geographic coordinates. Theses libraries
>> should be rewritten taking into account this fact, dont you think
>> so?..In fact right now if you intersect two lines with GEOS/JTS
>> (geographic
>> coordinates) the result is wrong (even if  GEOS had a sphere approach
>> since it would keep being wrong in rigorous point of view).
>>
>> The approach about projecting the geographic coordinates before
>> calling GEOS to a projection with the smallest errors and choosing
>> the right type (equivalent projections, conforming projection) could
>> be the 'only'
>> approach now?
>>
>> Thanks,
>> Jose Carlos Martinez
>>
>>
>>
>>
>> Paragon Corporation wrote:
>>  
>>> Nicklas and Paul,
>>>  
>>> Yap that's the main point.  To add
>>>  
>>> I'm not really in disagreement with Paul.  I see his point too.  I'm
>>> just prodding him to think about all his use cases a little more
>>> because I don't feel he has.
>>>  
>>> My feelings to sum up
>>> 1) We have not thought about the complete ramifications of this hack
>>> and I'm really concerned about the novice that transitions to an
>>> expert rather than just getting them hooked on PostGIS.  Perhaps I'm
>>> being overly silly with that and even said, Paul's approach might be
>>> an easier to transition solution.
>>>  
>>> 2) My concern is the penalty of putting it in and having to take it
>>> out later might be very great (both from a code, testing,  as well
>>> as a mindset perspective).  I just feel it needs more thought and
>>> testing and really if we want to make our December deadline, I don't
>>> want it rushed in so lightly.
>>>  
>>> Unless of course Paul -- you want to wait till January or February
>>> to release 1.5?
>>>  
>>> Now the ST_Max_Distance is a separate issue.  I would put in the
>>> ST_ConvexHull hack in place.  The reason being is that it just
>>> improves performance any way I can think you slice it and an
>>> experienced user would do exactly the same thing always and when you
>>> finally incorporate it into the core function,  there is no change
>>> in existing code just a speed improvement.  So to me its basically
>>> our ST_DWithin hack -- a very tried and trued obvious answer.  Its
>>> an implementation detail with no clear leaky effects.
>>>  
>>> With that said, there are some clear functions in geometry that are
>>> safe to put a geography cover over.  Those ones where there is
>>> clearly only one answer and don't involve transformation.
>>>  
>>> like ST_X, ST_Y etc.  That don't require transformation so no screw
>>> up in data.  Also observe that even the geometry(geography .... in
>>> these there is no penalty becuase the geometry/geography isn't
>>> changing so the planner can cache the geometry to geography
>>> conversion.  The ST_Transformation ones however, the
>>> geometry/geography is changing slightly at each step since
>>> ST_Tranformation is a lossy operation so you are not only incurring
>>> overhead (because these answers can't be cached), but also adding in
>>> extra errors .
>>>  
>>> To me this is a bleeding abstraction and that is the main reason I
>>> don't like it.
>>>  
>>> So getting back to you Paul,
>>>  
>>> What functions exactly are you planning to put a veil over?  
>>> ST_Buffer well that one is used so much and is not as exact anyway
>>> that I suppose I can grudgingly accept that as okay.
>>>  
>>> Thanks,
>>> Regina
>>>
>>>  
>>> --------------------------------------------------------------------
>>> --
>>> --
>>> *From:* postgis-devel-bounces@...
>>> [mailto:postgis-devel-bounces@...] *On Behalf Of
>>> *nicklas.aven@...
>>> *Sent:* Saturday, October 31, 2009 10:04 AM
>>> *To:* PostGIS Development Discussion
>>> *Subject:* Re: [postgis-devel] Geog/Geom Hack
>>>
>>> Hallo
>>>  
>>> I can see the points from both of you. I think the most important
>>> argument from you Regina is that it is not transparent enough. A
>>> skillfull user trying postgis might be disapointed when realizing
>>> that the nested functions caused an unnecessary big rounding-error.
>>> But if it is obvious that it is a "special" function at least for
>>> the experienced user knowing about common function-names I don't
>>> think it is a big problem and might work as an easy shortcut at
>>> least during the process of learning.
>>>  
>>> As I understand it this could be a solution for using many functions
>>> against geography so, why not  note it in the function name like:
>>> ST_tBuffer for transformed buffer. Then when time is to introduse a
>>> "real" variant of the function they can coexist and it will not
>>> change the bahavior inside an application without someone
>>> consciously changes    
>>
>>  
>>> the function name and remove the t.
>>>  
>>> the t would be independent of geography-geometry in semantics and
>>> just indicate that it is a lower-precision variant. I fit was
>>> commonly used it would work as a warning to experienced users.
>>>  
>>> I have a similar question about st_max_distance. The function gets
>>> very much more effective when ran together with convexhull. I saw
>>> the trick in ST_MinimumBoundingCircle and id makes a big difference
>>> to do :
>>> st_max_distance(st_convexhull(the_geom)) instead of just
>>> st_max_distance(the_geom).
>>> The question is: Should that be put in the sql-function?
>>> My opinion now is that we just tell about it in the documentation
>>> and aims at doing that trick internally in C in the future. Maybe
>>> together with moving the whole convexhull to postgis-native from
>>> geos. It didn't look that impossible fromthe JTS-code.
>>>  
>>> /Nicklas
>>>  
>>>
>>> 2009-10-31 Paul Ramsey wrote:
>>>
>>> I still think I'm right :) Honestly, I've got to a lot of trouble to
>>>    
>>>> make this stuff for newbies, and I don't think "learn how it works"
>>>> is the right answer for them. They had that option before, but
>>>> taking GIS
>>>> 101 is not an option for these people, they need something that
>>>> "just works". It's easier to teach the experienced people the
>>>> pitfalls than the inexperienced people the basics.
>>>>
>>>> BTW, I just upgraded distance_sphere and distance_spheroid to be as
>>>> powerful (handling point/line/polygon) as the geography variants,
>>>> removing excuses for transforming geometries into geographies for
>>>> processing purposes.
>>>>
>>>> P.
>>>>
>>>> On Fri, Oct 30, 2009 at 9:15 PM, Paragon Corporation wrote:
>>>>      
>>>>> Paul,
>>>>> For what its worth, here is another reason why I don't like this
>>>>>        
>>> idea and I
>>>    
>>>>> think we should at least think about its ramifications more so
>>>>>        
>>> should put it
>>>    
>>>>> off for consideration until 2.0.
>>>>>
>>>>> In geometry processing, its common practice to apply a lot of
>>>>>        
>>> functions in
>>>    
>>>>> succession
>>>>>
>>>>> process1(process2(process3(geometry/geography)
>>>>>
>>>>> With your hackish approach -- the unsuspecting novice user will be
>>>>>        
>>> incurring
>>>    
>>>>> a lot of transformation rounding errors with each process
>>>>>
>>>>> The advanced user, won't know if this is okay or not -- because
>>>>>        
>>> they can't
>>>    
>>>>> tell by looking at the function call the hidden transformations
>>>>>        
>>> going on.
>>>    
>>>>> If these did not exist, they would transform once before the
>>>>>        
>>> processes and
>>>    
>>>>> once after) and incurr much less penalty
>>>>>
>>>>> But if they both exist, they will treat them as being on equal
>>>>> footing
>>>>>
>>>>> ST_Buffer(geometry)  and ST_Buffer(geography)
>>>>>
>>>>>
>>>>> So your approach while well-meaning gives a questionable benefit
>>>>> to
>>>>>        
>>> novices
>>>    
>>>>> and is putting experienced users at a disadvantage.
>>>>>
>>>>> Thanks,
>>>>> Regina
>>>>>
>>>>> -----Original Message-----
>>>>> From: postgis-devel-bounces@...
>>>>> [mailto:postgis-devel-bounces@...] On Behalf
>>>>> Of
>>>>>        
>>> Paragon
>>>    
>>>>> Corporation
>>>>> Sent: Friday, October 30, 2009 11:54 PM
>>>>> To: 'PostGIS Development Discussion'
>>>>> Cc: 'PostGIS Users Discussion'
>>>>> Subject: Re: [postgis-devel] Geog/Geom Hack
>>>>>
>>>>> Paul,
>>>>> I suppose we can't just put this decision off till 2.0.  Isn't
>>>>> this
>>>>>        
>>> a bit of
>>>    
>>>>> scope creep?  I'm not absolutely sure which way is better, but I
>>>>>        
>>> know the
>>>    
>>>>> cost of rolling back the change is more.
>>>>>
>>>>> If you are going to do this, how many functions are you planning
>>>>> to
>>>>>        
>>> do this
>>>    
>>>>> for?
>>>>>
>>>>> I'm cc'ing the postgis users group too to get more of an opinion
>>>>> on
>>>>>        
>>> this
>>>    
>>>>> topic.
>>>>>
>>>>> So the question is it it a good idea to introduce a hack that
>>>>>        
>>> transforms a
>>>    
>>>>> geography into what we call BestSRID to perform geometry
>>>>> operations
>>>>>        
>>> on and
>>>    
>>>>> then transform back.  My concern is that this is a silent
>>>>> operation
>>>>>        
>>> that
>>>    
>>>>> gives the impression that these functions are natively done in
>>>>> spheroid space just for the benefit of  catering to less technical
>>>>>        
>> users.
>>  
>>>>>        
>>> http://trac.osgeo.org/postgis/browser/trunk/postgis/geography.sql.in
>>> .c
>>> #L541
>>>    
>>>>> So you can't really tell by looking the penalty
>>>>>
>>>>> Main examples of this as shown for ST_Buffer
>>>>>
>>>>> CREATE OR REPLACE FUNCTION _ST_BestSRID(geography, geography)
>>>>> 530         RETURNS integer
>>>>> 531         AS 'MODULE_PATHNAME','geography_bestsrid'
>>>>> 532         LANGUAGE 'C' IMMUTABLE STRICT;
>>>>> 533
>>>>> 534 -- Availability: 1.5.0
>>>>> 535 CREATE OR REPLACE FUNCTION _ST_BestSRID(geography)
>>>>> 536         RETURNS integer
>>>>> 537         AS 'SELECT _ST_BestSRID($1,$1)'
>>>>> 538         LANGUAGE 'SQL' IMMUTABLE STRICT;
>>>>> 539
>>>>> 540 -- Availability: 1.5.0
>>>>> 541 CREATE OR REPLACE FUNCTION ST_Buffer(geography, float8)
>>>>> 542         RETURNS geography
>>>>> 543         AS 'SELECT
>>>>> geography(ST_Transform(ST_Buffer(ST_Transform(geometry($1),
>>>>> _ST_BestSRID($1)), $2), 4326))'
>>>>> 544         LANGUAGE 'SQL' IMMUTABLE STRICT;
>>>>> 545
>>>>>
>>>>>
>>>>>
>>>>> Thanks,
>>>>> Regina
>>>>>
>>>>> -----Original Message-----
>>>>> From: postgis-devel-bounces@...
>>>>> [mailto:postgis-devel-bounces@...] On Behalf
>>>>> Of
>>>>>        
>>> Paul
>>>    
>>>>> Ramsey
>>>>> Sent: Friday, October 30, 2009 11:07 PM
>>>>> To: PostGIS Development Discussion
>>>>> Subject: Re: [postgis-devel] Geog/Geom Hack
>>>>>
>>>>> We're going to have to agree to disagree on this one, Regina.        
>>> Catering to
>>>    
>>>>> the less technical users is what this exercise is all about, to my
>>>>>        
>>> mind, and
>>>    
>>>>> that includes allowing easy flipping into geometry for
>>>>> calculations
>>>>>        
>>> that
>>>    
>>>>> aren't supported in geography yet. Oracle does this too.
>>>>>
>>>>> What do other folks think?
>>>>>
>>>>> P.
>>>>>
>>>>> On Fri, Oct 30, 2009 at 7:06 PM, Paragon Corporation wrote:
>>>>>        
>>>>>> Paul,
>>>>>> Hmm when I am comparing distance of two geometries in different
>>>>>> spatial refs which I do a lot.
>>>>>>
>>>>>> I still don't like the hack even if you disregard the above or if
>>>>>> you must hack -- don't give it the same name as the non-hacked
>>>>>>          
>> functions.
>>  
>>>>>> the whole idea of picking BestSRID for a person to cater to less
>>>>>> technical users I find extremely annoying as I can think of 20
>>>>>> "BestSRID" depending on what I am doing.  If they get to that
>>>>>> level of sophistication, I would rather have them think a little
>>>>>> more  and understand the implications of those decisions.
>>>>>>
>>>>>> We must learn to crawl before we can learn to walk,because
>>>>>> walking without understanding will just get you into trouble in
>>>>>> the long run.
>>>>>>
>>>>>>
>>>>>>  Thanks,
>>>>>> Regina
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: postgis-devel-bounces@...
>>>>>> [mailto:postgis-devel-bounces@...] On Behalf
>>>>>> Of Paul Ramsey
>>>>>> Sent: Friday, October 30, 2009 9:47 PM
>>>>>> To: PostGIS Development Discussion
>>>>>> Subject: Re: [postgis-devel] Geog/Geom Hack
>>>>>>
>>>>>> You *can*, but I strongly doubt you *will*. Because there's
>>>>>> nothing in geography that isn't already in geometry. So you as a
>>>>>> primary geometry user are going to have no working need to cast
>>>>>> things
>>>>>>          
>> to geography.
>>  
>>>>>> On the other hand, the very first question from users of
>>>>>> geography will be "how can I access ?" So having a relatively
>>>>>> full set of functions already available in geography makes sense
>>>>>> to me, even if they are hacked in with a planar trick.
>>>>>>
>>>>>> P.
>>>>>>
>>>>>> On Fri, Oct 30, 2009 at 5:46 PM, Paragon Corporation wrote:
>>>>>>          
>>>>>>> Paul,
>>>>>>> I can put a functional geography index on can't I and take
>>>>>>> advantage of geography index bindings?
>>>>>>>
>>>>>>> Lets say I have a large network of tables broken out by region
>>>>>>> so I know a specific table has one srid.
>>>>>>>
>>>>>>> For many queries, I may go to that table directly or if I'm
>>>>>>> doing single geometry processing, really don't care what srid as
>>>>>>> long as its in utm or whatever - so I can use the full power of
>>>>>>> GEOS.
>>>>>>>
>>>>>>> For my across the board distance checks and so forth, I would
>>>>>>> want to use geography and I could use a geography index if I put
>>>>>>> a functional geography index on my geometry correct?  Though
>>>>>>> that needs some more
>>>>>>>            
>>>>>> testing.
>>>>>>          
>>>>>>> So in short if 90% of my workload involves geometry processing,
>>>>>>> I will want to keep my data in geometry
>>>>>>>
>>>>>>> But the 10% I would want to convert to geography on the fly.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Regina
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: postgis-devel-bounces@...
>>>>>>> [mailto:postgis-devel-bounces@...] On Behalf
>>>>>>> Of Paul Ramsey
>>>>>>> Sent: Friday, October 30, 2009 8:34 PM
>>>>>>> To: PostGIS Development Discussion
>>>>>>> Subject: Re: [postgis-devel] Geog/Geom Hack
>>>>>>>
>>>>>>> I'm not sure I understand why you would ever convert a geometry
>>>>>>> to a geography as part of a query on a geometry table. I fully
>>>>>>> expect geography to be used as a storage type, because of the
>>>>>>> utility of having the correct spherical indexes, which are not
>>>>>>> available when you're just converting in via a cast. Since
>>>>>>> there's no functions available on geography that are not already
>>>>>>> available on geometry, why would you ever do a
>>>>>>> geometry->geography cast unless you are (a) testing geography or
>>>>>>> (b) bulk converting a table into geography for
>>>>>>>            
>>>>>> storage in that type.
>>>>>>          
>>>>>>> P.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Oct 30, 2009 at 5:24 PM, Paragon Corporation wrote:
>>>>>>>            
>>>>>>>> Paul,
>>>>>>>> I would rather you didn't for 2 reasons
>>>>>>>>
>>>>>>>> 1) I'm lazy and for each of these things we'd have to apply the
>>>>>>>> text additional function proto hack to prevent from it breaking
>>>>>>>>              
>> geometry.
>>  
>>>>>>>> which we will probably end up taking out anyway.
>>>>>>>>
>>>>>>>> 2) I don't like the hiddenness of it since it becomes
>>>>>>>> especially annoying if you have your native in geometry and you
>>>>>>>> are converting to geography for a special usecase, then you end
>>>>>>>> up with a slower implementation
>>>>>>>>
>>>>>>>> as you would really end up doing accidentally
>>>>>>>>
>>>>>>>> geometry -> geography -> geometry ->operation (and why do I
>>>>>>>> want my calcs done in UTM?)
>>>>>>>>
>>>>>>>> Instead of the more efficient
>>>>>>>>
>>>>>>>> geometry -> operation
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Regina
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: postgis-devel-bounces@...
>>>>>>>> [mailto:postgis-devel-bounces@...] On
>>>>>>>> Behalf Of Paul Ramsey
>>>>>>>> Sent: Friday, October 30, 2009 8:16 PM
>>>>>>>> To: PostGIS Development Discussion
>>>>>>>> Subject: [postgis-devel] Geog/Geom Hack
>>>>>>>>
>>>>>>>> I'm interested to know what the general opinion is of the trick
>>>>>>>> I've used on
>>>>>>>> ST_Buffer(geography):
>>>>>>>>
>>>>>>>>
>>>>>>>>              
>>> http://trac.osgeo.org/postgis/browser/trunk/postgis/geography.sql.in.
>>>    
>>>>>>>> c
>>>>>>>> #L541
>>>>>>>>
>>>>>>>> I ask because I could apply the same idea to the larger suite
>>>>>>>> of OGC SFSQL predicates before release. Is half-a-loaf better
>>>>>>>> than no loaf in
>>>>>>>>              
>>>>>>> this case?
>>>>>>>            
>>>>>>>> (Note that there will be failure cases for really large
>>>>>>>> geometry, like a polygon of "Asia" or "Russia" that have
>>>>>>>> polygons over the
>>>>>>>> dateline.)
>>>>>>>>
>>>>>>>> P.
>>>>>>>> _______________________________________________
>>>>>>>> postgis-devel mailing list
>>>>>>>> postgis-devel@...
>>>>>>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> postgis-devel mailing list
>>>>>>>> postgis-devel@...
>>>>>>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>>>>>>
>>>>>>>>              
>>>>>>> _______________________________________________
>>>>>>> postgis-devel mailing list
>>>>>>> postgis-devel@...
>>>>>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> postgis-devel mailing list
>>>>>>> postgis-devel@...
>>>>>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>>>>>
>>>>>>>            
>>>>>> _______________________________________________
>>>>>> postgis-devel mailing list
>>>>>> postgis-devel@...
>>>>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> postgis-devel mailing list
>>>>>> postgis-devel@...
>>>>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>>>>
>>>>>>          
>>>>> _______________________________________________
>>>>> postgis-devel mailing list
>>>>> postgis-devel@...
>>>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> postgis-devel mailing list
>>>>> postgis-devel@...
>>>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> postgis-devel mailing list
>>>>> postgis-devel@...
>>>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>>>
>>>>>        
>>>> _______________________________________________
>>>> postgis-devel mailing list
>>>> postgis-devel@...
>>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>>
>>>>
>>>>      
>>> --------------------------------------------------------------------
>>> --
>>> --
>>>
>>> _______________________________________________
>>> postgis-users mailing list
>>> postgis-users@...
>>> http://postgis.refractions.net/mailman/listinfo/postgis-users
>>>      
>>
>>
>> --
>> ------------------------------
>> José Carlos Martínez Llario
>>
>> Producción Cartográfica y SIG.
>> Dpto. Ingeniería Cartográfica.
>> Univ. Politécnica de Valencia.
>>
>> E-mail: jomarlla@...
>> Telf: 963877007 ext. 75599
>> ------------------------------
>>
>> _______________________________________________
>> postgis-users mailing list
>> postgis-users@...
>> http://postgis.refractions.net/mailman/listinfo/postgis-users
>>
>>
>> _______________________________________________
>> postgis-users mailing list
>> postgis-users@...
>> http://postgis.refractions.net/mailman/listinfo/postgis-users
>>  
>
>

--
------------------------------
José Carlos Martínez Llario

Producción Cartográfica y SIG.
Dpto. Ingeniería Cartográfica.
Univ. Politécnica de Valencia.

E-mail: jomarlla@...
Telf: 963877007 ext. 75599
------------------------------

_______________________________________________
postgis-users mailing list
postgis-users@...
http://postgis.refractions.net/mailman/listinfo/postgis-users


_______________________________________________
postgis-devel mailing list
postgis-devel@...
http://postgis.refractions.net/mailman/listinfo/postgis-devel

[Havard Tveite]

My opinion is, that if this is to be implemented, it must be
properly documented (for all affected functions and for the
geography support in general).  The support for geography in
1.5 will also have to be called "experimental" with this kind
of behaviour.

Since the plan is to implement all the functions properly
in the future, I think it is a good idea to use the function
names that are going to be used in the future (as Paul
suggests).  However, I guess it can be a lot of work to
do a proper implementation of some of these functions for
geography.

Paul's approach is clearly a hack, and the results will be
unreliable.
Examples: Using this approach, a geography line may not be
contained in it's buffer.  An intersection between to
geography lines will in the normal case not be on any of the
original lines.
So, we must expect a lot of topological inconsistencies
using this approach.

For cases where it is not possible to find an OK "BestSRID",
an error should probably be thrown.

Håvard Tveite

Paul Ramsey wrote:

> I'm interested to know what the general opinion is of the trick I've
> used on ST_Buffer(geography):
>
> http://trac.osgeo.org/postgis/browser/trunk/postgis/geography.sql.in.c#L541
>
> I ask because I could apply the same idea to the larger suite of OGC
> SFSQL predicates before release. Is half-a-loaf better than no loaf in
> this case? (Note that there will be failure cases for really large
> geometry, like a polygon of "Asia" or "Russia" that have polygons over
> the dateline.)
>
> P.

--
Håvard Tveite
Department of Mathematical Sciences and Technology, UMB
Drøbakveien 31, POBox 5003, N-1432 Ås, NORWAY
Phone: [phone] Fax: [phone] http://www.umb.no/imt/
_______________________________________________
postgis-devel mailing list
postgis-devel@...
http://postgis.refractions.net/mailman/listinfo/postgis-devel

[Paragon Corporation-2]

Havard,

Good points. You stated my concerns better than I could.  

I see the benefit of having these functions and even think we should have
them linked in our documentation, but I don't want to "pollute" our
production waters with them.  So I would much prefer just a link to these
functions as a separate thing people can improve on.  As Nicklas and I think
Steve mentioned -- use it almost like a tutorial to demonstrate how you can
expand on the functionality of geography and see how people improve on it.

the problem with putting it in our production code is
a) People will see it as a black box and won't bother to look behind the
covers and then they'll be disappointed when they run into issues and think
the whole geography datatype is a hack.
b) With our new policy of release, we won't be able to make patches to it or
add new ones until the next minor.  Which to me puts novices at a great
disadvantage.
c) I don't feel we know absolutely the best way of doing these even from a
hack point of view and I would like to see what others come up with as
solutions.

The geography functions we have in place are really spectacular I think.
They do the right thing - they measure around a sphere/spheroid and use a
more advanced spatial index (though just WGS84 for this first release).
Sure they don't do everything, but they satisfy the number one need of many
people -  How do I figure out proximities, areas, lengths and get real
accurate distances with long lat data and still have full power of spatial
indexes?

I would hate for people to think the whole thing is a hack by introducing
these things in what we call "production".

Thanks,
Regina

-----Original Message-----
From: postgis-devel-bounces@...
[mailto:postgis-devel-bounces@...] On Behalf Of Havard
Tveite
Sent: Monday, November 02, 2009 5:13 AM
To: PostGIS Development Discussion
Subject: Re: [postgis-devel] Geog/Geom Hack

My opinion is, that if this is to be implemented, it must be properly
documented (for all affected functions and for the geography support in
general).  The support for geography in
1.5 will also have to be called "experimental" with this kind of behaviour.

Since the plan is to implement all the functions properly in the future, I
think it is a good idea to use the function names that are going to be used
in the future (as Paul suggests).  However, I guess it can be a lot of work
to do a proper implementation of some of these functions for geography.

Paul's approach is clearly a hack, and the results will be unreliable.
Examples: Using this approach, a geography line may not be contained in it's
buffer.  An intersection between to geography lines will in the normal case
not be on any of the original lines.
So, we must expect a lot of topological inconsistencies using this approach.

For cases where it is not possible to find an OK "BestSRID", an error should
probably be thrown.

Håvard Tveite

Paul Ramsey wrote:

> I'm interested to know what the general opinion is of the trick I've
> used on ST_Buffer(geography):
>
> http://trac.osgeo.org/postgis/browser/trunk/postgis/geography.sql.in.c
> #L541
>
> I ask because I could apply the same idea to the larger suite of OGC
> SFSQL predicates before release. Is half-a-loaf better than no loaf in
> this case? (Note that there will be failure cases for really large
> geometry, like a polygon of "Asia" or "Russia" that have polygons over
> the dateline.)
>
> P.

--
Håvard Tveite
Department of Mathematical Sciences and Technology, UMB Drøbakveien 31,
POBox 5003, N-1432 Ås, NORWAY
Phone: [phone] Fax: [phone] http://www.umb.no/imt/
_______________________________________________
postgis-devel mailing list
postgis-devel@...
http://postgis.refractions.net/mailman/listinfo/postgis-devel



_______________________________________________
postgis-devel mailing list
postgis-devel@...
http://postgis.refractions.net/mailman/listinfo/postgis-devel

[Mark Cave-Ayland-3]

Paragon Corporation wrote:

> I'm not really in disagreement with Paul.  I see his point too.  I'm
> just prodding him to think about all his use cases a little more because
> I don't feel he has.
>  
> My feelings to sum up
> 1) We have not thought about the complete ramifications of this hack and
> I'm really concerned about the novice that transitions to an expert
> rather than just getting them hooked on PostGIS.  Perhaps I'm being
> overly silly with that and even said, Paul's approach might be an easier
> to transition solution.
>  
> 2) My concern is the penalty of putting it in and having to take it out
> later might be very great (both from a code, testing,  as well as a
> mindset perspective).  I just feel it needs more thought and testing and
> really if we want to make our December deadline, I don't want it rushed
> in so lightly.

I agree with Regina here: I'd be a bit nervous about creating a whole
set of functions based on a UTM hack that hasn't been field-tested. I
think I'd like to see one or two functions based upon the geography type
which make use of the hack in 1.5, and then if the feedback is good,
roll it out to other functions in a later release.


ATB,

Mark.

--
Mark Cave-Ayland - Senior Technical Architect
PostgreSQL - PostGIS
Sirius Corporation plc - control through freedom
http://www.siriusit.co.uk
t: [phone]

Sirius Labs: http://www.siriusit.co.uk/labs
_______________________________________________
postgis-devel mailing list
postgis-devel@...
http://postgis.refractions.net/mailman/listinfo/postgis-devel