Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for writing GeoTIFF files #16

Open
gschulze opened this issue Aug 29, 2024 · 6 comments
Open

Support for writing GeoTIFF files #16

gschulze opened this issue Aug 29, 2024 · 6 comments

Comments

@gschulze
Copy link
Collaborator

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
Copy link
Member

weiji14 commented Aug 30, 2024

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
Copy link
Collaborator Author

gschulze commented Sep 3, 2024

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
Copy link
Member

weiji14 commented Sep 3, 2024

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
Copy link
Collaborator Author

gschulze commented Sep 5, 2024

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?

@weiji14
Copy link
Member

weiji14 commented Sep 6, 2024

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
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants