postgrespro/pgsphere project tree reorganization
26 views
Skip to first unread message
Vitaly Davydov
Jun 5, 2023, 9:01:19 AM6/5/23
to pgSphere users and developers
Dear Colleagues,
I was assigned to continue developing of postgrespro/pgsphere. We have some plans for changes in pgsphere but i'm not sure how it can affect your forks, if any. There are a number of topics I would like to discuss are:
- Move source files into src subdirectory.
- Optional compilation of HEALPIX+SMOC (by default is OFF).
- Limit the scope of pgsphere - do not merge pull requests with domain specific functions (like astronomy functions).
Moving source files to src subdirectory is to avoid file mess in the top dir. Optional compilation of HEALPIX is a good option for those who do not use smoc functionality - no need to install and link with 3rd party libraries. Rejecting astronomy specific functions helps to keep the project in a minimal form to be widely used in other areas. There is the idea to create a new contrib like pgsphere-astro where astronomical functions will reside.
Is it suitable for you to accept such changes?
With best regards,
Vitaly
Edward J. Sabol
Jun 5, 2023, 9:09:44 PM6/5/23
to Vitaly Davydov, pgSphere users and developers
On Jun 5, 2023, at 9:01 AM, Vitaly Davydov <vit...@gmail.com> wrote:
- Limit the scope of pgsphere - do not merge pull requests with domain specific functions (like astronomy functions).
I don't know about this. I was under the impression that pgsphere was created by astronomers for astronomers, and it just happened to be useful in other use-cases. Maybe I don't know the true history of pgsphere though. I do think you risk forking if you alienate the astronomers. Just my two cents. And I'm obviously biased since our usage is primarily in astronomy-related databases.
Can you point to specific PRs you don't want to merge?
Regards,
Ed
Vitaly Davydov
Jun 6, 2023, 1:50:21 AM6/6/23
to Edward J. Sabol, pgSphere users and developers
Dear Edward,
Thank you for the fast reply. I really appreciate it. I would like to clarify my point of view. If to look at the functionality of postgrespro/pgsphere or pgsphere/pgsphere you will not find astronomical domain specific functions. For example, the page https://pgsphere.github.io/about.html describes the project scope which includes new data types, common operations on types including rotations by Euler angles, searching and indexing. My words about limiting the project scope are about to come to an agreement with the community because the original pgsphere functionality is already limited: it doesn't contain astronomical specific stuff. Limiting the project scope allows us to keep pgSphere minimal to be comfortably applied in other areas. I do propose not to extend the project scope by adding new functionality from other domains. pgSphere is defined as the library for spherical geometry calculations. I'm ok with adding healpix + smoc because it is about tessellation and searching. But the decision to add astronomical specific functions will greatly increase the project scope. If you look at SOFA library API you can find dozens of functions for astronomical purposes. I do not like the idea of putting lib SOFA into pgSphere. So, my final conclusion - pgSphere is the library for spherical geometry. I would propose to extend and polish the existing functionality and not to add new stuff from other domains.
I understand that there are forks of pgSphere which are extended with new functionality and are used in astronomy. I do not want to break existing relations. It is why I would like to discuss it and come to an agreement. IMHO, I do not see any problems with merging the changes from upstream if a fork will contain new specific functions - it is up to the owner of the fork (except for some changes in the project tree).
The pull request I was told about is https://github.com/postgrespro/pgsphere/pull/8
I graduated as an astronomer as well but in the last 20+ years I work as a software developer as well. I understand that it may be comfortable for astronomers to have some astronomical functions in pgSphere. But my 20 years experience in software development helped me to understand the importance of keeping the original project scope to avoid the creation of the library with monstrous functionality that is hard to support.
pgSphere may be the basis for other projects. One can create pgsphere-astro if there is the need to have astronomical functions in SQL.
I've found one interesting article that may help to come to an agreement. The authors introduce pgAstro library that is based on pgSphere.
http://www.sai.msu.su/~chil/publications/ADASSXIII_poster.pdf
With best regards,
Vitaly
Thank you for the fast reply. I really appreciate it. I would like to clarify my point of view. If to look at the functionality of postgrespro/pgsphere or pgsphere/pgsphere you will not find astronomical domain specific functions. For example, the page https://pgsphere.github.io/about.html describes the project scope which includes new data types, common operations on types including rotations by Euler angles, searching and indexing. My words about limiting the project scope are about to come to an agreement with the community because the original pgsphere functionality is already limited: it doesn't contain astronomical specific stuff. Limiting the project scope allows us to keep pgSphere minimal to be comfortably applied in other areas. I do propose not to extend the project scope by adding new functionality from other domains. pgSphere is defined as the library for spherical geometry calculations. I'm ok with adding healpix + smoc because it is about tessellation and searching. But the decision to add astronomical specific functions will greatly increase the project scope. If you look at SOFA library API you can find dozens of functions for astronomical purposes. I do not like the idea of putting lib SOFA into pgSphere. So, my final conclusion - pgSphere is the library for spherical geometry. I would propose to extend and polish the existing functionality and not to add new stuff from other domains.
I understand that there are forks of pgSphere which are extended with new functionality and are used in astronomy. I do not want to break existing relations. It is why I would like to discuss it and come to an agreement. IMHO, I do not see any problems with merging the changes from upstream if a fork will contain new specific functions - it is up to the owner of the fork (except for some changes in the project tree).
The pull request I was told about is https://github.com/postgrespro/pgsphere/pull/8
I graduated as an astronomer as well but in the last 20+ years I work as a software developer as well. I understand that it may be comfortable for astronomers to have some astronomical functions in pgSphere. But my 20 years experience in software development helped me to understand the importance of keeping the original project scope to avoid the creation of the library with monstrous functionality that is hard to support.
pgSphere may be the basis for other projects. One can create pgsphere-astro if there is the need to have astronomical functions in SQL.
I've found one interesting article that may help to come to an agreement. The authors introduce pgAstro library that is based on pgSphere.
http://www.sai.msu.su/~chil/publications/ADASSXIII_poster.pdf
With best regards,
Vitaly
вт, 6 июн. 2023 г. в 04:09, Edward J. Sabol <edward...@gmail.com>:
Edward J. Sabol
Jun 6, 2023, 11:07:25 AM6/6/23
to Vitaly Davydov, pgSphere users and developers
On Jun 6, 2023, at 1:50 AM, Vitaly Davydov <vit...@gmail.com> wrote:
The pull request I was told about is https://github.com/postgrespro/pgsphere/pull/8
I'm actually very interested in this functionality.
I've found one interesting article that may help to come to an agreement. The authors introduce pgAstro library that is based on pgSphere.
The pgastro.org website no longer exists, unfortunately. I suspect this was a grad student project that became defunct after the student moved on. The only references I've found on the Internet are to a single published paper and this ADASS poster. There's no code that I could find on the Internet (unless it changed names post-publication).
Regards,
Ed
Reply all
Reply to author
Forward
0 new messages