Please don't assume you have done something wrong, that is always a clue that you have found a problem or the documentation needs help (which is a also a chance to contribute).
I will keep a look out for your bug report, ideally you could get this in before tomorrows level meeting. -- Jody Garnett On Wed, 8 Apr 2020 at 16:56, Andrew Miskelly <amiske...@weatherzone.com.au> wrote: > Hi Jody, > > In answer to your subsequent questions: > > - I haven't created a bug report yet as I've been assuming that I'm doing > something wrong. I'm happy to create an issue outlining the process that I > included at the top of the thread. Once done, I'll mention it here. > > - Enabling advanced projection handing results in a "Bursa wolf parameters > required" error. > > The projection is based on "+proj=eqc +lat_ts=0 +lat_0=0 +lon_0=140.7 > +x_0=0 +y_0=0 +ellps=WGS84 +units=m" and I enabled advanced projection > handling via the StreamingRenderer's hints. > > ... > StreamingRenderer renderer = new StreamingRenderer(); > Map<Object, Object> rendererParams = new HashMap<>(); > rendererParams.put(StreamingRenderer.ADVANCED_PROJECTION_HANDLING_KEY, > Boolean.TRUE); > renderer.setRendererHints(rendererParams); > ... > > org.opengis.referencing.operation.OperationNotFoundException: Bursa wolf > parameters required. > at > org.geotools.referencing.operation.DefaultCoordinateOperationFactory.createOperationStep(DefaultCoordinateOperationFactory.java:1220) > at > org.geotools.referencing.operation.DefaultCoordinateOperationFactory.createOperationStep(DefaultCoordinateOperationFactory.java:1281) > at > org.geotools.referencing.operation.DefaultCoordinateOperationFactory.createOperationStep(DefaultCoordinateOperationFactory.java:922) > at > org.geotools.referencing.operation.DefaultCoordinateOperationFactory.findOperationSteps(DefaultCoordinateOperationFactory.java:1006) > at > org.geotools.referencing.operation.DefaultCoordinateOperationFactory.findOperations(DefaultCoordinateOperationFactory.java:341) > at > org.geotools.referencing.operation.DefaultCoordinateOperationFactory.createOperation(DefaultCoordinateOperationFactory.java:206) > at > org.geotools.referencing.operation.BufferedCoordinateOperationFactory.createOperation(BufferedCoordinateOperationFactory.java:233) > at org.geotools.referencing.CRS.findMathTransform(CRS.java:1266) > at org.geotools.referencing.CRS.findMathTransform(CRS.java:1234) > at > org.geotools.coverage.grid.io.ReadResolutionCalculator.<init>(ReadResolutionCalculator.java:91) > at > org.geotools.renderer.lite.gridcoverage2d.GridCoverageReaderHelper.computeReadingGeometry(GridCoverageReaderHelper.java:500) > at > org.geotools.renderer.lite.gridcoverage2d.GridCoverageReaderHelper.readCoverageInEnvelope(GridCoverageReaderHelper.java:363) > at > org.geotools.renderer.lite.gridcoverage2d.GridCoverageReaderHelper.readCoverages(GridCoverageReaderHelper.java:247) > at > org.geotools.renderer.lite.gridcoverage2d.GridCoverageRenderer.renderImage(GridCoverageRenderer.java:690) > at > org.geotools.renderer.lite.gridcoverage2d.GridCoverageRenderer.paint(GridCoverageRenderer.java:897) > at > org.geotools.renderer.lite.StreamingRenderer$RenderCoverageReaderRequest.execute(StreamingRenderer.java:3880) > at > org.geotools.renderer.lite.StreamingRenderer$PainterThread.run(StreamingRenderer.java:3991) > at > java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) > at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) > at > java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > at > java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at java.base/java.lang.Thread.run(Thread.java:830) > > Andrew > > On Thu, 9 Apr 2020 at 09:54, Andrew Miskelly <amiske...@weatherzone.com.au> > wrote: > >> Yes, sorry about that. My reply to your previous email follows, without >> the inline images, and I'll reply again to address your most recent email. >> >> No, I haven't managed to solve this. >> >> I wasn't using JAI-EXT but a static call to JAIExt.initJAIEXT() in the >> test class has not changed the results. (I'm also using 23-RC, in order to >> assist with the testing effort.) >> >> The starting image, in +proj=eqc +lon_0=140.7 +ellps=WGS84, looks like >> the following (Australia in the middle longitudes; ±180° about 3/4 across >> from the left): >> https://anero.id/geotools-202003/himawari-8-visible-eqc.tif >> >> When I reproject to a full world web mercator tile using GeoTools, and >> the test case outlined earlier, I get a gap between 140.7°E and 180°E (i.e. >> the right hand side): >> https://anero.id/geotools-202003/geotools-web-mercator.png >> >> Regards, >> >> Andrew >> >> On Tue, 7 Apr 2020 at 04:22, Jody Garnett <jody.garn...@gmail.com> wrote: >> >>> I love seeing your test data, although I expect that only went to me as >>> the mailing list blocks emails past a specific size. >>> >>> Next I have a couple obvious questions: >>> >>> - I have not looked yet, did you reported this as a bug to the issue >>> tracker, having a test case (and test data) very much helps reproduce the >>> issue. >>> - Have you enabled advanced reprojection handling >>> <https://docs.geotools.org/latest/userguide/faq.html#q-what-about-raster-advanced-projection-handling> >>> (which is specially for this kind of problem) >>> >>> I am not familiar with this specific area of the code; but I am >>> interested in learning the resolution. >>> >>> -- >>> Jody Garnett >>> >>> >>> On Thu, 2 Apr 2020 at 15:59, Andrew Miskelly < >>> amiske...@weatherzone.com.au> wrote: >>> >>>> Hi Jody, >>>> >>>> No, I haven't managed to solve this. >>>> >>>> I wasn't using JAI-EXT but a static call to JAIExt.initJAIEXT() in the >>>> test class has not changed the results. (I'm also using 23-RC, in order to >>>> assist with the testing effort.) >>>> >>>> The starting image, in +proj=eqc +lon_0=140.7 +ellps=WGS84, looks like >>>> the following (Australia in the middle longitudes; ±180° about 3/4 across >>>> from the left): >>>> >>>> When I reproject to a full world web mercator tile using GeoTools, and >>>> the test case outlined earlier, I get a gap between 140.7°E and 180°E (i.e. >>>> the right hand side): >>>> >>>> Regards, >>>> >>>> Andrew >>>> >>>> >>>> On Fri, 3 Apr 2020 at 05:51, Jody Garnett <jody.garn...@gmail.com> >>>> wrote: >>>> >>>>> I was curious if you resolved this issue? Some care has been taken >>>>> with JAI-EXT operations to better handle no data etc... can you confirm >>>>> your system is setup to use these operations? >>>>> JAI itself has some ideas for extending the border area to prevent >>>>> artifacts near edges ideally a solution would hook into this. >>>>> -- >>>>> Jody Garnett >>>>> >>>>> >>>>> On Mon, 16 Mar 2020 at 21:13, Andrew Miskelly < >>>>> amiske...@weatherzone.com.au> wrote: >>>>> >>>>>> Hi GeoTools people, >>>>>> >>>>>> I have a pipeline for data from geostationary satellites which >>>>>> involves the following: >>>>>> >>>>>> - use GDAL to reproject the data from its native, geostationary >>>>>> projection to a cylindrical projection >>>>>> - use GDAL to arrange the data into a cloud optimised GeoTIFF >>>>>> - use a GeoTools based server to render imagery from the COG to >>>>>> clients >>>>>> >>>>>> The reason for reprojecting is that I've never been able to get >>>>>> GeoTools to transform from the geostationary projections. >>>>>> >>>>>> A basic geographic projection is fine in cases where the satellite is >>>>>> centred nearer to 0°E but when its field of view encompasses the dateline >>>>>> it's helpful to use an equidistant cylindrical projection that's centred >>>>>> on >>>>>> the same longitude as the satellite. That avoids dealing with an image >>>>>> which spans from 180°W to 180°E and comprises mostly "nodata" pixels >>>>>> (with >>>>>> the data at the left and right edges). >>>>>> >>>>>> When rendering the latter images using GeoTools, though, I get a band >>>>>> of missing data near the dateline. I'm wondering whether anybody can see >>>>>> where I'm going wrong. >>>>>> >>>>>> To reproduce: >>>>>> >>>>>> The following is an image produced from Himawari-8's visible red >>>>>> band, in the native geostationary projection. >>>>>> https://anero.id/geotools-202003/himawari-8-visible.tif >>>>>> >>>>>> Here it is after reprojecting to +proj=eqc +lon_0=140.7 +ellps=WGS84 >>>>>> using GDAL. >>>>>> https://anero.id/geotools-202003/himawari-8-visible-eqc.tif >>>>>> >>>>>> And here's the image from GeoTools, rendered using the code below. >>>>>> Note the band of missing data between about 140°E (the central meridian >>>>>> of >>>>>> the projection?) and the 180°E (the right hand side of the image). >>>>>> https://anero.id/geotools-202003/geotools-web-mercator.png >>>>>> >>>>>> public void test(File in /* himawari-8-visible-eqc.tif */, File out >>>>>> /* geotools-web-mercator.png */) { >>>>>> AbstractGridFormat format = GridFormatFinder.findFormat(in); >>>>>> AbstractGridCoverage2DReader reader = format.getReader(in); >>>>>> >>>>>> Layer rasterLayer = new GridReaderLayer(reader, >>>>>> >>>>>> SLD.wrapSymbolizers(CommonFactoryFinder.getStyleFactory().getDefaultRasterSymbolizer())); >>>>>> >>>>>> MapContent mapContent = new MapContent(); >>>>>> mapContent.addLayer(rasterLayer); >>>>>> >>>>>> StreamingRenderer renderer = new StreamingRenderer(); >>>>>> //Map<Object, Object> rendererParams = new HashMap<>(); >>>>>> //rendererParams.put(StreamingRenderer.CONTINUOUS_MAP_WRAPPING, >>>>>> Boolean.TRUE); >>>>>> //renderer.setRendererHints(rendererParams); // had no effect >>>>>> renderer.setMapContent(mapContent); >>>>>> >>>>>> BufferedImage image = new BufferedImage(2048, 2048, >>>>>> BufferedImage.TYPE_INT_RGB); >>>>>> try { >>>>>> renderer.paint(image.createGraphics(), >>>>>> new Rectangle(image.getWidth(), image.getHeight()), >>>>>> new ReferencedEnvelope( >>>>>> -20026376.39, 20026376.39, -20026376.39, >>>>>> 20026376.39, CRS.decode("EPSG:3857"))); >>>>>> >>>>>> ImageIO.write(image, "png", out); >>>>>> } catch (Exception e) { >>>>>> e.printStackTrace(); >>>>>> } >>>>>> } >>>>>> >>>>>> Many thanks in advance for any help. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Andrew >>>>>> >>>>>> _______________________________________________ >>>>>> GeoTools-GT2-Users mailing list >>>>>> GeoTools-GT2-Users@lists.sourceforge.net >>>>>> https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users >>>>> >>>>> >
_______________________________________________ GeoTools-GT2-Users mailing list GeoTools-GT2-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
