Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [udig-devel] ShapefileRenderer and SLDStyleFactory

Jody, I confirm you that now the renderer behaves and that the
Styleeditor is always reset to black and width=1 when opened.

Thanks for the fix,
Andrea


On Sun, Aug 31, 2008 at 12:44 AM, Jody Garnett <jgarnett@xxxxxxxxxxxxxxx> wrote:
> Andrea Antonello - I located where the problem is.
> Andrea Aime - it seams that there is more performance to tease out of
> LiteralExpression and the use of Converters
>
> andrea antonello wrote:
>>
>> Just load ANY shapefile and it will be wrong. bc_borders for example
>> will load as black lines. Th eglyph shows that it should be green
>> lines (in my case now), but the lines are black.
>>
>
> Okay I have reproduced the problem ... moving through shapefile renderer I
> noticed that (at least for the sample uDig data set bc_borders) the poor
> renderer has to skip over a lot of records (logging all the way). I wonder
> if we can clean up our data set for increased initial speed?
>
> Moving on to SLDStyleFactory (the bit of code that takes an LineSymbolizer
> and converts it to stuff we can use for painting...). Turns out the problem
> is actually here...I can watch a good Style go in and Black (the fallback
> value) gets used instead.
>
> I can watch LiteralExpression.evaulate call:
>>
>>  public Object evaluate(Object feature, Class context) {
>>        return Converters.convert(literal, context);
>>  }
>
> When the literal is "#189E77" (ie a String) a converter is supposed to step
> in and make that into a Color for us... previously the SLDParser would try
> and convert data into a Color up front when parsing; and in several cases
> the renderer assumed the color would be a literal!
>
> Now that we are actually treating this thing as a real expression we are
> finding a few bugs like this one.
>
> Andrea Aime: I noticed LiteralExpression.evaulate( feature ) is performing
> similar guesswork to what the SLDParse used to do; storing the result as a
> "parsedValue". Can I make use of your parsedValue field to store the last
> result from evaulate( feature, Class ) ?
>
> I also wonder if a few Converters (like the ColorConverter) could keep a
> WeakHashMap of previously converted values - the performance gain could be
> felt across all Expression implementations then.
>>
>> Ok, I do not think for our purposes the theme will be mandatory, but
>> perhaps than we should hide it until it isn't here again.
>
> I do not mind either way; it is an alpha release so having functionality
> from a previous release that needs fixing may entice volunteers? As an
> example our printing code was not working very well; leaving it in the
> application brought in a contract to fix it.
>
> Jody
> _______________________________________________
> User-friendly Desktop Internet GIS (uDig)
> http://udig.refractions.net
> http://lists.refractions.net/mailman/listinfo/udig-devel
>


Back to the top