The goal is to allow introduction of a standard observing proposals to the system. The users should be particularly able to:

1. Create new targets through web interface
2. Edit various options (constraints) for their observations
3. Query for the best next observation
4. See when the target was observed

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:

• SIMBAD
• targets table
• try to parse as various RA DEC string

After user enters target and click submit button, new page appears, offering:

• list of targets with similar names already present in the database
• SIMBAD resolved names, with list of targets around those coordinates (think about somebody using NGC designation for M 57..)
• resolved coordinates (in case user enters something like 12 50 26 +36 45 48.8)

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.

User confirms his details (name, email where and if targets should be send to,..) and add constrains for proposal (minimum and maximum altitude, minimal lunar distance,..). Constraint should be implemented in list box - e.g. user can frealy edit them, add new, remove already entered,.. - that should be handled with JavaScript.

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.

1. have targets list
2. introduce proposals, which will have their PIs,..
3. introduce constraint for proposal (when to observe, how to observe, who should be notified,..)

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:

1. rts2-newtarget, which allows easy introduction (from CLI) of a new target. It included SIMBAD name resolver, so users do not have to bother with looking for coordinates
2. rts2-target which allows edition of script for devices and target management. Most commonly used options are -e/-d (enable/disable target), -p (priority), -c C0 -s 'script' (scripting management)

There is target table in RTS2 database, which holds target information.