Difference between revisions of "Filling Out the Coordinate Space Identification Classes"

From The SBN Wiki
Jump to navigation Jump to search
(Update Progress Save)
 
(Update for 1.2.0.0)
 
Line 1: Line 1:
 
The classes used to define coordinate spaces with respect to articulating devices on landers share a common structure.  These classes include ''<Coordinate_Space_Present>'' and ''<Coordinate_Space_Reference>''. This page describes the common internal structure of these two classes.
 
The classes used to define coordinate spaces with respect to articulating devices on landers share a common structure.  These classes include ''<Coordinate_Space_Present>'' and ''<Coordinate_Space_Reference>''. This page describes the common internal structure of these two classes.
 +
 +
Of the three optional subclasses listed in this class, one of ''<Coordinate_Space_Indexed>'', ''<Coordinate_Space_SPICE>'', and ''<Local_Internal_Reference>'' must be provided.  You may include more than one of these, and you may also repeat any of these as needed.
 +
 +
{| class="wikitable" style="background-color: yellow"
 +
| ''Do these inclusion constraint make any sense?!?''
 +
|}
  
 
== <Coordinate_Space_Indexed> ==
 
== <Coordinate_Space_Indexed> ==
Line 44: Line 50:
  
 
{| class="wikitable" style="background-color: yellow"
 
{| class="wikitable" style="background-color: yellow"
| ''This is defined as "the value with no applicable units as names by the associated index_id or index_name".  There is no requirement that either of those attributes exist in the containing class, no is the reference to the (disallowed) units comprehendable given the available definitions.  Also, this value is required to be a real number, whereas indices are generally integral - so how the value should be interpreted even in the presence of an index is not clear..''
+
| ''This is defined as ''"the value with no applicable units as named by the associated index_id or index_name"''.  There is no requirement that either of those attributes exist in the containing class, nor is the reference to the (disallowed) units comprehendable given the available definitions.  Also, this value is required to be a real number, whereas indices are generally integral - so how the value should be interpreted even in the presence of an index is not clear.''
 
|}
 
|}
  
Line 55: Line 61:
 
{| class="wikitable" style="background-color: yellow"
 
{| class="wikitable" style="background-color: yellow"
 
| ''The definition says this value is not case-sensitive, but that is not how it is defined and that is not an enforcable requirement, at least through schema validation.''
 
| ''The definition says this value is not case-sensitive, but that is not how it is defined and that is not an enforcable requirement, at least through schema validation.''
 +
|}
 +
 +
 +
 +
== <Coordinate_Space_SPICE> ==
 +
 +
''OPTIONAL''
 +
 +
This class identifies a coordinate space using SPICE identifiers.
 +
 +
=== <body_spice_name> ===
 +
 +
''REQUIRED''
 +
 +
This attribute provides the NAIF-recognized identification string for a physical object (a planet or spacecraft, e.g.).
 +
 +
=== <frame_spice_name> ===
 +
 +
''REQUIRED''
 +
 +
This attribute provides the NAIF-recognized identification string for a reference frame.
 +
 +
 +
 +
== <Local_Internal_Reference> ==
 +
 +
''OPTIONAL''
 +
 +
This class is used to reference another location within the same label, identified via a ''&lt;local_identifier&gt;'' attribute which is cited here. Details of how to fill out this class are identical to those on the [[Filling_out_the_Image_Display_Geometry_Class#.3CLocal_Internal_Reference.3E|Filling out the Image Display Geometry Class]] page.
 +
 +
{| class="wikitable" style="background-color: yellow"
 +
| ''It is not clear what it would be appropriate to reference at this point.''
 
|}
 
|}

Latest revision as of 15:44, 29 January 2016

The classes used to define coordinate spaces with respect to articulating devices on landers share a common structure. These classes include <Coordinate_Space_Present> and <Coordinate_Space_Reference>. This page describes the common internal structure of these two classes.

Of the three optional subclasses listed in this class, one of <Coordinate_Space_Indexed>, <Coordinate_Space_SPICE>, and <Local_Internal_Reference> must be provided. You may include more than one of these, and you may also repeat any of these as needed.

Do these inclusion constraint make any sense?!?

<Coordinate_Space_Indexed>

OPTIONAL

This class identifies an indexed coordinate space.

<coordinate_space_frame_type>

REQUIRED

This attribute is undefined. It is nillable.

<Coordinate_Space_Index>

REQUIRED

This class identifies a coordinate space using an index value given in an identified list.

There is no indication where or how the "identified list" is either identified or defined, or the actual relationship between the index and the list. Presumably the "index" has a corresponding value in the "list", but maybe not.

<index_sequence_number> or <index_name> or <index_id>

REQUIRED

At least one of these is required, two or all three may be specified. Use the attribute name that seems best fitted to the type of index value you're using. All three of these attributes have the same type definition (a string of printable ASCII characters and blanks).

<Local_Internal_Reference>

OPTIONAL

There is no indication of what might be referenced here or why.

<index_value_number>

OPTIONAL

This is defined as "the value with no applicable units as named by the associated index_id or index_name". There is no requirement that either of those attributes exist in the containing class, nor is the reference to the (disallowed) units comprehendable given the available definitions. Also, this value is required to be a real number, whereas indices are generally integral - so how the value should be interpreted even in the presence of an index is not clear.

<solution_id>

OPTIONAL

If the information in the containing class is based on a particular geometric or positional solution calculation, this attribute provides a place to identify which solution is apropos. In general, missions will define a set of values to be used here.

The definition says this value is not case-sensitive, but that is not how it is defined and that is not an enforcable requirement, at least through schema validation.


<Coordinate_Space_SPICE>

OPTIONAL

This class identifies a coordinate space using SPICE identifiers.

<body_spice_name>

REQUIRED

This attribute provides the NAIF-recognized identification string for a physical object (a planet or spacecraft, e.g.).

<frame_spice_name>

REQUIRED

This attribute provides the NAIF-recognized identification string for a reference frame.


<Local_Internal_Reference>

OPTIONAL

This class is used to reference another location within the same label, identified via a <local_identifier> attribute which is cited here. Details of how to fill out this class are identical to those on the Filling out the Image Display Geometry Class page.

It is not clear what it would be appropriate to reference at this point.