georust/geotiff

Support for writing GeoTIFF files

Opened this issue · 6 comments

gschulze commented

It would be nice also to be able to write GeoTIFFs. Given that the tiff crate is used in the background, it should be straightforward to implement this. I can offer to implement this.

weiji14 commented

Hi @gschulze, yes please, go for it! The migration to the tiff crate isn't fully complete yet (been caught up in travel lately so haven't found the time), but do take a look around and open PRs as needed.

gschulze commented

Hi, @weiji14! I managed to complete the migration to the tiff crate, although it might initially seem a bit radical. The corresponding PR is #17.

Next, I would do the coordinate transformation stuff, as, in my opinion, this is what should be provided by this crate on top of the functionality already in the tiff crate.

Writing GeoTIFFs should be straightforward, then. What is missing is the functionality to retrieve all tags from a file so that files can be read, modified, and written to disk again. I filed a corresponding issue over at the tiff repository.

weiji14 commented

Hi, @weiji14! I managed to complete the migration to the tiff crate, although it might initially seem a bit radical. The corresponding PR is #17.

Nice, thanks for doing all that work! I was planning to do the migration more gradually in a series of PRs as part of #7, but reached a point where it probably made sense to do a complete rewrite. I'll try and give that PR a review this week.

Next, I would do the coordinate transformation stuff, as, in my opinion, this is what should be provided by this crate on top of the functionality already in the tiff crate.

I've got some code to get the affine transform from a GeoTIFF that was implemented in weiji14/cog3pio#8. Would be happy to upstream it to here afterwards.

gschulze commented

I've got some code to get the affine transform from a GeoTIFF that was implemented in weiji14/cog3pio#8. Would be happy to upstream it to here afterwards.

Hi, that sounds good! I already wrote some boilerplate code to handle the various combinations of ModelTiepointTag, ModelPixelScaleTag and ModelTransformationTag, according to what I understood from https://docs.ogc.org/is/19-008r4/19-008r4.html#_coordinate_transformations. You can find the current work-in-progress here: https://github.com/gschulze/geotiff/tree/feature/coordinate-transformation

There seem to be three cases for doing coordinate transformations:

  1. Transformation by one tie point and pixel scale
  2. Transformation by a transformation matrix
  3. Transformation by using multiple tie points (or ground control points)

I think cases 1 and 2 are pretty straightforward; there are examples of how to do it properly, e.g., https://github.com/OSGeo/libgeotiff.

Case 3 is more complicated, and I did not find any standard way to do it. libgeotiff just has a TODO in the code at the corresponding location. One approach that comes to my mind would be to use Delaunay triangulation to decide the three control points that must be used for transforming a particular coordinate and then use linear interpolation to do the transformation.

I'm happy to continue with the implementation or leave it up to you if you want to. In that case, feel free to use anything you might find helpful from my feature branch.

By the way, things start to go a bit off-topic here. What do you think of opening a separate (tracking) issue for the things that need to be implemented so that we can better keep track of things?

  • 👀1
weiji14 commented

I think cases 1 and 2 are pretty straightforward; there are examples of how to do it properly, e.g., https://github.com/OSGeo/libgeotiff.

Case 3 is more complicated, ...

Yep, I think I have a good handle on case 1 & 2, but 3 is an entirely different beast! We can leave a bunch of unimplemented!() calls for those in the short-term.

By the way, things start to go a bit off-topic here. What do you think of opening a separate (tracking) issue for the things that need to be implemented so that we can better keep track of things?

Yes please! I'm usually hesitant to open (too many) issues when it's just one person doing all the work, preferring to just document things in PRs, but for >1 people, then it makes sense to have a proper checklist somewhere.

feefladder commented

I think such a complex thing as 3. would better be done by geodesy? They have an issue (busstoptaktik/geodesy#86), but I think that has a deformation for every pixel in our own tiff?

Anyways, the folks over at QGIS use polynomial/spline transformations for their georeferencing.