Well my very simple idea did in fact just get very complicated! Thank you very much for the detailed explanation. I'm not ready to give up on this, but with very tight time constraints, I think I'll focus on the GDAL virtual file system reader first and revisit this later.
On Thu, Jul 18, 2019 at 10:33 AM Andrea Aime <[email protected]> wrote: > On Thu, Jul 18, 2019 at 4:08 PM Josh Fix <[email protected]> wrote: > >> Thanks Andrea, >> >> - Can you point me to the source of the read parameters for this >> operation? Would it simply be a new member variable in >> FeatureInfoRequestParameters, or are you talking about a GeneralParameter? >> >> > A GeneralParameterValue that each GridCoverageReader gets as part of the > read operation > > >> >> - Is "excess granule removal" something that I would have to >> call/invoke? >> >> Something that you have to prepare for adding extra information in the > sources, either sidecar masks or integrated raster masks, and then > configure in > the mosaic file to activate. There are no much docs about it I think (or > at least, a quick google search did not return them), but there is a small > mention here: > https://geoserver.geo-solutions.it/edu/en/raster_data/mosaic_pyramid.html > > Anyhow, probably something you're not going to use. > > >> >> - For the feature collection aspect, the RasterLayerIdentifier >> currently returns a FeatureCollection containing a single SimpleFeature >> containing the pixel values. Instead of that feature containing a feature >> collection, I could potentially generatemultiple features in the >> collection >> that's already being created, one for each feature at that pixel location. >> However, this seems overkill and excessive duplication of data as each >> feature would have the same values. >> >> Agreed > >> >> - Using complex features for the response and including other feature >> data you mentioned (cloud cover, etc), in the event of multiple >> originating >> features, would those values have to be aggregated or averaged or >> something? Taking this a step further, would it be useful or make sense >> to >> build that collection that includes the original individual feature data >> and original pixel values for each original feature, and then a >> meta-feature that represents the mosaic? >> >> It would allow to avoid the duplication and create a "tree model" where > the root has the pixel values and a property contains a list of > sub-features. > However switching from simple to complex features is hard... it would > allow for probably the best setup, but it's hard. > > >> I'm getting pretty far out of my league here as this gets more complex, >> as I don't understand how granule selection works or what actually happens >> when there are multiple images. I based my original proposal on the >> discovery that the coverage contains a single "sourceUrl" property at the >> time the single SimpleFeature containing the pixel values is created. >> Tracing back further, the GranuleLoadingResult contains a single feature >> called "originator", and the RasterLayerResponse contains a single String >> for "sourceUrl", which it puts in the grid coverage's property map with the >> key GridCoverage2DReader.SOURCE_URL_PROPERTY. >> > > That property is a "fake", it just gives you the url of one of the > granules used. I don't remember why/how it was added, Ben worked on it. > If you check the coverage returned it also contains the list of all paths > for source files though, see > > https://github.com/geotools/geotools/blob/6df64a73e9b5288ed7523da95a8446b45fce0205/modules/library/coverage/src/main/java/org/geotools/coverage/grid/io/GridCoverage2DReader.java#L97 > and its usages. > > Image mosaic has "killed" many developers, only the most senior ones in > GeoSolutions are allowed anywhere > near it (part because it's very old code, part because it does so many > things it's hard to keep it in one developer's head... > I haven't managed to fit it all into mine so far)... you have been warned > ;-) > > Cheers > Andrea > > == > > GeoServer Professional Services from the experts! Visit > http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf > Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa > (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 > http://www.geo-solutions.it http://twitter.com/geosolutions_it > ------------------------------------------------------- *Con riferimento > alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - > Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni > circostanza inerente alla presente email (il suo contenuto, gli eventuali > allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i > destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per > errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le > sarei comunque grato se potesse darmene notizia. This email is intended > only for the person or entity to which it is addressed and may contain > information that is privileged, confidential or otherwise protected from > disclosure. We remind that - as provided by European Regulation 2016/679 > “GDPR” - copying, dissemination or use of this e-mail or the information > herein by anyone other than the intended recipient is prohibited. If you > have received this email by mistake, please notify us immediately by > telephone or e-mail.* >
_______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
