[Feat] Rewrite r.geomorphon JSON output to use parson library

[petrasovaa]

Is your feature request related to a problem? Please describe.
JSON output was added to r.geomorphon before introducing parson library.

The idea is to rewrite the current implementation to use parson library
for better maintainability.

[sakirr05]

hey @petrasovaa should the JSON output structure and keys remain exactly the same as the current implementation,
with this being a pure refactor to parson only?

[Rhushya]

@petrasovaa

I’d like to work on this issue. Here’s what I’m thinking:

Right now, the code manually builds JSON using a big array of tokens and then writes it out with custom formatting.

My plan is to replace that with the parson library, which GRASS already uses in other modules like v.what. Instead of storing tokens and formatting them manually, I’ll directly build the JSON object using parson’s API.

The external API will stay exactly the same (functions like prof_int, prof_sso, etc.)

Only the internal implementation will change

I’ll follow the same pattern used in the v.what module

I’ll add the parson library to the Makefile where needed

One question before I start:
Should I focus only on JSON output, or do you also want YAML and XML to be migrated?

If this sounds okay, I can open a draft PR to get feedback early.

Thanks

[echoix]

I’ll add the parson library to the Makefile where needed

The library already has wrappers in GRASS, it is not a "new" library to add.

One question before I start:
Should I focus only on JSON output, or do you also want YAML and XML to be migrated?

Focus on JSON, to make a concise PR. The bottleneck will likely be reviewing, so it would help out to keep it simple. The other two formats have probably different solutions.

If this sounds okay, I can open a draft PR to get feedback early.

Thanks

[Abhi-d-gr8]

Hi @petrasovaa and @echoix,
I opened PR #6984.

It switches r.geomorphon’s JSON profile output from manual string formatting to the GRASS JSON wrapper (gjson/parson), so we avoid comma/indent edge cases and build the output via a proper JSON object model.

YAML/XML paths are unchanged. The PR also adds a small test to sanity-check that the JSON file is created, non-empty, and contains the expected top-level keys.

[Rhushya]

Hi @petrasovaa and @echoix,

I've opened PR #7003 to address this issue.

My implementation switches the JSON profile output from manual string formatting to the GRASS gjson/parson wrapper. I followed the feedback to keep it simple - only the write_json() function was rewritten while keeping the existing token system so YAML and XML output remain unchanged.

The approach follows the same pattern used in the v.what module.

Thanks