Alberto.Micol at eso.org
Thu Feb 17 10:42:09 PST 2005
Sorry, but I don't really get the point.
Apples are apples, and bananas are bananas,
and the UCDs are clearly stating that those two things
are not of the same kind:
Jy -> phot.fluxDens
Jy/sr -> phot.fluxDens.sb
Why would you want to use the units to discriminate between the two?
On Feb 17, 2005, at 17:07, David Berry wrote:
>> the example case mentioned before about comparing Jy with Jy/sr, has
>> to do with
>> point versus extended source information. Whether a
>> source is extended will have to be stated in the metadata, and if a
>> source is extended and the flux is given in Jy/sr, the solid angle
>> subtended by the observation under which the flux is being given
>> (basically the extension of the source, I guess) should appear there.
> I agreed that to create a conversion from Jy to Jy/sr, a solid angle is
> required from somewhere.
>> Then, clients would get this piece of information (from the SED data
>> model, for example) and handle it. There is no other way to compare Jy
>> with Jy/sr, as the second is a relative measurement (relative to a
>> certain area). This problem is inherent to the type of data, and not
>> whether you use dimensional analysis or unit string parsing to make
> My question was really more to do with whether a dimensional analysis
> approach can tell that no simple conversion is possible between Jy and
> Jy/sr. Presumably if I have two flux density data sets, one in units
> of Jy
> and one in units of mJy, each with a dimensional analysis, it would be
> simple to determine the conversion between the data sets on the basis
> the dimensional analysis (the dimensions themselves would be equal but
> scale factor would differ). But if my second data set was not flux
> but surface brightness in units of Jy/sr, how would the conversion
> software recognize that the conversion is *not* possible? Since "sr" is
> dimensionless, the dimensional analysis of Jy and Jy/sr are identical.
> So in this case how does the conversion code realise that it is dealing
> with "Jy/sr" and not "Jy"? Adding more meta data to indicate source
> extension is not enough since, even if you have flag indicating that
> source is extended, you still have to determine if the data represents
> integrated flux of the extended source in Jy or the surface brightness
> the extended source in Jy/sr.
> Also, thinking of magnitudes, the dimensional analysis for "mag" would
> presumably be blank. So how does the code identify what it can and
> cannot do with the units?
ST-ECF HST Archive Scientist
More information about the dm