[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [udig-devel] IStyleConfigurator & rendering : more details
|
Dear All,
After some days thinking about stylers, renderers and configurators and
some days trying to implement some solutions, I don't exactly what I
will decide to reach my needs.
I expected that several independant configurators could be declared to
set the style of a layer. Independant means that I could choose a style
based on a marker with 'simple' configurator and another based on
'external icon' and switch between them use the configurator chooser.
Each style would be persistent (a action on 'external icon' has no
effect on the configuration of 'simple') so I can easily switch from the
recorded versions of the style for a layer. When apply is pressed, the
new style is active, others are disabled.
Adding a new rule (or symbolizer) to my style leads to a dependance
between my configurator and other configurators. How to find the rule
(or symbolizer), among all, that my configurator has to modify ?
'Simple' decides it works on the first. So I could choose the second.
What will happen in the future if I want to add new configurators, I
will have to know at build time what kind of configurators will be
deployed. It is not 'plugin compliant'.
For my need, I would have prefered that the styleblackboard has an
'active' style that would be set by the configurator view on apply
button. As I do not have a view of the whole framework, I am sure that
there are good reasons that lead the current design.
So I think I will create a new CustomStyle that will encapsulate the
Style, a new CustomRenderer that will encapsulate the
BasicFeatureRenderer, a StyleContent declaring CustomStyle as
styleClass. My CustomConfigurator will update a dedicated CustomStyle.
If I have well understood, at rendering time, my layer will be rendered
twice, once by BasicFeatureRenderer, with the style defined by 'simple
configurator', and once by CustomRenderer, with the style defined by
'CustomConfigurator'.
I will still be impossible to choose the first renderer to be applied
but I think that this solution will be the one that will best fit my needs.
Another solution (for me, not for the framework) could be not to deploy
the style.sld plugin and rewrite the plugin, including external graphic.
As I am now in holidays until 03/01/06, I won't be able to continue this
interesting discussion for several days. If you think I am on a wrong
way, do not hesitate to warn me.
I send you all by best wishes of a merry Christmas.
Thank you all for your support
Vincent
Richard Gould wrote:
I am just diving into this, so forgive me if I am making any wrong
assumptions.
Jody Garnett wrote:
Vincent Nouguier wrote:
Hi,
Jesse, I am not sure the solution you suggest will fit my needs. As
far as I understand, you suggest I simply declare a new
StyleConfigurator with styleId=SLDContent.ID. In this case, my
StyleConfigurator will remove the mark that was set by the 'Simple'
styleConfigurator. When I switch to the 'simple' configurator, I
have lost my 'simple' configuration. A better behaviour would have
been to undeploy the 'simple' configurator for points and to recode
a configurator that manages all PointSymbolizer possibilities (mark,
externalGraphic and symbols). Is it possible ? Is it discouraged ?
Jody, I am not familiar with layers and the rendering process, so it
is quite confusing for me. I don't understand what I have to do
(what extension to use) in order my layer being rendered twice. Your
suggestions leads me to the following questions: What is the
expected behaviour when a user uses two style configurators, the
layer is displayed with the style defined by the last configurator?
Right now the expected behavior is that Basic Renderer would engage
twice, once for each style.
Um, wouldn't it be dependant on the renderer? For example, my WMS
could use two StyleConfigurators at once (say one was SLD, the other
was relating to WMS options - file format or something).
If the two StyleConfigurators operate on the same Style, wouldn't one
just over-write the other? The StyleBlackboard only has support for
one object per ID. The two StyleConfigurators would have to operate on
the ideology of editing existing styles, rather than creating new ones.
Or is it rendered as the overlay of both styles?
I think the styles would be combined at the rule level .. but we
would need to check.
In this case, how do we define the rendering order?
That is indeed the issue, the style blackboard is unordered - do you
have any suggestions? This seems to be a gap in the approach, I
expected a single StyleLayerDescriptor instance on the blackboard.
I don't understand how I can use this 'double rendering' mecanism in
order to achieve my goal if I don't declare a new StyleClass and so
a new Renderer (what I would like to avoid).
What would be the best is if you can set up your StyleConfigurator to
edit the same SLD style that the BasicStyleConfigurator does. I am
out of time right now, but will ask Richard to fill in the details.
I think Jody is trying to say that your StyleConfigurator should edit
the existing SLD style, rather than creating a new one (and
over-writing the previous values)?
Richard
_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel
