[postgis-devel] Astronomical extensions

Chris Hodgson chodgson at refractions.net
Wed Oct 25 14:42:08 PDT 2006


What functions do you want to make use of in postgis? While an Ellipse 
may be a geometry in essence, none of the existing postgis functions 
would work with geometrical representation of an ellipse - we couldn't 
use geos functions, as there is no geos ellipse type. I think that the 
calculations that astronomers would do with ellipses are probably 
entirely separate from the handling of locations (points and other 
geometries) - so you would be adding your own functions for ellipse math 
handling. Seems to me then, like the ellipse is a new type of its own.

The only thing you really want from postgis, I expect, is the spatial 
indexing, and currently postgis spatial indexes don't correctly handle 
spherical coordinates - the international dateline is the edge of the 
world as far as the indexes are concerned for regular lat/long 
projections. I'm not sure if we need an entirely different form of index 
to properly handle spherical indexing or not, but it is a limitation 
that I think astronomers would find much more problematic than the GIS 
community has so far.

I think the approach of making an entirely separate library which 
requires postgis to be installed is probably the best, at least for 
getting started and possibly for the long term. I'm not sure how much of 
the different functionalities would be compatible... the generalization 
of projections to include astronomical projections seems reasonable, but 
without a single library that supports both terrestrial and astronomical 
projections, the implementation of the transform() function becomes (I 
think significantly) more complex.

Just my initial thoughts...

Chris

Jim Bosch wrote:
> I'm exploring the possibility of extending PostGIS to make it more
> useful for astronomers (i.e. me), and I was interested in seeing if
> anyone has any advice on how best to proceed (particularly in terms of
> how to organize such things with the PostGIS internals).
> 
> There are two primary issues:
> 
> -    Astronomers deal with ellipses, and often care very much about
> ellipse-specific things.  While approximating ellipses as polygons is
> perfectly fine for topological operations (so there's no need to worry
> about multi-ellipses, etc.), being able to extract things like
> ellipticity and orientation angle from individual ellipses is of utmost
> importance.  So I'd need to make an ellipse data type, and add the
> necessary operators for it to interact sensibly with existing PostGIS
> types.  I'm not sure, however, whether I should make this a new subtype
> of the PostGIS Geometry type, or a new PostgreSQL type altogether.
> There are probably a host of other more subtle questions as well.
> 
> -    Astronomers use a totally different set of coordinate systems.  A
> very basic gnomonic projection is by far the most common, but it is
> described very differently (not to mention the fact that everything is
> inside-out, since we look at the sky, not the ground).  The astronomical
> community already has a large set of standard coordinate systems and
> standard representations for them, as well as several libraries (similar
> to PROJ4 in nature) to do the actual transformations.  This step, then,
> at least seems straightforward: add one of these libraries as an
> alternate backend for transforms, and find a way to put the astronomical
> coordinate systems in the spatial reference table.
> 
> 
> There are also two primary strategies I can think of:
> -    Make an entirely separate library that requires PostGIS to be
> installed as well.
> -    Try to integrate my extensions with PostGIS itself, making my
> additions as optional compile-time options or something (would anyone
> want them?)
> 
> 
> Any thoughts?
> 
> 
> Thanks in advance,
> 
> Jim Bosch
> 
> 
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel




More information about the postgis-devel mailing list