[PATCH] Fix the definition of EPSG:3346

[nagisa]

Notably the default definition of the EPSG:3346 projection specified the wrong axes (none, using the default enu, while the correct one is neu) and was missing the bounds.

The added override specifies the bounds and the axes. I also included the test I added as part of https://josm.openstreetmap.de/ticket/20343 which indirectly confirms the fix for tile maps using this projection.

[nagisa]

The patch

[Don-vip]

We should begin by update the EPSG database, I did not update it since r13395

[Don-vip]

Ah, we can't update anymore, see #20160

[nagisa]

Is there anything blocking landing of this, while updates of EPSG database are being figured out? Most of the imagery in Lithuania is EPSG:3346 and, with this patch, contribution could become significantly easier in Lithuania.

[stoecker]

Milestone renamed

[Don-vip]

Replying to nagisa:

Is there anything blocking landing of this, while updates of EPSG database are being figured out?

It's going to take some time so I'm going to put the update aside.
The real problem is that the unit test does not work, maybe due to recent changes in JOSM?

java.lang.AssertionError: expected:<27> but was:<-47>
	at org.junit.Assert.fail(Assert.java:89)
	at org.junit.Assert.failNotEquals(Assert.java:835)
	at org.junit.Assert.assertEquals(Assert.java:647)
	at org.junit.Assert.assertEquals(Assert.java:633)
	at org.openstreetmap.josm.data.imagery.WMTSTileSourceTest.testProjectionWithENUAxis(WMTSTileSourceTest.java:260)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
	at com.github.tomakehurst.wiremock.junit.WireMockRule$1.evaluate(WireMockRule.java:79)
	at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
	at org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
	at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
	at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
	at org.openstreetmap.josm.testutils.JOSMTestRules$TimeoutThread.run(JOSMTestRules.java:781)

Can you please take a look?

[nagisa]

Hi Don-vip,

I ran the following commands:

svn co https://josm.openstreetmap.de/svn/trunk josm
cd josm
curl 'https://josm.openstreetmap.de/raw-attachment/ticket/20346/fix-3346.diff' | patch -p0
ant test '-Ddefault-junit-includes=**/WMTSTileSourceTest.class'

And was not able to reproduce the failure. In particular ant command reports all the tests succeeding:

...
[junitlauncher] Test run finished after 2519 ms
[junitlauncher] [         3 containers found      ]
[junitlauncher] [         0 containers skipped    ]
[junitlauncher] [         3 containers started    ]
[junitlauncher] [         0 containers aborted    ]
[junitlauncher] [         3 containers successful ]
[junitlauncher] [         0 containers failed     ]
[junitlauncher] [        18 tests found           ]
[junitlauncher] [         1 tests skipped         ]
[junitlauncher] [        17 tests started         ]
[junitlauncher] [         0 tests aborted         ]
[junitlauncher] [        17 tests successful      ]
[junitlauncher] [         0 tests failed          ]
[junitlauncher]
     [echo] Running functional tests with JUnit

BUILD SUCCESSFUL
Total time: 53 seconds

---

I remember seeing a similar issue in the past when I did not regenerate the epsg database (with ant epsg-compile) before running tests in Eclipse, so maybe that's why the problem arises?

[Don-vip]

Thanks. It's a double -> int casting issue that must depend on Java version. Just compare double values and it works:

    @Test
    public void testProjectionWithENUAxis() throws IOException, WMTSGetCapabilitiesException {
        ProjectionRegistry.setProjection(Projections.getProjectionByCode("EPSG:3346"));
        WMTSTileSource testSource = new WMTSTileSource(testImageryORT2LT);
        testSource.initProjection(ProjectionRegistry.getProjection());
        TileXY tileXY0 = testSource.latLonToTileXY(55.31083718860799, 22.172052608196587, 0);
        double delta = 1e-10;
        assertEquals(27.09619727782481, tileXY0.getX(), delta);
        assertEquals(19.03524443532604, tileXY0.getY(), delta);
        TileXY tileXY2 = testSource.latLonToTileXY(55.31083718860799, 22.172052608196587, 2);
        assertEquals(81.28859183347444, tileXY2.getX(), delta);
        assertEquals(57.10573330597811, tileXY2.getY(), delta);
    }

[Don-vip]

In 17549/josm:

fix #20346 - fix definition of EPSG:3346 for Lithuania (patch by nagisa)

[Stereo]

The tests are failing now:

Testcase: org.openstreetmap.josm.data.projection.ProjectionRefTest
Test: testProjections() took 34 sec(s) FAILED: Failing:
0 projections: []
0 definitions: {}
java.lang.AssertionError: Failing:
0 projections: []
0 definitions: {}
	at org.openstreetmap.josm.data.projection.ProjectionRefTest.testProjections(ProjectionRefTest.java:421)

[nagisa]

I can reproduce this one. Will take a look later today.

[nagisa]

Adjust for reference projection data file for changes in @17549

[nagisa]

I have attached an additional patch that should fix the failing test. My understanding that this file is effectively just test data. It does look auto-generated to me, but I didn't see any obvious ways to re-generate the file, so I went ahead and fixed the file up by hand and verified that with the attached patch the failing test now passes.

As somebody not super familiar with java in general, I have found it fairly confusing that ant could print out a "BUILD SUCCESSFUL" despite there being test failures somewhere in there.

[Don-vip]

Replying to nagisa:

I have attached an additional patch that should fix the failing test.

Thanks!

My understanding that this file is effectively just test data. It does look auto-generated to me, but I didn't see any obvious ways to re-generate the file, so I went ahead and fixed the file up by hand and verified that with the attached patch the failing test now passes.

This is clearly not the easier part of JOSM. I'll work on it next month as we need to adapt to proj4 major changes.

As somebody not super familiar with java in general, I have found it fairly confusing that ant could print out a "BUILD SUCCESSFUL" despite there being test failures somewhere in there.

This is specific to ant. It only fails when you say it to do so. Hopefully when we switch to gitlab it will be as simple as to open a pull request and we'll take care of everything. Thank you for the patches you provide meanwhile.

[Don-vip]

In 17550/josm:

fix #20346 - Adjust reference projection data file for changes in r17549 (patch by nagisa)