[Geoserver-devel] trying geoserver without vecmath

Trying out GeoServer without vecmath (the geotools “matrix” branch). I expect quite a few test cases to change based on difference matrix implementation. I had two tests change in GeoTools:
a) one based on different invert() results, needed to adjust tolerances to recognize result as an Identity matrix after calculation involving matrix. So very subtle differences in inverse() output - not sure which implementation was more accurate.
b) one based on transforming WMS lat/lon bounds to native bounds resulting in slightly different output. The transformation chain was epic so I am not surprised at the slight difference near the poles. It is this difference that has me expecting changes at the GeoServer level.

So far all I have noticed is the pom.xml references OpenPlans still, changing that to OSGeo :slight_smile:

I will report back later.

···


Jody Garnett

Later:

testRasterKeepNative(org.geoserver.wms.wms_1_1_1.GetFeatureInfoTest) Time elapsed: 28 sec <<< FAILURE!
java.lang.AssertionError
at org.junit.Assert.fail(Assert.java:86)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.junit.Assert.assertTrue(Assert.java:52)
at org.geoserver.wms.wms_1_1_1.GetFeatureInfoTest.testRasterKeepNative(GetFeatureInfoTest.java:816

And again:

testRasterKeepNative(org.geoserver.wms.featureinfo.GetFeatureInfoJSONTest) Time elapsed: 41 sec <<< FAILURE!
java.lang.AssertionError
at org.junit.Assert.fail(Assert.java:86)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.junit.Assert.assertTrue(Assert.java:52)
at org.geoserver.wms.wms_1_1_1.GetFeatureInfoTest.testRasterKeepNative(GetFeatureInfoTest.java:816)

···

On 30 April 2015 at 11:50, Jody Garnett <jody.garnett@anonymised.com> wrote:

Trying out GeoServer without vecmath (the geotools “matrix” branch). I expect quite a few test cases to change based on difference matrix implementation. I had two tests change in GeoTools:
a) one based on different invert() results, needed to adjust tolerances to recognize result as an Identity matrix after calculation involving matrix. So very subtle differences in inverse() output - not sure which implementation was more accurate.
b) one based on transforming WMS lat/lon bounds to native bounds resulting in slightly different output. The transformation chain was epic so I am not surprised at the slight difference near the poles. It is this difference that has me expecting changes at the GeoServer level.

So far all I have noticed is the pom.xml references OpenPlans still, changing that to OSGeo :slight_smile:

I will report back later.


Jody Garnett


Jody Garnett

These appear to fail due to “missing” there intended target - result is:

Results for FeatureType ‘http://www.opengis.net/cite:custom’:

···

On 30 April 2015 at 11:58, Jody Garnett <jody.garnett@anonymised.com> wrote:

Later:

testRasterKeepNative(org.geoserver.wms.wms_1_1_1.GetFeatureInfoTest) Time elapsed: 28 sec <<< FAILURE!
java.lang.AssertionError
at org.junit.Assert.fail(Assert.java:86)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.junit.Assert.assertTrue(Assert.java:52)
at org.geoserver.wms.wms_1_1_1.GetFeatureInfoTest.testRasterKeepNative(GetFeatureInfoTest.java:816

And again:

testRasterKeepNative(org.geoserver.wms.featureinfo.GetFeatureInfoJSONTest) Time elapsed: 41 sec <<< FAILURE!
java.lang.AssertionError
at org.junit.Assert.fail(Assert.java:86)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.junit.Assert.assertTrue(Assert.java:52)
at org.geoserver.wms.wms_1_1_1.GetFeatureInfoTest.testRasterKeepNative(GetFeatureInfoTest.java:816)


Jody Garnett


Jody Garnett

On 30 April 2015 at 11:50, Jody Garnett <jody.garnett@anonymised.com> wrote:

Trying out GeoServer without vecmath (the geotools “matrix” branch). I expect quite a few test cases to change based on difference matrix implementation. I had two tests change in GeoTools:
a) one based on different invert() results, needed to adjust tolerances to recognize result as an Identity matrix after calculation involving matrix. So very subtle differences in inverse() output - not sure which implementation was more accurate.
b) one based on transforming WMS lat/lon bounds to native bounds resulting in slightly different output. The transformation chain was epic so I am not surprised at the slight difference near the poles. It is this difference that has me expecting changes at the GeoServer level.

So far all I have noticed is the pom.xml references OpenPlans still, changing that to OSGeo :slight_smile:

I will report back later.


Jody Garnett

