Roadmap to ArchGDAL v1.0

[yeesian]

I did a search on https://github.com/search?q=ArchGDAL and there's a growing usage of this package that makes it increasingly urgent for us to fix bugs, have a good API and user-friendly documentation. Opening this ticket to track the discussion and work needed for us to get to that state.

It is being tracked here: https://github.com/yeesian/ArchGDAL.jl/milestone/1.

Top of mind (in terms of priorities) for me are:

• Closing out all existing / known bugs.
• Establishing an API that prevents bugs (e.g. escaping scoped objects)
• Alignment with "well-known types & behavior" in Julialang (e.g. tables, geometries, colors, arrays, null/nothing/missing, iterators, broadcasting, errors)
• Documentation (docstrings, references, examples, and user manuals e.g. https://jump.dev/JuMP.jl/stable/)
• Establishing guidelines and expectations (What v1.0 means)
  • continuity (staying up-to-date) over features (enhancements and functionality)
    • keeping pace with GDAL and Julialang takes work
    • automation (github workflows, doctesting, etc) over user support
  • coherence (ArchGDAL.jl) over comprehensiveness (GDAL.jl)
    • GDAL.jl provides comprehensiveness coverage; so this package leans more towards API design based on
    • pragmatism & user-centrality
  • community (collaboration, documentation) over speed of progress (project management and timelines)
    • encouraging versatility comes at the "cost" of not taking sides when there are multiple good options. We recognize it as a cost, and we're willing to pay for it.

[visr]

One thing that comes to mind is to regenerate the GDAL.jl wrapper with the rewritten Clang.jl, and see what effect that has.

[yeesian]

One thing that comes to mind is to regenerate the GDAL.jl wrapper with the rewritten Clang.jl, and see what effect that has.

Is #158 a blocker? If so, I should prioritize addressing it.

[visr]

It only affects the tests, so I'd say no.

I just tried running the GDAL Clang wrapper, and it's quite different, and smarter as well. We can probably turn off those new features to avoid changing too much, but it'll require some playing around.

[visr]

Another breaking change that could perhaps still be bundled with #353 is switching from Base.convert to GeoInterface.convert, see also JuliaGeo/GeoInterface.jl#85 (comment).

[rafaqz]

Yes let's get all the convert methods moved over.