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
