Ticket raised (https://osgeo-org.atlassian.net/browse/GEOS-7009) for this
regression, so I can attach screen shots.
--
Jody Garnett
On 30 April 2015 at 08:06, Jody Garnett <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 :)
>>>
>>> I will report back later.
>>> --
>>> Jody Garnett
>>>
>>
>>
>
------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
