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 scaling a specific region #2

Open
wants to merge 35 commits into
base: master
Choose a base branch
from

Conversation

cgoina
Copy link

@cgoina cgoina commented Oct 2, 2015

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.

@@ -72,46 +72,55 @@
{
public int tileWidth;
public int tileHeight;
public long minC;
Copy link
Contributor

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?

Copy link
Author

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.

Copy link
Contributor

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?

Copy link
Author

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.

cgoina added 26 commits October 2, 2015 18:53
…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
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

Successfully merging this pull request may close these issues.

2 participants