g.proj: add JSON support

[kritibirda26]

Use parson to add JSON support to g.proj. Currently, only works with the -p flag.

{
    "name": "Lambert Conformal Conic",
    "proj": "lcc",
    "datum": "nad83",
    "a": "6378137.0",
    "es": "0.006694380022900787",
    "lat_1": "36.16666666666666",
    "lat_2": "34.33333333333334",
    "lat_0": "33.75",
    "lon_0": "-79",
    "x_0": "609601.22",
    "y_0": "0",
    "no_defs": "defined",
    "srid": "EPSG:3358",
    "unit": "Meter",
    "units": "Meters",
    "meters": "1"
}

I tried to add support for some other flags as well but it seems the SHELL/PLAIN output needs to be parsed manually to obtain the data and there is no direct way to obtain the data directly, for instance for w flag.

Also, some floats are represented as strings at the moment and need to be fixed.

[cwhite911]

For the proj4 format flag -j and the WKT format flag -w you can just return the the flattened (flag -f) string to the json.

{
   "wtk": "string_value",
   "proj4": "string_value"
}

[kritibirda26]

@cwhite911 I have made the requested changes.

[cwhite911]

Looking good. Please add tests and update the docs.

[cwhite911]

From @florisvdh on issue #3020

Adding here that the preferred JSON encoding for g.proj output would be the PROJJSON specification: https://proj.org/en/latest/specifications/projjson.html. It's a JSON encoding of WKT2:2019.

[kritibirda26]

@cwhite911 I tried to update the output to use projjson specification, however there seem to be a lot of cases to handle. IIUC, there are 3 different major versions (4/5/6) of proj4 that need to be handled separately and another case of not having libproj4 but using internal Grass GIS functions. FWIW, libproj4 starting with v6 exposes a function to generate the projjson representation directly.

While reading the code in get_proj.c and related files, I saw some comments about a future cleanup of proj4 versions. I think it would be better to handle add the proper JSON representation of proj4 here at that stage.

[cwhite911]

@kritibirda26

@cwhite911 I tried to update the output to use projjson specification, however there seem to be a lot of cases to handle. IIUC, there are 3 different major versions (4/5/6) of proj4 that need to be handled separately and another case of not having libproj4 but using internal Grass GIS functions. FWIW, libproj4 starting with v6 exposes a function to generate the projjson representation directly.

While reading the code in get_proj.c and related files, I saw some comments about a future cleanup of proj4 versions. I think it would be better to handle add the proper JSON representation of proj4 here at that stage.

@kritibirda26 that sounds good to me. Thanks for looking into it!

[echoix]

Are we even running build that use proj4? I only remember seeing proj 5+ api at the end of configure, and now Proj is at 9.4 now.

[neteler]

Are we even running build that use proj4?

According to configure.ac we support "PROJ.4.4.6 or later".

[echoix]

Do we want to go forward finishing up and merging the existing json PRs kinda soon? since some work is being done to implement on other modules too.

[cwhite911]

We should merge this as it addresses the main purpose of the PR and make a new issues to discuss incorporating the PROJJSON specification.

[cwhite911]

@echoix same issue here. I am no longer able to resolve conversations.

[echoix]

Ok, resolved them. Do you think the tests failures are transient and I should update the PR, or there's some real changes to do?

[echoix]

Because of the open comments, when doing my rounds of PRs to merge, I didn't act on it.

[cwhite911]

We need to fix the shell format output when the g flag is set.

[cwhite911]

Suggested change

	fprintf(stdout, "%s=%s\n", projinfo->key[i], projinfo->value[i]);
	fprintf(stdout, "%-11s: %s\n", projinfo->key[i],
	projinfo->value[i]);

[cwhite911]

Suggested change

	fprintf(stdout, "%-11s: %s\n", projinfo->key[i],
	projinfo->value[i]);
	fprintf(stdout, "%s=%s\n", projinfo->key[i], projinfo->value[i]);

[cwhite911]

@kritibirda26 will you please accept these changes so we can merge this PR.

[cwhite911]

Ok, resolved them. Do you think the tests failures are transient and I should update the PR, or there's some real changes to do?

Real changes. Nice catch @echoix!