Point in Coord

[CresitelloDittmar, Mark]

Laurent,

To be clear..
The current arrangement of the objects is:

        [image: current.png]
To add a CelestialPoint would require either:
  + make coords:Point abstract
  + create a coords:GenericPoint + coords:CelestialPoint(lat/lon)  +
coords:CartesianPoint(x,y,z)
       * the specialized Points would need to constrain its
coordsys.coordSpace to match the type.
Or
  + add coords:CelestialPoint(lat/lon)
  + add meas:CelestialPosition containing CelestialPoint

The models have been in similar configurations in the past..
Both add objects, and generate >1 path for representing the same thing,
(which were negative comments on the earlier versions).

I'm not adverse to the idea, but don't want to go in circles.
Mark


On Wed, Apr 15, 2020 at 3:42 AM Laurent MICHEL <
laurent.michel at astro.unistra.fr> wrote:

> Mark
>
>
> I do not propose to turn back toward Frame-centric coords
> (GalacticPosition...)
> I'm just proposing to add a new class without altering the model structure.
> This class would be specific to the celestian sphere (lon/lat) and
> should be attached to a frame (ICRS...) as any other Point.
>
> It would be nice to get feebacks from other people on this.
>
> LM
>
> Le 08/04/2020 à 23:30, CresitelloDittmar, Mark a écrit :
> > Laurent,
> >
> > The hierarchy is: Point references a SpaceSys which contains the
> > SpaceFrame and the CoordSpace (both in composition).
> > Point
> >     |-> SpaceSys
> >           o-> SpaceFrame
> >           o-> PhysicalCoordSpace{Cartesian/SphericalCoordSpace}
> >
> > But that does not negate the question.
> >    "However, taking into consideration that spatial coordinates is the
> > most used thing in Astronomy, I'm wondering if it wouldn't be better to
> > have one specific class for Cartesian points (refering to
> > CartesianCoordSpace) and another for Spherical points (refering to
> > SphericalCoordSpace)."
> >
> >    * Earlier drafts of Coords (2018) had Frame-centric coords with
> > standard spaces (CartesianCoord, LongLatCoord)..
> >    * Due to feedback on this representation, they migrated in 2019 to
> > specialized singular coordinates (X,Y,Z,Long,Lat,R, etc) which referred
> > to axes of standard spaces, and were used in frame-centric Measures.
> > Which is what went to the RFC phase.
> >    * There, the frame-centric and space-centric Measures were generally
> > disliked (GalacticPosition, CartesianPosition)
> >    * The RFC actions called for replacing the specialized singular
> > coordinates with a single Point Coordinate, and removing the specialized
> > Measures, retaining only the single Position type containing a Point.
> > The consequence of users having to interrogate the Position to determine
> > the details of frame/space was considered acceptable.
> >
> > Obviously there is a sweet spot there somewhere, but I doubt we can
> > settle into it until we have more implementation experience with it.
> > Adding a CartesianPoint and SphericalPoint which constrains the space is
> > a simple update which can be done at any time.
> >
> > Mark
> >
> >
> >
> >
> >
> > On Tue, Apr 7, 2020 at 5:42 AM Laurent MICHEL
> > <laurent.michel at astro.unistra.fr
> > <mailto:laurent.michel at astro.unistra.fr>> wrote:
> >
> >     Dear DM
> >
> >     I'm exercising with Coords with spatial coordinates.
> >
> >     My understanding is as follow:
> >     ==============================
> >     Spatial coordinates are represented by Point instances that, skipping
> >     the details, refers to a SpaceSys that refer to a SpaceFrame that
> refer
> >     to a PhysicalCoordSpace that is either a SphericalCoordSpace or a
> >     CartesianCoordSpace.
> >
> >     Point
> >         |-> SpaceSys
> >               |-> SpaceFrame
> >                    |-> PhysicalCoordSpace{Cartesian/SphericalCoordSpace}
> >
> >     So a client that gets a Point instance will have to step down this
> >     cascade and to check the class of the associated PhysicalCoordSpace
> >     instance before to know whether this point is  Cartesian or
> Spherical.
> >
> >     Question:
> >     ========
> >     This is consistent but not very practical. I understand that this
> model
> >     provides components for host models that will be designed in a way to
> >     avoid clients to do such inferences. This could be the case with the
> >     upgrade of Meas.
> >     However, taking into consideration that spatial coordinates is the
> most
> >     used thing in Astronomy, I'm wondering if it wouldn't be better to
> have
> >     one specific class for Cartesian points (refering to
> >     CartesianCoordSpace) and another for Spherical points (refering to
> >     SphericalCoordSpace).
> >
> >     As a side effect this would allow to have one specific spherical
> >     CoordSpace for the celestial sphere (lat ,long, R=1).
> >
> >     Laurent
> >     --
> >     ---- Laurent MICHEL              Tel  (33 0) 3 68 85 24 37
> >            Observatoire de Strasbourg  Fax  (33 0) 3 68 85 24 32
> >            11 Rue de l'Universite      Mail
> >     laurent.michel at astro.unistra.fr <mailto:
> laurent.michel at astro.unistra.fr>
> >            67000 Strasbourg (France)   Web
> http://astro.u-strasbg.fr/~michel
> >     ---
> >
>
> --
> ---- Laurent MICHEL              Tel  (33 0) 3 68 85 24 37
>       Observatoire de Strasbourg  Fax  (33 0) 3 68 85 24 32
>       11 Rue de l'Universite      Mail laurent.michel at astro.unistra.fr
>       67000 Strasbourg (France)   Web  http://astro.u-strasbg.fr/~michel
> ---
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20200415/e77e3fa2/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: current.png
Type: image/png
Size: 12348 bytes
Desc: not available
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20200415/e77e3fa2/attachment-0001.png>