[postgis-devel] Re: Q3C

[Paul Ramsey]

For those listening from home, the key issues of geodetic support are:

- indexing
- useful functions

For indexing, the main problem is having an index that can deal with
the singularity points at the poles and across the dateline. Indexes
are used to having nice cartesian spaces to divvy up, not crazy
geometries that wrap on themselves, like circles and spheres.

So, the trick is to simply convert the spherical coordinates (omega,
phi) into geocentric ones (x,y,z) and index on those. There are some
special cases to handles for objects that encircle the x/y/z axes, but
otherwise the system should work pretty well.

For useful functions, some operations are best re-written in spherical
terms. Length, distance, area. Others would be very hard to do, but
can be approximated for most use cases by doing quick conversions into
local planar systems. If we wrap that conversion under the PgSQL
casting system, we can transparently make use of all the existing
geometry functions, which would be pretty damn cool.

Paul

On Wed, Mar 18, 2009 at 4:33 PM, Martin Davis <mbdavis at refractions.net> wrote:
> Er - of course, I remember this.  Those listening at home might not have
> heard of it though...   8^)  The context switch from indexing to geometry
> functions might have thrown them off the scent a bit too...
>
> Paul Ramsey wrote:
>>
>> We figured this out, remember? We're converting to geocentric
>> coordinates for the purpose of indexing.
>>
>> P
>>
>> On Wed, Mar 18, 2009 at 4:16 PM, Martin Davis <mbdavis at refractions.net>
>> wrote:
>>
>>>
>>> Hmmm.
>>>
>>> How will you handle indexing geometries which cross the dateline (which
>>> includes crossing the poles)?
>>>
>>> Paul Ramsey wrote:
>>>
>>>>
>>>> On Wed, Mar 18, 2009 at 2:41 PM, Paul Ramsey <pramsey at opengeo.org>
>>>> wrote:
>>>>
>>>>
>>>>>
>>>>> I'm having a grand time thinking about what the appropriate return
>>>>> value of geography::geometry is :)
>>>>>
>>>>>
>>>>
>>>> My current thought is an automagical planar projection into an
>>>> appropriate UTM zone or polar stereographic system, based on the
>>>> centroid of the feature. With the extra complication of first looking
>>>> into the projection cache to see what the last projection used was,
>>>> and if it's close enough, using that. Hopefully that way, in the case
>>>> of st_function(geog1, geog2) the two arguments would be both cast into
>>>> the same plane. This would magically allow the geography module to
>>>> make use of all the geometry functions, and only break for really
>>>> large objects that exceed our chosen planar areas.
>>>>
>>>> P.
>>>> _______________________________________________
>>>> postgis-devel mailing list
>>>> postgis-devel at postgis.refractions.net
>>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>>
>>>>
>>>>
>>>
>>> --
>>> Martin Davis
>>> Senior Technical Architect
>>> Refractions Research, Inc.
>>> (250) 383-3022
>>>
>>> _______________________________________________
>>> 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
>>
>>
>
> --
> Martin Davis
> Senior Technical Architect
> Refractions Research, Inc.
> (250) 383-3022
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>