-
Notifications
You must be signed in to change notification settings - Fork 4
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 scaling a specific region #2
base: master
Are you sure you want to change the base?
Conversation
…d column and start/end row
@@ -72,46 +72,55 @@ | |||
{ | |||
public int tileWidth; | |||
public int tileHeight; | |||
public long minC; |
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 do not think that this is useful because scaling usually processes an entire z-section from full resolution down until it becomes a single tile or less. Processing only parts of it does not make sense. What is the rational behind this?
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 thought this would make it possible to parallelize by x and y but I can see why the entire z-section needs to be available in order for the scaling to be acurate. However we need a mechanism to keep going even when no immediate tiles are found since empty tiles may not be written. This is something that Eric requested.
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.
It's not about accuracy but about being possible at all. We cannot scale to the final level without having scaled everything beforehand. One could certainly generate one new scale level at a time, do that in chunks in parallel and after that do the next scale level in chunks. I think that's a good idea but not what's implemented here. Do you want to do that? As an alternative tool?
You are right about the mechanism to keep going despite missing tiles on the road. It was convenient to assume that if there is no data we could stop because it works without knowing about the width and height of the dataset. For that, however, we need only the physical width and height of the dataset, so only two parameters, conveniently in pixel coordinates at scale level 0 to not confuse stuff. These parameters are only required if ignoreEmptyTiles is true. What do you think?
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.
IMO we need all four parameters considering that the retiler can take all four params - I don't think it hurts having them anyway. If you prefer them to be in pixel coordinates at scale 0 that's perfectly fine and it is consistent with the retiler.
…n the tiler pattern to be consistent with the scaler
…that these would take precedence if defined over the corresponding pixel coordinates, otherwise their defaults will be derived from the corresponding pixel coordinates
Changed the target tile format in the tiler to be consistent with the way the tile format is specified in all the other cases.
Changed the scaler to support a specific region specified by start - end column tile and start - end row tile.
Changed the Downsampler to return a boolean - true if at least one pixel in the entire image is non black.