• [x] I agree to follow the project's code of conduct.
• [x] I added an entry to CHANGES.md if knowledge of this change could be valuable to users.

I noticed that there is a segmentation fault when calling read_as_string for the MDArray if it is not of type string. This is why I check for its datatype first.

Moreover, there are new Clippy lints that I had to consider.

• [X] I agree to follow the project's code of conduct.
• [x] I added an entry to CHANGES.md if knowledge of this change could be valuable to users.

We ran into the problem of having non-Send Layers. Without Send it is barely usable in an asynchronous or threading context. You cannot store it somewhere and create tasks that do something with them since you would need to send a Layer to another thread.

From previous discussions about thread-safety in GDAL we found out that we must not access Datasets or Layers at the same time from different threads. But for Datasets, we found that it is safe to Send them to another thread since GDAL 2.4 (or something). For Layers, it is actually okay to assume that the are Send as long as we have a one-to-one relationship between Datasets or Layers, or, stated differently, we must ensure that there are no two Layers that point to one Dataset. If we would have to Layers pointing to the same Dataset and they are Send, then we could have two different threads accessing the same Dataset. We must not allow this.

However, from discussions with @jdroenner , we thought that if we would introduce a Layer that owns its Dataset, we could make it Send since we can ensure that the Dataset isn't accessed another time, for instance, from another thread.

So in this draft PR I've created an OwnedLayer that does exactly this, it encapsulates a Layer and its Dataset. In Dataset, we can then choose if we want to have a reference to Layer or we want to convert our Dataset into an OwnedLayer. I've added a test that this behavior works.

Since the operations on Layer and OwnedLayer are more or less the same, I've transferred them into a LayerAccess trait. This unfortunately would mean a breaking change. On the other hand, it means not much more code for preserving both types.

Having said all this, what are your opinions on OwnedLayers? Do you like or criticize the concept? What are your thoughts on naming the two types?

Closes #50 Closes #56

TODO:

• [x] figure out how to find the GDAL include path
• [x] clean up bindgen config
• [x] choose between libc and std::os::raw
• [x] see if it makes sense to split the bindings into sub-modules
• [x] decide whether to use the modules for enums
• [x] use modules for the remaining enums
• [x] pick again between 1 and TRUE
• [x] clean up the pointer casts
• [x] bring back re-exports in submodules
• [x] see where the generated file should live
• [x] figure out the Windows story
• [x] decide whether to use bindgen or commit the generated file
• [x] decide whether to use the system GDAL headers
• [x] figure out why my headers are missing parameter names
• [x] try to use the generated handle types instead of *mut c_void
• [x] consider replacing WkbType with OGRwkbGeometryType
• [x] decide whether we really want to do this
• [x] do something about OGRErr
• [x] look into i32 vs. u32 for enums
• [x] allow setting the include and link paths
• [x] allow static GDAL builds
• [x] update gdal-sys build instructions
• [x] bump version

Implement a gdal::vsi::read_dir function and test.

• [x] I agree to follow the project's code of conduct.
• [x] I added an entry to CHANGES.md if knowledge of this change could be valuable to users.

• [x] I agree to follow the project's code of conduct.
• [ ] I added an entry to CHANGES.md if knowledge of this change could be valuable to users.

Closes #239

I left alldatatypes.nc untouched because it's string arrays are not supported. Unfortunately, I had to disable these tests on pre-3.4 GDAL, where Zarr is not supported.

• [x] I agree to follow the project's code of conduct.
• [x] I added an entry to CHANGES.md if knowledge of this change could be valuable to users.

This PR adds basic support to read overviews.

Hello everyone. I hope you are having a good start to the year.

I'm having problems compiling the docs for my crate (map-engine) probably because docs.rs' build system doesn't have GDAL installed.

I saw that you guys have a custom build script that mentions a similar (?) problem. I was hoping that docs.rs would execute that and that everything would work :smile:

I also noticed that many of the crates that depend on gdal (not as a development dependency) have the same problem.

Do you have any recommendations on how to deal with this?

For future reference, I also created an issue on their repo: https://github.com/rust-lang/docs.rs/issues/1591

Thanks

I'm unable to access get the points of any GDAL Geometry instance I create. The following will fail at the last test:

#[test]
fn test_get_points() -> std::result::Result<(), GdalError> {
    let sample = "/vsicurl/https://gist.githubusercontent.com/metasim/15fb05bbe76c1d7e5583033f2b6757f7/raw/fac8b385b733f50f0b7a1466db03e7918084b4a1/test.geojson";
    let ds = Dataset::open(sample)?;
    let layer = ds.layer(0)?;
    let feature = layer.feature(0).unwrap();
    let geom = feature.geometry();

    assert_eq!(geom.geometry_count(), 1);
    assert!(geom.area() > 0.);
    assert_eq!(geom.geometry_type(), gdal_sys::OGRwkbGeometryType::wkbPolygon);
    assert!(geom.json()?.contains("Polygon"));
    let points = geom.get_point_vec();
    assert!(!points.is_empty());

    Ok(())
}

Hello! I am trying to implement support for doing SQL queries through the ExecuteSQL functions. I've got basic functionality working: you can pass a SQL query to Dataset::execute_sql and you get back a handle to a new type ResultSet, which is a thin wrapper around a handle to a Layer and the layer's Dataset. The new type was necessary because SQL result sets must be freed explicitly, whereas regular layers owned by a Dataset do not.

However, I'm submitting a draft, as I'd like your feedback on the changes, and also because I'm running into a problem, and I was hoping maybe you could help. It seems that there is some kind of problem with choosing the sqlite dialect. Using ogrinfo works just fine using sqlite with spatialite functions:

