[postgis-devel] Astronomical extensions

[Jim Bosch]

Chris Hodgson wrote:
> 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 ellipses definitely could be turned into basic polygons for 
comparisons with other objects, which would be fine; this would deal 
with queries like "which galaxies overlap this ugly-polygon-shaped 
exclusion region", or "which stars fall on the same rectangular CCD".  
At least, I can't think of any times when such an approximation wouldn't 
be appropriate, since it's almost always the boolean operations, and the 
borders of galaxies are fuzzy anyhow.  It's only for the unary 
operations that having a "true" ellipse would matter.  But you may be 
right about it being a totally different type.  The challenge is then 
making a new type with a set of operators that can use both the PostGIS 
indexes and the new indexes.

> 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.
>
That is indeed a problem, and it's one I didn't mention because I think 
there are other solutions for it better than PostGIS, and it's a whole 
new can of worms.  From PostGIS, I'm primarily looking for database 
objects that represent those on a single astronomical image, which is 
indeed flat (though their relation to the spherical sky is not quite 
indentical to the relationship of earth-objects to the spherical earth).
> 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
>

Thanks!

Jim



> 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
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel