-
Notifications
You must be signed in to change notification settings - Fork 3
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
unnecessary(?) extra dimension when reading GeoImage to array #7
Comments
Is there any case where you wouldn't want to drop that dimension? It is a placeholder for a temporal dimension. I guess you wouldn't want to always squeeze. If you were expecting 4 dimensions, but there was only one image, then that dim would disappear. Does it cause a problem if you don't squeeze?
|
I think that was really the original question - is the dimension potentially used for anything. I was not sure.
|
a temporal dimension makes sense, but I think it would make more sense if it were (time, bands, rows, columns). Then you could call arr = img[0].Read() which would return a shape of (80, 548, 4395) [i.e., the same result as if you were to call arr = img.Read().squeeze() on an image with 4 dimensions (time, bands, rows, cols)] Is there an advantage or a particular convention for having the temporal dimension expressed band by band instead of entire images expressed over time? |
Any ordering is fine to me, but I guess I like the idea of |
when reading a multiband GeoImage to array with img.Read(), there is an extra dimension in the resulting array:
For example, this 80 band image:
This can be overcome with a numpy function ( arr = img.Read().squeeze() ), but seems an unnecessary step if there isn't a reason to have the extra dimension.
The text was updated successfully, but these errors were encountered: