[PROJ] [EXTERNAL] Re: Proj 6 API questions

[Even Rouault]

On mardi 26 mars 2019 19:56:22 CET Nyall Dawson wrote:
> On Tue, 26 Mar 2019 at 17:58, Lesparre, Jochem
> 
> <Jochem.Lesparre at kadaster.nl> wrote:
> > > I honestly don't have any plans to change this behavior. I cannot see
> > > a way to remove this choice from users, as QGIS projects don't have a
> > > single CRS, but they DO need a single ellipsoid. The best we can do is
> > > make sure that a good default selection is given to users, but we
> > > cannot totally remove this choice.
> > 
> > To add a 3rd opinion in the debate: I think the ellipsoid should should
> > NOT automatically be set to the ellipsoid of a CRS used by the user, but
> > it should by default kept set to GRS80, unless the user explicitly
> > manually selects another ellipsoid. GRS80 is scientifically the best
> > ellipsoid, all others are outdated (not the most accurate estimation of
> > the size of the earth), unconventional (seldomly used) or wrong (e.g. due
> > to rounding of parameters). The only exception would be extra-terrestrial
> > CRSs: there GRS80 make no sense and the scientifically best ellipsoid of
> > the planet in question should be selected by default. When a user is
> > using a national CRS based on a old ellipsoid, (s)he mostly doesn't want
> > distances and areas based on this outdated ellispoid but distances and
> > areas computed in the best way possible, which is GRS80.
> I'm very much in favour of this approach!

The question raised by Kristian is still valid. How do you convert from 
project coordinates to coordinates on the measurement ellipsoid ?
- is is a no-op conversion, that is
    lon,lat(measurement_ellipsoid) = lon,lat(project_crs)  ?
  That would be wrong.
- or some form of coordinate transformation from the project CRS to the
  measurement ellipsoid, but then you'll get no datum shifts. That said, for
  measurement, that probably doesn't make a lot of difference in the resulting
  computation (assuming that the shift would be almost homogeneous on the area
  of interest)

> I wonder if this is something which belongs in the proj db itself.
> I.e. some API to query the recommended ellipsoid for a given planetary
> body.

Before the API, we would need the information. The database doesn't store a 
concept of recommended ellipsoid. Could be a new column in 'ellipsoid' table 
with a check that there's a single recommended ellipsoid for a celestial_body, 
and that for each body, there's a recommended ellipsoid (commit.sql can be 
used to add consistency checks that don't fall in usual SQL constraints)
(thinking out loud. haven't given that more thought)

Even
-- 
Spatialys - Geospatial professional services
http://www.spatialys.com