The goal is to allow introduction of a standard observing proposals to the system. The users should be particularly able to:
Probably the best way how to do this is to present this as a Web application. RTS2 currently includes Web server (rts2-xmlrpcd) which can be used to generate Web pages. The idea of the flow of pages is described bellow, together with status of their implementation:
Simple page with a single text input. User enters anything - SIMBAD name, coordinates,.. - and we try our best to resolve target name. The following should be looked for:
After user enters target and click submit button, new page appears, offering:
User can pick what he/she wants, and go to proposal details page.
Almost done on /addtarget page. Missing is SIMBAD support - due to various reasons, I would like to get rid of gSOAP library which was used for SIMBAD resolving, and implement own HTTP client for this. The work to finish this is almost done.
Requires target adding working with SIMBAD resolving - not started yet.
I do not belive that it is easily possible to store all strange observing constraints in the database. Major problem is that we do not exactly know in advance which constrains are needed. And it is a real pain to make database change for every new constrain.
The ideal structure should be split into database and XML supporting files. Database is great for indexing (storing IDs of proposals), XML files are great for possibility to easy extend them without any significant penalty. The ideal design should merge those two advantages to create a flexible system which will suit our needs.
The first item is implemented in target table. The second is partially implemented (as part of GA scheduling experiment). The last is partially implemented in target table, but must be definitly moved out of the database.
Also the next design should be proposal centric. Current design is target centric - e.g. it is impossible to schedule observation based on proposal, it is only possible to schedule observation based on target. Although multiple targets for same object can be created to overcome this problem, this is most probably not the correct solution.
Currently RTS2 provides those tools for creating and managing observation targets database:
There is target table in RTS2 database, which holds target information.