optimise extract performance

[rafaqz]

Closes #625

@alex-s-gardner this PR should fix some of your performance concerns, looks like at least an order of magnitude faster, a million points should take a fraction of a second.

[alex-s-gardner]

extract no longer works if pts = Vector{Tuple{Float64, Float64}}

using GeoInterface
using Rasters

lon, lat = X(25:.1:30), Y(25:.1:30);
mask0 = Raster(falses(lon, lat));

lon = rand(25:0.1:30, 100);
lat = rand(25:0.1:30, 100);

pts1 = GeoInterface.PointTuple.([((Y=y, X=x)) for (x, y) in
    zip(lon, lat)]);

pts2 = extract(mask0, pts1, atol=0.0001, index=true, geometry=false);

ERROR: MethodError: Cannot `convert` an object of type X{Contains{Float64}} to an object of type Int64

Closest candidates are:
  convert(::Type{T}, ::T) where T
   @ Base Base.jl:84
  convert(::Type{T}, ::LoopVectorization.UpperBoundedInteger) where T<:Integer
   @ LoopVectorization ~/.julia/packages/LoopVectorization/1hqld/src/reconstruct_loopset.jl:30
  convert(::Type{T}, ::EzXML.NodeType) where T<:Integer
   @ EzXML ~/.julia/packages/EzXML/DL8na/src/node.jl:36
  ...

Stacktrace:
  [1] cvt1
    @ ./essentials.jl:468 [inlined]
  [2] ntuple
    @ ./ntuple.jl:49 [inlined]
  [3] convert(::Type{Tuple{Int64, Int64}}, x::Tuple{X{Contains{Float64}}, Y{Contains{Float64}}})
    @ Base ./essentials.jl:470
  [4] convert(::Type{Union{Missing, Tuple{Int64, Int64}}}, x::Tuple{X{Contains{Float64}}, Y{Contains{Float64}}})
    @ Base ./missing.jl:70
  [5] cvt1
    @ ./essentials.jl:468 [inlined]
  [6] ntuple(f::Base.var"#cvt1#1"{Tuple{Union{…}, Union{…}}, Tuple{Tuple{…}, UInt8}}, ::Val{2})
    @ Base ./ntuple.jl:49
  [7] convert
    @ ./essentials.jl:470 [inlined]
  [8] Tuple
    @ ./namedtuple.jl:201 [inlined]
  [9] convert
    @ ./namedtuple.jl:196 [inlined]
 [10] _maybe_add_fields
    @ ~/.julia/packages/Rasters/deZXg/src/methods/extract.jl:232 [inlined]
 [11] #_extract_point#734
    @ ~/.julia/packages/Rasters/deZXg/src/methods/extract.jl:221 [inlined]
 [12] _extract_point
    @ ~/.julia/packages/Rasters/deZXg/src/methods/extract.jl:191 [inlined]
 [13] _extract(A::Raster{…}, ::Nothing, geoms::Vector{…}; names::@NamedTuple{…}, skipmissing::DimensionalData.Dimensions.Lookups._False, kw::@Kwargs{…})
    @ Rasters ~/.julia/packages/Rasters/deZXg/src/methods/extract.jl:117
 [14] _extract
    @ ~/.julia/packages/Rasters/deZXg/src/methods/extract.jl:98 [inlined]
 [15] _extract
    @ ~/.julia/packages/Rasters/deZXg/src/methods/extract.jl:94 [inlined]
 [16] #_extract#693
    @ ~/.julia/packages/Rasters/deZXg/src/methods/extract.jl:86 [inlined]
 [17] #extract#692
    @ ~/.julia/packages/Rasters/deZXg/src/methods/extract.jl:66 [inlined]
 [18] top-level scope
    @ REPL[23]:1
Some type information was truncated. Use `show(err)` to see complete types.

Same error when not using GeoInterface:

pts1 = ([((y, x)) for (x, y) in zip(lon, lat)]);
pts2 = extract(mask0, pts1, atol=0.0001, index=true, geometry=false);

