[GRASS-dev] [PROJ] GRASS GIS + PROJ 6 + GDAL 2.5

[Roger Bivand]

On Fri, 8 Mar 2019, Even Rouault wrote:

> On vendredi 8 mars 2019 12:27:37 CET Markus Metz wrote:
>> On Fri, Mar 8, 2019 at 10:49 AM Roger Bivand <Roger.Bivand at nhh.no> wrote:
>>> Since rgdal::make_EPSG() is facing the same problems of listing tabulated
>>> EPSG fields as g.proj -l, I was very happy to see Markus' code in
>>> g.proj/main.c mentioned in this thread, and have used this approach in
>>
>> https://r-forge.r-project.org/scm/viewvc.php/pkg/src/proj_info6.cpp?view=mar
>> kup&root=rgdal
>>> However, there are plenty of messages such as: "proj_as_proj_string:
>>> Unsupported conversion method: Lambert Conic Conformal (West
>>
>> Orientated)". I
>>
>>> haven't installed GRASS trunk with PROJ6, so I can't see whether g.proj -l
>>> also sees the same messages.
>>
>> I get the same messages with g.proj, but no error code from PROJ error
>> handlers.
>>
>>> If it does, maybe we could ask on the proj list
>>
>> yes, we should ask. For now g.proj is ignoring those codes for which no
>> proj string can be retrieved.
>
> I'm not sure what the question is exactly :-) Is that proj_context_errno()
> doesn't return an error in that case ?

Yes, for example:

...
     for (i = 0; i < crs_cnt; i++) {
         const char *proj_definition;

         pj = proj_create_from_database(ctx, proj_crs_info[i]->auth_name,
             proj_crs_info[i]->code, PJ_CATEGORY_CRS, 0, NULL);
Rprintf("proj_create_from_database %s: %d\n", proj_crs_info[i]->code, 
proj_context_errno(ctx));
         proj_definition = proj_as_proj_string(ctx, pj, PJ_PROJ_5, NULL);
Rprintf("proj_as_proj_string %s: %d\n", proj_crs_info[i]->code, 
proj_context_errno(ctx));
...

showing in one case:

proj_create_from_database 7082: 0
proj_as_proj_string: Unsupported conversion method: Polar Stereographic 
(variant C)
proj_as_proj_string 7082: 0

so the message is being delivered to the console (stderr?), no errno (or 
other notification seems to be set. Is there a way of checking first 
before calling proj_as_proj_string() to avoid the message?

I did find the *_destroy() functions instead of legacy pj_free() etc., 
thanks for prompting me to re-read proj.h.

I'm assuming there is no error handler to hook onto, to divert errors to 
R's error handler. In this case, it doesn't matter for replacing legacy 
functionality.

Roger

> That's related to the error being emitted from the new code emitting C++
> exceptions, which are caught by the C wrapper. It doesn't set errno style
> errors currently. I'm not a big fan of the errno approach, and find the proper
> error string currently emitted to be more expressive, but that can be
> discussed if some harmonization should be done.
>
> Even
>
>

-- 
Roger Bivand
Department of Economics, Norwegian School of Economics,
Helleveien 30, N-5045 Bergen, Norway.
voice: +47 55 95 93 55; e-mail: Roger.Bivand at nhh.no
https://orcid.org/0000-0003-2392-6140
https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en