-
Notifications
You must be signed in to change notification settings - Fork 26
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
factor out layer copying into its own function #382
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall LGTM (modulo the changes requested), thank you!
I've just made the requested changes except for one :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just removed the line superseding #381, as it's just a minor change anyway. Now it can be merged regardless of the changes in GDAL itself. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me, thanks!
Oh I just saw that the GDAL PR had already been merged and that you closed #381. I'll put the line back tomorrow, then this can be merged. |
Ok, done - sorry for the forth and back! |
Hi! I have factored out the layer copying from writelayers into its own function. So basically I changed (pseudocode):
to
That should now allow to copy data from and to arbitrary datasets, whether on disk or not. You can also give the layer indices you want to be copied. I added a tiny test for that. Furthermore I adjusted the docstrings for nicer rendering in the REPL. I'm not sure with the naming
copylayers
, is it ok? What do you think in general? Lastly, this supersedes #381, but I can take that part out if you want to merge this before the change to GDAL.