ERROR: MethodError: Cannot `convert` an object of type X{At{Float64, Float64, Nothing}} to an object of type Int64

Closest candidates are:
  convert(::Type{T}, ::T) where T
   @ Base Base.jl:84
  convert(::Type{T}, ::LoopVectorization.UpperBoundedInteger) where T<:Integer
   @ LoopVectorization ~/.julia/packages/LoopVectorization/1hqld/src/reconstruct_loopset.jl:30
  convert(::Type{T}, ::EzXML.NodeType) where T<:Integer
   @ EzXML ~/.julia/packages/EzXML/DL8na/src/node.jl:36
  ...

Stacktrace:
  [1] cvt1
    @ ./essentials.jl:468 [inlined]
  [2] ntuple
    @ ./ntuple.jl:49 [inlined]
  [3] convert(::Type{Tuple{Int64, Int64}}, x::Tuple{X{At{Float64, Float64, Nothing}}, Y{At{Float64, Float64, Nothing}}})
    @ Base ./essentials.jl:470
  [4] convert(::Type{Union{Missing, Tuple{…}}}, x::Tuple{X{At{…}}, Y{At{…}}})
    @ Base ./missing.jl:70
  [5] cvt1
    @ ./essentials.jl:468 [inlined]
  [6] ntuple(f::Base.var"#cvt1#1"{Tuple{Union{…}, Union{…}}, Tuple{Tuple{…}, Bool}}, ::Val{2})
    @ Base ./ntuple.jl:49
  [7] convert
    @ ./essentials.jl:470 [inlined]
  [8] Tuple
    @ ./namedtuple.jl:201 [inlined]
  [9] convert
    @ ./namedtuple.jl:196 [inlined]
 [10] _maybe_add_fields
    @ ~/.julia/packages/Rasters/deZXg/src/methods/extract.jl:232 [inlined]
 [11] _extract_point(::Type{…}, x::Raster{…}, point::Tuple{…}; dims::Tuple{…}, names::@NamedTuple{…}, atol::Float64, kw::@Kwargs{…})
    @ Rasters ~/.julia/packages/Rasters/deZXg/src/methods/extract.jl:221
 [12] _extract_point
    @ ~/.julia/packages/Rasters/deZXg/src/methods/extract.jl:191 [inlined]
 [13] _extract(A::Raster{…}, ::Nothing, geoms::Vector{…}; names::@NamedTuple{…}, skipmissing::DimensionalData.Dimensions.Lookups._False, kw::@Kwargs{…})
    @ Rasters ~/.julia/packages/Rasters/deZXg/src/methods/extract.jl:117
 [14] _extract
    @ ~/.julia/packages/Rasters/deZXg/src/methods/extract.jl:98 [inlined]
 [15] _extract
    @ ~/.julia/packages/Rasters/deZXg/src/methods/extract.jl:94 [inlined]
 [16] #_extract#693
    @ ~/.julia/packages/Rasters/deZXg/src/methods/extract.jl:86 [inlined]
 [17] #extract#692
    @ ~/.julia/packages/Rasters/deZXg/src/methods/extract.jl:66 [inlined]
 [18] top-level scope
    @ REPL[66]:1
Some type information was truncated. Use `show(err)` to see complete types.

[rafaqz]

In progress PR still failing tests ?

[codecov]

Codecov Report

Attention: Patch coverage is 82.03593% with 30 lines in your changes are missing coverage. Please review.

Project coverage is 82.48%. Comparing base (a15ebb1) to head (dc7ac0e).
Report is 3 commits behind head on main.

Files	Patch %	Lines
src/methods/extract.jl	82.03%	30 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #641      +/-   ##
==========================================
+ Coverage   82.32%   82.48%   +0.15%     
==========================================
  Files          60       60              
  Lines        4357     4459     +102     
==========================================
+ Hits         3587     3678      +91     
- Misses        770      781      +11     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.