Servicetype

class pyvo.registry.rtcons.Servicetype(*stds)

Bases: pyvo.registry.rtcons.Constraint

A constraint for for the availability of a certain kind of service on the result.

The constraint normally is a custom keyword, one of:

• image

• spectrum

• scs (for cone search services)

• line (for SLAP services)

• table (for TAP services)

You can also pass in the standards’ ivoid (which generally looks like ivo://ivoa.net/std/<standardname> and have to be URIs with a scheme part in any case); note, however, that for standards pyVO does not know about it will not build service instances for you.

Multiple service types can be passed in; a match in that case is for records having any of the service types passed in.

The match is literal (i.e., no patterns are allowed); this means that you will not receive records that only have auxiliary services, which is what you want when enumerating all services of a certain type in the VO. In data discovery (where, however, you generally should not have Servicetype constraints), you can use Servicetype(...).include_auxiliary_services() or use registry.search’s includeaux parameter; but, really, there is little point using this constraint in data discovery in the first place.

Parameters

*stds: tuple of str

one or more standards identifiers. The constraint will match records that have any of them.

Methods Summary

get_search_condition()	Formats this constraint to an ADQL fragment.
include_auxiliary_services()	returns a Servicetype constraint that has self’s service types but includes the associated auxiliary services.

Methods Documentation

get_search_condition()

Formats this constraint to an ADQL fragment.

Returns

str

A string ready for inclusion into a WHERE clause.

include_auxiliary_services()

returns a Servicetype constraint that has self’s service types but includes the associated auxiliary services.

This is a convenience to maintain registry.search’s signature.