Ticket raised (https://osgeo-org.atlassian.net/browse/GEOS-7009) for this regression, so I can attach screen shots.

···

On 30 April 2015 at 08:06, Jody Garnett <jody.garnett@anonymised.com> wrote:

These appear to fail due to “missing” there intended target - result is:

Results for FeatureType ‘http://www.opengis.net/cite:custom’:


PALETTE_INDEX = 2.0


This is odd as the test is trying to keep things in the native projection, which I assume would be less prone to differences due to reprojection.

// force it to “keep native”
CoverageInfo ci = getCatalog().getCoverageByName(getLayerId(CUSTOM));
ci.setProjectionPolicy(ProjectionPolicy.NONE);
getCatalog().save(ci);


Jody Garnett


Jody Garnett

On 30 April 2015 at 11:58, Jody Garnett <jody.garnett@anonymised.com> wrote:

Later:

testRasterKeepNative(org.geoserver.wms.wms_1_1_1.GetFeatureInfoTest) Time elapsed: 28 sec <<< FAILURE!
java.lang.AssertionError
at org.junit.Assert.fail(Assert.java:86)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.junit.Assert.assertTrue(Assert.java:52)
at org.geoserver.wms.wms_1_1_1.GetFeatureInfoTest.testRasterKeepNative(GetFeatureInfoTest.java:816

And again:

testRasterKeepNative(org.geoserver.wms.featureinfo.GetFeatureInfoJSONTest) Time elapsed: 41 sec <<< FAILURE!
java.lang.AssertionError
at org.junit.Assert.fail(Assert.java:86)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.junit.Assert.assertTrue(Assert.java:52)
at org.geoserver.wms.wms_1_1_1.GetFeatureInfoTest.testRasterKeepNative(GetFeatureInfoTest.java:816)


Jody Garnett

On 30 April 2015 at 11:50, Jody Garnett <jody.garnett@anonymised.com> wrote:

Trying out GeoServer without vecmath (the geotools “matrix” branch). I expect quite a few test cases to change based on difference matrix implementation. I had two tests change in GeoTools:
a) one based on different invert() results, needed to adjust tolerances to recognize result as an Identity matrix after calculation involving matrix. So very subtle differences in inverse() output - not sure which implementation was more accurate.
b) one based on transforming WMS lat/lon bounds to native bounds resulting in slightly different output. The transformation chain was epic so I am not surprised at the slight difference near the poles. It is this difference that has me expecting changes at the GeoServer level.

So far all I have noticed is the pom.xml references OpenPlans still, changing that to OSGeo :slight_smile:

I will report back later.


Jody Garnett

Pull request available for the one regression with GetFeatureInfo (https://github.com/geoserver/geoserver/pull/1043).
While I would love feedback on the difference found (especially the visual difference) we are now ready to proceed.

···

On 6 May 2015 at 13:14, Jody Garnett <jody.garnett@anonymised.com> wrote:

Ticket raised (https://osgeo-org.atlassian.net/browse/GEOS-7009) for this regression, so I can attach screen shots.


Jody Garnett


Jody Garnett

On 30 April 2015 at 08:06, Jody Garnett <jody.garnett@anonymised.com> wrote:

These appear to fail due to “missing” there intended target - result is:

Results for FeatureType ‘http://www.opengis.net/cite:custom’:


PALETTE_INDEX = 2.0


This is odd as the test is trying to keep things in the native projection, which I assume would be less prone to differences due to reprojection.

// force it to “keep native”
CoverageInfo ci = getCatalog().getCoverageByName(getLayerId(CUSTOM));
ci.setProjectionPolicy(ProjectionPolicy.NONE);
getCatalog().save(ci);


Jody Garnett

On 30 April 2015 at 11:58, Jody Garnett <jody.garnett@anonymised.com> wrote:

Later:

testRasterKeepNative(org.geoserver.wms.wms_1_1_1.GetFeatureInfoTest) Time elapsed: 28 sec <<< FAILURE!
java.lang.AssertionError
at org.junit.Assert.fail(Assert.java:86)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.junit.Assert.assertTrue(Assert.java:52)
at org.geoserver.wms.wms_1_1_1.GetFeatureInfoTest.testRasterKeepNative(GetFeatureInfoTest.java:816

And again:

testRasterKeepNative(org.geoserver.wms.featureinfo.GetFeatureInfoJSONTest) Time elapsed: 41 sec <<< FAILURE!
java.lang.AssertionError
at org.junit.Assert.fail(Assert.java:86)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.junit.Assert.assertTrue(Assert.java:52)
at org.geoserver.wms.wms_1_1_1.GetFeatureInfoTest.testRasterKeepNative(GetFeatureInfoTest.java:816)


Jody Garnett

On 30 April 2015 at 11:50, Jody Garnett <jody.garnett@anonymised.com> wrote:

Trying out GeoServer without vecmath (the geotools “matrix” branch). I expect quite a few test cases to change based on difference matrix implementation. I had two tests change in GeoTools:
a) one based on different invert() results, needed to adjust tolerances to recognize result as an Identity matrix after calculation involving matrix. So very subtle differences in inverse() output - not sure which implementation was more accurate.
b) one based on transforming WMS lat/lon bounds to native bounds resulting in slightly different output. The transformation chain was epic so I am not surprised at the slight difference near the poles. It is this difference that has me expecting changes at the GeoServer level.

So far all I have noticed is the pom.xml references OpenPlans still, changing that to OSGeo :slight_smile:

I will report back later.


Jody Garnett