[PROJ] Proj 6 API questions

Kristian Evers kreve at sdfe.dk
Mon Mar 18 22:36:01 PDT 2019 


> On 19 Mar 2019, at 02:19, Nyall Dawson <nyall.dawson at gmail.com> wrote:
> 
> 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.
> 
> I'm a little confused by some of the results I'm seeing here. Eg:
> 
>> bin/projinfo -o all "Airy 1830"
> 
> PROJ string:
> +ellps=airy
> 
> WKT2_2015 string:
> ELLIPSOID["Airy 1830",6377563.396,299.3249646,
>    LENGTHUNIT["metre",1],
>    ID["EPSG",7001]]
> ...
> 
> Looks good. But if I try querying EPSG:7001, I get
> 
>> bin/projinfo -o all "EPSG:7001"
> 
> input string: parsing of user string failed: crs not found
> 
> Shouldn't that give the same results as searching by name?
> 

From the projinfo docs:

"where {object_definition} or {object_definition} is a PROJ string, a WKT string,
an object name or a AUTHORITY:CODE (where AUTHORITY is the name of a
CRS authority and CODE the code of a CRS found in the proj.db database)."

You are giving a authority:code combination so it is only looking for a CRS. With
the -k switch you can change that behaviour to look for a operation instead. 

Maybe there’s a need for more options to the -k switch? Like ellipsoid, axis, AoU
and so on?

> 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
> _______________________________________________
> PROJ mailing list
> PROJ at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/proj

More information about the PROJ mailing list