Ok I see, I misunderstood your proposal. I thinked your were adding new functions (with the protocol thing) and by doing so, no fallowing the SE.
sorry. The font support for symbol is a good thing. so +1 for your proposal. Andrea Aime a écrit : > 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
