[fitsbits] Cartesian coordinates question.

On Fri 2004/05/14 14:44:39 -0400, Tom McGlynn wrote
in a message to:

When an image is requested in a Cartesian
projection, SkyView always sets the reference coordinate
to 0,0.

If SkyView *always* sets (CRVAL1,CRVAL2) = (0,0) then it may be making
the mistake described in detail in Sect. 7.3.4 of WCS Paper II.
However, this only affects grid-drawing software, coordinates may still
be computed correctly.

Thus for a patch of the
sky with RA (or longitude) between 180 and 360, the
X-coordinates of the center of the image, i.e.,
(NAXIS1/2-CRPIX1)*CDELT1 is negative.

If I understand correctly, isn't this just a trivial normalization
issue? See below.

Our user was concerned that SkyView was making it
unnecessarily difficult to use the image, since they couldn't
just use the X-value as the RA without checking
the range.

In a plate carree projection the x-value gives the native longitude.
Depending on the obliquity this may or may not have a simple
relationship to the celestial longitude. If you want the celestial
longitude (i.e. RA) to match the x-value (i.e. native longitude), then
(CRVAL1,CRVAL2) = (0,0) is required. However, this may not be
normalized as your user wishes (see below) and may be incorrect for the
reason mentioned above. Thus CRVAL1 will often have to be set non-zero;
your user may be expecting too much.

In fact, since the CAR projection is
cylindrically symmetric it is possible to use
a value for CRVAL1 such that for most smallish
images the RA within the image would always be
computed in the range 0RA360 even without
any range checking.

Normalization of the celestial longitude (RA) is outside the scope of
WCS Paper II and so is implementation dependent; WCSLIB applies a
normalization consistent with the CRVAL1 value, and it does this for
all projections, not just cylindricals. For WCSLIB then, what you say
is correct.

However, other WCS implementations may produce celestial longitudes in
the range [-180,180] regardless of anything. You would then need to
renormalize to [0,360] yourself (and then convert to HMS).

Does anyone have any experience with how others
have addressed this issue?

Yes, too much.

Mark Calabretta
ATNF

On Fri 2004/05/14 14:44:39 -0400, Tom McGlynn wrote
in a message to:

When an image is requested in a Cartesian
projection, SkyView always sets the reference coordinate
to 0,0.

If SkyView *always* sets (CRVAL1,CRVAL2) = (0,0) then it may be making
the mistake described in detail in Sect. 7.3.4 of WCS Paper II.
However, this only affects grid-drawing software, coordinates may still
be computed correctly.

Thus for a patch of the
sky with RA (or longitude) between 180 and 360, the
X-coordinates of the center of the image, i.e.,
(NAXIS1/2-CRPIX1)*CDELT1 is negative.

If I understand correctly, isn't this just a trivial normalization
issue? See below.

Our user was concerned that SkyView was making it
unnecessarily difficult to use the image, since they couldn't
just use the X-value as the RA without checking
the range.

In a plate carree projection the x-value gives the native longitude.
Depending on the obliquity this may or may not have a simple
relationship to the celestial longitude. If you want the celestial
longitude (i.e. RA) to match the x-value (i.e. native longitude), then
(CRVAL1,CRVAL2) = (0,0) is required. However, this may not be
normalized as your user wishes (see below) and may be incorrect for the
reason mentioned above. Thus CRVAL1 will often have to be set non-zero;
your user may be expecting too much.

In fact, since the CAR projection is
cylindrically symmetric it is possible to use
a value for CRVAL1 such that for most smallish
images the RA within the image would always be
computed in the range 0RA360 even without
any range checking.

Normalization of the celestial longitude (RA) is outside the scope of
WCS Paper II and so is implementation dependent; WCSLIB applies a
normalization consistent with the CRVAL1 value, and it does this for
all projections, not just cylindricals. For WCSLIB then, what you say
is correct.

However, other WCS implementations may produce celestial longitudes in
the range [-180,180] regardless of anything. You would then need to
renormalize to [0,360] yourself (and then convert to HMS).

Does anyone have any experience with how others
have addressed this issue?

Yes, too much.

Mark Calabretta
ATNF