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.biv...@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.biv...@nhh.no
https://orcid.org/0000-0003-2392-6140
https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev
