Add converter from WKT2 to PROJSON strings

[juliohm]

Issue

The GeoParquet specification does not adhere to OGC WKT-CRS standards, and instead relies on PROJJSON strings.

Therefore, we need to convert from our native CoordRefSystems.wkt2 strings added in JuliaEarth/CoordRefSystems.jl#245 to the PROJJSON encoding in order to save data in GeoParquet format.

Bounty

Our current implementation, which can be found here, relies on external calls to GDAL:

function projjsonstring(code; multiline=false)
  spref = spatialref(code)
  wktptr = Ref{Cstring}()
  options = ["MULTILINE=$(multiline ? "YES" : "NO")"]
  GDAL.osrexporttoprojjson(spref, wktptr, options)
  unsafe_string(wktptr[])
end

We need to rewrite this function in terms of CoordRefSystems.wkt2(code), parsing the resulting string into a valid PROJJSON.

A Julia-native solution that

1. satisfies the PROJJSON schema
2. matches the GDAL results to the best extent possible
3. adheres to our code style and is tested with most relevant CRS codes

will get a /bounty $250.

Tips

• The opposite operation from PROJSON to WKT2 has been implemented in different languages. One example implementation in Python is https://github.com/rouault/projjson_to_wkt

[algora-pbc]

💎 $400 bounty • JuliaEarth

Steps to solve:

1. Start working: Comment /attempt #150 with your implementation plan
2. Submit work: Create a pull request including /claim #150 in the PR body to claim the bounty
3. Receive payment: 100% of the bounty is received 2-5 days post-reward. Make sure you are eligible for payouts

❗ Important guidelines:

• To claim a bounty, you need to provide a short demo video of your changes in your pull request
• If anything is unclear, ask for clarification before starting as this will help avoid potential rework
• Low quality AI PRs will not receive review and will be closed
• Do not ask to be assigned unless you've contributed before

Thank you for contributing to JuliaEarth/GeoIO.jl!

Attempt	Started (UTC)	Solution	Actions
🟢 @jealteris	Apr 04, 2025, 07:14:38 AM	WIP
🟢 @dharmitpatel81	Apr 13, 2025, 12:39:47 AM	#154	Reward
🟢 @zelosleone	Apr 20, 2025, 08:49:24 AM	#155	Reward
🟢 @nsajko	Apr 20, 2025, 09:54:21 AM	#157	Reward
🟢 @Kishan-Patel-dev	Mar 23, 2025, 12:13:36 PM	WIP
🟢 @Gmin2	Mar 23, 2025, 11:04:15 PM	WIP
🟢 @onyedikachi-david	Mar 26, 2025, 12:17:31 AM	#152	Reward

[Kishan-Patel-dev]

/attempt #150

Options

• Cancel my attempt

[Gmin2]

/attempt #150

Algora profile	Completed bounties	Tech	Active attempts	Options
@Gmin2	17 bounties from 8 projects	TypeScript, Rust, JavaScript & more		Cancel attempt

[algora-pbc]

💡 @onyedikachi-david submitted a pull request that claims the bounty. You can visit your bounty board to reward.

[dharmitpatel81]

/attempt #150

Options

• Cancel my attempt

[jealteris]

/attempt #150

[zelosleone]

I will chime in and say a few things about the bounty, maybe some advice as well specially regarding the GDAL testing, since i spent last 2 days working through it. It's actually very easy to do a complete parser (and not use regex or hardcoded matching) using tree discovery, but GDAL (in this case Arch GDAL) uses a different numbering system internally, which messes up the whole flow of testing.

[juliohm]

Thank you for sharing @zelosleone. Could you please elaborate on the different numbering system? Our ultimate goal is to completely eliminate the dependency on GDAL. So we would be happy to adjust the tests accordingly if we see there is no point in trying to match GDAL's output. The main concern we have is correctness of the PROJJSON string, and adherence to the schema.

[zelosleone]

Thank you for sharing @zelosleone. Could you please elaborate on the different numbering system? Our ultimate goal is to completely eliminate the dependency on GDAL. So we would be happy to adjust the tests accordingly if we see there is no point in trying to match GDAL's output. The main concern we have is correctness of the PROJJSON string, and adherence to the schema.

I didn't exactly test like onyedi, I used manual datas to load up the WKT2 files (since your testing builds were built exactly like this) Sample datas were taken from official sources as well, then used their authority numbers and turns out, Arch GDAL uses a different numbering system.

[juliohm]

Sample datas were taken from official sources as well, then used their authority numbers and turns out, Arch GDAL uses a different numbering system.

If you can share examples of mismatch, that can help us decide the next steps.

[juliohm]

Increasing to /bounty $400.

[zelosleone]

/attempt #150

[zelosleone]

Sample datas were taken from official sources as well, then used their authority numbers and turns out, Arch GDAL uses a different numbering system.

If you can share examples of mismatch, that can help us decide the next steps.

I will provide example data and a PR (i spent the full day on this! haha, but all things aside it was a really experimental attempt because of C calls, but my testing shows up-to-date conversion so it was a success. it will be okay even if you guys reject it tbh, though hopefully not. Small PR as well, happy easter!)

[nsajko]

/attempt #150

working on a pure Julia solution

[nsajko]

is tested with most relevant CRS codes

What do "most" and "relevant" mean here? Is it not necessary to support all EPSG definitions?

[juliohm]

What do "most" and "relevant" mean here? Is it not necessary to support all EPSG definitions?

Hi @nsajko , we need to support the EPSG codes currently mapped to CRS types here:

https://github.com/JuliaEarth/CoordRefSystems.jl/blob/ae9c4d5e038e36761a0516db53a62d4237d84172/src/get.jl#L46-L106