This is an old revision of the document!
The goal is to allow introduction of a standard observing proposals to the system. The users should be particularly able to:
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.