[PROJ] Proj 6 API questions

Mon Mar 18 03:39:24 PDT 2019

I don't think there's duplicates at the moment but I am not sure
there's a guarantee for that always being the case. Here's the
relevant SQL create statement:

CREATE TABLE ellipsoid (
    auth_name TEXT NOT NULL CHECK (length(auth_name) >= 1),
    code TEXT NOT NULL CHECK (length(code) >= 1),
    name TEXT NOT NULL CHECK (length(name) >= 2),
    description TEXT,
    celestial_body_auth_name TEXT NOT NULL,
    celestial_body_code TEXT NOT NULL,
    semi_major_axis FLOAT NOT NULL CHECK (semi_major_axis > 0),
    uom_auth_name TEXT NOT NULL,
    uom_code TEXT NOT NULL,
    inv_flattening FLOAT CHECK (inv_flattening = 0 OR inv_flattening >= 1.0),
    semi_minor_axis FLOAT CHECK (semi_minor_axis > 0 AND semi_minor_axis <= semi_major_axis),
    deprecated BOOLEAN NOT NULL CHECK (deprecated IN (0, 1)),
    CONSTRAINT pk_ellipsoid PRIMARY KEY (auth_name, code),
    CONSTRAINT fk_ellipsoid_celestial_body FOREIGN KEY (celestial_body_auth_name, celestial_body_code) REFERENCES celestial_body(auth_name, code),
    CONSTRAINT fk_ellipsoid_unit_of_measure FOREIGN KEY (uom_auth_name, uom_code) REFERENCES unit_of_measure(auth_name, code)
);

from https://github.com/OSGeo/proj.4/blob/master/data/sql/proj_db_table_defs.sql 

I guess name should have a unique constraint if we were to guarantee unique names.
I may be missing something though - I am not particularly skilled in the ways of SQL.

/Kristian

-----Oprindelig meddelelse-----
Fra: Nyall Dawson <nyall.dawson at gmail.com> 
Sendt: 18. marts 2019 11:29
Til: Kristian Evers <kreve at sdfe.dk>
Cc: PROJ <proj at lists.osgeo.org>
Emne: Re: [PROJ] Proj 6 API questions

On Mon, 18 Mar 2019 at 20:19, Kristian Evers <kreve at sdfe.dk> wrote:
>
> Instead of using the acronym you can just use the parameters from
> proj_ellipsoid_get_parameters() directly, so that
>
>      +ellpsg=GRS80
>
> becomes
>
>     + a=6378137.0  +rf=298.257222101.
>
> For both your use cases that should work fine. You will of course have
> to do a bit of string manipulation to achieve this.

Ok, and I guess I can use proj_get_name on the ellipsoid object to get
the friendly name too. Are these names unique? Or is there no
guarantee for that?

Nyall

