Release 0.15

[metasim]

I'd like to advocate for a new release. It's been 6 months since 0.14. Internally in my org, we're building from GitHub URLs, which I don't like doing for too long.

I'd also like to learn how to do a release if the project owners are amenable to that.

Open Items

https://github.com/georust/gdal/milestone/1

[metasim]

A convenience summary of the changes since 0.14:

---

• Added SpatialRef::to_projjson

  • Add SpatialRef::to_projjson() #389

• Added Geometry::length

  • Add Geometry::length #384

• Added Geometry::union

  • add union operation for geometry #379

• Added Geometry::from_gml

  • Add Geometry::from_gml #378

• Added CoordTransform::new_with_options and CoordTransformOptions

  • Implement CoordTransformOptions and CoordTransform::new_with_options constructor #372

• Set the link flag of gdal-sys to "libgdal". Emit the libgdal version via cargo:version_number. Remove wrong build-dependency on gdal-sys and remove docs_rs workaround.

  • link and version #377

• Added Geometry::from_geojson

  • Add Geometry::from_geojson #375

• Added CslStringList::add_string

  • Add CslStringList::add_string #364

• Possibly breaking: Set MSRV to 1.58.

  • Make clippy happy #363

• Added a TryFrom array implementation for CslStringList

  • Replace CslStringList From implementation with TryFrom #362

• Added Rasterband::c_rasterband to obtain the raw C pointer to GDALRasterBandH

  • Adds c_rasterband method to Rasterband #359

• Breaking: Feature::geometry returns an Option<&Geometry> instead of &Geometry. Calls to Feature::geometry will no longer panic.

  • Handling cases where feature may not have any geometry at all #349

• Breaking: RasterBand::band_type returns the GdalDataType enum instead of GDALDataType::Type ordinal. Fixes #333

  • Fixes leakage of GDALDataType::Type in RasterBand. #334

• The default features of the chrono dependency are now disabled

  • Disable default chrono features #347

• Added prebuilt bindings for GDAL 3.6 (released 6 November 2022).

  • Add prebuilt bindings for GDAL 3.6 and document how to do it #352

• Breaking: Layer::spatial_ref returns Option instead of Result, thereby better reflecting the semantics documented in the C++ API

  • Changed return type of Layer::spatial_ref from Result to Option. #355

• Exposed various functions on Geometry: make_valid, geometry_name, and point_count.

  • Implements Geometry::make_valid. #356

• Exposed read_arrow_stream on Layer to access OGR's columnar reading API.

  • Implement support for RFC 86: Column-oriented read API for vector layers #367

• Exposed spatial predicates over Geometry: intersects, contains, disjoint, touches, crosses, within, and overlaps.

  • Exposed spatial predicates over Geometry #366

• Added Geometry::envelope and Geometry::envelope_3d.

  • Added envelope* methods to Geometry. #370

• Added support for getting the SpatialRef of embedded ground control points (GCPs) via Dataset::gcp_spatial_ref.

  • Support for accessing the SpatialRef of GCPs. #397

[lnicola]

I was planning to work on exposing the GCPs, since somewhat requested it recently, and it works as a counterpart to #397. What do you think?

We might also want #400.

[metasim]

I was planning to work on exposing the GCPs

I started looking into that as well, and I came back to thinking we needed to define a better set of principles around pointers to foreign types, which led to the foreign_types prototype, which leads to a bunch of breaking changes, which leads to debates on if we should or shouldn't do it, etc. etc. etc 😆

So it's one of those "is perfect being the enemy of good enough" evaluations. Where I sit right this moment is: Let's get what's working released now, and have a fresh baseline for the next round of improvements, which may or may not include cleaning up pointer handling.

What might help me in considering this is understanding the "cost of releasing". I've only been around for 2 or 3 releases, but each time it seems to create an urge to get straggling features in before cutting the release, making me believe that a release is a "costly" activity.

Is this true, and if so, are there some structural changes we can make to enable us to more easily do releases more regularly?

In my other projects I usually feel more comfortable when PRs can live unreleased state for a bit to allow willing participants to give them some extra testing before getting released, while unwilling users can just stick to feature that have matured for a while longer. But that's just personal preference.

[lnicola]

