You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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.
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.
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.
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?
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.
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.
Activity
weiji14 commentedon 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 commentedon 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 commentedon Sep 3, 2024
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.
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 commentedon Sep 5, 2024
Hi, that sounds good! I already wrote some boilerplate code to handle the various combinations of
ModelTiepointTag
,ModelPixelScaleTag
andModelTransformationTag
, 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-transformationThere seem to be three cases for doing coordinate transformations:
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 aTODO
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 commentedon Sep 6, 2024
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.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 commentedon Sep 18, 2024
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.