uDIG

LineSymbolizer width not being used in Drawing.paint()

Details

Description

When using the DrawFeatureCommand to render a LineString feature on the map, I discovered that the net.refractions.udig.ui.Drawing.paint() method does not use the width attribute of the LineSymbolizer.

Suspect code (line 289-297):
if( symb instanceof LineSymbolizer){
LineSymbolizer lineSymbolizer = (LineSymbolizer) symb;
Color c = SLDs.color( lineSymbolizer );
int w = SLDs.width( lineSymbolizer );
if( c != null && w > 0 )

{ g.setColor( c ); g.draw( shape ); }


}

Note that 'w' is not used to set the stroke width when rendering the shape.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Jesse Eichar added a comment -
width is being used
Show
Jesse Eichar added a comment - width is being used
Hide
Permalink
Mark Presling added a comment -
The width is still not being set into the SWTGraphics, and subsequently into the GC when drawing.paint() is called to render a Feature of type Line or Point.

From the beginning:
1. DrawFeatureCommand.run() calls Drawing.drawFeature()
2. Drawing.drawFeature() calls overloaded Drawing.drawFeature()
3. drawFeature() calls paint()
4. paint() checks for type of symbolizer
5. If it's a LineSymbolizer the width is retrieved from the line symbolizer
6. That width is never set into the ViewportGraphics
7. g.draw() is called to render the shape

The key thing that makes this problem visible is that I have changed the default size of the line symbolizer created by Drawing.getSymbolizers(Class type, Color baseColor) from 2 to 4 so that my road segments are rendered a bit wider than the default. This is because there is no way of setting the stroke width (or type) in the DrawFeatureCommand.

Side effects:
Setting the width with the code snippet originally supplied has a flow on effect. Calling g.setStroke(ViewportGraphics.LINE_SOLID, w) then makes all subsequent line rendering use this new width. This is most evident when you use DrawFeatureCommand to render a line of size 4 and then go and use the ruler tool. The line rendered by this tool is now 4 pixels wide.

Using the following code fixes this:
                try {
                    g.setColor( c );
                    g.setStroke(ViewportGraphics.LINE_SOLID, w);
                    g.draw( shape );
                } finally {
                    g.setStroke(ViewportGraphics.LINE_SOLID, 1);
                }

But obviously this is not elegant.

Show
Mark Presling added a comment - The width is still not being set into the SWTGraphics, and subsequently into the GC when drawing.paint() is called to render a Feature of type Line or Point. From the beginning: 1. DrawFeatureCommand.run() calls Drawing.drawFeature() 2. Drawing.drawFeature() calls overloaded Drawing.drawFeature() 3. drawFeature() calls paint() 4. paint() checks for type of symbolizer 5. If it's a LineSymbolizer the width is retrieved from the line symbolizer 6. That width is never set into the ViewportGraphics 7. g.draw() is called to render the shape The key thing that makes this problem visible is that I have changed the default size of the line symbolizer created by Drawing.getSymbolizers(Class type, Color baseColor) from 2 to 4 so that my road segments are rendered a bit wider than the default. This is because there is no way of setting the stroke width (or type) in the DrawFeatureCommand. Side effects: Setting the width with the code snippet originally supplied has a flow on effect. Calling g.setStroke(ViewportGraphics.LINE_SOLID, w) then makes all subsequent line rendering use this new width. This is most evident when you use DrawFeatureCommand to render a line of size 4 and then go and use the ruler tool. The line rendered by this tool is now 4 pixels wide. Using the following code fixes this:                 try {                     g.setColor( c );                     g.setStroke(ViewportGraphics.LINE_SOLID, w);                     g.draw( shape );                 } finally {                     g.setStroke(ViewportGraphics.LINE_SOLID, 1);                 } But obviously this is not elegant.
Hide
Permalink
Mark Presling added a comment -
That first line of my last comment should read "... a Feature of type Line" (not Point - that has already been fixed)
Show
Mark Presling added a comment - That first line of my last comment should read "... a Feature of type Line" (not Point - that has already been fixed)
Hide
Permalink
Jesse Eichar added a comment -
added a test case in DrawingTest that tests line width in line. no tests for point yet.
Show
Jesse Eichar added a comment - added a test case in DrawingTest that tests line width in line. no tests for point yet.
Hide
Permalink
Jody Garnett added a comment -
Should be easy enough to check; and I have worked with the LineString -> Shape code recently as part of hunting down SLDParser problems. In general the code is responding better to Expressions being used rather than assuming literals all the time.
Show
Jody Garnett added a comment - Should be easy enough to check; and I have worked with the LineString -> Shape code recently as part of hunting down SLDParser problems. In general the code is responding better to Expressions being used rather than assuming literals all the time.
Hide
Permalink
Andrea Antonello added a comment -
Jody, if you know the code, please look into it, I gave it a quick look ,but it takes me too long right now.
Show
Andrea Antonello added a comment - Jody, if you know the code, please look into it, I gave it a quick look ,but it takes me too long right now.

People

  • Assignee:
    Unassigned
    Reporter:
    Mark Presling
Vote (0)
Watch (1)

Dates

  • Created:
    Updated: