[postgis-users] [postgis-devel] Geog/Geom Hack
Stephen Woodbridge
woodbri at swoodbridge.com
Sat Oct 31 09:47:29 PDT 2009
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 at postgis.refractions.net
> [mailto:postgis-devel-bounces at postgis.refractions.net] *On Behalf Of
> *nicklas.aven at jordogskog.no
> *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 at postgis.refractions.net
> >> [mailto:postgis-devel-bounces at postgis.refractions.net] 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 at postgis.refractions.net
> >> [mailto:postgis-devel-bounces at postgis.refractions.net] 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 at postgis.refractions.net
> >>> [mailto:postgis-devel-bounces at postgis.refractions.net] 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 at postgis.refractions.net
> >>>> [mailto:postgis-devel-bounces at postgis.refractions.net] 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 at postgis.refractions.net
> >>>>> [mailto:postgis-devel-bounces at postgis.refractions.net] 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 at postgis.refractions.net
> >>>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
> >>>>>
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> postgis-devel mailing list
> >>>>> postgis-devel at postgis.refractions.net
> >>>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
> >>>>>
> >>>> _______________________________________________
> >>>> postgis-devel mailing list
> >>>> postgis-devel at postgis.refractions.net
> >>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
> >>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> postgis-devel mailing list
> >>>> postgis-devel at postgis.refractions.net
> >>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
> >>>>
> >>> _______________________________________________
> >>> postgis-devel mailing list
> >>> postgis-devel at postgis.refractions.net
> >>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
> >>>
> >>>
> >>> _______________________________________________
> >>> postgis-devel mailing list
> >>> postgis-devel at postgis.refractions.net
> >>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
> >>>
> >> _______________________________________________
> >> postgis-devel mailing list
> >> postgis-devel at postgis.refractions.net
> >> http://postgis.refractions.net/mailman/listinfo/postgis-devel
> >>
> >>
> >> _______________________________________________
> >> postgis-devel mailing list
> >> postgis-devel at postgis.refractions.net
> >> http://postgis.refractions.net/mailman/listinfo/postgis-devel
> >>
> >>
> >> _______________________________________________
> >> postgis-devel mailing list
> >> postgis-devel at postgis.refractions.net
> >> http://postgis.refractions.net/mailman/listinfo/postgis-devel
> >>
> >_______________________________________________
> >postgis-devel mailing list
> >postgis-devel at postgis.refractions.net
> >http://postgis.refractions.net/mailman/listinfo/postgis-devel
> >
> >
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users
More information about the postgis-users
mailing list