Modify

#20346 closed defect (fixed)

[PATCH] Fix the definition of EPSG:3346

Reported by: nagisa Owned by: Don-vip
Priority: normal Milestone: 21.02
Component: Core Version: latest
Keywords: projection lithuania Cc:

Description

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.

Attachments (2)

fix-3346.diff (6.9 KB) - added by nagisa 17 months ago.
The patch
fix-projection-refrence-data.patch (2.3 KB) - added by nagisa 15 months ago.
Adjust for reference projection data file for changes in @17549

Download all attachments as: .zip

Change History (19)

Changed 17 months ago by nagisa

Attachment: fix-3346.diff added

The patch

comment:1 Changed 16 months ago by Don-vip

Keywords: projection lithuania added
Milestone: 21.01

comment:2 Changed 16 months ago by Don-vip

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

comment:3 Changed 16 months ago by Don-vip

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

comment:4 Changed 16 months ago by 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.

comment:5 Changed 15 months ago by stoecker

Milestone: 21.0121.02

Milestone renamed

comment:6 in reply to:  4 Changed 15 months ago by 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?

comment:7 Changed 15 months ago by Don-vip

Owner: changed from team to nagisa
Status: newneedinfo

comment:8 Changed 15 months ago by 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?

comment:9 Changed 15 months ago by 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);
    }

comment:10 Changed 15 months ago by Don-vip

Owner: changed from nagisa to Don-vip
Status: needinfoassigned

comment:11 Changed 15 months ago by Don-vip

Resolution: fixed
Status: assignedclosed

In 17549/josm:

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

comment:12 Changed 15 months ago by 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)

comment:13 Changed 15 months ago by nagisa

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

comment:14 Changed 15 months ago by Don-vip

Resolution: fixed
Status: closedreopened

Changed 15 months ago by nagisa

Adjust for reference projection data file for changes in @17549

comment:15 Changed 15 months ago by 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.

Last edited 15 months ago by nagisa (previous) (diff)

comment:16 in reply to:  15 Changed 15 months ago by 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.

comment:17 Changed 15 months ago by Don-vip

Resolution: fixed
Status: reopenedclosed

In 17550/josm:

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

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain Don-vip.
as The resolution will be set.
The resolution will be deleted.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.