The bug report is at https://osgeo-org.atlassian.net/browse/GEOT-6547.
Andrew On Tue, 14 Apr 2020 at 03:34, Jody Garnett <jody.garn...@gmail.com> wrote: > 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
