ArchGDAL.jl
ArchGDAL.jl copied to clipboard
Error debugging basic geometries
Paste the following code inside a function and execute in debug mode in VSCode:
import ArchGDAL as AG
import GeoInterface as GI
import Tables
function test()
data = AG.read("test1.gpkg")
table = AG.getlayer(data, 0)
cols = Tables.columns(table)
geoms = Tables.getcolumn(cols, :geom)
GI.geomtrait(geoms[1])
end
@enter test()
Step through the code until the line GI.geomtrait and the following cryptic error will be shown:
Error while running the debugger (consider adding a breakpoint for uncaught exceptions):
ERROR: MethodError: no method matching namemap(::Type{ArchGDAL.OGRwkbGeometryType})
The applicable method may be too new: running in world age 32436, while current world is 32543.
Closest candidates are:
namemap(::Type{ArchGDAL.OGRwkbGeometryType}) at Enums.jl:201 (method too new to be called from this world context.)
namemap(::Type{LibGit2.Consts.GIT_CREDTYPE}) at Enums.jl:201
namemap(::Type{Pkg.Types.PreserveLevel}) at Enums.jl:201
...
Stacktrace:
[1] _symbol(x::ArchGDAL.OGRwkbGeometryType)
@ Base.Enums ./Enums.jl:29
[2] show(io::IOContext{IOBuffer}, x::ArchGDAL.OGRwkbGeometryType)
@ Base.Enums ./Enums.jl:37
[3] show_typeparams(io::IOContext{IOBuffer}, env::Core.SimpleVector, orig::Core.SimpleVector, wheres::Vector{TypeVar})
@ Base ./show.jl:638
[4] show_datatype(io::IOContext{IOBuffer}, x::DataType, wheres::Vector{TypeVar})
@ Base ./show.jl:1011
[5] show_datatype
@ ./show.jl:989 [inlined]
[6] _show_type(io::IOContext{IOBuffer}, x::Type)
@ Base ./show.jl:889
[7] show(io::IOContext{IOBuffer}, x::Type)
@ Base ./show.jl:881
[8] show_typeparams(io::IOContext{IOBuffer}, env::Core.SimpleVector, orig::Core.SimpleVector, wheres::Vector{TypeVar})
@ Base ./show.jl:638
[9] show_typealias(io::IOBuffer, name::GlobalRef, x::Type, env::Core.SimpleVector, wheres::Vector{TypeVar})
@ Base ./show.jl:671
[10] show_typealias(io::IOBuffer, x::Type)
@ Base ./show.jl:724
[11] _show_type(io::IOBuffer, x::Type)
@ Base ./show.jl:886
[12] show(io::IOBuffer, x::Type)
@ Base ./show.jl:881
[13] print(io::IOBuffer, x::Type)
@ Base ./strings/io.jl:35
[14] print_to_string(xs::Type)
@ Base ./strings/io.jl:144
[15] string
@ ./strings/io.jl:185 [inlined]
[16] construct_return_msg_for_var(state::VSCodeServer.DebugAdapter.DebuggerState, name::String, value::
The dataset to reproduce the error is here: https://github.com/JuliaEarth/GeoTables.jl/blob/master/test/data/test1.gpkg
The code above used to work just fine in previous versions of ArchGDAL.jl
Which version of ArchGDAL does this still work on? Or could it be due to the new GDAL 3.6 build that comes with GDAL.jl v1.5, which was released recently?
Just to clarify, it works fine in execution mode. It is in debug mode that it fails. I don't recall running debug mode before, so maybe this never worked. I am using the latest stable release of the packages.
This attempt to debug the function came up because code that used to work fine in the previous version of ArchGDAL.jl stopped working. In particular, this geometry conversion is not working anymore:
https://github.com/JuliaEarth/GeoTables.jl/blob/a7353e5d5719f09f5a1ba192fdc640adeadbf52b/src/conversion.jl#L58-L72
The function hangs whenever I try to convert simple points in this data set.
You can reproduce with the master branch:
] add GeoTables#master
using GeoTables
# hangs with ArchGDAL v0.9.3 and GeoInterface v1.0.1
GeoTables.load("test1.gpkg")
Ok for this hang it's still useful to know the extra information I asked for, to know whether it's ArchGDAL.jl or the GDAL build we ship.
From the output of ] st -m:
[c9ce4bd3] ArchGDAL v0.9.3 [add2ef01] GDAL v1.5.0 [a7073274] GDAL_jll v301.600.0+0 [cf35fbd7] GeoInterface v1.0.1
Can you try GDAL.jl v1.4, and otherwise the previous ArchGDAL release?
Tried with GDAL.jl v1.4 and the same error occurs. Can you reproduce or is it only in my machine?
Also happens with ArchGDAL.jl v0.8 (the previous version) if I replace GI.geomtrait (which didn't exist) by GI.coordinates.
I see the same thing I think, though a bit of a different stacktrace. I see you removed the test file, so here is a permalink: https://github.com/JuliaEarth/GeoTables.jl/blob/a7353e5d5719f09f5a1ba192fdc640adeadbf52b/test/data/test1.gpkg
import ArchGDAL as AG
import GeoTables
data = AG.read("test1.gpkg")
table = AG.getlayer(data, 0)
GeoTables.GeoTable(table)
This works fine if I put a semicolon after the last line to stop it from showing. But if not, I get this:
ERROR: KeyError: key GDAL.wkbPoint not found
Stacktrace:
[1] getindex
@ .\dict.jl:819 [inlined]
[2] convert
@ D:\visser_mn\.julia\dev\ArchGDAL\src\utils.jl:164 [inlined]
[3] _infergeomtype(ptr::Ptr{Nothing})
@ ArchGDAL D:\visser_mn\.julia\dev\ArchGDAL\src\types.jl:228
[4] ArchGDAL.IGeometry(ptr::Ptr{Nothing})
@ ArchGDAL D:\visser_mn\.julia\dev\ArchGDAL\src\types.jl:257
[5] getgeom(feature::ArchGDAL.IFeature, i::Int32)
@ ArchGDAL D:\visser_mn\.julia\dev\ArchGDAL\src\ogr\feature.jl:789
[6] getgeom(feature::ArchGDAL.IFeature, name::Symbol)
@ ArchGDAL D:\visser_mn\.julia\dev\ArchGDAL\src\ogr\feature.jl:810
[7] getcolumn
@ D:\visser_mn\.julia\dev\ArchGDAL\src\tables.jl:27 [inlined]
[8] eachcolumns
@ d:\visser_mn\.julia\packages\Tables\T7rHm\src\utils.jl:127 [inlined]
[9] _buildcolumns(rowitr::ArchGDAL.IFeatureLayer, row::ArchGDAL.IFeature, st::Int64, sch::Tables.Schema{(:geom, :id, :x, :y, :z), nothing}, columns::NTuple{5, Tables.EmptyVector}, updated::Base.RefValue{Any})
@ Tables d:\visser_mn\.julia\packages\Tables\T7rHm\src\fallbacks.jl:190
[10] buildcolumns
@ d:\visser_mn\.julia\packages\Tables\T7rHm\src\fallbacks.jl:220 [inlined]
[11] columns
@ d:\visser_mn\.julia\packages\Tables\T7rHm\src\fallbacks.jl:256 [inlined]
[12] domain(t::GeoTables.GeoTable{ArchGDAL.IFeatureLayer})
@ GeoTables d:\visser_mn\.julia\dev\GeoTables\src\geotable.jl:21
[13] show(io::IOContext{Base.TTY}, #unused#::MIME{Symbol("text/plain")}, data::GeoTables.GeoTable{ArchGDAL.IFeatureLayer})
@ Meshes d:\visser_mn\.julia\packages\Meshes\1bpiW\src\traits\data.jl:273
This looks like an issue in the enum mapping from ArchGDAL to GDAL, pointing to this line. It's a bit hard to follow though.
The debug issue might be the same, since the debugger tries to show more things.