Thanks for the brain dump Andrea (and to Devon for starting this
conversation). The key reason we are reaching out to geotools-devel is the
sheer wasted disk space represented by a static "gdal command line"
solution (which no doubt would perform better).
Devon has been exploring the dynamic approach (using a resample prior to
mosaic) in a branch. We did not consider grouping granules with similar CRS
- as our unsupported/dem use cases focuses on many overlapping granules
that are sorted according to need (resolution, date, etc...).
This work will be a balancing between meeting our use-case - and leaving
the design open for other stories that are perhaps more common. Thank you
for the information on "excess granule removal" - while I have identified
it as a risk I am not sure it will be addressed in this first cut.
--
Jody Garnett
On 13 April 2016 at 01:37, Andrea Aime <andrea.a...@geo-solutions.it> wrote:
> On Tue, Apr 12, 2016 at 7:17 PM, Devon Tucker <devonrtuc...@gmail.com>
> wrote:
>
>> Hi all,
>>
>> We've been looking into doing on-the-fly reprojection in image mosaic to
>> handle multiple projections dynamically (kinda similar to what QGIS can
>> do). Some of the issues with this we've worked out already, but one thing
>> I've been wondering is where might be an appropriate place in the code to
>> do the actual resampling.
>>
>> My first thought would be somewhere in the RasterLayerResponse either in
>> the prepareResponse or produce methods either during or after the granules
>> are collected, but I'm definitely interested in advice/feedback on what's
>> good/appropriate.
>>
>
> Hi,
> as Simone said mixing multiple projections in the same mosaic can be
> tricky.
> Mind, I'm not exactly the expert here, Daniele would know more and I'd
> invite him to chip in and correct mistakes/fill in
> voids.
> This is also going to be a bit of a brain dump, and it has a lot of
> facets... I'll just assume by now you're familiar with
> both mosaic and coverage rendering.
>
> First of all, as you have might noticed the mosaic does not use full
> coverage readers, but imageio, and uses a single grid to
> world transform for everything (assuming the geometry maps the bbox of the
> file). This is done for performance reasons,
> reading the whole file header can take time (and sometimes you have to
> read 1-2 sidecar files, depending on the format).
>
> With multiple CRSs in the mix I believe you'll have to register the CRS of
> the granule... in the lucky case that means storing
> a EPSG number, but what about CRSs that do not have a match in the EPSG
> database?
> Similar but not same, there's the issue of images that have rotated world
> to grid transforms, which we do not handle today,
> and for which I guess one would have to store the transform in the index.
>
> Either that, or start using actual coverage readers to do the reading, and
> take a performance hit for doing so.
>
> There's also the issue that the index needs to have geometries in a single
> CRS, and the mosaic itself has to advertise
> itself as a uniform CRS object, so one has to decide how to set the target
> CRS in advance I believe.
>
> Then there is the actual mosaicking. Right now we read the data, apply an
> affine to position the image in raster space
> so that it can be mosaicked, and then mosaic the images.
> With multiple CRSs it is temping to read the image, reproject it to the
> target CRS, apply affine, and then mosaic,
> but from experience doing so might result in black/white lines, or slight
> visual mis-alignemnts, due to border effects (if two tiles that are supposed
> to touch each other are reprojected separately).
>
> Normally we avoid the issue above by collecting all granules in the
> desired sequence (applying whatever sort by is required,
> e.g., freshest on top, highest res on top), then group the sequence in
> subsets of common CRS, mosaic them, reproject the
> results, make a grand mosaic of the partial results.
>
> Now, there is another catch in this game, if the mosaic reader does not
> advertise it can reproject, the rendering machinery
> will ask stuff in its advertised native CRS and then deal with
> reprojection on its own, applying a set of extra steps known
> as "advanced projection handling" to deal with common but nasty border
> cases (dateline, polar wrapping, un-reprojectable areas, and so on).
> This means two reprojections, one from native to mosaic declared CRS, and
> then another from mosaic declared to target one...
> we have a "warp to warp" simplification in ImageWorker, but it's not going
> to work always because in general you'll have mosaic operations
> in the middle (read -> mosaic same crs -> warp to mosaic crs -> mosaic all
> -> warp to target).
> Double reprojection normally has a visible effect on quality, since you're
> resampling pixels (heavily) twice, and of course
> takes also some performance toll.
> Also, in a multi-crs mosaic you're performing reprojection internally, and
> not all of them will be "sane", some will trigger
> the artifacts and errors that advanced projection handling is designed to
> handle.
>
> The code can detect readers that can do reprojection on their own (e.g.,
> the WMS reader) and ask directly for the
> output in target CRS, but in that case of course it cannot apply the
> special handling anymore, if the result of the read is already
> in the desired CRS.
>
> In the best of worlds, the mosaic would declare itself as reprojecting
> capable, but able to perform advanced projection
> handling internally... which I believe should be possible, but not trivial
> (don't have a one minute suggestion, need
> some design work to lay it out).
>
> Jody, about your question about having several overlapping samples, I'm
> wondering if your angle is just to avoid
> opening source images that are not contributing to the final output (in
> case you have a lot of overlapping ones).
> This is know as "excess granule removal" and we have a few implementation
> of it lying around, but it requires one
> to quickly access a good, but not too complex footprint of each granule,
> put them in the right order, and process
> until the target area is full or the granules are exhausted. That
> information is normally not available in a standard
> GT image mosaic, we normally perform that pre-processing before getting to
> it, but one could also look at extending
> mosaic to have simplified footprints around.
>
> Hope this helps...
>
> 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
>
> *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*
>
> Le informazioni contenute in questo messaggio di posta elettronica e/o
> nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
> loro utilizzo è consentito esclusivamente al destinatario del messaggio,
> per le finalità indicate nel messaggio stesso. Qualora riceviate questo
> messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
> darcene notizia via e-mail e di procedere alla distruzione del messaggio
> stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
> divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
> utilizzarlo per finalità diverse, costituisce comportamento contrario ai
> principi dettati dal D.Lgs. 196/2003.
>
>
>
> The information in this message and/or attachments, is intended solely for
> the attention and use of the named addressee(s) and may be confidential or
> proprietary in nature or covered by the provisions of privacy act
> (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
> Code).Any use not in accord with its purpose, any disclosure, reproduction,
> copying, distribution, or either dissemination, either whole or partial, is
> strictly forbidden except previous formal approval of the named
> addressee(s). If you are not the intended recipient, please contact
> immediately the sender by telephone, fax or e-mail and delete the
> information in this message that has been received in error. The sender
> does not give any warranty or accept liability as the content, accuracy or
> completeness of sent messages and accepts no responsibility for changes
> made after they were sent or for other risks which arise as a result of
> e-mail transmission, viruses, etc.
>
> -------------------------------------------------------
>
>
> ------------------------------------------------------------------------------
> Find and fix application performance issues faster with Applications
> Manager
> Applications Manager provides deep performance insights into multiple
> tiers of
> your business applications. It resolves application problems quickly and
> reduces your MTTR. Get your free trial!
> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
> _______________________________________________
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
>
------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
