GeoTools

Rendering Transforms are applied to all FeatureTypeStyles

Details

  • Type: Bug Bug
  • Status: Resolved Resolved
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 8.0-M4
  • Fix Version/s: None
  • Component/s: main
  • Labels:
    None
  • Environment:
    OS X, Java 6

Description

I have an SLD (see line_rendering_transform.sld)
that contains two FeatureTypeStyles. The first FTS contains a
<sld:Transformation/> that uses the gs:BufferFeatureCollection process. The
second FTS just contains a LineSymbolizer. When I render this SLD with the
lines from the SLD Cook Book, I get the following image: rendering_transform_line1.png.

It appears that the LineSymbolizer from the second FTS is being applied to
the polygons created by the buffer process. I assumed that they would apply
to the original lines.

When I flip the order of the FTS (line above buffer) I get a wierder result: rendering_transform_line2.png

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Jared Erickson added a comment -
A small maven project that illustrates the bug.
Show
Jared Erickson added a comment - A small maven project that illustrates the bug.
Hide
Permalink
Jared Erickson added a comment -
Patch that fixes the bug.
Show
Jared Erickson added a comment - Patch that fixes the bug.
Hide
Permalink
Andrea Aime added a comment -
Yep, seems like a good fix. We need to factory out the block that classifies by tx in its own method to avoid confusion with variables and add a test before commit can be done
Show
Andrea Aime added a comment - Yep, seems like a good fix. We need to factory out the block that classifies by tx in its own method to avoid confusion with variables and add a test before commit can be done
Hide
Permalink
Jared Erickson added a comment -
New patch with classification block extracted as a method. Andrea, I am not sure how to write a unit test for this. Could you point me in the right direction?
Show
Jared Erickson added a comment - New patch with classification block extracted as a method. Andrea, I am not sure how to write a unit test for this. Could you point me in the right direction?
Hide
Permalink
Andrea Aime added a comment -
Ah, for this one the easiest thing is to make it render an image, and then peek it in different pixels to check if the actual rendering did what you expected. Or if you have perceptual diff installed on your machine, use ImageAssert
Have a look at LineTest in the renderer module or at the last test in GeometryTransformationTest
Show
Andrea Aime added a comment - Ah, for this one the easiest thing is to make it render an image, and then peek it in different pixels to check if the actual rendering did what you expected. Or if you have perceptual diff installed on your machine, use ImageAssert Have a look at LineTest in the renderer module or at the last test in GeometryTransformationTest
Hide
Permalink
Jared Erickson added a comment -
New patch with unit test using ImageAssert and perceptualdiff. I added a method to LineTest but had to add a test dependency of process-feature to the render module. I really appreciate the help so far Andrea, let me know if I can improve this patch in any way!
Show
Jared Erickson added a comment - New patch with unit test using ImageAssert and perceptualdiff. I added a method to LineTest but had to add a test dependency of process-feature to the render module. I really appreciate the help so far Andrea, let me know if I can improve this patch in any way!
Hide
Permalink
Jared Erickson added a comment -
Just noticed that svn diff didn't include the image used in the ImageAssert unit test. This should go in src/test/resources/org/geotools/renderer/lite/test-data/line/
Show
Jared Erickson added a comment - Just noticed that svn diff didn't include the image used in the ImageAssert unit test. This should go in src/test/resources/org/geotools/renderer/lite/test-data/line/
Hide
Permalink
Andrea Aime added a comment -
Patch applied on trunk with some modifications.
The SLD buffering distance was higher than in the image, resulting in a different map, the sld file name did not match the one in the code, and the dependency from a supported module towards an unsupported one is not usable since they won't be both in the build unless you specify -Dall.
For the latter I rolled a quick buffering function that does the same work without being a process and that keeps everything in memory (good enough for testing anyways).
Show
Andrea Aime added a comment - Patch applied on trunk with some modifications. The SLD buffering distance was higher than in the image, resulting in a different map, the sld file name did not match the one in the code, and the dependency from a supported module towards an unsupported one is not usable since they won't be both in the build unless you specify -Dall. For the latter I rolled a quick buffering function that does the same work without being a process and that keeps everything in memory (good enough for testing anyways).

People

  • Assignee:
    Andrea Aime
    Reporter:
    Jared Erickson
Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: