<div dir="ltr"><div dir="ltr"><div>Markus.. Thanks for the read and feedback.<br></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Dec 20, 2018 at 12:04 PM Markus Demleitner <<a href="mailto:msdemlei@ari.uni-heidelberg.de">msdemlei@ari.uni-heidelberg.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi DM,<br>
<br>[Begin side issue]<br>
I still believe there's room for substantial simplifications without<br>
impacting functionality and actually improving robustness; for<br>
instance, I'd say EclipticCoord, EquatorialCoord, GalacticCoord, and<br>
LongLatCoord should all just be LongLatCoord; the associated frame is<br>
enough to tell them apart, and I can't see where having separate<br>
types for them would help a client (or even a server).<br>
<br></blockquote><div><br>The plan is to use these in the Measurement model. I've started reviewing it, and working the documentation this week. (FYI: Transform is pretty much ready to go out to the WG). It comes down to where to draw the line for the common Astronomical data which these 'shortcuts' address. I think it is important that something like (ra,dec) is easy to spot, and "A Position whose coordinate is LongLatCoord type referencing a SpaceFrame with refFrame=[ICRS|FK4|FK5]" doesn't seem that intuitive. <br></div><div>So this specializes the compound coordinate to make it easy. "A Position whose coordinate is EquatorialCoord type"<br>Remember.. Position is the spatial Measure type.<br></div><div><br></div><div>I've been giving is some thought and there is another option. Whether or not it is better depends on what one considers (ra,dec) to be.<br></div><div>We COULD:<br></div><div> + instead of defining specialized compound coordinates, specify specialized individual coordinates for each of the Standard Coordinate Space axes,<br></div><div> o CartesianX, CartesianY, CartesianZ, Longitude, Latitude, SphericalRadius <br> something like that, we need to be able to distinguish coordinates pointing to axes of the same 'name' in different spaces, like Cartesian vs Cylindrical<br></div><div> + then the Measurement model could define specialized measurements using them:<br></div><div> o EquatorialPosition<br></div><div> *ra:Longitude<br></div><div> *dec:Latitude<br></div><div> *error:Error<br></div><div> o GalacticPosition<br></div><div> *l:Longitude<br></div><div> *b:Latitude<br></div><div> *error:Error<br></div><div> In addition to the generic position<br></div><div> o GenericPosition<br></div><div> * coord: Coordinate<br></div><div> * error: Error<br></div><div> with constraint {coord.frame == SpaceFrame}<br></div><div><br></div><div>The difference is in the interpretation:<br></div><div> current: (ra,dec) is a coordinate in a spherical coordinate space with a particular orientation (given by the frame)<br></div><div> this: (ra,dec) is the measured position of an object represented in a spherical coordinate space with a particular orientation (given by the frame).<br><br></div><div>Pros to this approach:<br></div><div> + I like that people looking for RA,DEC will find it in Measurement, which is probably what they want to be using (rather than the Coord).<br></div><div> + It brings discovery up one level. (ra,dec) is an EquatorialPosition.<br></div><div>Cons:<br></div><div> - doing this would mean losing a common 'coord' attribute/vodml-id for all CoordMeasure-s in the measurement model.<br><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
[Begin main issue]<br>
Similarly (and this is quite a bit more itchy to me right now), I'm<br>
strongly advocating to make TimeInstant concrete and remove all its<br>
derived types (ISOTime, JD, MJD, TimeOffset). Instead, TimeFrame<br>
should grow a timeorigin attribute.<br></blockquote><div><br></div><div>We've beat around this bush a couple times. <br><br></div><div>Full disclosure, I haven't read the apps thread re: TIMESYS, but as I recall, it works only because it requires that timeorigin is expressed in JD specifically.<br></div><div>This is not OK for general usage, and without the restriction you get a cyclical problem in the model. <br> * The separation of TimeOffset from TimeInstant prevents this and, I think is pretty non-negotiable.<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
The rationale here is that the concrete form of the timestamp is a<br>
*serialisation* issue, i.e., one of VOTable, FITS, or whatever else.<br>
If the serialisation provides for having ISO-like dates or a binary<br>
representation of civil dates or nothing of the sort shouldn't<br>
determine whether you can serialise STC instances into them.<br></blockquote><div><br></div><div>Not sure I would call it a serialization issue, but yes.. its related. The thing is, when we have time data, we need to convey how to interpret that value (which on its face is just a 'real' ).<br></div><div>This modeling makes it easy to convey that info.. you have a Column or Param which you identify as type "coords:domain.time.JD". The alternative is to have a single Type (TimeInstant), and a format enumeration/flag. Which means you need 2 bits of information to interpet the value instead of 1. Both of those bits would need to be in the model, and have a vodml-id. So, there would still be potential conflict between vo-dml annotation vs other 'serialization specific annotations' (like the xtype). <br><br></div><div>I do expect that most will <u>implement</u> a single object, which can be initialized from any of the flavors, and provide 'format' interface for getting it in the different forms, but that is just a more efficient way of implementing the model.<br></div><div>Bottom line: I'm really pretty convinced that this is the proper modeling of these bits.<br><br></div>Mark<br><br></div></div></div>