Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add GDT_Int8 data type #423

Merged
merged 1 commit into from
May 6, 2024
Merged

add GDT_Int8 data type #423

merged 1 commit into from
May 6, 2024

Conversation

tiemvanderdeure
Copy link
Contributor

A Signed Int8 data type was added in GDAL 3.7: https://gdal.org/development/rfc/rfc87_signed_int8.html

This PR adds support for this datatype.

The GDALDataType enum defined in this package does not completely match the enum in the latest version of GDAL (I found it here: https://gdal.org/doxygen/gdal_8h.html).

For now I just added GDT_Int8 as field 14 and moved GDT_TypeCount to field 15. I'm not sure what consequences it would have to change the other fields?

@rafaqz
Copy link
Collaborator

rafaqz commented May 6, 2024

@meggart DiskArrays 0.4 is creating some issues still, we really need that version fix

@felixcremer
Copy link
Contributor

The DiskArrays compat is fixed in General and the tests could be rerun on 1.6

@rafaqz
Copy link
Collaborator

rafaqz commented May 6, 2024

Int8 was added to GDAL here:
OSGeo/gdal#6634

@yeesian yeesian merged commit 3254f27 into yeesian:master May 6, 2024
10 of 11 checks passed
@yeesian
Copy link
Owner

yeesian commented May 6, 2024

Thank you!

@tiemvanderdeure tiemvanderdeure deleted the gdt_int8 branch May 7, 2024 08:17
@asinghvi17
Copy link
Contributor

asinghvi17 commented May 11, 2024

It looks like this is causing precompiles to fail for me on Mac M1, possibly the compat bounds on GDAL.jl were too loose. I seem to have some other package issues as well though.

ERROR: LoadError: UndefVarError: `GDT_Int8` not defined
Stacktrace:
  [1] eval
    @ ./boot.jl:385 [inlined]
  [2] eval
    @ ~/.julia/packages/ArchGDAL/SiT9o/src/ArchGDAL.jl:1 [inlined]
  [3] _broadcast_getindex_evalf
    @ ./broadcast.jl:709 [inlined]
  [4] _broadcast_getindex
    @ ./broadcast.jl:682 [inlined]
  [5] getindex
    @ ./broadcast.jl:636 [inlined]
  [6] copyto_nonleaf!(dest::Vector{ArchGDAL.GDALDataType}, bc::Base.Broadcast.Broadcasted{Base.Broadcast.DefaultArrayStyle{1}, Tuple{Base.OneTo{Int64}}, typeof(ArchGDAL.eval), Tuple{Base.Broadcast.Extruded{Vector{Any}, Tuple{Bool}, Tuple{Int64}}}}, iter::Base.OneTo{Int64}, state::Int64, count::Int64)
    @ Base.Broadcast ./broadcast.jl:1098
  [7] copy
    @ ./broadcast.jl:950 [inlined]
  [8] materialize
    @ ./broadcast.jl:903 [inlined]
  [9] (::ArchGDAL.var"#1#5")(a::Expr)
    @ ArchGDAL ./none:0
 [10] iterate(g::Base.Generator{NTuple{16, Expr}, ArchGDAL.var"#1#5"}, s::Int64)
    @ Base ./generator.jl:47
 [11] var"@convert"(__source__::LineNumberNode, __module__::Module, args::Vararg{Any})
    @ ArchGDAL ~/.julia/packages/ArchGDAL/SiT9o/src/utils.jl:102
 [12] include(mod::Module, _path::String)
    @ Base ./Base.jl:495
 [13] include(x::String)
    @ ArchGDAL ~/.julia/packages/ArchGDAL/SiT9o/src/ArchGDAL.jl:1
 [14] top-level scope
    @ ~/.julia/packages/ArchGDAL/SiT9o/src/ArchGDAL.jl:17

@visr
Copy link
Collaborator

visr commented May 11, 2024

Yes looks like #425

@rafaqz
Copy link
Collaborator

rafaqz commented May 11, 2024

Yeah we forgot to add lower bounds. Its not a new change but there must still be ways to get the old binaries

@visr visr mentioned this pull request May 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants