>
> Jody Garnett wrote:
>
>> Oh the reason is simple - the SLDParser has a job to do - namely parsing
>> SLD files.
>> If we are starting to work with UOM information we are looking at parsing
>> SE files.
>>
>
> Ahm, sorry, ignorant here again: isn't the SLDParser already doing lots of
> SE-specific stuff such as parsing symbolizers, marks, fills, strokes..?
Okay let me help ... about SLDParser:
- Style Layer Descriptor 1.0 defines FeatureTypeStyle, symbolizer, marks,
fills and strokes (and StyleLayerDescriptor, and NamedLayer, etc...)
- it uses Filter 1.0 for expressions
- it uses GML 2.x for geometry
- this is what SLDParser handles
- this is what there is an xml binding for as well
About the proposed SEParser or SE bindings:
- StyleLayerDescriptor was split into two: Style Layer Descriptor 1.1
(handling StyleLayerDescriptor and NamedLayer) and Symbology Encoding 1.1
(handling symbolier, makrs, fills and strokes ... and adding concepts such
as UOM)
- it uses Filter 1.1 for expressions
- it uses GML 3.x for geometry
That is what I am focused on making some new code for handling UOM; we are
parsing a new document.
Now the good news; we can start this work by copying what we have; and we
can focus on just adding UOM support since that is what you care about. At
the end of the day when 2.6 is released we can have the whole thing ready;
but we can add functionality as needed for your project.
The other good thing is that by focusing on new code you do not have to
worry about breaking code that others are already using; it allows you to be
a bit more relaxed and take your time.
> Why not UOM as well? I guess if we are to have a real SEParser, then we
> would have to move there all those SE-specific methods from the current
> SLDParser, and leave only the main methods such as "parseSLD". But that
> really doesn't look like a priority in my view: I guess it would be more
> interesting to invest in the bindings framework.
Agreed.
>
>
>
>> Here is the information from the pom.xml
>> <groupId>org.geotools.xsd</groupId>
>> <artifactId>gt-xsd-sld</artifactId>
>>
>> Does that give you the information you need?
>>
>
> YEP! Thanks a lot! Don't know why I couldn't find that one, maybe I
> misspelled the groupId when I tried that artifact.. Anyway, it would be nice
> to have that pointer in the javadoc (as in
> http://javadoc.geotools.fr/2.6/org/geotools/styling/FeatureTypeStyle.html)
>
> So, I gave it a try with a sample SLD file here and was able to see a
> number of issues, such as problems with TextSymbolizer, fills, and others.
Can you be more specific? if the binding framework is not working I would
like to know - as far as I know it is handling its test cases in
a reasonable fashion?
>
>
> I guess we will stick to the SLDParser for now, which we are more familiar
> with. I guess we just need to clarify the "copy and rename to SEParser"
> issue :) and then we can start..
>
> Hmm, final note - the SLDParser module is still using all those deprecated
> setXXX methods. I guess we wouldn't want to create a new deprecated
> setUnitOfMeasure method in all symbolizers right..? (we did that in our
> preliminary working UOM sketch). My first guess would be to add
> StyleFactory.createXXXSymbolizer methods that also receive an UOM argument.
> What do you suggest?
I have a new StyleFactoryInterface defined in geoapi; I think it already has
the UOM parameter. I am still torn on the use of setXXX methods; I
understand why it is done (so we can renderer faster); but I am considering
a hybrid approach where you can call set methods until a method "freeze" is
called at which point the set methods would call an illegalstate exception.
Jody
------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
