add function: spos and spbox, for create gist index.

[hebl]

Add 2 functions:

• spos(ra,dec): create a spoint from (ra,dec) in degree.
• spbox(ra_tl,dec_tl,ra_bl,dec_bl,ra_br,dec_br,ra_tr,dec_tr) in degree.

Example:

• CREATE INDEX some_tbl_idx_spos ON some.tbl USING GIST(spos(RA,Dec));
• CREATE INDEX some_tbl_idx_spbox ON some.tbl USING GIST(spbox(ra_tl,dec_tl,ra_bl,dec_bl,ra_br,dec_br,ra_tr,dec_tr));

[ghost]

Thank you for your request! Creating PgSphere objects from coordinates in degrees is certainly an important use case, especially for the virtual observatory community (to which I belong myself). However, I would prefer a more uniform naming, such as

• spoint_deg(ra, dec) to create an spoint from coordinates in degrees, and
• spoly_deg(ra0, dec0, ra1, dec1, ...) to create an spoly from coordinates in degrees, having also a flexible number of arguments, see https://www.postgresql.org/docs/current/static/xfunc-sql.html#XFUNC-SQL-VARIADIC-FUNCTIONS
• (and possibly similar functions for scircle, etc.)

The overhead of using plpgsql makes me at bit uneasy. Maybe an implementation in 'language sql' could be sufficiently efficient, but an implementation in C would have the additional benefit of sharing the same style with the rest of the PgSphere code base. Thoughts?

[funbringer]

@mnullmei +1 for implementation in C

[hebl]

I have added functions: spoint_deg, sploy_deg, implementation in C.

[funbringer]

Hi again,

The diff is large. I guess it has to do with your indentation settings. Could you fix that?

[hebl]

@funbringer, New file: astro.h, astro.c, pgs_astro.sql.in and astro.md.

[funbringer]

@hebl,

I'm sorry, but I don't get it. What are you trying to say? You've changed 8 files, including polygon.c & polygon.h. Most of the changes are completely unnecessary due to incorrect indentation settings.

[ghost]

@hebl Thank you for providing a C implementation. But due to public holidays over here, I will find time to look into it only by the end of next week.

[funbringer]

@mnullmei, @hebl, looks like this PR has stalled. Perhaps we should clean it up a little bit and merge it. Thoughts?

[ghost]

Perhaps we should clean it up a little bit and merge it.

Agreed, that would be actually my plan as well.

One thing I still would like to add is a VARIADIC overload of spoly_deg(), as hinted above.