Astroquery: Organization?

[keflavich]

1214 raised an issue where there are now multiple JPL-provided services, raising the question of whether to host them under jpl/ or jpl_<servicename>/. I lean toward the former, but that is something new.

This issue prompted me to consider whether a broader reorganization might be useful. There are now several planetary/solar system modules, several line modules, and many more generic on-sky query modules. I think it would be convenient and helpful to have additional astroquery modules astroquery/planetary, astroquery/sky, astroquery/lines, etc. that would populate their namespaces with all relevant astroquery packages. These would be 'shortcut' subpackages meant to help people find the right tools more easily.

If we went with such a change, it would warrant a minor or major version number change.

[mommermi]

I propose astroquery/solarsystem with submodules mpc, jpl and other services that we plan to implement as part of sbpy.

[bsipocz]

I'm super convinced for the super big modules, but a bit of structuring may help.
The main question is whether that would help discovering the services or make it more obscure and difficult.

E.g. sky is not very helpful imo, but maybe structuring all the line databases under lines or something similar is helpful, after all they can share an API that is different to the rest. If we go this way, mpc and jpl could stay at top level as at the end of the day they offer some sky region/coordinate querying functionality.

E.g. cds could have simbad/vizier/xmatch as well as the current cds, wfau can have ukirt and vsa. But indeed, what's the fraction of astronomers currently using simbad who knows that it's a cds product, so they should look for it there?

[keflavich]

Right. I'm suggesting these would be additional links, not replacements for the existing flat structure.

Good point that cds/simbad might hide more than reveal.

[bsipocz]

Yes, I don't actually mind to provide all modules in the top level namespace as well as lower down.

[mommermi]

Would you like the Solar System stuff to be top-level, too? Those modules might be different enough to warrant putting them all under one umbrella...

[keflavich]

I propose adding a surveys/ subdirectory, which currently would include magpis, alfalfa, ukidss, vsa, maybe.

We probably need several namespaces to include multiple items. For example, magpis is both a survey (it's the name of an actual survey and the primary hosting site for that survey) and a cutout service for other surveys, so it belongs under surveys/ and image_services/.

Is it safe and reasonable to host these folders under some specific heading and simply import them into the other namespaces they reasonably could live in?

[bsipocz]

I think that should be easily doable to make them available from multiple namespaces. I would argue to make the "surveys" the default, big place.

However not sure whether moving sdss there would make any sense, also vsa is the borderline case as those are dedicated telescopes, too and e.g. vsa is not serving only one survey.

[keflavich]

Right, good points.

I'm raising this because I've recently added a single-survey server (though the parent serves other things):https://github.com/astropy/astroquery/pull/1324 and I'm working on another one that's even more one-off.

[bsipocz]

Yes, that one should definitely go under a survey substructure. Or could even go under a Herchel module, but given there isn't a central archive for all its programs it may not be that useful.

[bsipocz]

however keeping alfaalfa around may not make that much sense as it point to ned anyway: https://github.com/astropy/astroquery/issues/1285