[Quantity] Re: Expressing 2- and 3-D coordinates

[Brian Thomas]

	Hi Arnold, All,

	I guess this is the appropriate juncture to mention that this is the
	sort of thing that the Quantity Data Modeling group has already
	tackled. From the Q point of view, the coordinate model would look
	like a vector, captured as:

	<astroCoordinates>
		<astroCoordSystem refId="J2000"/>
		<position2D>
			<vector>
				<astroCoordSystem refid="J2000"/>
				<component name="x">
					<units>m</units>
					<float length="3" precision="1"/>
				</component>
				<component name="y">
					<units>cm</units>
					<float length="3" precision="1"/>
				</component>
			</vector>
			<values><value>5.0</value><value>10.0</value></values>
		</position2D>
		<timeCoord>....</timeCoord>
		<velocityCoord>...</velocityCoord>
	</astroCoordinates>

	A "position3D" exists, and is only different in that it adds a 3rd component to the 
	vector. The coordinate system may be referenced at a variety of points, in order to preserve
	encapsulization/containerization of all the appropriate information (only 2 points
	shown in the above example, I could have ref'd the coordinate system with the 
	individual components, which I am not sure is desirable..).

	The Q model also allows (XML compliant) description of the values as a list as well,
	so in the above example, the "values node" could alternatively look like:

	<values>5.0 10.0</values>

	I can also show an example so that errors are included as well.

	Schema which describe this (yes, these won't load into XMLSpy, but do validate
	with 3 other major schema validators) which are derived from STC 1.20 may be 
	found at (Look in VOCoordinates/VOCoordinateSystems):

	http://archive.astro.umd.edu/VOCatalog/schema_and_examples/

	=brian


On Tuesday 13 December 2005 02:22 pm, Arnold Rots wrote:
> A question has come up on expressing multi-dimensional STC coordinates
> in the context of VOEvent that I would like to put to the DM forum.
> 
> In the STC schemata I have implemented coordinate vectors and error
> matrices for 2-D and 3-D spatial coordinates as lists of 2, 3, 4, or 9
> doubles - the equivalent of arrays of specific length.
> It is perfectly clear and unambiguous XML and it leads to something
> like:
> 
> <Position2D>
>   <Value2>140 69</Value2>
>   <Error2Matrix>0.05 0.0 0.0 0.05</Error2Matrix>
> </Position2D>
> 
> As you may be aware, there have been complaints about this, not only
> from people in VOEvent but also in VOTable, who want to separate the
> coordinates.  We have always argued that these coordinates need to be
> considered as a vector and should not be treated as separate items -
> for one thing, errors, sizes, and regions are functions of the vectors
> in non-separable form.
> 
> Now an old proposal has been presented again (I believe it was
> considered and rejected before) and we need to think about it.
> It is to make the individual vector components separate elements
> within a vector element, resulting in:
> 
> <Position2D>
>   <Value2>
>     <Coord1>140</Coord1>
>     <Coord2>69</Coord2>
>   </Value2>
>   <Error2Matrix>
>     <M11>0.05</M11>
>     <M12>0.0</M12>
>     <M21>0.0</M21>
>     <M22>0.05</M22>
>   </Error2Matrix>
> </Position2D>
> 
> Of course, the same nesting would apply to all other appearances of
> multi-dimensional coordinates, e.g., in regions.  And the referencing
> mechanism would have to be propagated through all nesting levels.
> 
> The impetus for this is a desire to appease VOEvent articipants who
> have complained that parsers have trouble parsing the lists of doubles.
> I believe this is a valid issue since XPath1 does not handle
> individual elements in lists; XPath2 is supposed to but there are
> rumors that it might not.  On the other hand, one might argue, of
> course, that one should always retrieve the entire vector.
> 
> The problem, of course, is that it seems a rather laborious way to
> describe something that is available and supported by XML Schema (list
> types) and it makes the documents even more verbose.
> On the other hand, it would also resolve one of the issues that
> VOTable has with STC.  Although in that case use of groups (to mimic
> the lists) are also an appropriate solution.
> 
> VOEvent has been told that this had to be run by DM - like STCLite -
> and might be rejected on solid grounds.  Here I don't quite see the
> problems that STCLite had but I'd welcome any thoughts and wisdoms you
> may have on this issue.
> 
> Cheers,
> 
>   - Arnold
> 
> 
> --------------------------------------------------------------------------
> Arnold H. Rots                                Chandra X-ray Science Center
> Smithsonian Astrophysical Observatory                tel:  +1 617 496 7701
> 60 Garden Street, MS 67                              fax:  +1 617 495 7356
> Cambridge, MA 02138                             arots at head.cfa.harvard.edu
> USA                                     http://hea-www.harvard.edu/~arots/
> --------------------------------------------------------------------------
> 

-- 
--------------------------------------
|                                     
| Dr. Brian Thomas                    
|                                     
| Dept of Astronomy                   
| University of Maryland-College Park 
|
| Phone: (301) 405-2312               
| Fax: (301) 314-9067                 
|                                     
--------------------------------------