[postgis-users] [postgis-devel] Geog/Geom Hack
Jose Carlos Martinez Llario
jomarlla at cgf.upv.es
Sat Oct 31 10:32:03 PDT 2009
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 at postgis.refractions.net
> [mailto:postgis-users-bounces at postgis.refractions.net] 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 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
>>
>>
>
>
> --
> ------------------------------
> José Carlos Martínez Llario
>
> Producción Cartográfica y SIG.
> Dpto. Ingeniería Cartográfica.
> Univ. Politécnica de Valencia.
>
> E-mail: jomarlla at cgf.upv.es
> Telf: 963877007 ext. 75599
> ------------------------------
>
> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users
>
>
> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> 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 at cgf.upv.es
Telf: 963877007 ext. 75599
------------------------------
More information about the postgis-users
mailing list