johann sorel ha scritto: > Hello, > > Sorry to stop this proposal but I'm actualy working on > multiple portrayal specification i'm willing to add in GeoAPI/GeoTools > > Actually GeoTools is based on SLD style system v:1.0.0 , before making a > proposal to move > away from the OGC SLD specification I suggest we implement SLD v:1.1.0 . > SLD 1.10 has been splitted in SLD 1.1 and SE 1.1 (SE = Symbology Encoding)
And we would end up exactly in the same situation. SE 1.1 does not support what my proposal is trying to provide, the mark index is a pretty pathetic subsystite and it's a static number, not an expression. > You can know more about SE here : > http://www.opengeospatial.org/standards/symbol > So I suggest to fix geotools to handle SLD1.1 and SE 1.1 before making > any hacks. I've read the SE 1.1 specification and I fail to see how it addresses any of the proposals I'm making. Besides, look at the proposal, I'm not suggesting to change a single object in the object model nor in SLD, everything that's a URL remains a URL and everything that's a string remains a string. Not even the SLD needs to be extended. Please explain how this is a "hack", since afaik I've been playing strictly withing the limits of the standard, the only creating element is how to interpret the URLs and names that do define the symbols, I don't see the SLD/SE standard > As I said I'm working on styles : OGC SE and ISO 19117 "portrayal" and > I'll update geotools > and geoapi to fit those specifications in the coming weeks I hope. You need a very big proposal for that, since you're going to break all the API, and recode the SLDStyleFactory too. Anyways, a move to SE 1.1 that does not break backwards compatibility with SLD 1.0 is a good thing imho. > I believe SE can handle your needs by using symbolizer functions : > see : http://portal.opengeospatial.org/files/?artifact_id=16700 > Chapter : 11.6 Symbology Encoding Functions Not at all unless I'm missing something. These functions are a very welcomed addition, but from what I can see they can be used only in SvgParam. I don't see how they address the needs of stating a symbol name that does depend on the feature attributes without issuing hundreds or rules for the different possible combinations. Neither I see how they enable me to use AutoCAD hatch or a TTF font as a Mark. On the contrary, if in SE 1.1 you want to use se:OnlineResource or se:InlineContent in any way that's not a static reference in a file you'll need the same infrastructure the proposal is making up. Cheers Andrea ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
