date:20200408

Re: [Geotools-gt2-users] Gaps in rendered raster data

2020-04-08 Thread Andrew Miskelly

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 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.(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 
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  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
>> 
>> (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:

Re: [Geotools-gt2-users] Gaps in rendered raster data

2020-04-08 Thread Andrew Miskelly

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  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
> 
> (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 
> 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  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,

Re: [Geotools-gt2-users] Coordinate Transformation

2020-04-08 Thread Ian Turton

OK WIndows updates still running so more digging:

Using this code:

CoordinateOperationFactory operationFactory =
ReferencingFactoryFinder.getCoordinateOperationFactory(null);
Set ops =
operationFactory.findOperations(sourceCRS, targetCRS);

for (CoordinateOperation o : ops) {
  System.out.println(o);
}

I get the following - the last one is your file (I added an
epsg_operations.properties file to
src/main/resources/org/geotools/referencing/factory/gridshift) - what I'm
not clear on is how to force a pick of that one.
ConcatenatedOperation["ProjectedCRS[DHDN / 3-degree Gauss-Kruger zone 3] ⇨
ProjectedCRS[ETRS89 / UTM zone 32N (zE-N)]",
  SOURCE["DHDN / 3-degree Gauss-Kruger zone 3", AUTHORITY["EPSG","31467"]],
  TARGET["ETRS89 / UTM zone 32N (zE-N)", AUTHORITY["EPSG","4647"]],
  CylindricalProjection["ProjectedCRS[DHDN / 3-degree Gauss-Kruger zone 3]
⇨ GeographicCRS[DHDN]",
SOURCE["DHDN / 3-degree Gauss-Kruger zone 3",
AUTHORITY["EPSG","31467"]],
TARGET["DHDN", AUTHORITY["EPSG","4314"]],
METHOD["Transverse_Mercator", AUTHORITY["EPSG","9807"]]],
  Transformation["DHDN to ETRS89 (5)",
SOURCE["DHDN", AUTHORITY["EPSG","4314"]],
TARGET["ETRS89", AUTHORITY["EPSG","4258"]],
METHOD["Position Vector transformation (geog2D domain)",
AUTHORITY["EPSG","9606"]],
AUTHORITY["EPSG","1780"]],
  CylindricalProjection["UTM zone 32N with prefix",
SOURCE["ETRS89", AUTHORITY["EPSG","4258"]],
TARGET["ETRS89 / UTM zone 32N (zE-N)", AUTHORITY["EPSG","4647"]],
METHOD["Transverse_Mercator", AUTHORITY["EPSG","9807"]],
AUTHORITY["EPSG","4648"]]]
ConcatenatedOperation["ProjectedCRS[DHDN / 3-degree Gauss-Kruger zone 3] ⇨
ProjectedCRS[ETRS89 / UTM zone 32N (zE-N)]",
  SOURCE["DHDN / 3-degree Gauss-Kruger zone 3", AUTHORITY["EPSG","31467"]],
  TARGET["ETRS89 / UTM zone 32N (zE-N)", AUTHORITY["EPSG","4647"]],
  CylindricalProjection["ProjectedCRS[DHDN / 3-degree Gauss-Kruger zone 3]
⇨ GeographicCRS[DHDN]",
SOURCE["DHDN / 3-degree Gauss-Kruger zone 3",
AUTHORITY["EPSG","31467"]],
TARGET["DHDN", AUTHORITY["EPSG","4314"]],
METHOD["Transverse_Mercator", AUTHORITY["EPSG","9807"]]],
  Transformation["DHDN to ETRS89 (4)",
SOURCE["DHDN", AUTHORITY["EPSG","4314"]],
TARGET["ETRS89", AUTHORITY["EPSG","4258"]],
METHOD["Position Vector transformation (geog2D domain)",
AUTHORITY["EPSG","9606"]],
AUTHORITY["EPSG","1779"]],
  CylindricalProjection["UTM zone 32N with prefix",
SOURCE["ETRS89", AUTHORITY["EPSG","4258"]],
TARGET["ETRS89 / UTM zone 32N (zE-N)", AUTHORITY["EPSG","4647"]],
METHOD["Transverse_Mercator", AUTHORITY["EPSG","9807"]],
AUTHORITY["EPSG","4648"]]]
ConcatenatedOperation["ProjectedCRS[DHDN / 3-degree Gauss-Kruger zone 3] ⇨
ProjectedCRS[ETRS89 / UTM zone 32N (zE-N)]",
  SOURCE["DHDN / 3-degree Gauss-Kruger zone 3", AUTHORITY["EPSG","31467"]],
  TARGET["ETRS89 / UTM zone 32N (zE-N)", AUTHORITY["EPSG","4647"]],
  CylindricalProjection["ProjectedCRS[DHDN / 3-degree Gauss-Kruger zone 3]
⇨ GeographicCRS[DHDN]",
SOURCE["DHDN / 3-degree Gauss-Kruger zone 3",
AUTHORITY["EPSG","31467"]],
TARGET["DHDN", AUTHORITY["EPSG","4314"]],
METHOD["Transverse_Mercator", AUTHORITY["EPSG","9807"]]],
  Transformation["DHDN to ETRS89 (2)",
SOURCE["DHDN", AUTHORITY["EPSG","4314"]],
TARGET["ETRS89", AUTHORITY["EPSG","4258"]],
METHOD["Position Vector transformation (geog2D domain)",
AUTHORITY["EPSG","9606"]],
AUTHORITY["EPSG","1776"]],
  CylindricalProjection["UTM zone 32N with prefix",
SOURCE["ETRS89", AUTHORITY["EPSG","4258"]],
TARGET["ETRS89 / UTM zone 32N (zE-N)", AUTHORITY["EPSG","4647"]],
METHOD["Transverse_Mercator", AUTHORITY["EPSG","9807"]],
AUTHORITY["EPSG","4648"]]]
ConcatenatedOperation["ProjectedCRS[DHDN / 3-degree Gauss-Kruger zone 3] ⇨
ProjectedCRS[ETRS89 / UTM zone 32N (zE-N)]",
  SOURCE["DHDN / 3-degree Gauss-Kruger zone 3", AUTHORITY["EPSG","31467"]],
  TARGET["ETRS89 / UTM zone 32N (zE-N)", AUTHORITY["EPSG","4647"]],
  CylindricalProjection["ProjectedCRS[DHDN / 3-degree Gauss-Kruger zone 3]
⇨ GeographicCRS[DHDN]",
SOURCE["DHDN / 3-degree Gauss-Kruger zone 3",
AUTHORITY["EPSG","31467"]],
TARGET["DHDN", AUTHORITY["EPSG","4314"]],
METHOD["Transverse_Mercator", AUTHORITY["EPSG","9807"]]],
  Transformation["DHDN to ETRS89 (3)",
SOURCE["DHDN", AUTHORITY["EPSG","4314"]],
TARGET["ETRS89", AUTHORITY["EPSG","4258"]],
METHOD["Position Vector transformation (geog2D domain)",
AUTHORITY["EPSG","9606"]],
AUTHORITY["EPSG","1778"]],
  CylindricalProjection["UTM zone 32N with prefix",
SOURCE["ETRS89", AUTHORITY["EPSG","4258"]],
TARGET["ETRS89 / UTM zone 32N (zE-N)", AUTHORITY["EPSG","4647"]],
METHOD["Transverse_Mercator", AUTHORITY["EPSG","9807"]],
AUTHORITY["EPSG","4648"]]]
ConcatenatedOperation["ProjectedCRS[DHDN / 3-degree Gauss-Kruger zone 3] ⇨
ProjectedCRS[ETRS89 / UTM zone 32N (zE-N)]",
  SOURCE["DHDN / 3-degree Gauss-Kruger zone 3", AUTHORITY["EPSG","31467"]],

Re: [Geotools-gt2-users] Coordinate Transformation

2020-04-08 Thread Ian Turton

On Wed, 8 Apr 2020 at 13:57, Benjamin Sokolowski <
benjamin.sokolow...@data-experts.de> wrote:

> >> Are you sure this transform is in the EPSG tables?
> Probably not. The grid was calculated specifically for the state of
> Schleswig Holstein in Germany. In my head it is like this: I register a
> user-defined transformation in geotools of 31467 to 4647. This is always
> done taking into account the grid I provide (the specific gsb file). Am I
> wrong?
>

Where are you registering that?

Ian
___
GeoTools-GT2-Users mailing list
GeoTools-GT2-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users

Re: [Geotools-gt2-users] Coordinate Transformation

2020-04-08 Thread Ian Turton

A bit more digging

NTv2GridShiftFactory fac = new NTv2GridShiftFactory();
URL url = fac.getClass().getResource("shtransntv2.gsb");
System.out.println(fac.isNTv2Grid(url));
GridShiftFile grid = fac.createNTv2Grid(url);
System.out.println(grid);

gives

Headers  : 11
Sub Hdrs : 11
Sub Grids: 1
Type : SECONDS
Version  : NTv2.0
Fr Ellpsd: DHDN90
To Ellpsd: ETRS89
Fr Maj Ax: 6377397.155
Fr Min Ax: 6356078.963
To Maj Ax: 6378137.0
To Min Ax: 6356752.314

so it looks like that transform will only be used between DHDN geoids (
http://epsg.io/4314-15949) and ETRS89 - so it might work with DHDN /
3-degree Gauss-Kruger zone 3 (E-N) (http://epsg.io/5677)

Ian

On Wed, 8 Apr 2020 at 13:32, Ian Turton  wrote:

> On further investigation at epgs.io I can get a gsb transform for
> epsg:31467->epsg:4326 (WGS84) using BETA2007.gsb but not the epsg:4258
> (ETRS) which is the base for EPSG:4647 (ETRS89 / UTM zone 32N (zE-N)).
>
> I can't find any reference to the need for a grid file for this transform
> so that may be why it isn't picked up by the code? Are you sure this
> transform is in the EPSG tables?
>
> Ian
>
> On Wed, 8 Apr 2020 at 05:55, Benjamin Sokolowski <
> benjamin.sokolow...@data-experts.de> wrote:
>
>> With and without gsb file the same output:
>>
>> CONCAT_MT[INVERSE_MT[PARAM_MT["Transverse_Mercator",
>>   PARAMETER["semi_major", 6377397.155],
>>   PARAMETER["semi_minor", 6356078.962818189],
>>   PARAMETER["central_meridian", 9.0],
>>   PARAMETER["latitude_of_origin", 0.0],
>>   PARAMETER["scale_factor", 1.0],
>>   PARAMETER["false_easting", 350.0],
>>   PARAMETER["false_northing", 0.0]]],
>>   PARAM_MT["Ellipsoid_To_Geocentric",
>> PARAMETER["dim", 2],
>> PARAMETER["semi_major", 6377397.155],
>> PARAMETER["semi_minor", 6356078.962818189]],
>>   PARAM_MT["Affine",
>> PARAMETER["num_row", 4],
>> PARAMETER["num_col", 4],
>> PARAMETER["elt_0_0", 1.0255],
>> PARAMETER["elt_0_1", 0.1356027323924231],
>> PARAMETER["elt_0_2", 0.0027634450290912],
>> PARAMETER["elt_0_3", 612.4],
>> PARAMETER["elt_1_0", -0.1356027323924231],
>> PARAMETER["elt_1_1", 1.0255],
>> PARAMETER["elt_1_2", 0.0026180005538759],
>> PARAMETER["elt_1_3", 77.0],
>> PARAMETER["elt_2_0", -0.0027634450290912],
>> PARAMETER["elt_2_1", -0.0026180005538759],
>> PARAMETER["elt_2_2", 1.0255],
>> PARAMETER["elt_2_3", 440.2]],
>>   PARAM_MT["Geocentric_To_Ellipsoid",
>> PARAMETER["dim", 2],
>> PARAMETER["semi_major", 6378137.0],
>> PARAMETER["semi_minor", 6356752.314140356]],
>>   PARAM_MT["Transverse_Mercator",
>> PARAMETER["semi_major", 6378137.0],
>> PARAMETER["semi_minor", 6356752.314140356],
>> PARAMETER["central_meridian", 9.0],
>> PARAMETER["latitude_of_origin", 0.0],
>> PARAMETER["scale_factor", 0.9996],
>> PARAMETER["false_easting", 3250.0],
>> PARAMETER["false_northing", 0.0]]]
>>
>> which i think, is the default transformation of geotools. Here's the gsb
>> file
>>
>>
>> Benjamin
>>
>>
>>
>> Von:"Ian Turton" 
>> An:"Benjamin Sokolowski" 
>> Kopie:"geotools-users" 
>> Datum:07.04.2020 15:53
>> Betreff:Re: Re: Re: [Geotools-gt2-users] Coordinate
>> Transformation
>> --
>>
>>
>>
>> Can you try this program with and without the GSB file
>>
>> import org.geotools.referencing.CRS;
>> import org.opengis.referencing.FactoryException;
>> import org.opengis.referencing.NoSuchAuthorityCodeException;
>> import org.opengis.referencing.crs.CoordinateReferenceSystem;
>> import org.opengis.referencing.operation.MathTransform;
>>
>> public class gridShiftTest {
>>
>>   public static void main(String[] args) throws
>> NoSuchAuthorityCodeException, FactoryException {
>>
>> CoordinateReferenceSystem sourceCRS = CRS.decode( "EPSG:31467" );
>> CoordinateReferenceSystem targetCRS = CRS.decode( "EPSG:4647" );
>> MathTransform transform = CRS.findMathTransform(sourceCRS, targetCRS);
>>
>> System.out.println(transform);
>>   }
>>
>> }
>>
>> Or mail me the gsb file if you can and I'll try - I don't seem to have a
>> grid file for this transformation on my system because I've mainly used UK
>> and USA ones in the past.
>>
>> Ian
>>
>> On Tue, 7 Apr 2020 at 13:21, Benjamin Sokolowski <
>> *benjamin.sokolow...@data-experts.de*
>> > wrote:
>> Hi Ian,
>>
>> even with the .gsb in the new folder with your given name, no changes at
>> all. Same wrong results. Do you have another idea what i'm missing? The
>> "epsg_operations.properties" is not mandatory right? I don't have that
>> right now.
>>
>> Benjamin
>>
>>
>>
>> Von:"Ian Turton" <*ijtur...@gmail.com* >
>> An:"Benjamin Sokolowski" <*benjamin.sokolow...@data-experts.de*
>> >
>> Kopie:"geotools-users" <
>> *geotools-gt2-users@lists.sourceforge.net*
>> >
>> Datum:07.04.2020 11:33
>> Betreff:Re: Re:

[Geotools-gt2-users] Antwort: Re: Re: Re: Re: Coordinate Transformation

2020-04-08 Thread Benjamin Sokolowski

>> Are you sure this transform is in the EPSG tables? 
Probably not. The grid was calculated specifically for the state of 
Schleswig Holstein in Germany. In my head it is like this: I register a 
user-defined transformation in geotools of 31467 to 4647. This is always 
done taking into account the grid I provide (the specific gsb file). Am I 
wrong?

Benjamin



Von:"Ian Turton" 
An: "Benjamin Sokolowski" 
Kopie:  "geotools-users" 
Datum:  08.04.2020 14:33
Betreff:Re: Re: Re: Re: [Geotools-gt2-users] Coordinate 
Transformation



On further investigation at epgs.io I can get a gsb transform for 
epsg:31467->epsg:4326 (WGS84) using BETA2007.gsb but not the epsg:4258 
(ETRS) which is the base for EPSG:4647 (ETRS89 / UTM zone 32N (zE-N)). 

I can't find any reference to the need for a grid file for this transform 
so that may be why it isn't picked up by the code? Are you sure this 
transform is in the EPSG tables? 

Ian

On Wed, 8 Apr 2020 at 05:55, Benjamin Sokolowski <
benjamin.sokolow...@data-experts.de> wrote:
With and without gsb file the same output: 

CONCAT_MT[INVERSE_MT[PARAM_MT["Transverse_Mercator", 
  PARAMETER["semi_major", 6377397.155], 
  PARAMETER["semi_minor", 6356078.962818189], 
  PARAMETER["central_meridian", 9.0], 
  PARAMETER["latitude_of_origin", 0.0], 
  PARAMETER["scale_factor", 1.0], 
  PARAMETER["false_easting", 350.0], 
  PARAMETER["false_northing", 0.0]]], 
  PARAM_MT["Ellipsoid_To_Geocentric", 
PARAMETER["dim", 2], 
PARAMETER["semi_major", 6377397.155], 
PARAMETER["semi_minor", 6356078.962818189]], 
  PARAM_MT["Affine", 
PARAMETER["num_row", 4], 
PARAMETER["num_col", 4], 
PARAMETER["elt_0_0", 1.0255], 
PARAMETER["elt_0_1", 0.1356027323924231], 
PARAMETER["elt_0_2", 0.0027634450290912], 
PARAMETER["elt_0_3", 612.4], 
PARAMETER["elt_1_0", -0.1356027323924231], 
PARAMETER["elt_1_1", 1.0255], 
PARAMETER["elt_1_2", 0.0026180005538759], 
PARAMETER["elt_1_3", 77.0], 
PARAMETER["elt_2_0", -0.0027634450290912], 
PARAMETER["elt_2_1", -0.0026180005538759], 
PARAMETER["elt_2_2", 1.0255], 
PARAMETER["elt_2_3", 440.2]], 
  PARAM_MT["Geocentric_To_Ellipsoid", 
PARAMETER["dim", 2], 
PARAMETER["semi_major", 6378137.0], 
PARAMETER["semi_minor", 6356752.314140356]], 
  PARAM_MT["Transverse_Mercator", 
PARAMETER["semi_major", 6378137.0], 
PARAMETER["semi_minor", 6356752.314140356], 
PARAMETER["central_meridian", 9.0], 
PARAMETER["latitude_of_origin", 0.0], 
PARAMETER["scale_factor", 0.9996], 
PARAMETER["false_easting", 3250.0], 
PARAMETER["false_northing", 0.0]]] 

which i think, is the default transformation of geotools. Here's the gsb 
file 


Benjamin 



Von:"Ian Turton"  
An:"Benjamin Sokolowski"  
Kopie:"geotools-users"  
Datum:07.04.2020 15:53 
Betreff:Re: Re: Re: [Geotools-gt2-users] Coordinate Transformation 




Can you try this program with and without the GSB file  

import org.geotools.referencing.CRS;
import org.opengis.referencing.FactoryException;
import org.opengis.referencing.NoSuchAuthorityCodeException;
import org.opengis.referencing.crs.CoordinateReferenceSystem;
import org.opengis.referencing.operation.MathTransform;

public class gridShiftTest {

  public static void main(String[] args) throws 
NoSuchAuthorityCodeException, FactoryException {

CoordinateReferenceSystem sourceCRS = CRS.decode( "EPSG:31467" );
CoordinateReferenceSystem targetCRS = CRS.decode( "EPSG:4647" );
MathTransform transform = CRS.findMathTransform(sourceCRS, targetCRS);

System.out.println(transform);
  }

} 

Or mail me the gsb file if you can and I'll try - I don't seem to have a 
grid file for this transformation on my system because I've mainly used UK 
and USA ones in the past. 

Ian 

On Tue, 7 Apr 2020 at 13:21, Benjamin Sokolowski <
benjamin.sokolow...@data-experts.de> wrote: 
Hi Ian, 

even with the .gsb in the new folder with your given name, no changes at 
all. Same wrong results. Do you have another idea what i'm missing? The 
"epsg_operations.properties" is not mandatory right? I don't have that 
right now. 

Benjamin 



Von:"Ian Turton"  
An:"Benjamin Sokolowski"  
Kopie:"geotools-users"  
Datum:07.04.2020 11:33 
Betreff:Re: Re: [Geotools-gt2-users] Coordinate Transformation 



I've never tried adding a gsb file directly to the jar file, I usually 
create the folder 
src/main/resources/org/geotools/referencing/factory/gridshift in my 
project and store the file in there.  

Ian 

On Tue, 7 Apr 2020 at 10:14, Benjamin Sokolowski <
benjamin.sokolow...@data-experts.de> wrote: 
Hi Ian, 

thanks for the reply. Found the discussion at stackexchange already, but 
it didn't help me. Maybe i didn't understand it correctly. 
>> where exactly did you put it? 
Do you mean in which jar-File?

Re: [Geotools-gt2-users] Coordinate Transformation

2020-04-08 Thread Ian Turton

On further investigation at epgs.io I can get a gsb transform for
epsg:31467->epsg:4326 (WGS84) using BETA2007.gsb but not the epsg:4258
(ETRS) which is the base for EPSG:4647 (ETRS89 / UTM zone 32N (zE-N)).

I can't find any reference to the need for a grid file for this transform
so that may be why it isn't picked up by the code? Are you sure this
transform is in the EPSG tables?

Ian

On Wed, 8 Apr 2020 at 05:55, Benjamin Sokolowski <
benjamin.sokolow...@data-experts.de> wrote:

> With and without gsb file the same output:
>
> CONCAT_MT[INVERSE_MT[PARAM_MT["Transverse_Mercator",
>   PARAMETER["semi_major", 6377397.155],
>   PARAMETER["semi_minor", 6356078.962818189],
>   PARAMETER["central_meridian", 9.0],
>   PARAMETER["latitude_of_origin", 0.0],
>   PARAMETER["scale_factor", 1.0],
>   PARAMETER["false_easting", 350.0],
>   PARAMETER["false_northing", 0.0]]],
>   PARAM_MT["Ellipsoid_To_Geocentric",
> PARAMETER["dim", 2],
> PARAMETER["semi_major", 6377397.155],
> PARAMETER["semi_minor", 6356078.962818189]],
>   PARAM_MT["Affine",
> PARAMETER["num_row", 4],
> PARAMETER["num_col", 4],
> PARAMETER["elt_0_0", 1.0255],
> PARAMETER["elt_0_1", 0.1356027323924231],
> PARAMETER["elt_0_2", 0.0027634450290912],
> PARAMETER["elt_0_3", 612.4],
> PARAMETER["elt_1_0", -0.1356027323924231],
> PARAMETER["elt_1_1", 1.0255],
> PARAMETER["elt_1_2", 0.0026180005538759],
> PARAMETER["elt_1_3", 77.0],
> PARAMETER["elt_2_0", -0.0027634450290912],
> PARAMETER["elt_2_1", -0.0026180005538759],
> PARAMETER["elt_2_2", 1.0255],
> PARAMETER["elt_2_3", 440.2]],
>   PARAM_MT["Geocentric_To_Ellipsoid",
> PARAMETER["dim", 2],
> PARAMETER["semi_major", 6378137.0],
> PARAMETER["semi_minor", 6356752.314140356]],
>   PARAM_MT["Transverse_Mercator",
> PARAMETER["semi_major", 6378137.0],
> PARAMETER["semi_minor", 6356752.314140356],
> PARAMETER["central_meridian", 9.0],
> PARAMETER["latitude_of_origin", 0.0],
> PARAMETER["scale_factor", 0.9996],
> PARAMETER["false_easting", 3250.0],
> PARAMETER["false_northing", 0.0]]]
>
> which i think, is the default transformation of geotools. Here's the gsb
> file
>
>
> Benjamin
>
>
>
> Von:"Ian Turton" 
> An:"Benjamin Sokolowski" 
> Kopie:"geotools-users" 
> Datum:07.04.2020 15:53
> Betreff:Re: Re: Re: [Geotools-gt2-users] Coordinate Transformation
> --
>
>
>
> Can you try this program with and without the GSB file
>
> import org.geotools.referencing.CRS;
> import org.opengis.referencing.FactoryException;
> import org.opengis.referencing.NoSuchAuthorityCodeException;
> import org.opengis.referencing.crs.CoordinateReferenceSystem;
> import org.opengis.referencing.operation.MathTransform;
>
> public class gridShiftTest {
>
>   public static void main(String[] args) throws
> NoSuchAuthorityCodeException, FactoryException {
>
> CoordinateReferenceSystem sourceCRS = CRS.decode( "EPSG:31467" );
> CoordinateReferenceSystem targetCRS = CRS.decode( "EPSG:4647" );
> MathTransform transform = CRS.findMathTransform(sourceCRS, targetCRS);
>
> System.out.println(transform);
>   }
>
> }
>
> Or mail me the gsb file if you can and I'll try - I don't seem to have a
> grid file for this transformation on my system because I've mainly used UK
> and USA ones in the past.
>
> Ian
>
> On Tue, 7 Apr 2020 at 13:21, Benjamin Sokolowski <
> *benjamin.sokolow...@data-experts.de*
> > wrote:
> Hi Ian,
>
> even with the .gsb in the new folder with your given name, no changes at
> all. Same wrong results. Do you have another idea what i'm missing? The
> "epsg_operations.properties" is not mandatory right? I don't have that
> right now.
>
> Benjamin
>
>
>
> Von:"Ian Turton" <*ijtur...@gmail.com* >
> An:"Benjamin Sokolowski" <*benjamin.sokolow...@data-experts.de*
> >
> Kopie:"geotools-users" <*geotools-gt2-users@lists.sourceforge.net*
> >
> Datum:07.04.2020 11:33
> Betreff:Re: Re: [Geotools-gt2-users] Coordinate Transformation
> --
>
>
>
> I've never tried adding a gsb file directly to the jar file, I usually
> create the folder 
> src/main/resources/org/geotools/referencing/factory/gridshift
> in my project and store the file in there.
>
> Ian
>
> On Tue, 7 Apr 2020 at 10:14, Benjamin Sokolowski <
> *benjamin.sokolow...@data-experts.de*
> > wrote:
> Hi Ian,
>
> thanks for the reply. Found the discussion at stackexchange already, but
> it didn't help me. Maybe i didn't understand it correctly.
> >> *where exactly did you put it?*
> Do you mean in which jar-File?   gt-referencing-16.0.jar
> I only have geotools in the build path, not the sources.
>
> Benjamin
>
>
>
> Von:"Ian Turton" <*ijtur...@gmail.com* >
> An:"Benjamin Sokolowski" <*benjamin.sokolow...@data-experts.de*
> >
> Kopie:

Re: [Geotools-gt2-users] Gaps in rendered raster data

Re: [Geotools-gt2-users] Gaps in rendered raster data

Re: [Geotools-gt2-users] Coordinate Transformation

Re: [Geotools-gt2-users] Coordinate Transformation

Re: [Geotools-gt2-users] Coordinate Transformation

[Geotools-gt2-users] Antwort: Re: Re: Re: Re: Coordinate Transformation

Re: [Geotools-gt2-users] Coordinate Transformation

7 matches

Site Navigation

Mail list logo

Footer information