Photometry data model working draft

Jonathan McDowell jcm at head.cfa.harvard.edu
Tue Nov 30 19:48:43 PST 2010


Jesus, and Mireille -
  Thanks for circulating that draft in time for me to see it,
much appreciated. 
 
I do see a lot of commonality in our approaches, and a few differences.
I think it would be very helpful to have a few VOTABLE serialization
examples in your model, ideally the same use cases as in my document so
we can directly compare the approaches and see what a full
PhotometryPoint document instance would look like. I wasn't quite clear
why PhotometryPoint has a reference to ZeroPoint rather than
PhotometryFilter, and in a PhotometryPoint instance how one traverses
the tree to figure out what the wavelength
(PhotometryFilter.SpectralAxis.Coverage.Location) is. If I understand
your use case, we find PhotometryPoint.ZeroPoint.UniqueIdentifier and
that points to an external instance of ZeroPoint which contains a
ZeroPoint.PhotometryFilter that points to the PhotometryFilter instance.
Is that right? and if so, why that way round and not 
 PhotometryPoint ->(pointsto)-> PhotometryFilter ->(has a)->ZeroPoint ?

 I like the inclusion of the luptitudes, I wish I had thought of that
and agree we definitely need to support them. I also agree that
implementations should not use the same code to calculate both luptitudes and
Pogson mags, but since b=0 => Pogson we could consider serializing them
the same way, saying that "the default value of b is 0 and that implies
Pogson", but "if b is present and nonzero then it's asinh". That would
simplify things a little bit.

 OK, back to packing for my very early Thursday flight!
  - Jonathan


  


More information about the dm mailing list