For GCP's, I think we could simply copy the data and return a Vec, bypassing the fancy pointer question. But okay, we can postpone that if you want. I'd still want to get in the GDAL 3.7 bindings though -- it shouldn't be hard, I can try that tomorrow.

Is this true, and if so, are there some structural changes we can make to enable us to more easily do releases more regularly?

I'd personally like a workflow where we bump the version and it would get published automatically 😅.

Other than that, no, I don't have any specific ideas.

[metasim]

For GCP's, I think we could simply copy the data and return a Vec

I'm not adverse to that if it's just fetching the values. Would it be all of the fields here?

Comprehensively speaking (again, beyond "good enough"?), I was assuming it would include:

• GDALInitGCPs (...::new??)
• GDALDeinitGCPs (Drop??)
• GDALDuplicateGCPs (Clone??)
• GDALGCPsToGeoTransform
• GDALGetGCPCount
• GDALGetGCPProjection
• GDALSetGCPs
• GDALSetGCPs2.

I'd still want to get in the GDAL 3.7 bindings though -- it shouldn't be hard, I can try that tomorrow.

Sounds great! Do it!

[metasim]

I'd personally like a workflow where we bump the version and it would get published automatically.

I saw that in another project recently but forgot which. I'll see if I can find it. I think it was triggered from on.release event, which is cool.

[metasim]

PS: I should have done GDALGetGCPProjection when I did GDALGetGCPSpatialRef, but I was responding to a colleague's specific request and didn't pay close attention to neighboring functions.

[jdroenner]

I am on vacation and will be back next week. Will look into this issue then :)

[lnicola]

I saw that in another project recently but forgot which.

rowan does that by checking whether there's already a git tag with the current version. There's a little crate for it, xaction.

[metasim]

@lnicola Since we have a week until jdreonner gets back, would you like help on the GCP stuff? Want me to take an initial stab at it, or were you really wanting to do it?

Edit: Started this branch: #402

[lnicola]

@metasim I pretty much got the GCP access working.

[jdroenner]

i'm back from vacation :)
Are there things we want to get into the release? Is the GCP access done?

[lnicola]

Welcome back!

I'll rebase it today and the API is a bit questionable. Then there's also #406, which might be nice to get in. That one has some pending changes I'd like to see, but might benefit from another pair of eyes.

[metasim]

@jdroenner I know this is annoying scope creep beyond the request to cut a release, but would you be willing to take a peek at #404 and #406 and give us your opinion of these API "shapes"?

I think #404 is probably fine (I wonder if there's a way of removing the replication of C struct in Rust for instantiation convenience purposes).

#406 has a situation where the C API uses the error code as side-band communications for indicating a default value was used, and the proposed solutions don't feel fully idiomatic.

Whether or not we get these exact APIs "perfect" is probably not that critical, but I don't think they are unique, and your advice might help us come up with a replicable solution for future cases of similar shape.

[lnicola]

This is going to be the best release ever 😃.

[metasim]

Maybe we should blog/reddit about it (briefly) so we can announce it in This Week in Rust. 🤠 🦀

See: TWIR on link only announcements

[metasim]

Anything else we want to add?

[lnicola]

I'm tempted to file a PR to tweak this API, but I think we can stop now :-).

[metasim]

I'm tempted to file a PR to tweak this API, but I think we can stop now :-).

Interesting. I use this API at work. Are you looking to replace the tuples with something more semantically explicit?

[lnicola]

Yeah, to unpack the tuples. And I'm not use isize is useful there. I've used it a number of times, and it was always annoying :-). Anyway, doesn't matter.

[metasim]

And I'm not use isize is useful there.

IMO, the discrepancy between isize, usize, and i32 is all over the place, and often the fault of the C API being unclear as to whether negative values are valid, niche or invalid. I'd suggest tackling that will take careful inspection of of the C code. It is annoying, but when i tried to normalize over it in my work code it became a mess.

[metasim]

@jdroenner Anything else we need to do or can help with to cut a release (and document the process)?

[lnicola]

I wouldn't be surprised if some format (looking at you, NetCDF) supported negative cell coordinates. 🙄

[lnicola]

Just asked on the mailing list, the block offsets are always positive.

[jdroenner]

i can do the release today if all PRs you want are merged. The process is not that complex. All i need to do is editing the changelog and running cargo release 😅

[jdroenner]

https://crates.io/crates/gdal

[metasim]

Thanks @jdroenner !! 😄