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

[GEOT-5392] Mosaicking refactor #1253

Merged
merged 1 commit into from Aug 17, 2016
Merged

Conversation

dvntucker
Copy link
Contributor

Lots of changes here. Refactored a lot of the Mosaicker into its own package.

  • GranuleCollector becomes SubmosaicProducer. SubmosaicProducer is now responsible for mosaicking its own contents.
  • ReprojectingSubmosaicProducer implementation for OTF reprojection.
  • All backwards compatible with imagemosaic
  • Test cases for the new mosaic implementation

Mainly putting this PR together for ease of review/commenting

@aaime
Copy link
Member

aaime commented Jul 27, 2016

It seems there are conflicts

@dvntucker
Copy link
Contributor Author

Yep, I'll take a look this morning. Hopefully nothing too crazy.

@dvntucker dvntucker force-pushed the mosaicking_refactor branch 2 times, most recently from 983f0c0 to 67ffe61 Compare July 27, 2016 19:11
@aaime
Copy link
Member

aaime commented Jul 28, 2016

The first two commits create a lot of new public API (visible to anyone using Geotools, not just inside the mosaic) apparently only for the sake of moving 3 classes in their own package. I recommend moving those classes back and return the visibility to package private.
It could however be argued that mosaic is already pretty broken in that respect, since it's already exporting ton of public classes... so maybe not a big deal, let's talk about it.

* Responsible for creating subsets of the whole imagemosaic. Since there are frequently parts of
* a mosaic that need to be handled differently, a submosaic producer is responsible for handling
* those parts separately before they're added to the whole mosaic. For example a single dimension
* can be handled on its own before being
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"before being..." incomplete javadoc

@dvntucker
Copy link
Contributor Author

This is now rebased off of the formatting changes.

@@ -137,14 +140,25 @@

OverviewsController overviewsController;

private CoordinateReferenceSystem granuleCRS;

public GeneralEnvelope coverageEnvelope;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The granule CRS is added and exposed via a getter, but this one is public?
The name is also confusing, what you really have is the granule/reader envelope, not the "coverage" one, indeed the descriptor does not deal with coverages at all.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll change the name to be more accurate and take a look at the visibility to make sure it's correct.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This has been renamed and been made private.

SimpleFeature granuleFeature = granuleDescriptor.getOriginator();
SimpleFeature templateFeature = templateDescriptor.getOriginator();
for (SortBy sortKey : sortBy) {
Object incomingAttribute = granuleFeature
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure I understand why this is necessary. I though ensuring uniform CRS in the producer was enough. E.g., if I have all features in the same CRS but I'm sorting on date, do I really need to roll each feature in its own sub-mosaicker?

@aaime
Copy link
Member

aaime commented Aug 10, 2016

Just added a few more minor comments, everything looks otherwise pretty good. Looks like there are merge conflicts though.

@dvntucker
Copy link
Contributor Author

I'll squash and rebase. I also want to rename one of the packages (granule collector) before merging.

Creating a GranuleCollectorFactory to abstract out creating granule
collectors, moving actual mosaic creation logic into granule collector,
eventually going to rename these classes to reflect their new
responsibilities. Had to make some inner classes static to accomplish
this.
Moving GranuleCollector to its own package + all the necessary modifier changes for that
Adding granule collector factory to raster layer response
Indexer is now initialized when ImageMosaic is initialized.
this was done so that we have access to its configuration while
reading the image mosaic.
A decent number of things shuffling around, in particular moving some
subclasses out of RasterLayerResponse to top level classes for clarity
(since these classes are now used outside of this class)
Added the correct test results image
Don't use default Operations object, instead create one with hints we may need.
Removed some unused code that was missed
Removed some unused imports
Fixed a test case with a fixed number and the size check in RasterLayerResponse to account for nulls in the list
Fixed an issue where indexer file wasn't getting initilized correctly

Reformatting the code in Eclipse

Renamed isHasAlpha and isDoTransparency to more sensible names

- Changed ReprojectingConfigHandler to properly respect sort order
- Relax requirement on property collectors in order to support collectors that don't need config
- Added some defaults to properties collectors and granulecollector when HETEROGENEOUS_CRS is true

- Rename coverageEnvelope to granuleEnvelope and make its access private

- Removing unused granuleCRS

- Rename old references to GranuleCollectors to SubmosaicProducers

- Move Mosaicker into its own compilation unit.

- Add another utility method to indexer utils for setting params on an Indexer
- Remove submosaic producer artifacts from GranuleCatalog and CatalogConfiguration bean, now moved to RasterManager

- Removed some debugging code that had been left in.

Simplified the sorting

Fixed a test that had been messed up by a mangled rebase
@dvntucker
Copy link
Contributor Author

Simplified the Sorting along the lines we discussed last week.

@bmmpxf
Copy link

bmmpxf commented Aug 16, 2016

@aaime Is this ready to be merged now?

@aaime
Copy link
Member

aaime commented Aug 17, 2016

All good. I noticed at least one file with missing copyright header, I'll add it post-merge

@aaime aaime merged commit 89fcf34 into geotools:master Aug 17, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
3 participants