Page tree
Skip to end of metadata
Go to start of metadata

Notes from Group 1


Services:

SPHERE, MOVIS, EPN TA, MP3C


Stéphane Erard  to answer some of the questions from day2, about small bodies services:

• Service title

Find a handy and explicit title for your VO service - this is also used as a Unix directory name, as an SQL table name, and as an ID in the registry, so keep it simple. This is an acronym rather than a name (you will define a long name elsewhere).

No particular syntax rule, but special characters (. # - , " ' etc) can't be included. This also has political exposure, so don't call it Apollo13 if you were not the PI (wink) (you should append your project / institute name at least).

See the list of services for inspiration: http://vespa.obspm.fr (in green boxes, presented as: Title - Long name)

(service_title is used in several situations: the table name used in queries is <service_title>.epn_core; the directory name where your service is located on your server; a space name in the gitlab, see here: 2021-workshop-service-info; and it appears in the table itself for call back mechanisms, if needed).


• Target_name

It must contain only 1 name or ID of the target, not alternative names
It must not contain both the number and name of small bodies (eg: "(1) Ceres") , this would make it impossible to use on line ephemeris or even to cross-correlate services.

- The mpc EPN-TAP service (which is doing this) needs to be updated - don't use it as a model (sad) (in particular for target_name - this causes a major interoperability issue)

Compliant services with small bodies include: spectro_asteroids, M4ast, SBNAF, TNOsarecool

• Other designations etc, can be provided in alt_target_name as a list of values separated by #, e.g. "1#Ceres", etc 

• Case and spelling must follow IAU conventions, except that funny characters (esp. quotes) are forbidden and replaced by _ (and no diacritical marks, but spaces are allowed)


• Values for SPHERE service:

instrument_host_name  = "VLT" (used in spectro_asteroids for instance - as a general rule this is the name of telescope, not the observatory (ESO in this case) )

instrument_name  = "SPHERE"


UCD in measurement_type and product description (for SPHERE):

Images:

   measurement_type = "phot.radiance;obs.image" and dataproduct_type = "im"

Shape models:

  measurement_type = "pos.outline" (but TBC) and dataproduct_type = "vo"


• Ephemeris values

If you need to retrieve the phase of an object at a given moment from Miriade (which is a nice addition for the users, easily used as a search parameter): 

http://vo.imcce.fr/webservices/miriade/ephemcc_query.php?-name=a:pallas&-type=&-ep=2453002.24128009239&-mime=html

  (text or json outputs may come handy here, instead of html)

See doc here:  http://vo.imcce.fr/webservices/miriade/ (both ephemph and ephemcc services return the phase angle)

You can either retrieve all the values before ingestion and include them in the CSV, or query Miriade during ingestion (but this is a bit challenging for occasional users of Miriade)


• Question from MP3C

bib_reference can contain a list of values, eg: "dio1#dio2" or "bibcode1#bibcode2#bibcode3". This is blurring the association with the exact parameter, but still provides reference.

In addition, you may want to use external_link to point to an object page in your site (this can be a web service query) - see the exoplanets or VIMS_satellites services which are similar. This provides the user with an entry point to the complexity of your service, and can provide access to the history of parameters. 


• Small body subtypes: 

We plan to use a consistent vocabulary for all services requiring grouping of targets, based on conventions active in the field.

Please comment this page if you feel something is missing: Small bodies sub-types — (log in first, then select a sentence, click on the icon which appears after ~ 1s)

(even if you don't include such values in your service table)


  • No labels

6 Comments

  1. Anonymous

    MP3C will be able to provide best values physical parameters of asteroids. These are one value per parameter per asteroid. These values are obtained by averaging public values. 

  2. Anonymous

    We can provide source information in a string, hash separated. That is a great idea (from Stephane)

  3. Anonymous

    What are the storage requirements for the server - eg cache can grow - does it need maintenance?

    Does cache size have any relarion to data being served?

  4. Anonymous

    Time unit is not useful for geologic age. Maybe a unit "Age" in myr (million year) is possible?

    1. I think you're asking for a new parameter providing age, not for a unit.

      We may discuss this but My is not the scale of choice in the solar system, I would advocate Gy.

  5. Please login to post comments (wink) this is much better when we know who we're talking to 

Write a comment...