> Andrea can I ask if this is a problem with the SLD parser; or a problem
>> with the data structures?
>>
>
> The data structures. Fixing the parser is a piece of cake.
We have already taken the Filter definition in this direction; taking the
style definition in this direction should be fine as w
johann sorel ha scritto:
> Hi, (read bellow)
>
> Andrea Aime a écrit :
>> Hi all,
>> I'm writing this mail to explore the possibility of extending
>> our current SLD support for symbolizer geometry.
>> With the current SLD 1.0 (and even with SE 1.1) we're stuck
>> with just telling the symbolizer
Hi, (read bellow)
Andrea Aime a écrit :
> Hi all,
> I'm writing this mail to explore the possibility of extending
> our current SLD support for symbolizer geometry.
> With the current SLD 1.0 (and even with SE 1.1) we're stuck
> with just telling the symbolizer which geometry attribute to
> use, a
Jody Garnett ha scritto:
> Andrea can I ask if this is a problem with the SLD parser; or a problem
> with the data structures?
The data structures. Fixing the parser is a piece of cake.
> I tried to carefully make the geometry
> operations reduce their values to two expressions; the String bas
Andrea can I ask if this is a problem with the SLD parser; or a problem with
the data structures? I tried to carefully make the geometry operations
reduce their values to two expressions; the String based PropertyName
accessors are still there; but have warnings that they only work with the
express
Hi all,
I'm writing this mail to explore the possibility of extending
our current SLD support for symbolizer geometry.
With the current SLD 1.0 (and even with SE 1.1) we're stuck
with just telling the symbolizer which geometry attribute to
use, as the element is hard coded to be a
PropertyName.
T