>
> /Kristian
>
> -----Oprindelig meddelelse-----
> Fra: PROJ <proj-bounces at lists.osgeo.org> På vegne af Nyall Dawson
> Sendt: 18. marts 2019 10:40
> Til: Kristian Evers <kreve at sdfe.dk>
> Cc: PROJ <proj at lists.osgeo.org>
> Emne: Re: [PROJ] Proj 6 API questions
>
> On Mon, 18 Mar 2019 at 17:34, Kristian Evers <kreve at sdfe.dk> wrote:
> >
> > I may be wrong but I don’t think there are acronyms for them. It’s based
> > on the EPSG dataset and acronyms are not assigned in that regime. Do
> > you actually need them or is this just so that it fits better in existing QGIS
> > infrastructure?
>
> There's two things QGIS uses this for:
>
> 1. When a user selects the CRS for their project, the project
> ellipsoid (used when calculating geodetic distances/areas for the
> project) is automatically set to match the ellipsoid corresponding to
> this CRS. i.e. select EPSG:28356 and the project ellipsoid is set to
> GRS80, set it to EPSG:102013 and you get International 1909.  So we
> need a way to get the ellipsoid from an acronym (or alternatively,
> directly from a CRS).
>
> 2. When performing geodetic distance/area calculations, QGIS
> transforms coordinates from the layer's source CRS to a crs crafted
> from "+proj=longlat +ellps=XXXXX +nodefs", and then uses the result
> when performing the geodetic calculations. So we need a way to obtain
> the ellipsoid acronym given an ellipsoid definition (where a
> corresponding one exists).
>
> (Full disclaimer: I'm not fully aware of the background behind this
> logic, and there may be superior logic to follow. Let me know if you
> think there is!)
>
> Nyall
>
>
> >
> > We could potentially assign acronyms for all ellipsoids but I fear that will
> > become a maintenance mess whenever the EPSG dataset is updated.
> >
> > /Kristian
> >
> > > On 18 Mar 2019, at 08:27, Nyall Dawson <nyall.dawson at gmail.com> wrote:
> > >
> > > On Mon, 18 Mar 2019 at 16:56, Kristian Evers <kreve at sdfe.dk> wrote:
> > >>
> > >> You use proj_get_authorities_from_database() for that. Generally there’s functions
> > >> for retrieving all info like that, just search around in the function reference a bit and you’ll
> > >> find it.
> > >
> > > Ok, that part is working, and I'm seeing a LOT more! But now I'm a bit
> > > confused... if I use this approach to iterate through the ellipsoids,
> > > is there anyway to get the ellipsoid acronym from them? Using
> > > proj_list_ellps I could get PJ_ELLPS->id.
> > >
> > > Nyall
> > >
> > >
> > >
> > >>
> > >> /Kristian
> > >>
> > >> On 18 Mar 2019, at 07:52, Nyall Dawson <nyall.dawson at gmail.com> wrote:
> > >>
> > >> On Mon, 18 Mar 2019 at 16:42, Kristian Evers <kreve at sdfe.dk> wrote:
> > >>
> > >>
> > >> Hi Nyall,
> > >>
> > >> I am very happy to see that you have started working on this!
> > >>
> > >> You will probably get less discrepancies between the QGIS list of ellipsoids
> > >> and the PROJ equivalent if you instead use proj_get_codes_from_database
> > >> using type PJ_TYPE_ELLIPSOID.
> > >>
> > >>
> > >> What should I use as auth_name if I want to get ALL ellipsoids? The
> > >> dox state it must not be null...
> > >>
> > >> Thanks for the detailed pointers, I'll let you know the result!
> > >>
> > >> Nyall
> > >>
> > >>
> > >> You should then be able to get the
> > >> parameters with proj_ellipsoid_get_parameters. This is untested on my part
> > >> but I believe that is the general workflow you have to go through to get the
> > >> ellipsoid out of proj.db.
> > >>
> > >> proj_list_ellps() simply shows you the same list as you would get from calling
> > >> `proj -le`, i.e. ellipsoids that can be used with `+ellps=xxx` parameters. This
> > >> is confusing and I shall think of a way to change the docs so it is less confusing :-)
> > >>
> > >> It would be interesting to see the difference between the ellipsoid tables from
> > >> The QGIS and PROJ databases.
> > >>
> > >> /Kristian
> > >>
> > >> On 18 Mar 2019, at 04:39, Nyall Dawson <nyall.dawson at gmail.com> wrote:
> > >>
> > >> Hi list,
> > >>
> > >> So (thanks for sponsorship from the ICSM), I'm working on porting QGIS
> > >> to the Proj 6 API. I suspect I'll have many more questions (especially
> > >> as I attempt to drop QGIS' own custom projection database in favour of
> > >> the upstream proj one). Let's get started...
> > >>
> > >> I thought I'd begin with a simple task of replacing QGIS' ellipsoid db
> > >> with proj's, using proj_list_ellps(). QGIS has this table of
> > >> "standard" ellipsoids, built up from... somewhere... in the vast
> > >> history of the QGIS project. When comparing against proj's db, it
> > >> includes many items which are missing in proj's:
> > >>
> > >> Adrastea2000: Adrastea2000 10000.0/7000.0
> > >> Amalthea2000: Amalthea2000 125000.0/64000.0
> > >> Ananke2000: Ananke2000 10000.0/10000.0
> > >> Ariel2000: Ariel2000 581100.0/577700.0
> > >> Atlas2000: Atlas2000 18500.0/13500.0
> > >> Belinda2000: Belinda2000 33000.0/33000.0
> > >> Bianca2000: Bianca2000 21000.0/21000.0
> > >> Callisto2000: Callisto2000 2409400.0/2409300.0
> > >> Calypso2000: Calypso2000 15000.0/8000.0
> > >> Carme2000: Carme2000 15000.0/15000.0
> > >> Charon2000: Charon2000 593000.0/593000.0
> > >> IGNF:ELG004: Clarke 1866 6378206.4/6356583.799998981
> > >> IGNF:ELG003: Clarke 1880 Anglais 6378249.1453/6356514.8698
> > >> IGNF:ELG010: Clarke 1880 IGN 6378249.2/6356514.999978254
> > >> cape: Clarke 1880 mod. 6378249.145/6356514.966398753
> > >> Cordelia2000: Cordelia2000 13000.0/13000.0
> > >> Cressida2000: Cressida2000 31000.0/31000.0
> > >> Deimos2000: Deimos2000 7500.0/5200.0
> > >> Desdemona2000: Desdemona2000 27000.0/27000.0
> > >> Despina2000: Despina2000 74000.0/74000.0
> > >> Dione2000: Dione2000 560000.0/560000.0
> > >> Earth2000: Earth2000 6378140.0/6356750.0
> > >> Elara2000: Elara2000 40000.0/40000.0
> > >> Enceladus2000: Enceladus2000 256300.0/244600.0
> > >> Epimetheus2000: Epimetheus2000 69000.0/55000.0
> > >> Europa2000: Europa2000 1564130.0/1560930.0
> > >> Galatea2000: Galatea2000 79000.0/79000.0
> > >> Ganymede2000: Ganymede2000 2632400.0/2632350.0
> > >> Helene2000: Helene2000 16000.0/16000.0
> > >> Himalia2000: Himalia2000 85000.0/85000.0
> > >> Hyperion2000: Hyperion2000 164000.0/107000.0
> > >> IGNF:ELG108: IAG GRS 1967 6378160.0/6356774.5161
> > >> IGNF:ELG037: IAG GRS 1980 6378137.0/6356752.314140356
> > >> Iapetus2000: Iapetus2000 718000.0/718000.0
> > >> IGNF:ELG001: International-Hayford 1909 6378388.0/6356911.9461279465
> > >> Io2000: Io2000 1829400.0/1815700.0
> > >> Janus2000: Janus2000 97000.0/77000.0
> > >> Juliet2000: Juliet2000 42000.0/42000.0
> > >> Jupiter2000: Jupiter2000 71492000.0/66854000.0
> > >> Larissa2000: Larissa2000 96000.0/96000.0
> > >> Leda2000: Leda2000 5000.0/5000.0
> > >> Lysithea2000: Lysithea2000 12000.0/12000.0
> > >> Mars2000: Mars2000 3396190.0/3376200.0
> > >> Mercury2000: Mercury2000 2439700.0/2439700.0
> > >> Metis2000: Metis2000 21500.0/21500.0
> > >> Mimas2000: Mimas2000 209100.0/191400.0
> > >> Miranda2000: Miranda2000 240400.0/232900.0
> > >> Moon2000: Moon2000 1737400.0/1737400.0
> > >> Naiad2000: Naiad2000 29000.0/29000.0
> > >> Neptune2000: Neptune2000 24764000.0/24341000.0
> > >> Nereid2000: Nereid2000 170000.0/170000.0
> > >> Oberon2000: Oberon2000 761400.0/761400.0
> > >> Ophelia2000: Ophelia2000 15000.0/15000.0
> > >> IGNF:ELG017: PLESSIS 1817 6376523.0/6355862.933255573
> > >> Pan2000: Pan2000 10000.0/10000.0
> > >> Pandora2000: Pandora2000 55000.0/31000.0
> > >> Pasiphae2000: Pasiphae2000 18000.0/18000.0
> > >> Phobos2000: Phobos2000 13400.0/9200.0
> > >> Phoebe2000: Phoebe2000 115000.0/105000.0
> > >> Pluto2000: Pluto2000 1195000.0/1195000.0
> > >> Portia2000: Portia2000 54000.0/54000.0
> > >> Prometheus2000: Prometheus2000 74000.0/34000.0
> > >> Proteus2000: Proteus2000 218000.0/201000.0
> > >> Puck2000: Puck2000 77000.0/77000.0
> > >> Rhea2000: Rhea2000 764000.0/764000.0
> > >> Rosalind2000: Rosalind2000 27000.0/27000.0
> > >> IGNF:ELG032: SPHERE PICARD 6371598.0/6371598.0
> > >> Saturn2000: Saturn2000 60268000.0/54364000.0
> > >> Sinope2000: Sinope2000 14000.0/14000.0
> > >> Telesto2000: Telesto2000 15000.0/7500.0
> > >> Tethys2000: Tethys2000 535600.0/525800.0
> > >> Thalassa2000: Thalassa2000 40000.0/40000.0
> > >> Thebe2000: Thebe2000 58000.0/42000.0
> > >> Titan2000: Titan2000 2575000.0/2575000.0
> > >> Titania2000: Titania2000 788900.0/788900.0
> > >> Triton2000: Triton2000 1352600.0/1352600.0
> > >> Umbriel2000: Umbriel2000 584700.0/584700.0
> > >> Uranus2000: Uranus2000 25559000.0/24973000.0
> > >> Venus2000: Venus2000 6051800.0/6051800.0
> > >> IGNF:ELG052: WGS72 6378135.0/6356750.520016094
> > >> IGNF:ELG102: WGS72 (NWL-10F) 6378135.0/6356750.520016094
> > >> IGNF:ELG053: WGS84 6378137.0/6356752.314245179
> > >>
> > >> The vast majority of these are planetary ellipsoids/moons, but there's
> > >> others which are less obvious (cape/IGNF*). So
> > >>
> > >> Question 1: should the non-Earth ellipsoids be included in the proj database?
> > >>
> > >> Question 2: What about cape/IGNF* ? Should they be included in proj,
> > >> or are they mistakes and should not even be included in the current
> > >> QGIS db?
> > >>
> > >> Nyall
> > >> _______________________________________________
> > >> PROJ mailing list
> > >> PROJ at lists.osgeo.org
> > >> https://lists.osgeo.org/mailman/listinfo/proj
> > >>
> > >>
> > >> _______________________________________________
> > >> PROJ mailing list
> > >> PROJ at lists.osgeo.org
> > >> https://lists.osgeo.org/mailman/listinfo/proj
> > >>
> > >>
> >
> _______________________________________________
> PROJ mailing list
> PROJ at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/proj