Configuration

[First]

[Project]

[Mysql]

[Web]

[VO options]

[Fields]

[Photometry]

[Search Opts.]

[File Paths]

[Scripts]

[Registry]

[Spectra]

[Links]

[References]

Catalogue fields

This one is probably the most important section of the configuration. And, given that you must write a lot of information, it can be the most confusing one. So we will try to explain the meaning of everything.

The main idea is that your catalogue can be seen as a series of rows (one for each observation) and columns (a column for each property of that observation).

We want that information stored in a database table with the same structure: rows and columns.

And you probably have the information in a CSV file with the information separated by commas (meaning different columns).

Here we ask you several things about the columns.

In order to explain this more clearly let's look at the example included with the distribution.

The structure of the data is:

and you have it as a CSV file like:

The idea is that there are 8 columns with different meanings. We want to know the meaning of each column (and some extra information).

Now let's go to the configuration form:

(Click in the image for a larger version. It will be opened in a different window)

Here you must fill as many rows as columns you have in your CSV file. That is, you have to give information about the 8 properties in your catalogue.

You can also add columns in this configuration that are not part of your CSV or the database table. In this case we have included two columns (lnk_dat, lnk_png) as placeholders to show links to datafiles. These columns will be further configured later, in the Links section.

• First, you must give a name to each property. This name will be the name of this property in the MySQL database when we create it (or it must be the name of the column in the database if you have already created it by yourself). It can only contain alphanumeric characters and the '_' symbol. And none of them can be a reserved word in MySQL.
• Then you say the datatype of this field. It can be: string, double or integer. This will be used to create the table properly. String fields allow searches with wildcards characters whereas numerical fields allow searches by range (see the Search Options section below).
• The 'Show' column says if you want to show this field in the search results or not deppending on the level of verbosity required. The ConeSearch protocol defines three different possible levels of verbosity: 1 for minimal verbosity (only show the most important properties), 2 for medium verbosity (this is the default) and 3 for maximum (usually: show all fields). You can specify 'never' if you don't want that a property is shown in any case. In our example catalogue we want to show all the available columns by default, so we configure all the columns with 'VERB=1' so that all of them will be always shown in the search results.
• If you mark 'No VO = Yes' this column won't be show in the response of VO services (ConeSearch for instance). This makes sense when you want to show something in the web page but it does not make sense to include it in listings as VOTable or CSV.
• By default, you have the option to sort the results table clicking in any column header. If you consider that it does not make sense to do this for some specific column, you can configure 'No sort = Yes'. In our example catalogue we do this for the last two columns (lnk_dat, lnk_png) that are special columns that we have included here to show links and do not correspond to columns in the database.
• 'CSV Order': here you must say in what position is this field in your CSV file. In our case, we have written the fields here in the same order than in the CSV file and the numbers run from 1 to 8. This only makes sense for columns that are already included in the CSV file. If we want to add other columns in this configuration we must set 'CSV Order = -1'.
• 'Res. Order': here you must say how you want to order the fields in search results. For instance, in our example, the 'epoch' property is in the eight position in the CSV file (before J,H,Ks magnitudes) but we want to show it in the last position in the search results. And as we don't want to show ra_hms and dec_hms we don't give an order for them.
• 'Title': this is the title that you want for this field when we show it in the search results table in the web page. For instance, we decide that the DECdeg column must be shown as 'DEC (ICRS)' although its name in the database will continue to be 'DECdeg'.
• You can also group several columns under the same title. If you want to do so, you just need to use the same word for them in the 'Web group' column. We don't need to do that in this case.
• 'Unit': write a string for the unit corresponding to this field. Leave it empty if units don't apply.
• 'Description': a text description of this property. It will be used both in the web page (a window is opened with the field description if the users moved the mouse over the "?" symbol) and the ConeSearch VO responses. You can use html here but be cautious because some html or symbols could generate problems (or look bad) in the VO services. If this happens try to use simple ascii here (no accents, no symbols, no html tags).
• 'UCD': the UCD's, or Unified Content Descriptors, are a special vocabulary defined for the Virtual Observatory to give more information, in VO services, about the physical meaning of each field. The ConeSearch protocol requires:
  • UCD=POS_EQ_RA_MAIN for RAdeg.
  • UCD=POS_EQ_DEC_MAIN for DECdeg.
  • UCD=ID_MAIN for the main object identifier (it will probably there exist such a field in your catalogue, in our example, it is the ID field).
  
  (In this case, as there are not RA,DEC coordinates in the catalogue, the first two requirements do not apply).

  For the other fields you can use the UCD builder at the CDS to find the adequate UCD for each case. It is not a big problem if you decide to leave this blank if you don't find a good UCD for a given catalogue property.

• The 'UType' column allows you to include a reference to a VO data model. In our example we are not going to go that further.
• 'Format (Web)' gives you the option to specify a particular format for this column when it is displayed in the web page. In some cases, for instance, it looks ugly to show to omany decimals in a column and you could prefer to limit them. Formats should be compliant to those allowed by the PHP sprintf function.
• 'Format (VO)' gives you the option to specify a particular format for this column when it is included in a VO response. In most cases you won't need to restrict anything here and you will leave this option empty to show, in the VO response, the actual content of your database.
• 'Phot. Group': if some fields correspond to photometric data give a name here to label the group to which it belongs. Then you will have to describe the group properties in the 'Photom. Groups' configuration section. Take into account that several fields can belong to the same group (for instance, a given magnitude and its error). In our example catalogue we don't have photometric properties, so we don't write anything here.

Here you can see the effect of some of these configuration options (but for understanding the three last columns you have to go to the Links and References sections).