✦ ❯ ogrinfo -dialect sqlite -sql "select * from roads where highway = 'pedestrian' and NumPoints(GEOMETRY) = 3" -spat 26.1017 44.4297 26.1025 44.4303 fixtures/roads.geojson
INFO: Open of `fixtures/roads.geojson'
      using driver `GeoJSON' successful.

Layer name: SELECT
Geometry: Line String
Feature Count: 1
Extent: (26.102255, 44.429870) - (26.102745, 44.430318)
Layer SRS WKT:
GEOGCRS["WGS 84",
    DATUM["World Geodetic System 1984",
        ELLIPSOID["WGS 84",6378137,298.257223563,
            LENGTHUNIT["metre",1]]],
    PRIMEM["Greenwich",0,
        ANGLEUNIT["degree",0.0174532925199433]],
    CS[ellipsoidal,2],
        AXIS["geodetic latitude (Lat)",north,
            ORDER[1],
            ANGLEUNIT["degree",0.0174532925199433]],
        AXIS["geodetic longitude (Lon)",east,
            ORDER[2],
            ANGLEUNIT["degree",0.0174532925199433]],
    ID["EPSG",4326]]
Data axis to CRS axis mapping: 2,1
Geometry Column = GEOMETRY
kind: String (0.0)
sort_key: Real (0.0)
is_link: String (0.0)
is_tunnel: String (0.0)
is_bridge: String (0.0)
railway: String (0.0)
highway: String (0.0)
OGRFeature(SELECT):0
  kind (String) = path
  sort_key (Real) = -9
  is_link (String) = no
  is_tunnel (String) = no
  is_bridge (String) = no
  railway (String) = (null)
  highway (String) = pedestrian
  LINESTRING (26.1027453 44.4303179,26.1024025 44.4300045,26.102255 44.4298696)

However, doing the same query from inside a unit test, it seems like it is not using the sqlite dialect, even though there are no errors that say as much. The failing unit test is test_sql_with_dialect. It currently fails with:

thread 'vector::vector_tests::test_sql_with_dialect' panicked at 'called `Result::unwrap()` on an `Err` value: CplError { class: 3, number: 1, msg: "Undefined function \'NumPoints\' used." }', src/vector/vector_tests/mod.rs:133:73
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

I'm not sure if there's something special that needs to be done at compile time to enable sqlite/spatialite support, and my search-fu has not been very effective. Do you have any ideas about what is needed to get sqlite working?

Work left

• [X] I agree to follow the project's code of conduct.
• [x] Add an entry to CHANGES.md
• [x] Add documentation for Dataset::execute_sql and ResultSet
• [x] Get SQLITE dialect working
• [x] Add more unit tests around the boundaries of the API: empty result sets, erroneous queries, etc.

Use dynamic code-gen to build-around non-availabiltiy of some packages.

• [X] I agree to follow the project's code of conduct.
• [X] I added an entry to CHANGES.md if knowledge of this change could be valuable to users.

• [X] I agree to follow the project's code of conduct.
• [ ] I added an entry to CHANGES.md if knowledge of this change could be valuable to users.

At the moment, compiling the docs fail due to a problem with docs.rs/cargo. The full discussion is here: #240

This is a temporary fix for it. At least until docs.rs/cargo fixes the bug.

• [x] I agree to follow the project's code of conduct.
• [x] I added an entry to CHANGES.md if knowledge of this change could be valuable to users.

Partially addresses #306.

cc: @thomas001

• [X] I agree to follow the project's code of conduct.
• [X] I added an entry to CHANGES.md if knowledge of this change could be valuable to users.

Building on Windows using pkg-config to find GDAL works fine, if you remove the if cfg!(windows) block.

This is a quick workaround; this PR is not ready to be merged. It should also be made to work by setting GDAL_HOME, as in the Windows CI job.

Whenever I call get_vsi_mem_file_bytes_owned the operation appears to succeed with no error, however the following is always written to stderr:

ERROR 6: Cannot extended in-memory file whose ownership was not transferred

I worked around this by doing the following, which has the same effect as get_vsi_mem_file_bytes_owned, but doesn't produce the error message:

    let mut owned_bytes = vec![];
    gdal::vsi::call_on_mem_file_bytes(
        "/vsimem/some_path,
        |bytes| {
            owned_bytes.extend_from_slice(bytes);
        },
    )?;

Currently not all of the C Geometry API is wrapped, so users will need to go to gdal-sys and raw unsafe C calls from time to time. This is fine, wrapping all of GDAL is a huge undertaking. So right now I have code like this:

let p = gdal_sys::OGR_G_MakeValid(geom.c_geometry());
let v = Geometry::lazy_feature_geometry();
v.set_c_geometry(p);
v

As you can see creating a Geometry back from the raw C pointer is cumbersome and it leaks memory since v doesn't own the C geometry. I am asking for a function like Geometry::from_owned_c_geometry which will own the passed C object. So the above code could become

unsafe { 
  Geometry::from_owned_c_geometry(gdal_sys::OGR_G_MakeValid(geom.c_geometry()))
}

Please consider implementing it in public API. There seems to be a crate local function that almost does this, so maybe just change it to public .

GDAL 3.6 added support for a column-oriented API in RFC 86. This is a feature request to add an API for this in the Rust bindings.

For higher-level bindings to GDAL, such as from Python, this API is a big performance improvement as it moves the row-to-columnar conversion loop into C. I don't know how Rust-C bindings work well enough to know if this would also improve performance compared to a Rust loop. But regardless, for a Rust application that would like to use Arrow memory, it would be most ergonomic to reuse the GDAL implementation.